On Wed, 2016-01-20 at 17:47 -0800, Jesse Gross wrote:
> Just to merge the two threads together, all of protocols that would be
> affected by this also have "normal" GRO handlers that will run when
> the packet is first received. There's no argument that that is
> preferable if it is available. However, GRO cells do provide a
> performance benefit in other situations so it would be nice to avoid
> disabling it if possible.
Note that having a second stage GRO can introduce packet reorders,
because GRO packets given to the second layer simply bypass GRO engine.
Say sender sends P1,P2,P3
Receiver gets P1 alone, put P1 in the GRO cell (2nd layer)
Then we get P2 and P3, aggregated by first layer.
We decap tunnel header, then give P2-P3 to 2nd GRO engine, P2-P3 is
directly given to upper stack. [1]
Then P1 will follow later.
-> packets received out of order. Slow paths on both senders and
receiver, extra sack, ...
[1]
static enum gro_result dev_gro_receive(struct napi_struct *napi, struct
sk_buff *skb)
{
...
if (!(skb->dev->features & NETIF_F_GRO))
goto normal;
if (skb_is_gso(skb) || skb_has_frag_list(skb) || skb->csum_bad)
goto normal;
