Waskiewicz Jr, Peter P wrote:
quoted text
> I've given this much more thought, and have some additional feedback.
> While I see your point about each driver wanting to support DCB
> shouldn't have to create their own netlink interface, having the ioctl's
> in ethtool for every other driver not supporting DCB isn't necessary
> either.  I understand there are commands in ethtool that some drivers
> don't implement, but the required commands for DCB would add a pretty
> decent chunk of code into ethtool.  But for other advanced features
> today, many drivers implement sysfs interfaces to support tweaking of
> values outside of the ethtool umbrella.  Given this is less than a
> driver-only configuration tool, but it's a tool that is configuring the
> behavior of the entire network, we need one userspace tool that can
> communicate to all registered devices, and netlink lends itself well to
> that.
> 
> I also looked at Thomas' proposal, and it does look fine.  However, we'd
> have the same issue of needing to implement all the DCB commands in
> ethtool, which I'm still not totally convinced is the correct thing to
> do, given how the DCB stack from userspace to the link partner works.
> 
> Our long-term goal is to implement the dcbd (userspace daemon) interface
> in the kernel as a module interface, so the userspace commands interact
> with it and only it directly.  Much like the mac80211 interface, which
> the dcbd interface in the kernel would push the commands to registered
> drivers through a common kernel interface, most likely through the
> netdev.  We're not there yet, but we need to step before we run.  Hence
> why the driver is using netlink today.


If its complex enough, or doesn't fit the ioctl model well, it doesn't 
necessarily have to be via the ethtool ioctl.

Two goals I have, though, are

* the userspace ethtool utility configures this stuff.  Note I did /not/ 
say "must use ethtool ioctl."  The core idea behind ethtool is to 
centralize NIC-specific knowledge -- thus that's the place where 
chip-specific register dumping code resides.  So within reason, it's OK 
to put DCB-specific commands into ethtool that do not use the ethtool ioctl.

But like everything else in life, one must weight various costs.  Maybe 
it is complex enough to warrant a new tool.  We don't know until there's 
a design doc or review of the generic interface that will be used for DCB.

* the kernel portion can be used by other non-Intel drivers, i.e. a 
generic and separate piece.  We should not be embedding an entire 
netlink interface into each driver.

Regards,

	Jeff



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html