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?messageID=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
