[EMAIL PROTECTED] wrote:
A couple of observations pertaining to the libnwam header changes
proposed in
http://cr.grommit.com/~jbeck/renee-nwam1-ln2/
- NWAM is considering the mtu as a configurable property, but it should
be clarified that this is just the IP mtu (set via SIOCSLIFMTU) and
not the driver mtu (which would have to be modified separately to
configure Jumbo Frames). In order to modify the latter via NWAM,
the changes being implemented by the Brussels project will be needed.
- At least for the near future, we will have two daemons: nwamd and
linkmgmtd, that both do some sort of "setprop" for configuring link
properties. It also looks like the definition of what is a link
property is subjective: NWAM does not configure link speed/duplex
etc., but does look at mtu, whereas linkmgmtd's focus appears to be
link-aggregations.
While the design documents for linkmgmtd and related API's do emphasis
aggregations, that's because we decided to EOL
/etc/dladm/aggregation.conf as part of the Project Clearview work. The
code and the API should be generic enough to handle any link properties.
Having 2 daemons that do very similar property management makes
things a bit hairy for a project like Brussels: there are now two
setprop functions that will need to be examined to see if they
need to leverage from Brussels enhancements.
I realize that the two projects are approaching the problem from
different ends of the stack (bottom and top) but one hopes that
the two paths will meet somehwere in the future.
I hope so too. The NWAM folks and I had a private conversation about
this, and at the time, we didn't think it would not be too hard to
convert the API's I'm working on as part of vanity naming to do things
that the NWAM team would like. We didn't see it as a priority at the
time, so we didn't pursue it. I hope that it is still not to hard to
convert the code over.
Dan
_______________________________________________
networking-discuss mailing list
[email protected]
