On Tuesday 08 January 2008 07:36:45 Anthony Liguori wrote:
> Avi and I were talking this afternoon and he suggested that we should
> remove the tx_timer from the virtio_net front-end and replace it with a
> tx_timer in the backend.
>
> Since the backend can suppress notifications, this is appealing since it
> gives much more flexibility to the backend in determining how to do tx
> batching. I've done a quick implementation and performance is pretty good.
>
> We may need an ABI change, however. When the backend disables
> notifications, there is absolutely no way for the frontend to notify
> anymore. In the case where the queue fills up, it cannot flush since
> the backend has disabled notifications. To work around this, I had to
> least notifications enabled and check for the case where the queue fills
> up manually.
>
> I think a possible solution to this would be to differentiate between a
> soft and hard notify. We would introduce a VRING_USED_F_NOTIFY_ON_FULL
> and a VRING_AVAIL_F_NOTIFY_ON_FULL.
>
> The NO_NOTIFY variants would indicate that the other end never sends a
> notify, whereas NOTIFY_ON_FULL would indicate that the other end never
> sends a notify unless the queue fills up.
Hi Anthony,
I really like this (in proportion to my discomfort with the hrtimers hack,
in fact). The good news is that I don't think we need a significant ABI
change: I think we should have the vring_get_buf() failure path kick the
other end unconditionally.
This makes sense: the NO_INTERRUPT flag is really a "you don't need to
interrupt me" hint; you're allowed to interrupt even if it's set. So it
should be at worst harmless. It should work in the inter-guest case, for
example.
Rather than apply this, I will just drop the hrtimer patches, and do a
separate "kick on queue full" patch.
Thanks!
Rusty.
|
