netdev - Re: [patch net-next RFC v2 0/6] 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]

Message-ID: <CAGVrzcYE9uuD0Gxd5-OND4p5ieikYFchhpBm=ZiK5GaMqiQVyA@mail.gmail.com>
Date:	Thu, 27 Mar 2014 09:27:58 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	dborkman <dborkman@...hat.com>, ogerlitz <ogerlitz@...lanox.com>,
	jesse <jesse@...ira.com>, pshelar <pshelar@...ira.com>,
	azhou <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>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	John Linville <linville@...driver.com>,
	dev <dev@...nvswitch.org>
Subject: Re: [patch net-next RFC v2 0/6] introduce infrastructure for support
 of switch chip datapath

2014-03-27 4:02 GMT-07:00 Thomas Graf <tgraf@...g.ch>:
> On 03/27/14 at 06:27am, Jamal Hadi Salim wrote:
>> On 03/27/14 03:21, Jiri Pirko wrote:
>> >Wed, Mar 26, 2014 at 10:44:31PM CET, jhs@...atatu.com wrote:
>>
>> >Well, I think there are 2 main models to be considered:
>> >1. OSV-like model, where everything is flows and that is the OneWay(tm)
>> >    mode you mentioned :)
>> >2. clasic switch setting-like model where you manually set up vlans,
>> >    lag, whatever.
>> >
>> >The phase one for me is 1. and that is what I'm trying to resolve with
>> >this patchset.
>> >
>> > From what I understand from the discussion, 2. is likely the model you
>> >have in mind.
>> >
>>
>> In my opinion there is no difference when setting the ACL table(s).
>> We are going to need your .ndo for more than flows. Something
>> in the stack is going to have to talk to those .ndo interfaces
>> (I keep bringing up the concept of routing code for example).
>> What i meant by no OneWay is i think it will depend on the
>> chip - some will require more work than other. I do believe it
>> is a longer discussion needed than the port resolving.
>
> There is definitely need beyond an ndo that is capable of
> adding flows. You mention routes. Another example would be
> devices capable of offloading iptables & nft rules.

Those devices usually require (at least for Broadcom) an entity
identifying the flows and uploading flows offloading rules to the
hardware. Although I do not think it hurts to keep those in mind to
come up with the right design, my feeling is that they will require
more intrusive modifications at the socket, route and forwarding path
level if we want the Linux kernel to offer a consistent API across
different hardware variations.

It is not clear to me at this point whether we want those special
offloading devices to appear as separate net_device with specific
flags to advertise their offloading features (NAT, IP routing...) or
something else?

>
> But wouldn't you want to introduce an additional ndo to
> cover these?

I would start with making sure everyone is on the same page regarding
switches before we start building the conversation on NAT/IP-routing
offloading, but it is good that you mention it.

>
> What speaks against going with what Jiri proposes and adjust
> & extend as needed as we go along?


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