Re: [RFC] GRO scalability

Rick Jones
2012-10-08T17:49:17Z

On 10/08/2012 09:59 AM, Eric Dumazet wrote:
> On Mon, 2012-10-08 at 09:40 -0700, Rick Jones wrote:
>> Whe I say shuffle I mean something along the lines of interleave. So,
>> if we have four flows, 1-4, a perfect shuffle of their segments would be
>> something like:
>>
>> 1 2 3 4 1 2 3 4 1 2 3 4
>>
>> but not well shuffled might look like
>>
>> 1 1 3 2 3 2 4 4 4 1 3 2
>>
>
> If all these packets are delivered in the same NAPI run, and correctly
> aggregated, their order doesnt matter.
>
> In first case, we will deliver B1, B2, B3, B4 (B being a GRO packet
> with 3 MSS)
>
> In second case we will deliver
>
> B1 B3 B2 B4

So, with my term shuffle better defined, let's circle back to your
proposal to try to GRO-service a very much larger group of flows, with a
"flush queued packets older than N packets" heuristic as part of the
latency minimization. If N were 2 there - half the number of flows, the
"perfect" shuffle" doesn't get aggregated at all right? N would have to
be 4 or the number of concurrent flows. What I'm trying to get at is
just to how many concurrent flows you are trying to get GRO to scale,
and whether at that level you have asymptotically approached having a
hash/retained state that is, basically, a duplicate of what is happening
in TCP.

rick