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] [day] [month] [year] [list]

Date:	Sat, 17 May 2008 02:14:30 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Stephen Hemminger" <shemminger@...tta.com>
Cc:	"Jeff Garzik" <jgarzik@...ox.com>,
	"David Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: RE: [PATCH 1/3] ixgbe: Add Data Center Bridging netlink listener for DCB runtime changes.

> I wonder if doing this generically with existing bridge code would
> be a better approach. It seems like the TOE problem all over again,
> only this time it is Traffic Control offload. Sorry, just because
> you can do it in hardware doesn't mean it is a good thing.

How is this anything like TOE?  We're not bypassing the stack, we're not
inserting any exit points in the stack, it's just another way the
hardware can schedule traffic internally to itself.  But there needs to
be a mechanism to configure it.  We have 4 options.  1) Do nothing.
This is very unattractive for 10 GbE devices, especially since a number
of 10 GbE devices have fairly complex and useful Tx and Rx advanced
features.  2) Insert these commands into ethtool.  This doesn't make
much sense, since most drivers around won't need these entry points to
the driver.  3) Embed the interface in the driver.  Jeff G. made a good
point that this isn't sustainable for the future, which I agree with.
This is a new standard in ethernet, so we should make the generic
interface.  4) Make the generic interface captured in the design doc
from the previous email from me in this thread.

All I'm proposing is 9 entry points into the drivers via netlink for
device configuration.  I'm not asking for a stack rewrite or insertion
into the stack to bypass the existing stack.

Cheers,
-PJ Waskiewicz
--
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