[lkml]   [2010]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [RFC PATCH 2/2] macvtap: TX zero copy between guest and host kernel
    >From: Arnd Bergmann []
    >Sent: Tuesday, September 14, 2010 11:21 PM
    >To: Shirley Ma
    >Cc: Avi Kivity; David Miller;; Xin, Xiaohui;;
    >Subject: Re: [RFC PATCH 2/2] macvtap: TX zero copy between guest and host kernel
    >On Tuesday 14 September 2010, Shirley Ma wrote:
    >> On Tue, 2010-09-14 at 11:12 +0200, Avi Kivity wrote:
    >> > That's what io_submit() is for. Then io_getevents() tells you what
    >> > "a
    >> > while" actually was.
    >> This macvtap zero copy uses iov buffers from vhost ring, which is
    >> allocated from guest kernel. In host kernel, vhost calls macvtap
    >> sendmsg. macvtap sendmsg calls get_user_pages_fast to pin these buffers'
    >> pages for zero copy.
    >> The patch is relying on how vhost handle these buffers. I need to look
    >> at vhost code (qemu) first for addressing the questions here.
    >I guess the best solution would be to make macvtap_aio_write return
    >-EIOCBQUEUED when a packet gets passed down to the adapter, and
    >call aio_complete when the adapter is done with it.
    >This would change the regular behavior of macvtap into a model where
    >every write on the file blocks until the packet has left the machine,
    >which gives us better flow control, but does slow down the traffic
    >when we only put one packet at a time into the queue.
    >It also allows the user to call io_submit instead of write in order
    >to do an asynchronous submission as Avi was suggesting.

    But currently, this patch is communicated with vhost-net, which is almost
    in the kernel side. If it uses aio stuff, it should be communicate with user
    space Backend.

    > Arnd

     \ /
      Last update: 2010-09-15 03:59    [W:0.027 / U:54.912 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site