From: Eric Dumazet <redacted>
Date: Sat, 29 Mar 2014 21:28:21 -0700

From: Eric Dumazet <edumazet@google.com>

Main difference between napi_frags_skb() and napi_gro_receive() is that
the later is called while ethernet header was already pulled by the NIC
driver (eth_type_trans() was called before napi_gro_receive())

Jerry Chu in commit 299603e8370a ("net-gro: Prepare GRO stack for the
upcoming tunneling support") tried to remove this difference by calling
eth_type_trans() from napi_frags_skb() instead of doing this later from
napi_frags_finish()

Goal was that napi_gro_complete() could call 
ptype->callbacks.gro_complete(skb, 0)  (offset of first network header =
0)

Also, xxx_gro_receive() handlers all use off = skb_gro_offset(skb) to
point to their own header, for the current skb and ones held in gro_list

Problem is this cleanup work defeated the frag0 optimization:
It turns out the consecutive pskb_may_pull() calls are too expensive.

This patch brings back the frag0 stuff in napi_frags_skb().

As all skb have their mac header in skb head, we no longer need
skb_gro_mac_header()

Reported-by: Michal Schmidt <redacted>
Fixes: 299603e8370a ("net-gro: Prepare GRO stack for the upcoming tunneling support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jerry Chu <redacted>
---
David, this patch is definitely risky, I targeted net-next for staging
it. I tested it with mlx4 NIC.

BTW, I believe the BUG_ON(skb->end - skb->tail < grow); could trigger
if the headers are bigger than what the driver allocated for skb->head.

After encapsulation support added by Jerry, this might happen ?

We probably need to tweak skb_gro_reset_offset() to cap frag0_len to
force calling slow path. I'll cook a patch.

Ok, applied, thanks for taking care of this Eric.

We can send to -stable after it's gotten a lot of testing and
auditing.