GRO after RPS?

GRO after RPS?

[David Miller]

Herbert, after thinking about some ideas we've been discussing and
some suggestions from folks like Tom Herbert, I'm thinking of changing
it such that we do GRO after RPS sends the packet to a remove cpu.

The idea being that, this way, if we have a device provided ->rxhash
we can elide touching the packet headers entirely.

Initially I wanted to defer the eth_type_trans() by adding a state bit
to sk_buff, and making ->ndo_type_trans() a new netdev op.  The state
bit exists so that we can have a transition period and avoid doing
the type_trans multiple times if the driver still does it early.

So, in this way, when RPS doesn't even need to touch the packet
headers, due to a device provided skb->rxhash, we can defer the
type_trans all the way to the remote cpu.

The only thing getting in the way of this is GRO, since it wants to
parse the packet headers too for flow matching.

At first I thought this was a bad idea to defer GRO to the remote cpu,
since if we do batch things up it means we have less packets to queue
up to the remote cpu.

But upon further consideration it doesn't matter, because GRO is going
to fuddle with the packets and link them up into a list anyways.

So if the list handling is a wash, then it's a real win to defer GRO
and thus potentially all packet header touching to the remote cpu.

Also, we can add the quick ->rxhash check to the GRO flow matcher
like we discussed several times in the past.  And guess what?  Now
that RPS runs first, we'll always have a valid skb->rhash available
for this purpose since RPS will compute one in software for us :-)

So Herbert, any objections before I start hacking on this?

Re: GRO after RPS?

[Herbert Xu]

On Sun, Apr 25, 2010 at 05:09:33PM -0700, David Miller wrote:
> 
> Herbert, after thinking about some ideas we've been discussing and
> some suggestions from folks like Tom Herbert, I'm thinking of changing
> it such that we do GRO after RPS sends the packet to a remove cpu.

Actually, I'd've thought that doing GRO before RPS would be a
better solution as it means that RPS would have a lot less work
to do.

> The idea being that, this way, if we have a device provided ->rxhash
> we can elide touching the packet headers entirely.

Yes not touching the headers was also the plan for GRO, I just
never got around to it.  So we would only examine a packet if
its hash matched one already processed in the current NAPI window.

Of course we'd need to change the way we currently store packets
in GRO and use a data structure more efficient than a linked list.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: GRO after RPS?

[David Miller]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 26 Apr 2010 08:49:34 +0800

> On Sun, Apr 25, 2010 at 05:09:33PM -0700, David Miller wrote:
>> 
>> Herbert, after thinking about some ideas we've been discussing and
>> some suggestions from folks like Tom Herbert, I'm thinking of changing
>> it such that we do GRO after RPS sends the packet to a remove cpu.
> 
> Actually, I'd've thought that doing GRO before RPS would be a
> better solution as it means that RPS would have a lot less work
> to do.

Either GRO walks the skb->rxhash values one by one, or GRO does, the
cost is going to be roughly equivalent I think.

And when the packets do match, you can't just trust the ->rxhash in
the GRO code, since a hash match only indicates that the packets might
have the same flow.  So you're going to have to touch the packet
headers in that case on the pre-RPS cpu.

The goal is to eliminate all packet header references from the pre-RPS
path, and let the post-RPS cpu do it.

Re: GRO after RPS?

[Changli Gao]

On Mon, Apr 26, 2010 at 9:17 AM, David Miller <davem@davemloft.net> wrote:
>
> The goal is to eliminate all packet header references from the pre-RPS
> path, and let the post-RPS cpu do it.

If the NIC doesn't provide rxhash, RPS will have to compute one by one
by itself. Is the hash computation more expensive than GRO? I think
the hash computation is cheaper than GRO, so we can do RPS ASAP to
avoid the direct CPU overload.

-- 
Regards，
Changli Gao(xiaosuo@gmail.com)

Re: GRO after RPS?

[Herbert Xu]

On Mon, Apr 26, 2010 at 09:40:35AM +0800, Changli Gao wrote:
> On Mon, Apr 26, 2010 at 9:17 AM, David Miller <davem@davemloft.net> wrote:
> >
> > The goal is to eliminate all packet header references from the pre-RPS
> > path, and let the post-RPS cpu do it.
> 
> If the NIC doesn't provide rxhash, RPS will have to compute one by one
> by itself. Is the hash computation more expensive than GRO? I think
> the hash computation is cheaper than GRO, so we can do RPS ASAP to
> avoid the direct CPU overload.

The dominating cost will be pulling the memory into cache.  So
once you do that the cost of GRO will be negligible.

As I said, if we had hardware rxhashes, we can change GRO to only
pull in the header when we're likely to have a match.

When we do get a mergeable flow, the difference between doing
GRO before/after RPS is going to be redirecting 1 packet vs.
~100 packets.

So if RPS is so cheap that it's able to process 100 packets at
a cost tantamount to 1 packet, then sure we should postpone GRO.

Otherwise I think GRO before RPS is definitely a win.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: GRO after RPS?

[Herbert Xu]

On Sun, Apr 25, 2010 at 06:17:57PM -0700, David Miller wrote:
>
> Either GRO walks the skb->rxhash values one by one, or GRO does, the
> cost is going to be roughly equivalent I think.

(I presume one of those GROs is meant to be RPS).
Right, in fact if we could combine the two it would be even better.

> And when the packets do match, you can't just trust the ->rxhash in
> the GRO code, since a hash match only indicates that the packets might
> have the same flow.  So you're going to have to touch the packet
> headers in that case on the pre-RPS cpu.

Yes, if the rxhash matches then we need to examine the packet
header.  However, in that case the packet will most likely turn
out to be a GRO candidate, meaning that you have to do one fewer
RPS lookup/redirection.

Besides, the place where you need GRO most is where the hardware
doesn't do it directly.  That same hardware is probably not going
to give you a hash either.  When if we have to touch the packet
header, it would be beneficial to do GRO while it's still hot.

> The goal is to eliminate all packet header references from the pre-RPS
> path, and let the post-RPS cpu do it.

So if we changed GRO to use hardware hashes, then the only case
where it would touch the packet header unnecessarily is when we
get a hash collision.

In all other cases the header would only be touched in case we
have a hash match, which will most likely result in a merging.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt