From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6255-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id E12229860B4 for ; Thu, 24 Oct 2019 11:22:19 +0000 (UTC) From: Shahaf Shuler Date: Thu, 24 Oct 2019 11:22:16 +0000 Message-ID: Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM0PR0502MB37958EA359A04C0A67DB1A36C36A0AM0PR0502MB3795_" MIME-Version: 1.0 Subject: [virtio-dev] Virtio device specific MSIX arming To: Virtio-Dev , "Michael S . Tsirkin" Cc: Tzahi Oved , Alex Rosenbaum List-ID: --_000_AM0PR0502MB37958EA359A04C0A67DB1A36C36A0AM0PR0502MB3795_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below question mainly raise when looking on the ways to have vDPA implement= ation of virtio-net device. One complexity we encounter is with the MSIX relay between the device and t= he 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 trigger= ed. 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 dev= ice. Is above correct? Or there is a way to re-arm virtio device for next interr= upt? 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? --_000_AM0PR0502MB37958EA359A04C0A67DB1A36C36A0AM0PR0502MB3795_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Below question mainly raise when looking on the w= ays to have vDPA implementation of virtio-net device.

One complexity we encounter is with the MSIX rela= y between the device and the guest.

Reading the spec, and looking on the driver imple= mentation, it seems there is no way for the driver to re-arm the virtio dev= ice after MSIX was triggered.

There is a way to suppress interrupt by setting s= ome flags on the available rings, however it is hard to poll on it from a r= eal (not emulated) PCI device.

Is above correct? Or there is a way to re-arm vir= tio 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 impl= ementation? Use static

interrupt moderation?

--_000_AM0PR0502MB37958EA359A04C0A67DB1A36C36A0AM0PR0502MB3795_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6256-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id D932F9860B4 for ; Thu, 24 Oct 2019 11:35:42 +0000 (UTC) Date: Thu, 24 Oct 2019 07:35:34 -0400 From: "Michael S. Tsirkin" Message-ID: <20191024072302-mutt-send-email-mst@kernel.org> References: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [virtio-dev] Virtio device specific MSIX arming To: Shahaf Shuler Cc: Virtio-Dev , Tzahi Oved , Alex Rosenbaum List-ID: On Thu, Oct 24, 2019 at 11:22:16AM +0000, Shahaf Shuler wrote: > Hi, >=20 > =20 >=20 > Below question mainly raise when looking on the ways to have vDPA > implementation of virtio-net device. >=20 > =20 >=20 > One complexity we encounter is with the MSIX relay between the device and= the > guest. >=20 > Reading the spec, and looking on the driver implementation, it seems ther= e is > no way for the driver to re-arm the virtio device after MSIX was triggere= d. >=20 > =20 >=20 > There is a way to suppress interrupt by setting some flags on the availab= le > rings, however it is hard to poll on it from a real (not emulated) PCI de= vice. >=20 > =20 >=20 > Is above correct? Or there is a way to re-arm virtio device for next inte= rrupt? >=20 > =20 >=20 > If no way to re-arm, >=20 > 1. are there any thoughts on adding such addition to spec? >=20 > 2. What is the recommended approach for vDPA implementation? Use static >=20 > interrupt moderation? >=20 > =20 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. --=20 MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org