Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752077Ab0F1J4Q (ORCPT ); Mon, 28 Jun 2010 05:56:16 -0400 Received: from mga09.intel.com ([134.134.136.24]:61841 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751398Ab0F1J4N convert rfc822-to-8bit (ORCPT ); Mon, 28 Jun 2010 05:56:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.53,496,1272870000"; d="scan'208";a="530906554" From: "Xin, Xiaohui" To: Herbert Xu , "Dong, Eddie" CC: Stephen Hemminger , "netdev@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "mst@redhat.com" , "mingo@elte.hu" , "davem@davemloft.net" , "jdike@linux.intel.com" Date: Mon, 28 Jun 2010 17:56:07 +0800 Subject: RE: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. Thread-Topic: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. Thread-Index: AcsVwBTk585FagDAS/G7saLFpDwf8gA32TNw Message-ID: References: <20100611052112.GA25649@gondor.apana.org.au> <20100617112119.GB1515@gondor.apana.org.au> <1A42CE6F5F474C41B63392A5F80372B21F58CD9A@shsmsx501.ccr.corp.intel.com> <20100623095254.GA32491@gondor.apana.org.au> <1A42CE6F5F474C41B63392A5F80372B21F58CE7F@shsmsx501.ccr.corp.intel.com> <20100624100836.GA16220@gondor.apana.org.au> <1A42CE6F5F474C41B63392A5F80372B21F58D666@shsmsx501.ccr.corp.intel.com> <20100627061455.GA16782@gondor.apana.org.au> In-Reply-To: <20100627061455.GA16782@gondor.apana.org.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2592 Lines: 57 >-----Original Message----- >From: Herbert Xu [mailto:herbert@gondor.apana.org.au] >Sent: Sunday, June 27, 2010 2:15 PM >To: Dong, Eddie >Cc: Xin, Xiaohui; Stephen Hemminger; netdev@vger.kernel.org; kvm@vger.kernel.org; >linux-kernel@vger.kernel.org; mst@redhat.com; mingo@elte.hu; davem@davemloft.net; >jdike@linux.intel.com >Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. > >On Fri, Jun 25, 2010 at 09:03:46AM +0800, Dong, Eddie wrote: >> >> In current patch, each SKB for the assigned device (SRIOV VF or NIC or a complete >queue pairs) uses the buffer from guest, so it eliminates copy completely in software and >requires hardware to do so. If we can have an additonal place to store the buffer per skb (may >cause copy later on), we can do copy later on or re-post the buffer to assigned NIC driver >later on. But that may be not very clean either :( > >OK, if I understand you correctly then I don't think have a >problem. With your current patch-set you have exactly the same >situation when the skb->data is reallocated as a kernel buffer. > When will skb->data to be reallocated? May you point me the code path? >This is OK because as you correctly argue, it is a rare situation. > >With my proposal you will need to get this extra external buffer >in even less cases, because you'd only need to do it if the skb >head grows, which only happens if it becomes encapsulated. >So let me explain it in a bit more detail: > >Our packet starts out as a purely non-linear skb, i.e., skb->head >contains nothing and all the page frags come from the guest. > >During host processing we may pull data into skb->head but the >first frag will remain unless we pull all of it. If we did do >that then you would have a free external buffer anyway. > >Now in the common case the header may be modified or pulled, but >it very rarely grows. So you can just copy the header back into >the first frag just before we give it to the guest. > Since the data is still there, so recompute the page offset and size is ok, right? >Only in the case where the packet header grows (e.g., encapsulation) >would you need to get an extra external buffer. > >Cheers, >-- >Email: Herbert Xu >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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/