[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131107071531.GA31857@gondor.apana.org.au>
Date: Thu, 7 Nov 2013 15:15:31 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Ben Hutchings <bhutchings@...arflare.com>,
David Miller <davem@...emloft.net>,
christoph.paasch@...ouvain.be, netdev@...r.kernel.org,
hkchu@...gle.com, mwdalton@...gle.com
Subject: Re: gso: Attempt to handle mega-GRO packets
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.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists