Date:	Mon, 25 Aug 2014 12:15:30 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Thomas Graf <tgraf@...g.ch>
CC:	John Fastabend <john.fastabend@...il.com>,
	Scott Feldman <sfeldma@...ulusnetworks.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@...ira.com, pshelar@...ira.com, azhou@...ira.com,
	ben@...adent.org.uk, stephen@...workplumber.org,
	jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
	xiyou.wangcong@...il.com, john.r.fastabend@...el.com,
	edumazet@...gle.com, f.fainelli@...il.com,
	roopa@...ulusnetworks.com, linville@...driver.com,
	dev@...nvswitch.org, jasowang@...hat.com, ebiederm@...ssion.com,
	nicolas.dichtel@...nd.com, ryazanov.s.a@...il.com,
	buytenh@...tstofly.org, aviadr@...lanox.com, nbd@...nwrt.org,
	alexei.starovoitov@...il.com, Neil.Jerram@...aswitch.com,
	ronye@...lanox.com
Subject: Re: [patch net-next RFC 10/12] openvswitch: add support for datapath
 hardware offload

On 08/25/14 10:17, Thomas Graf wrote:
> On 08/25/14 at 09:53am, Jamal Hadi Salim wrote:

> fdb_add() *is* flow based. At least in my understanding, the whole
> point here is to extend the idea of fdb_add() and make it understand
> L2-L4 in a more generic way for the most common protocols.
>
> The reason fdb_add() is not reused is because it is Netlink specific
> and only suitable for User -> HW offload. Kernel -> HW offload is
> technically possible but not clean.
>

I dont think we have a problem handling any of this today.


> The only reason swdev is needed at all is to represent the port model
> and to allow for non flow based models built on top of the same
> hardware abstraction. I see now reason why br_fdb cannot be represented
> through swdev as soon as the code is stable.
>

This is where our (shall i say strong) disagreement is.
I think you will find it non-trivial to show me how you can
actually take the simple L2 bridge and map it to a "flow".
Since your starting point is "everything can be represented via a flow
and some table" - we are at a crosspath.

> The point I was trying to make earlier is that it is very hard to
> program both protocol aware and generic filtering hardware through
> a single NDO. It will make the driver specific part complex.
>

The tc filter API seems to be doing just that.
You have different types of classifiers - the h/w may not be able
to support some classifier types - but that is a capability discovery
challenge.

> If you are saying we need yet another classifier model in the kernel
> then I'm not sure that is needed in the presence of cls/act, iptables,
> and nftables. They seem suitable to represent non flow based models
> and I see nothing that would prevent an offload through swdev for them.
>

I am saying two things:
1) There are a few "fundamental" interfaces; L2 and L3 being some.
Add crypto offload and a few i mentioned in  my presentation. We
know how to do those. example; there is nothing i cant do with
the rtmsg that is L3. or the fdb/port/vlan filter for L2.
This flow thing should stay out of those.

2) The flow thing should allow a variety of classifiers to be
handled. Again capability discovery would take care of differences.

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

Powered by blists - more mailing lists