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-dev] Virtio device specific MSIX arming


On Thu, Oct 24, 2019 at 11:22:16AM +0000, Shahaf Shuler wrote:
> Hi,
> 
>  
> 
> Below question mainly raise when looking on the ways to have vDPA
> implementation of virtio-net device.
> 
>  
> 
> One complexity we encounter is with the MSIX relay between the device and the
> guest.
> 
> Reading the spec, and looking on the driver implementation, it seems there is
> no way for the driver to re-arm the virtio device after MSIX was triggered.
> 
>  
> 
> There is a way to suppress interrupt by setting some flags on the available
> rings, however it is hard to poll on it from a real (not emulated) PCI device.
> 
>  
> 
> Is above correct? Or there is a way to re-arm virtio device for next interrupt?
> 
>  
> 
> If no way to re-arm,
> 
> 1. are there any thoughts on adding such addition to spec?
> 
> 2. What is the recommended approach for vDPA implementation? Use static
> 
>     interrupt moderation?
> 
>  

As of 1.1 as well as latest spec draft, there's no way to
notify device about changes to the used buffer notification
suppression structure.

An early draft of 1.1 included an option to notify the device,
about such changes (as well as provide an interrupt
to driver in case of changes to available buffer notification
suppression structure).

We can still add this with a feature flag in a future spec version.
If you see there's value pls propose something like this on
virtio-comment.

For now, I think the best option is a combination of static interrupt
moderation, and reading the suppression structure in RAM. As interrupts
are already very expensive and have a huge latency, an extra PCI read
might not be a big deal, latency-wise.  And after all, the point is to
offload as much as possible from the CPU.


-- 
MST



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