All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Shahaf Shuler <shahafs@mellanox.com>
Cc: Virtio-Dev <virtio-dev@lists.oasis-open.org>,
	Tzahi Oved <tzahio@mellanox.com>,
	Alex Rosenbaum <alexr@mellanox.com>
Subject: Re: [virtio-dev] Virtio device specific MSIX arming
Date: Thu, 24 Oct 2019 07:35:34 -0400	[thread overview]
Message-ID: <20191024072302-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <AM0PR0502MB37958EA359A04C0A67DB1A36C36A0@AM0PR0502MB3795.eurprd05.prod.outlook.com>

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


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


      reply	other threads:[~2019-10-24 11:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 11:22 [virtio-dev] Virtio device specific MSIX arming Shahaf Shuler
2019-10-24 11:35 ` Michael S. Tsirkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191024072302-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alexr@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=tzahio@mellanox.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.