Re: Flows! Offload them.

[Jamal Hadi Salim <jhs@mojatatu.com>]

On 03/01/15 09:05, Neil Horman wrote:
> On Sun, Mar 01, 2015 at 09:36:43AM +0000, Arad, Ronen wrote:
>>

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


Sounds sane as a starting point. Lets just talk L3 since this applies
to any tcam approach (and expense of repeating things already discussed)
For hook #2 Dave proposes in other email to just flush everything and do
things in s/ware at that point for initial implementation.

[Most people would try to aggregate  things into a /24 for example to
make space for more /32s. And theres all sorts of crazy shit to amortize
tcam space that people do]

But this brings in another requirement: CCing the Mellanox folks who
brought up this  issue numerous times.
Things tend to "freeze" at that point while the kernel is madly moving
things around (as would be the case with Dave's suggested "move all
to software"). At netdev01, Aviad was suggesting that the kernel
respond first with a netlink message "work in progress" or even lie
with "success" if it knows it will accomplish this goal.
Ccing Sol who had a different reason for waiting seconds long for things
to be inserted into hardware.


cheers,
jamal