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.
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.
The idea is simple, just to pin the guest VM user space and then
let host
