Date:	Sun, 1 Mar 2015 09:05:47 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	"Arad, Ronen" <ronen.arad@...el.com>
Cc:	Thomas Graf <tgraf@...g.ch>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Simon Horman <simon.horman@...ronome.com>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	Jiri Pirko <jiri@...nulli.us>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"andy@...yhouse.net" <andy@...yhouse.net>,
	"dborkman@...hat.com" <dborkman@...hat.com>,
	"ogerlitz@...lanox.com" <ogerlitz@...lanox.com>,
	"jesse@...ira.com" <jesse@...ira.com>,
	"jpettit@...ira.com" <jpettit@...ira.com>,
	"joestringer@...ira.com" <joestringer@...ira.com>,
	"jhs@...atatu.com" <jhs@...atatu.com>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
	"linville@...driver.com" <linville@...driver.com>,
	"shrijeet@...il.com" <shrijeet@...il.com>,
	"gospo@...ulusnetworks.com" <gospo@...ulusnetworks.com>,
	"bcrl@...ck.org" <bcrl@...ck.org>
Subject: Re: Flows! Offload them.

On Sun, Mar 01, 2015 at 09:36:43AM +0000, Arad, Ronen wrote:
> 
> 
> >-----Original Message-----
> >From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On
> >Behalf Of Thomas Graf
> >Sent: Friday, February 27, 2015 12:42 AM
> >To: Neil Horman
> >Cc: Simon Horman; Fastabend, John R; Jiri Pirko; netdev@...r.kernel.org;
> >davem@...emloft.net; andy@...yhouse.net; dborkman@...hat.com;
> >ogerlitz@...lanox.com; jesse@...ira.com; jpettit@...ira.com;
> >joestringer@...ira.com; jhs@...atatu.com; sfeldma@...il.com;
> >f.fainelli@...il.com; roopa@...ulusnetworks.com; linville@...driver.com;
> >shrijeet@...il.com; gospo@...ulusnetworks.com; bcrl@...ck.org
> >Subject: Re: Flows! Offload them.
> >
> >Blind random offload of some packets is better than nothing but knowing
> >and having control over which packets are offloaded is essential. You
> >typically don't want to randomly give one flow priority over another ;-)
> >Some software CPUs might not be able to handle the load. I know what
> >you mean though and as long as we allow to disable and overwrite this
> >behaviour we are good.
> >
> 
> Random offloading of flows does not preserve policy in general.
> For example let's consider two flows A.B.C.0/24 and A.B.C.D with the more
> specific rule has higher priority.
> If only the first rule is offloaded to HW, packets matched by the second
> rule will not be processed as expected by the user.
> Deciding which flow could be offloaded is an optimization decision that
> is better handled outside of the kernel. 
>   
Regarding the description of offload:
Random is I think a improper term here.  There is nothing random about flow
offload.  There is only the reality of needing to select which rules to offload,
as it is inevitable that hardware dataplane capacity won't/can't match that of
software limits.  All we can do is select which of those flows are offloaded.
When dealing with offload in the context of an existing sofware function, the
constraints of selecting which rules those are become fairly clear.  For example
with routing:
1) More specific rules get offloaded first
2) on overflow, you replace a rule that conforms to a pre-packaged policy (ex.
LRU), and iff it doesn't violate (1)
Theres nothing random about that.  The selection policy can make replacement as
deterministic as you like (though if you're more interested in just offloading
functionality, determinism of rules is less important, than just optimizing the
performance of the offloaded function within the above constraints).

Regarding offload selection:
I disagree.  you're correct when the key match is a multiple word tuple that has
no real context with in the kernel, but for the case you describe (l3
forwarding), the policy can be made fairly clearly.  All you need to do is
offload the more specific rule first.  Thats it.  If that doesn't give you the
offload performance you're looking for because theres not space for both rules
in the hw dataplane, too bad, thats the limitation of doing a kernel-function
mirroring to the hardware.  Hopefully that will get better as hardware dataplane
capacity improves.  Until then, thats what Johns Flow API is for.  It should
live in parallel with such a functional offload, so that if those limitations
are unacceptable to you, you can go off the reservation, and customize the
hardware behavior.

Neil

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