On Thu, Jun 04, 2009 at 01:16:05PM -0400, Gregory Haskins wrote: > 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> Thanks > (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. You mean virtio-ring implementation? I intended to basically start by reusing the code from Documentation/lguest/lguest.c Isn't this all there is to it? > 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 > It seems that a character device with a couple of ioctls would be simpler for an initial prototype. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
