Message-ID: <20140327172048.GC13573@casper.infradead.org>
Date:	Thu, 27 Mar 2014 17:20:48 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Florian Fainelli <f.fainelli@...il.com>
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

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.

> 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