Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

["John W. Linville" <linville@tuxdriver.com>]

On Wed, Mar 26, 2014 at 07:10:31AM -0400, Neil Horman wrote:
> On Tue, Mar 25, 2014 at 04:56:38PM -0400, Jamal Hadi Salim wrote:

> > I think i am with you mostly - just not on the visibility of a "master"
> > device.
> > Expose the ports. Users create bridges bonds and if the hardware is
> > capable it does the hard work to ensure consistency. No change in tools.
> > 
> But by creating net_devices that are registered in the current fashion we
> implicitly agree to levels of functionality that are assumed to be available and
> as such are not within the purview of a net_device to reject.  E.g. it is
> assumed that a netdevice can filter frames using iptables/ebtables, limit
> traffic using tc, etc. And if a switch fabric is short cutting traffic so that
> the cpu doesn't see them, those bits of functionality won't work.  I agree we
> can likely work around that with richer feature capabilities, but such an
> infrastructure would both require extensive kernel changes to fully cover the
> set of existing features at a sufficient granularity, and require user space
> changes to grok the feature set of a given device.  Not saying its impossibible
> or even undesireable mind you, just thats its not any less invasive than what
> I'm proposing.

Some of this sounds akin to the old (but true) arguments against TOE
hardware.  But as Thomas suggests, I think most of this disappears
if you give the driver the chance to implement such rules and/or fall
back to software-only forwarding.

While I'm sure there will be significant kernel changes to allow
for some of that, I think that by putting that intelligence in the
drivers we can avoid most/all of the user space changes for groking
device features.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.