netdev - Re: [PATCH 1/3] ixgbe: Add Data Center Bridging netlink listener for DCB runtime changes.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 07 May 2008 17:13:29 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH 1/3] ixgbe: Add Data Center Bridging netlink listener
 for DCB runtime changes.

Waskiewicz Jr, Peter P wrote:
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html