Re: [RFC] GRO scalability

Eric Dumazet
2012-10-08T17:56:00Z

On Mon, 2012-10-08 at 10:49 -0700, Rick Jones wrote:

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

I didnt said "flush queued packets older than N packets" but instead
suggested to use a time limit, eventually a sysctl.

"flush packet if the oldest part of it is aged by xxx us"

Say the default would be 500 us

If your hardware is capable of receiving 2 packets per us, this would
allow 1000 packets in GRO queue. So using a hash table with 128 slots,
and keeping the current limit of 8 entries per bucket would allow this
kind of workload.

If your hardware is capable of receiving one packet per us, this would
allow 50 packets in GRO queue.