Michael S. Tsirkin wrote: > As I'm new to qemu/kvm, to figure out how networking performance can be improved, I > went over the code and took some notes. As I did this, I tried to record ideas > from recent discussions and ideas that came up on improving performance. Thus > this list. > > This includes a partial overview of networking code in a virtual environment, with > focus on performance: I'm only interested in sending and receiving packets, > ignoring configuration etc. > > I have likely missed a ton of clever ideas and older discussions, and probably > misunderstood some code. Please pipe up with corrections, additions, etc. And > please don't take offence if I didn't attribute the idea correctly - most of > them are marked mst by I don't claim they are original. Just let me know. > > And there are a couple of trivial questions on the code - I'll > add answers here as they become available. > > I out up a copy at http://www.linux-kvm.org/page/Networking_Performance as > well, and intend to dump updates there from time to time. > Hi Michael, Not sure if you have seen this, but I've already started to work on the code for in-kernel devices and have a (currently non-virtio based) proof-of-concept network device which you can for comparative data. You can find details here: http://lkml.org/lkml/2009/4/21/408 <snip> (Will look at your list later, to see if I can add anything) > --- > > Short term plans: I plan to start out with trying out the following ideas: > > save a copy in qemu on RX side in case of a single nic in vlan > implement virtio-host kernel module > > *detail on virtio-host-net kernel module project* > > virtio-host-net is a simple character device which gets memory layout information > from qemu, and uses this to convert between virtio descriptors to skbs. > The skbs are then passed to/from raw socket (or we could bind virtio-host > to physical device like raw socket does TBD). > > Interrupts will be reported to eventfd descriptors, and device will poll > eventfd descriptors to get kicks from guest. > > I currently have a virtio transport for vbus implemented, but it still needs a virtio-net device-model backend written. If you are interested, we can work on this together to implement your idea. Its on my "todo" list for vbus anyway, but I am currently distracted with the irqfd/iosignalfd projects which are prereqs for vbus to be considered for merge. Basically vbus is a framework for declaring in-kernel devices (not kvm specific, per se) with a full security/containment model, a hot-pluggable configuration engine, and a dynamically loadable device-model. The framework takes care of the details of signal-path and memory routing for you so that something like a virtio-net model can be implemented once and work in a variety of environments such as kvm, lguest, etc. Interested? -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
