RE: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-06 Thread Shreyas Bhatewara
-Original Message- From: Scott Feldman [mailto:scofe...@cisco.com] Sent: Wednesday, May 05, 2010 7:04 PM To: Shreyas Bhatewara; Arnd Bergmann; Dmitry Torokhov Cc: Christoph Hellwig; pv-driv...@vmware.com; net...@vger.kernel.org; linux-ker...@vger.kernel.org;

Re: [GIT PULL] amended: first round of vhost-net enhancements for net-next

2010-05-06 Thread David Miller
From: Michael S. Tsirkin m...@redhat.com Date: Tue, 4 May 2010 14:21:01 +0300 This is an amended pull request: I have rebased the tree to the correct patches. This has been through basic tests and seems to work fine here. The following tree includes a couple of enhancements that help

Re: [Qemu-devel] Re: [PATCH] virtio-spec: document block CMD and FLUSH

2010-05-06 Thread Jamie Lokier
Rusty Russell wrote: On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote: Jens Axboe wrote: On Tue, May 04 2010, Rusty Russell wrote: ISTR someone mentioning a desire for such an API years ago, so CC'ing the usual I/O suspects... It would be nice to have a more fuller API

Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-06 Thread Pankaj Thakkar
On Thu, May 06, 2010 at 01:19:33AM -0700, Gleb Natapov wrote: Overhead of interpreting bytecode plugin is written in. Or are you saying plugin is x86 assembly (32bit or 64bit btw?) and other arches will have to have in kernel x86 emulator to use the plugin (like some of them had for vgabios)?

Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-06 Thread Christoph Hellwig
On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote: Forget about the licensing. Loading binary blobs written to a shim layer is a complete pain in the ass and totally unsupportable, and also uninteresting because of the overhead. [PT] Why do you think it is unsupportable? How

Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

2010-05-06 Thread Christoph Hellwig
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote: Let me put it bluntly. Any design that allows external code to run in the kernel is not going to be accepted. Out of tree kernel modules are enough of a pain already, why do you expect the developers to add another

Re: virtio: put last_used and last_avail index into ring itself.

2010-05-06 Thread Rusty Russell
On Thu, 6 May 2010 03:57:55 pm Michael S. Tsirkin wrote: On Thu, May 06, 2010 at 10:22:12AM +0930, Rusty Russell wrote: On Wed, 5 May 2010 03:52:36 am Michael S. Tsirkin wrote: What do you think? I think everyone is settled on 128 byte cache lines for the forseeable future, so it's

Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself

2010-05-06 Thread Rusty Russell
On Thu, 6 May 2010 07:30:00 pm Avi Kivity wrote: On 05/05/2010 11:58 PM, Michael S. Tsirkin wrote: + /* We publish the last-seen used index at the end of the available ring. +* It is at the end for backwards compatibility. */ + vr-last_used_idx =(vr)-avail-ring[num]; + /* Verify

Re: [PATCH RFC] virtio: put last seen used index into ring itself

2010-05-06 Thread Rusty Russell
On Thu, 6 May 2010 03:49:46 pm Michael S. Tsirkin wrote: Now, I also added an mb() in guest between read and write so that last used index write can not get ahead of used index read. It does feel good to have it there, but I can not say why it's helpful. Works fine without it, but then these

[PATCH] virtio: initialize earlier

2010-05-06 Thread Rusty Russell
From: Stijn Tintel st...@linux-ipv6.be Move initialization of the virtio framework before the initialization of mtd, so that block2mtd can be used on virtio-based block devices. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15644 Signed-off-by: Stijn Tintel st...@linux-ipv6.be