From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [Xen-devel] Re: [PATCH RFC 1/3] virtio infrastructure Date: Mon, 04 Jun 2007 09:53:56 +1000 Message-ID: <1180914836.17442.104.camel@localhost.localdomain> References: <1180613947.11133.58.camel@localhost.localdomain> <46610E8D.10706@qumranet.com> <1180777836.9228.44.camel@localhost.localdomain> <46625192.5020108@qumranet.com> <1180866540.17442.74.camel@localhost.localdomain> <4662A86A.7010706@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jimi Xenidis , Stephen Rothwell , Xen Mailing List , "jmk-zzFmDc4TPjtKvsKVC3L/VUEOCMrvLtNR@public.gmane.org" , Herbert Xu , kvm-devel , virtualization , Christian Borntraeger , Suzanne McIntosh , Martin Schwidefsky To: Avi Kivity Return-path: In-Reply-To: <4662A86A.7010706-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Sun, 2007-06-03 at 14:39 +0300, Avi Kivity wrote: > Rusty Russell wrote: > > Hmm... Perhaps I should move the used arrays into the "struct > > virtio_device" and guarantee that the id (returned by add_*buf) is an > > index into that. Then we can trivially add a corresponding bit array. > > That may force the virtio backend to do things it doesn't want to. Well, I have two implementations, and both ids already fit this model so I have some confidence. I just need to add the set_bit/clear_bit to the read/write one, and use sync_clear_bit to the descriptor-based one (which I suspect will actually get a little cleaner). So I think this constraint is a reasonable thing to add anyway. > > This also makes the "id" easier to use from the driver side: if we add a > > "max_id" field it can size its own arrays if it wants to. Gets rid of > > the linked-list in the block driver... > > > > How about > > struct virtio_completion { > unsigned long length; > void *data; > }; > > int virtio_complete(struct virtio_completion *completions, int nr); > > where 'data' is an opaque pointer passed by the device during add_*buf()? Other than the fact that the driver will look less like a normal driver, it's actually harder to write the net driver if that complete call can happen off an interrupt: we can't free skbs in interrupt context, which is why the used-outbuf cleanup is currently done (inefficiently, but that's orthogonal) in the xmit routine. I'll code up the modifications now and check if I'm right about the impact on the code. I might have to come up with something else... Cheers, Rusty. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/