From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: gso: Attempt to handle mega-GRO packets Date: Wed, 06 Nov 2013 17:08:08 -0800 Message-ID: <1383786488.2878.18.camel@edumazet-glaptop2.roam.corp.google.com> References: <1383499603.4291.71.camel@edumazet-glaptop2.roam.corp.google.com> <20131104041108.GA22823@gondor.apana.org.au> <20131106013038.GA14894@gondor.apana.org.au> <20131106123900.GA20259@gondor.apana.org.au> <20131106133045.GA20931@gondor.apana.org.au> <20131106143927.GA21604@gondor.apana.org.au> <1383767241.21999.9.camel@edumazet-glaptop2.roam.corp.google.com> <1383783321.2878.6.camel@edumazet-glaptop2.roam.corp.google.com> <20131107004704.GB28156@gondor.apana.org.au> <1383785763.2878.8.camel@edumazet-glaptop2.roam.corp.google.com> <20131107010037.GA28421@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Ben Hutchings , David Miller , christoph.paasch@uclouvain.be, netdev@vger.kernel.org, hkchu@google.com, mwdalton@google.com To: Herbert Xu Return-path: Received: from mail-qe0-f45.google.com ([209.85.128.45]:44192 "EHLO mail-qe0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751235Ab3KGBIM (ORCPT ); Wed, 6 Nov 2013 20:08:12 -0500 Received: by mail-qe0-f45.google.com with SMTP id 8so337343qea.4 for ; Wed, 06 Nov 2013 17:08:11 -0800 (PST) In-Reply-To: <20131107010037.GA28421@gondor.apana.org.au> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 2013-11-07 at 09:00 +0800, Herbert Xu wrote: > On Wed, Nov 06, 2013 at 04:56:03PM -0800, Eric Dumazet wrote: > > On Thu, 2013-11-07 at 08:47 +0800, Herbert Xu wrote: > > > On Wed, Nov 06, 2013 at 04:15:21PM -0800, Eric Dumazet wrote: > > > > > > > > Here is the patch I came into (I tested it and it works very fine) > > > > > > Thanks. However, unless I'm missing something aren't you now > > > copying every linear skb frag_list? With the current code we > > > just do a clone and add the headers. > > > > No copy at all. > > > > As explained, all RX skb are now backed to a page frag. (see > > skb->head_frag) > > Even if we have called pskb_expand_head on it? Well, in this case we pulled only the headers in skb->head. Only few buggy drivers do a pull of say 64 bytes in skb->head before calling eth_type_trans() so could possibly have a few bytes of TCP payload in skb->head And this case is handled without copy.