Date:	Thu, 27 Mar 2014 18:26:00 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	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

Thu, Mar 27, 2014 at 06:20:48PM CET, tgraf@...g.ch wrote:
>On 03/27/14 at 09:27am, Florian Fainelli wrote:
>> 2014-03-27 4:02 GMT-07:00 Thomas Graf <tgraf@...g.ch>:
>> > 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.
>
>I absolutely agree. This is where the challenging bits start to
>appear ;-) I don't want to speak for Jiri but my understanding is
>that the flow focused approach early on is entirely because it is
>the easiest case to solve. Taking OVS as an example has the
>advantage of already being guarded by OpenFlow abstraction which
>by nature is very device oriented.

Yep, exactly.

>
>> 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?
>
>One lesson that could serve as an example which differs from TOE is
>the offloading provided by recent FC HBAs. The device looks like a
>regular SCSI device to the kernel but offers a full DCB engine to
>allow for FCoE. The DCB bits can and must be configured. By not
>representing that engine with a net_device we cannot configure the
>engine through the Netlink interface dcbnl. dcbnl can certainly be
>extended to allow taking a scsi id of some sort instead of a ifindex
>but it's far from ideal.
>
>My take on this is that if it makes sense to use rtnl or ethtool
>to configure these offload engines then let's just go with a
>globally visible net_device and improve our capabilities system.
>
>> > 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.
>
>Agreed
--
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

Powered by blists - more mailing lists