Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-16 Thread Shirley Ma
On Mon, 2012-05-14 at 21:39 +0300, Michael S. Tsirkin wrote:
  Hello Mike,
  
  Have you tested this patch? I think the difference between macvtap
 and
  tap is tap forwarding the packet to bridge. The zerocopy is disabled
 in
  this case.
  
  Shirley
 
 Testing in progress, but the patchset I pointed to enables
 zerocopy with bridge. 

Hello Mike,

You meant this patch or another patchset for enabling bridge zerocopy?

I remembered we disabled forward skb zerocopy since the user space
program might hold the buffers too long or forever.

In tap/bridge case, when the tx buffers will be released?

Thanks
Shirley

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-16 Thread Michael S. Tsirkin
On Wed, May 16, 2012 at 08:16:55AM -0700, Shirley Ma wrote:
 On Mon, 2012-05-14 at 21:39 +0300, Michael S. Tsirkin wrote:
   Hello Mike,
   
   Have you tested this patch? I think the difference between macvtap
  and
   tap is tap forwarding the packet to bridge. The zerocopy is disabled
  in
   this case.
   
   Shirley
  
  Testing in progress, but the patchset I pointed to enables
  zerocopy with bridge. 
 
 Hello Mike,
 
 You meant this patch or another patchset for enabling bridge zerocopy?
 
 I remembered we disabled forward skb zerocopy since the user space
 program might hold the buffers too long or forever.
 
 In tap/bridge case, when the tx buffers will be released?
 
 Thanks
 Shirley

It still fails some tests for me but maybe I'll post the whole
patchset so you can see how it works.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-15 Thread Shirley Ma
On Mon, 2012-05-14 at 22:31 +0300, Michael S. Tsirkin wrote:
 On Mon, May 14, 2012 at 09:21:47PM +0200, Eric Dumazet wrote:
  On Mon, 2012-05-14 at 22:14 +0300, Michael S. Tsirkin wrote:
  
   They seem to be in net-next, or did I miss something?
  
  Yes, you re-introduce in this patch some bugs already fixed in
 macvtap
 
 Could explain why I see some problems in testing :)
 Maybe common code should go into net/core?
 I couldn't decide whether the increase in kernel
 size is worth it.

Which problem you hit during testing?

The logic of zerocopy_sg_from_iovec should work well. Jason's fix made
the code more clear.

Thanks
Shirley

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Stephen Hemminger
On Sun, 13 May 2012 18:52:06 +0300
Michael S. Tsirkin m...@redhat.com wrote:

 + /* Userspace may produce vectors with count greater than
 +  * MAX_SKB_FRAGS, so we need to linearize parts of the skb
 +  * to let the rest of data to be fit in the frags.
 +  */
Rather than complex partial code, just go through slow path for
requests with too many frags (or for really small requests).
Creating mixed skb's seems too easy to get wrong.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Michael S. Tsirkin
On Mon, May 14, 2012 at 09:54:46AM -0700, Stephen Hemminger wrote:
 On Sun, 13 May 2012 18:52:06 +0300
 Michael S. Tsirkin m...@redhat.com wrote:
 
  +   /* Userspace may produce vectors with count greater than
  +* MAX_SKB_FRAGS, so we need to linearize parts of the skb
  +* to let the rest of data to be fit in the frags.
  +*/
 Rather than complex partial code, just go through slow path for
 requests with too many frags (or for really small requests).
 Creating mixed skb's seems too easy to get wrong.

I don't object in principle but macvtap has same code
so seems better to stay consistent.

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Shirley Ma
On Sun, 2012-05-13 at 18:52 +0300, Michael S. Tsirkin wrote:
 Let vhost-net utilize zero copy tx when the experimental
 zero copy mode is enabled and when used with tun.  This works on
 top of the patchset 'copy aside frags with destructors' that I posted
 previously. This is not using tcp so doesn't have the
 issue with early skb cloning noticed by Ian.
 
 For those that wish to test this with kvm, I intend to post a patchset
 +
 git tree with just the necessary bits from the destructor patch
 a bit later.
 
 Signed-off-by: Michael S. Tsirkin m...@redhat.com 

Hello Mike,

Have you tested this patch? I think the difference between macvtap and
tap is tap forwarding the packet to bridge. The zerocopy is disabled in
this case.

Shirley

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Michael S. Tsirkin
On Mon, May 14, 2012 at 10:34:50AM -0700, Shirley Ma wrote:
 On Sun, 2012-05-13 at 18:52 +0300, Michael S. Tsirkin wrote:
  Let vhost-net utilize zero copy tx when the experimental
  zero copy mode is enabled and when used with tun.  This works on
  top of the patchset 'copy aside frags with destructors' that I posted
  previously. This is not using tcp so doesn't have the
  issue with early skb cloning noticed by Ian.
  
  For those that wish to test this with kvm, I intend to post a patchset
  +
  git tree with just the necessary bits from the destructor patch
  a bit later.
  
  Signed-off-by: Michael S. Tsirkin m...@redhat.com 
 
 Hello Mike,
 
 Have you tested this patch? I think the difference between macvtap and
 tap is tap forwarding the packet to bridge. The zerocopy is disabled in
 this case.
 
 Shirley

