"Michael S. Tsirkin" <m...@redhat.com> writes: > On Thu, Feb 21, 2013 at 10:15:58AM -0600, Anthony Liguori wrote: >> "Michael S. Tsirkin" <m...@redhat.com> writes: >> >> > On Thu, Feb 21, 2013 at 08:54:44PM +0800, Liu Ping Fan wrote: >> >> This is a emulation to virtio-blk dataplane, which push the data >> >> handling out of biglock. And it is a try to implement this process >> >> in userspace, while vhost-net in kernel. >> > >> > What's the motivation for doing this? >> >> I haven't looked carefully at the patches, but I don't think we should >> "cheat" when it comes to virtio-net. I think it's useful to have a >> baseline proof of concept but I think we should focus on making the >> network layer re-entrant. >> >> In terms of why even bother, if we can make virtio-net a viable >> alternative to vhost-net, it's a huge win. Being in userspace is a huge >> advantage. >> >> I understand the challenges with zero-copy but we really need a proper >> userspace implementation to determine how much it really matters. >> Zero-copy tap is also not entirely outside the realm of possibility. > > This is exactly what we have, vhost-net is the interface we use > for asynchronous communication. If you want to add yet another > asynchronous interface in kernel, it's certainly doable but then what's > the point? > >> >> The iperf's result show it improving the perfermance of base line, >> >> but still slower than vhost-net (maybe the rx path need optimized). >> >> >> >> Todo: >> >> implement fine lock for net-subsystem >> > >> > vhost-net is currently the only way to get zero copy transmit >> > on linux (and zero copy receive in the future) >> > so at least in theory it'll always be faster. >> >> It might always be faster. But that doesn't mean we should limit the >> performance of virtio-net in userspace. Some people may be willing to >> take a small performance hit in order to obtain the security offered by >> being in userspace. >> >> Regards, >> >> Anthony Liguori > > By 'being in userspace' I presume you mean the ring processing code.
I mean that: 1) the same code path is used regardless of network backend 2) QEMU has the ability to manipulate the traffic if it needs/wants to 3) the state of the device model is userspace at all times 4) QEMU is always the front-line interface communicating with the guest Yes, this could be a model where -netdev vhost-net was the backend used by QEMU. > Ring processing can be done in userspace if you are ready > to use the synchronous read/write operations, skipping > this bunch of code might improve security. But it requires a data > copy almost by definition. Not sure what you mean here. If you are talking about read/write on a tap file descriptor, I'm not even suggesting that. I'm perfectly fine with vhost-net being a -netdev backend. But that's a very different model than how we use it today. Regards, Anthony Liguori > > >> > >> >> Liu Ping Fan (9): >> >> vring: split the modification and publish of used ring >> >> vring: introduce vring_restore() to restore from img >> >> event poll: make epoll work for normal fd >> >> event poll: pass event type to event callback >> >> event poll: enable event poll handle more than one event each time >> >> virtio net: introduce dataplane for virtio net >> >> tap: make tap peer work on dedicated data-plane thread >> >> virtio net: enable dataplane for virtio net >> >> configure: make virtio net dataplane configurable >> >> >> >> configure | 12 ++ >> >> hw/dataplane/Makefile.objs | 4 +- >> >> hw/dataplane/event-poll.c | 69 +++++-- >> >> hw/dataplane/event-poll.h | 14 ++- >> >> hw/dataplane/virtio-blk.c | 8 +- >> >> hw/dataplane/virtio-net.c | 444 >> >> ++++++++++++++++++++++++++++++++++++++++++++ >> >> hw/dataplane/virtio-net.h | 32 ++++ >> >> hw/dataplane/vring.c | 37 ++++ >> >> hw/dataplane/vring.h | 3 + >> >> hw/virtio-net.c | 94 +++++----- >> >> hw/virtio-net.h | 64 +++++++ >> >> hw/virtio-pci.c | 2 +- >> >> include/net/tap.h | 6 + >> >> net/tap.c | 92 +++++++++- >> >> 14 files changed, 806 insertions(+), 75 deletions(-) >> >> create mode 100644 hw/dataplane/virtio-net.c >> >> create mode 100644 hw/dataplane/virtio-net.h >> >> >> >> -- >> >> 1.7.4.4 >> >>
