OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio] RE: Re: [virtio-dev] Device-to-driver notification management for hardware implementations


(Apologies if you got this a second time: The first copy went to the wrong list).

I think your proposal of write to p_int_en_doorbell will work for us. The write
event to this new address in BAR itself implicitly tell the device that
interrupt is enabled and also it conveys the last used entry that it processed. Then device can provide nice interrupt moderation by making sure at least one new used entry was written and some time has elapsed from previous interrupt to
driver.

It would also be helpful if you can also outline the new structure and your
proposal for offset in the BAR.


Chandra
So this boils down to adding ability to notify devices about enabling
interrupts. Question would be, this slows down the driver. Is this
still worth doing? Right now we are trying to offload as
much as we can to the device.
I don't think it slows down the driver significantly, because the interrupt rate is usually moderated so that it is not too high. (So these notify MMIOs should not be issued at a high enough rate to get close to causing a bottleneck).

It is a win in terms of PCIe overheads, as the device never needs to read the suppression structure. But again the win is limited because interrupt rate will usually be limited by moderation.

It can be a win for latency. In the case of a net rx virt-queue the device can issue an interrupt without first reading the suppression structure.

However, despite having made the proposal, I no longer consider this high priority: Because it is an optional feature it would not reduce complexity since a device has to be able to operate without it. I'm not sure the benefits are worth the complexity added.

David

--
David Riddoch  <driddoch@solarflare.com> -- Chief Architect, Solarflare



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]