Testing in progress, but the patchset I pointed to enables
zerocopy with bridge.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Eric Dumazet
On Mon, 2012-05-14 at 20:04 +0300, Michael S. Tsirkin wrote:
 On Mon, May 14, 2012 at 09:54:46AM -0700, Stephen Hemminger wrote:
  On Sun, 13 May 2012 18:52:06 +0300
  Michael S. Tsirkin m...@redhat.com wrote:
  
   + /* Userspace may produce vectors with count greater than
   +  * MAX_SKB_FRAGS, so we need to linearize parts of the skb
   +  * to let the rest of data to be fit in the frags.
   +  */
  Rather than complex partial code, just go through slow path for
  requests with too many frags (or for really small requests).
  Creating mixed skb's seems too easy to get wrong.
 
 I don't object in principle but macvtap has same code
 so seems better to stay consistent.
 

If I remember well, code in vtap was buggy and still is.

Jason Wang fixes are not yet in, so maybe wait a bit, so that we dont
add a pile of new bugs ?




--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Michael S. Tsirkin
On Mon, May 14, 2012 at 09:02:26PM +0200, Eric Dumazet wrote:
 On Mon, 2012-05-14 at 20:04 +0300, Michael S. Tsirkin wrote:
  On Mon, May 14, 2012 at 09:54:46AM -0700, Stephen Hemminger wrote:
   On Sun, 13 May 2012 18:52:06 +0300
   Michael S. Tsirkin m...@redhat.com wrote:
   
+   /* Userspace may produce vectors with count greater than
+* MAX_SKB_FRAGS, so we need to linearize parts of the 
skb
+* to let the rest of data to be fit in the frags.
+*/
   Rather than complex partial code, just go through slow path for
   requests with too many frags (or for really small requests).
   Creating mixed skb's seems too easy to get wrong.
  
  I don't object in principle but macvtap has same code
  so seems better to stay consistent.
  
 
 If I remember well, code in vtap was buggy and still is.
 
 Jason Wang fixes are not yet in,

They seem to be in net-next, or did I miss something?

 so maybe wait a bit, so that we dont
 add a pile of new bugs ?
 
 
 
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Michael S. Tsirkin
On Mon, May 14, 2012 at 10:14:56PM +0300, Michael S. Tsirkin wrote:
 On Mon, May 14, 2012 at 09:02:26PM +0200, Eric Dumazet wrote:
  On Mon, 2012-05-14 at 20:04 +0300, Michael S. Tsirkin wrote:
   On Mon, May 14, 2012 at 09:54:46AM -0700, Stephen Hemminger wrote:
On Sun, 13 May 2012 18:52:06 +0300
Michael S. Tsirkin m...@redhat.com wrote:

 + /* Userspace may produce vectors with count greater than
 +  * MAX_SKB_FRAGS, so we need to linearize parts of the 
 skb
 +  * to let the rest of data to be fit in the frags.
 +  */
Rather than complex partial code, just go through slow path for
requests with too many frags (or for really small requests).
Creating mixed skb's seems too easy to get wrong.
   
   I don't object in principle but macvtap has same code
   so seems better to stay consistent.
   
  
  If I remember well, code in vtap was buggy and still is.
  
  Jason Wang fixes are not yet in,
 
 They seem to be in net-next, or did I miss something?
 
  so maybe wait a bit, so that we dont
  add a pile of new bugs ?
  
  

Things progress smoother upstream than out of tree
is my experience.

Also everything is guarded by a mod param in vhost
which is off by default and the name
experimental_zcopytx makes it hopefully clear there's
risk involved.

So the chance of hurting someone is imo minimal.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Eric Dumazet
On Mon, 2012-05-14 at 22:14 +0300, Michael S. Tsirkin wrote:

 They seem to be in net-next, or did I miss something?

Yes, you re-introduce in this patch some bugs already fixed in macvtap



--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] tun: experimental zero copy tx support

2012-05-14 Thread Michael S. Tsirkin
On Mon, May 14, 2012 at 09:21:47PM +0200, Eric Dumazet wrote:
 On Mon, 2012-05-14 at 22:14 +0300, Michael S. Tsirkin wrote:
 
  They seem to be in net-next, or did I miss something?
 
 Yes, you re-introduce in this patch some bugs already fixed in macvtap

Could explain why I see some problems in testing :)
Maybe common code should go into net/core?
I couldn't decide whether the increase in kernel
size is worth it.

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html