Re: gso: Attempt to handle mega-GRO packets

Herbert Xu
2013-11-07T07:17:49Z

On Thu, Nov 07, 2013 at 03:15:31PM +0800, Herbert Xu wrote:
> On Wed, Nov 06, 2013 at 11:11:02PM -0800, Eric Dumazet wrote:
> > On Thu, 2013-11-07 at 08:43 +0800, Herbert Xu wrote:
> >
> > > - if (fskb != skb_shinfo(skb)->frag_list)
> > > - goto perform_csum_check;
> > > + if (fskb != skb_shinfo(skb)->frag_list) {
> > > + struct sk_buff *nsegs;
> > > +
> > > + if (nskb->len == len + doffset)
> > > + goto perform_csum_check;
> > > +
> > > + if (skb_has_frag_list(nskb)) {
> > > + net_warn_ratelimited(
> > > + "skb_segment: "
> > > + "nested frag_list detected\n");
> > > + kfree(nskb);
> > > + err = -EINVAL;
> > > + goto err;
> > > + }
> > > +
> > > + __skb_pull(nskb, doffset);
> > > + skb_shinfo(nskb)->gso_size = mss;
> > > + nsegs = skb_segment(nskb, features);
> > > +
> >
> > This still assumes each skb found in frag_list has a exact multiple of
> > @mss bytes, and that the initial skb also ends at a right boundary.
>
> So what in our stack violates this assumption? We've never handled
> arbitrary frag_lists in GSO and I see no reason why we need to start
> doing that now.
>
> Also GRO was designed to only merge packets that satisfy these
> assumptions so that through GSO the original packets can be
> recovered without losing end-to-end connectivity. This is really
> important for routers/switches.

Or perhaps you are saying that this doesn't handle page frags?
It should because each GRO frag_list entry looks just like any
boring old GSO packet filled with frags.

Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt