edhat.com; mi...@elte.hu; herb...@gondor.apana.org.au;
>jd...@linux.intel.com
>Subject: RE: [PATCH v15 00/17] Provide a zero-copy method on KVM virtio-net.
>
>>-Original Message-
>>From: David Miller [mailto:da...@davemloft.net]
>>Sent: Thursday, Nov
apana.org.au;
>jd...@linux.intel.com
>Subject: Re: [PATCH v15 00/17] Provide a zero-copy method on KVM virtio-net.
>
>From: xiaohui@intel.com
>Date: Wed, 10 Nov 2010 17:23:28 +0800
>
>> From: Xin Xiaohui
>>
>>>2) The idea to key off of skb->dev in skb_release_data()
From: xiaohui@intel.com
Date: Wed, 10 Nov 2010 17:23:28 +0800
> From: Xin Xiaohui
>
>>2) The idea to key off of skb->dev in skb_release_data() is
>> fundamentally flawed since many actions can change skb->dev on you,
>> which will end up causing a leak of your external data areas.
>
> H
From: Xin Xiaohui
>2) The idea to key off of skb->dev in skb_release_data() is
> fundamentally flawed since many actions can change skb->dev on you,
> which will end up causing a leak of your external data areas.
How about this one? If the destructor_arg is not a good candidate,
then I have
From: xiaohui@intel.com
Date: Tue, 9 Nov 2010 17:03:05 +0800
> We provide an zero-copy method which driver side may get external
> buffers to DMA. Here external means driver don't use kernel space
> to allocate skb buffers. Currently the external buffer can be from
> guest virtio-net driver.
