Rusty Russell wrote:
quoted text
> On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:
>  =20
>> You do not need to know when the packet is copied (which I currently
>> do).  You only need it for zero-copy (of which I would like to support=
,
quoted text
>> but as I understand it there are problems with the reliability of prop=
er
quoted text
>> callback (i.e. skb->destructor).
>>    =20
>
> But if you have a UP guest,

I assume you mean UP host ;)

quoted text
>  there will *never* be another packet in the queue
> at this point, since it wasn't running.
>  =20
Yep, and I'll be the first to admit that my design only looks forward.=20
Its for high speed links and multi-core cpus, etc.  If you have a
uniprocessor host, the throughput would likely start to suffer with my
current strategy.  You could probably reclaim some of that throughput
(but trading latency) by doing as you are suggesting with the deferred
initial signalling.  However, it is still a tradeoff to account for the
lower-end rig.  I could certainly put a heuristic/timer on the
guest->host to mitigate this as well, but this is not my target use case
anyway so I am not sure it is worth it.


quoted text
> As Avi said, you can do the processing in another thread and go back to=
 the
quoted text
> guest; lguest pre-virtio did a hacky "weak" wakeup to ensure the guest =
ran
quoted text
> again before the thread did for exactly this kind of reason.
>
> While Avi's point about a "powerful enough userspace API" is probably v=
alid,
quoted text
> I don't think it's going to happen.  It's almost certainly less code to=
 put a
quoted text
> virtio_net server in the kernel, than it is to create such a powerful
> interface (see vringfd & tap).  And that interface would have one user =
in
quoted text
> practice.
>
> So, let's roll out a kernel virtio_net server.  Anyone?
>  =20
Hmm..well I was hoping to be able to work with you guys to make my
proposal fit this role.  If there is no interest in that, I hope that my
infrastructure itself may still be considered for merging (in *some*
tree, not -kvm per se) as I would prefer to not maintain it out of tree
if it can be avoided.  I think people will find that the new logic
touches very few existing kernel lines at all, and can be completely
disabled with config options so it should be relatively inconsequential
to those that do not care.

-Greg