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

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, 26 Mar 2014 08:19:47 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Neil Horman <nhorman@...driver.com>
CC:	Thomas Graf <tgraf@...g.ch>, Jiri Pirko <jiri@...nulli.us>,
	Florian Fainelli <f.fainelli@...il.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, andy@...yhouse.net,
	dborkman@...hat.com, ogerlitz@...lanox.com, jesse@...ira.com,
	pshelar@...ira.com, azhou@...ira.com,
	Ben Hutchings <ben@...adent.org.uk>,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support
 of switch chip datapath

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

> 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.

More like my response to Roopa: there are things that can be tied to 
ports and others are not.
This is where i think we need more discussion - I believe that
the offload model offered by current bridging is a good starting point
for things tied to ports. In that setup, something in the netlink header
says "give me stuff that is in the hardware" or "set this to the fdb
table in the kernel as well as in the hardware".
That is the part i like - and that concept, although tied to ports in
the case of bridging, applies generically.
Most of these things tend to be in the form of a table abstraction in
the chip.
If i add a FIB where the tie to a port is weak (occassionaly the nexthop
tie may be to a port), I should still be able to use the same method.
If this request shows up in the kernel, mechanisms are needed to shunt
it to said driver.

> And if a switch fabric is short cutting traffic so that
> the cpu doesn't see them, those bits of functionality won't work.

Separate control from data. What i am refering about is control.
Datapath and what shows up in the CPU is dependent on what gets set in
the hardware.

> 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.

We would need to change some things - but i think it is a small
evolution (as opposed to a revolution).

cheers,
jamal

--
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