On Thu, Jul 2, 2015 at 9:50 PM, Eric Dumazet <[email protected]> wrote: > On Thu, 2015-07-02 at 14:04 -0700, Tom Herbert wrote: >> When setting up the first skb in a gro list we ensure that all the >> headers up to skb_gro_offset have been pulled into head. In subsequent >> uses of this skb (e.g. determining same_flow) it is assumed that the >> headers can be accessed in the skb head. >> >> Signed-off-by: Tom Herbert <[email protected]> >> --- >> net/core/dev.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/net/core/dev.c b/net/core/dev.c >> index 6778a99..05e0e37 100644 >> --- a/net/core/dev.c >> +++ b/net/core/dev.c >> @@ -4228,6 +4228,10 @@ static enum gro_result dev_gro_receive(struct >> napi_struct *napi, struct sk_buff >> } else { >> napi->gro_count++; >> } >> + >> + /* Ensure all headers are pulled into head for 1st skb */ >> + skb_gro_header_slow(skb, skb_gro_offset(skb), 0); >> + >> NAPI_GRO_CB(skb)->count = 1; >> NAPI_GRO_CB(skb)->age = jiffies; >> NAPI_GRO_CB(skb)->last = skb; > > I do not see how we can reach this point without having headers already > pulled. > > For example, tcp_gro_receive() has : > > off = skb_gro_offset(skb); > hlen = off + sizeof(*th); > th = skb_gro_header_fast(skb, off); > if (skb_gro_header_hard(skb, hlen)) { > th = skb_gro_header_slow(skb, hlen, off); > if (unlikely(!th)) > goto out; > } > > So by definition, skb is put in gro_list only if it was fully validated as a > GRO > candidate. > That code will access the data from fragments if possible, the skb_gro_header_slow is what pulls the data into head. In tcp_gro_receive we do tcp_hdr(p) on the 1st skbuf in a gro list so it is assumed there that the headers have been pulled into head.
> Given the complexity of your 2nd patch, I am stopping the review right > now. > > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
