Sowmini.Varadhan at Sun.COM 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
