On Mon, Jun 28, 2010 at 05:56:07PM +0800, Xin, Xiaohui wrote:
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
;
jd...@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
...@vger.kernel.org; m...@redhat.com; mi...@elte.hu;
da...@davemloft.net;
jd...@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
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
On Fri, Jun 25, 2010 at 09:03:46AM +0800, Dong, Eddie wrote:
Herbert Xu wrote:
On Wed, Jun 23, 2010 at 06:05:41PM +0800, Dong, Eddie wrote:
I mean once the frontend side driver post the buffers to the backend
driver, the backend driver will immediately use that buffers to
compose skb
On Wed, Jun 23, 2010 at 06:05:41PM +0800, Dong, Eddie wrote:
I mean once the frontend side driver post the buffers to the backend driver,
the backend driver will immediately use that buffers to compose skb or
gro_frags and post them to the assigned host NIC driver as receive buffers.
In
Herbert Xu wrote:
On Wed, Jun 23, 2010 at 06:05:41PM +0800, Dong, Eddie wrote:
I mean once the frontend side driver post the buffers to the backend
driver, the backend driver will immediately use that buffers to
compose skb or gro_frags and post them to the assigned host NIC
driver as
]
Sent: Thursday, June 24, 2010 6:09 PM
To: Dong, Eddie
Cc: Xin, Xiaohui; Stephen Hemminger; net...@vger.kernel.org;
kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; m...@redhat.com; mi...@elte.hu;
da...@davemloft.net;
jd...@linux.intel.com
Subject: Re: [RFC PATCH v7 01/19] Add a new structure
3) As I have mentioned above, with this idea, netdev_alloc_skb() will
allocate
as usual, the data pointed by skb-data will be copied into the first
guest buffer.
That means we should reserve sufficient room in guest buffer. For PS
mode
supported driver (for example ixgbe), the room will
Herbert Xu wrote:
On Wed, Jun 23, 2010 at 04:09:40PM +0800, Dong, Eddie wrote:
Xiaohui Herbert:
Mixing copy of head 0-copy of bulk data imposes additional
challange to find the guest buffer. The backend driver may be
unable to find a spare guest buffer from virtqueue at that
On Wed, Jun 23, 2010 at 04:09:40PM +0800, Dong, Eddie wrote:
Xiaohui Herbert:
Mixing copy of head 0-copy of bulk data imposes additional challange
to find the guest buffer. The backend driver may be unable to find a spare
guest buffer from virtqueue at that time which may block the
On Sun, Jun 20, 2010 at 01:06:32PM +0300, Michael S. Tsirkin wrote:
Changing the guest virtio to match the backend is a problem,
this breaks migration etc.
As long as it's done in a backwards compatible way it should be
fine. It's just like migrating from a backend that supports TSO
to one
On Sun, Jun 20, 2010 at 08:32:35PM +1000, Herbert Xu wrote:
On Sun, Jun 20, 2010 at 01:06:32PM +0300, Michael S. Tsirkin wrote:
Changing the guest virtio to match the backend is a problem,
this breaks migration etc.
As long as it's done in a backwards compatible way it should be
fine.
On Sun, Jun 20, 2010 at 01:39:09PM +0300, Michael S. Tsirkin wrote:
It's just like migrating from a backend that supports TSO
to one that doesn't.
Exactly. We don't support such migration.
Well that's something that has to be addressed in the virtio_net.
Cheers,
--
Visit Openswan at
On Sun, Jun 20, 2010 at 09:02:54PM +1000, Herbert Xu wrote:
On Sun, Jun 20, 2010 at 01:39:09PM +0300, Michael S. Tsirkin wrote:
It's just like migrating from a backend that supports TSO
to one that doesn't.
Exactly. We don't support such migration.
Well that's something that has
On Sun, Jun 20, 2010 at 02:11:24PM +0300, Michael S. Tsirkin wrote:
Rather than modifying all guests, it seems much easier not to assume
specific buffer layout in host. Copying network header around seems a
small cost.
Well sure we can debate the specifics of this implementation detail.
On Sun, Jun 20, 2010 at 02:47:19PM +0300, Michael S. Tsirkin wrote:
Let's do this then. So far the virtio spec avoided making layout
assumptions, leaving guests lay out data as they see fit.
Isn't it possible to keep supporting this with zero copy for hardware
that can issue DMA at arbitrary
On Sun, Jun 20, 2010 at 09:59:26PM +1000, Herbert Xu wrote:
On Sun, Jun 20, 2010 at 02:47:19PM +0300, Michael S. Tsirkin wrote:
Let's do this then. So far the virtio spec avoided making layout
assumptions, leaving guests lay out data as they see fit.
Isn't it possible to keep supporting
On Sun, 2010-06-20 at 21:59 +1000, Herbert Xu wrote:
On Sun, Jun 20, 2010 at 02:47:19PM +0300, Michael S. Tsirkin wrote:
Let's do this then. So far the virtio spec avoided making layout
assumptions, leaving guests lay out data as they see fit.
Isn't it possible to keep supporting this
On Fri, Jun 18, 2010 at 01:26:49PM +0800, Xin, Xiaohui wrote:
Herbert,
I have questions about the idea above:
1) Since netdev_alloc_skb() is still there, and we only modify alloc_page(),
then we don't need napi_gro_frags() any more, the driver's original receiving
function is ok. Right?
...@linux.intel.com; Rusty Russell
Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from
external.
On Fri, Jun 18, 2010 at 01:26:49PM +0800, Xin, Xiaohui wrote:
Herbert,
I have questions about the idea above:
1) Since netdev_alloc_skb() is still there, and we only modify alloc_page
On Fri, Jun 18, 2010 at 03:14:18PM +0800, Xin, Xiaohui wrote:
Thanks for the verification. By the way, does that mean that nearly all
drivers can use the
same napi_gro_frags() to receive buffers though currently each driver has
it's own receiving
function?
There is no reason why the
On Sat, Jun 12, 2010 at 05:31:10PM +0800, Xin, Xiaohui wrote:
1) Modify driver from netdev_alloc_skb() to alloc user pages if dev is
zero-copyed.
If the driver support PS mode, then modify alloc_page() too.
Well if you were doing this then the driver won't be generating
skbs at all. So
On Sun, Jun 13, 2010 at 04:58:36PM +0800, Xin, Xiaohui wrote:
Herbert,
In this way, I think we should create 3 functions at least in drivers to
allocate rx buffer, to receive the rx buffers, and to clean the rx buffers.
We can also have another way here. We can provide a function to only
...@elte.hu;
da...@davemloft.net;
jd...@linux.intel.com
Subject: RE: [RFC PATCH v7 01/19] Add a new structure for skb buffer from
external.
-Original Message-
From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
Sent: Friday, June 11, 2010 1:21 PM
To: Xin, Xiaohui
Cc: Stephen Hemminger
...@linux.intel.com
Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from
external.
On Wed, Jun 09, 2010 at 05:54:02PM +0800, Xin, Xiaohui wrote:
I'm not sure if I understand your way correctly:
1) Does the way only deal with driver with SG feature? Since packet
is non-linear
;
jd...@linux.intel.com
Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from
external.
Still not sure this is a good idea for a couple of reasons:
1. We already have lots of special cases with skb's (frags and fraglist),
and skb's travel through a lot of different parts
...@elte.hu;
da...@davemloft.net;
herb...@gondor.apana.org.au; jd...@linux.intel.com
Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from
external.
Stephen Hemminger shemmin...@vyatta.com writes:
Still not sure this is a good idea for a couple of reasons:
1. We already have lots
;
herb...@gondor.apana.org.au; jd...@linux.intel.com
Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from
external.
On Jun 7, 2010, at 12:51 AM, Andi Kleen wrote:
Stephen Hemminger shemmin...@vyatta.com writes:
Still not sure this is a good idea for a couple of reasons
...@linux.intel.com
Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from
external.
On Sun, Jun 06, 2010 at 04:13:48PM -0700, Stephen Hemminger wrote:
Still not sure this is a good idea for a couple of reasons:
1. We already have lots of special cases with skb's (frags and fraglist
Stephen Hemminger shemmin...@vyatta.com writes:
Still not sure this is a good idea for a couple of reasons:
1. We already have lots of special cases with skb's (frags and fraglist),
and skb's travel through a lot of different parts of the kernel. So any
new change like this creates
On Jun 7, 2010, at 12:51 AM, Andi Kleen wrote:
Stephen Hemminger shemmin...@vyatta.com writes:
Still not sure this is a good idea for a couple of reasons:
1. We already have lots of special cases with skb's (frags and fraglist),
and skb's travel through a lot of different parts of the
On Sun, Jun 06, 2010 at 04:13:48PM -0700, Stephen Hemminger wrote:
Still not sure this is a good idea for a couple of reasons:
1. We already have lots of special cases with skb's (frags and fraglist),
and skb's travel through a lot of different parts of the kernel. So any
new change
Still not sure this is a good idea for a couple of reasons:
1. We already have lots of special cases with skb's (frags and fraglist),
and skb's travel through a lot of different parts of the kernel. So any
new change like this creates lots of exposed points for new bugs. Look
at cases
From: Xin Xiaohui xiaohui@intel.com
Signed-off-by: Xin Xiaohui xiaohui@intel.com
Signed-off-by: Zhao Yu yzhao81...@gmail.com
Reviewed-by: Jeff Dike jd...@linux.intel.com
---
include/linux/skbuff.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git
35 matches
Mail list logo
