Following up on past discussions about extending Brussels
for the TCP/IP layer-
An earlier proposal was:
ipadm
|
ifconfig----------. | .- newer CLI's
V V V
.-------------> libipadm <-----> smf
repository
| ^ ^
ndd | |
| | user
--------------|---------------|-------------------------
| |
kernel
| |
V V
get/set tunable restore settings.
where legacy invocations via ifconfig and ndd would not
modify the smf repository (i.e., no persistence) whereas
using
ipadm and any newer CLI's would update the smf repository.
One important difference from dladm is that since IP is
never
unloaded, we have different design constraints on restoring
the
saved settings.
Some open questions here:
- Let's say that we have some tool /sbin/ipadm which follows
the
invocation model of dladm. /sbin/dladm operates on links.
What object do we want ipadm to operate on? One proposal
is
something like
/sbin/ipadm <verb>-<noun>
<name>=<val> [<link>:]<proto>
where bge0:tcp or bge0:ip would indicate tcp/ip plumbed
over bge0,
and the absence of a link specification implies "all
links".
other alternative suggestions are welcome, since I realize
that CVUV
adds several degrees of freedom to link names- maybe the
link should
be specified with a -l parameter, i.e.,
/sbin/ipadm <verb>-<noun> [-l <link>]
<name>=<val> <proto>
with the absence of the -l arg implying "all
links".
I'm not sure if it makes sense to customize every protocol
parameter
per link (e.g., it doesn't make sense to talk about
tcp_smallest_anon_port on a per-link basis). For these
parameters,
ipadm would have to enforce that the implied link was
"all links".
- Restoring the values: although we have some simplicity
compared
to the dladm-driver interaction because IP is never
unloaded, there
is still the complexity of *when* to set parameters. In
the rc*.d
model, this was trivially determined by where the
ndd/ifconfig/etc.
invocation was placed in the rc*d sequence, but the smf
model is
not as straight-forward. There are some parameters such as
tcp_smallest_anon_port whose effect can vary widely
depending on
when the saved setting is restored. Much water has gone
under this
bridge; see:
http://www.opensolaris.org/jive/thread.jspa?mess
ageID=24434&
So if we divide the parameters into:
1. global parameters that apply to all modules,
2. datalink specific parameters to be applied before the
link starts
(addressed by dladm/dlmgmtd)
3. datalink specific parameters to be applied after the
interface is up
and Layer 3 services are plumbed
One proposal is to apply parameters under #1 as part of
a
network/physical:default service, and those under #3 as
part of a
network/ip:<link> service.
As Jim Carlson pointed out, one flaw in this approach is
that the
networking module (e.g., ip) is loaded into the kernel
well before
the service starts, and is running without the
customizations that
will be applied by the service. So, for example, the
network/physical
service my try to set tcp_smallest_anon_port to 40000, but
some
daemon started earlier (by some service that runs before
network/physical) may already have grabbed port 38000,
making the
tcp_smallest_anon_port meaningless.
Ideally we would be able to read the relevant smf settings
from
ip_ddi_init() itself, but as has already been encountered
in Brussels
in the past, there are no Interfaces to push smf settings
into the
kernel. Using a daemon in this case is full of its own
problems-
ip_ddi_init is called before any daemons are spawned
(before init is
started). So at least at this time, we have to settle for
the next
best approximation of associating smf-parameter settings
with the
start of smf network services.
Thoughts? Comments?
--Sowmini
_______________________________________________
nwam-discuss mailing list
nwam-discuss opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss
|