DragonFly BSD
DragonFly kernel List (threaded) for 2010-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: RFC: virtio blk driver


From: Pratyush Kshirsagar <pratyush.kshirsagar@xxxxxxxxx>
Date: Wed, 22 Dec 2010 13:36:55 +0000 (UTC)

Alex Hornung <ahornung <at> gmail.com> writes:

> 
> > Pratyush and I have been working on the virtio drivers. The virtio-blk
> > driver is ready for more testing and eyes looking at the code. The
> > virtio-net driver is still in progress.
> 
> My first question: What is blkv2? How is it different from blk?
> 
> Regarding the code, this is definitely not in a good shape as far as
> style(9) goes. The indentations are pretty random and there are a lot of
> C++ comments to comment out code (//foo). Code should be commented out
> with #if 0 ... #endif. It makes it pretty much a pain to read.
> 
> Now regarding the performance, is that the performance you were
> expecting? How is the performance on NetBSD on the same system? If not
> the same, where's the problem?
> 
> I'm also not so sure about the way you dispatch I/O in
> virtio_disk_strategy. You essentially insert the I/O to be dispatched at
> the end of a queue, then you call virtio_blk_execute, from exactly that
> same point, and this then dispatches the first I/O on the queue. This
> sounds quite dodgy and probably shouldn't be the case. How do you
> guarantee all the enqueued I/Os are dispatched eventually? You can't
> just assume you'll get more strategy calls. Maybe you are covering that
> case, but from a short glance I don't see it. In any case, dispatching a
> completely different I/O from the requested one in a strategy call might
> not be the greatest idea for a plain block driver.
> 
> [...]
> 
> > The wiki has some notes about it: installing, architecture, porting
> > notes, etc:
> 
> Regarding your 'Misc Porting Notes' on the wiki: Using spin locks to
> protect the lists should be fine, as long as that's pretty much all they
> are used for. spinlocks can't be used in blocking conditions; if that's
> your intention, you'll have to use mutexes or lockmgr locks.
> 
> It seems your intentions are to make the design lockless? Do you have
> any more detailed plans on this? One queue/ring per CPU, or what is your
> intention?
> 
> Regards,
> Alex Hornung
> 
> 

Yes, the code is not in the style(9) format and some cleaning is needed for 
sure.
Tim and me thought that once block drivers are up to some mark,we can put the 
going on's on the IRC. 
Currently, the network driver is in progress and once some substantial work is 
done, we will move forward to clean, modularize and optimize everything.
Tim has been checking the statistics and working of virtio on NetBSD and various 
other *nix systems. I think he'll give some details for sure. 
We'll go for mutexes where needed unless we are in interrupt context will be 
using spin lock.
I think other block driver details are better left for Tim as he has been doing 
all the work on it.
We are definitely looking for more suggestions :)

---->>Virtio driver/ Device driver writing is like searching for a black cat in 
a dark room which isn't their ;)

Have a nice day guys.
- Pratyush.






[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]