linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: vfio/pci - uAPI for WC
       [not found] <d42f195bffa444719065f4e84098fe0c@EX13D47EUB004.ant.amazon.com>
@ 2022-08-05 16:05 ` Bjorn Helgaas
  2022-08-05 17:26   ` Alex Williamson
  0 siblings, 1 reply; 2+ messages in thread
From: Bjorn Helgaas @ 2022-08-05 16:05 UTC (permalink / raw)
  To: Arinzon, David
  Cc: linux-pci, Dagan, Noam, Agroskin, Shay, Brandes, Shai,
	Kiyanovski, Arthur, mk, Alex Williamson, Cornelia Huck, kvm,
	linux-kernel

[+cc Alex, Cornelia, kvm, lkml (from "get_maintainer.pl drivers/vfio")
and rewrapped for plain-text readability]
On Thu, Aug 04, 2022 at 09:47:36AM +0000, Arinzon, David wrote:
> Hi,
> 
> There's currently no mechanism for vfio that exposes WC-related
> operations (check if memory is WC capable, ask to WC memory) to user
> space module entities, such as DPDK, for example.
>
> This topic has been previously discussed in [1], [2] and [3], but
> there was no follow-up.
>
> This capability is very useful for DPDK, specifically to the DPDK
> ENA driver that uses vfio-pci, which requires memory to be WC on the
> TX path. Without WC, higher CPU utilization and performance
> degradation are observed.
>
> In the above mentioned discussions, three options were suggested:
> sysfs, ioctl, mmap extension (extra attributes).
> 
> Was there any progress on this area? Is there someone who's looking
> into this?
>
> We're leaning towards the ioctl option, if there are no objections,
> we'd come up with an RFC.

> [1]: https://patchwork.kernel.org/project/kvm/patch/20171009025000.39435-1-aik@ozlabs.ru/
> [2]: https://lore.kernel.org/linux-pci/2b539df4c9ec703458e46da2fc879ee3b310b31c.camel@kernel.crashing.org/
> [3]: https://lore.kernel.org/lkml/20210429162906.32742-2-sdonthineni@nvidia.com/
> 
> Thanks,
> David

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: vfio/pci - uAPI for WC
  2022-08-05 16:05 ` vfio/pci - uAPI for WC Bjorn Helgaas
@ 2022-08-05 17:26   ` Alex Williamson
  0 siblings, 0 replies; 2+ messages in thread
From: Alex Williamson @ 2022-08-05 17:26 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Arinzon, David, linux-pci, Dagan, Noam, Agroskin, Shay, Brandes,
	Shai, Kiyanovski, Arthur, mk, Cornelia Huck, kvm, linux-kernel

On Fri, 5 Aug 2022 11:05:45 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:

> [+cc Alex, Cornelia, kvm, lkml (from "get_maintainer.pl drivers/vfio")
> and rewrapped for plain-text readability]
> On Thu, Aug 04, 2022 at 09:47:36AM +0000, Arinzon, David wrote:
> > Hi,
> > 
> > There's currently no mechanism for vfio that exposes WC-related
> > operations (check if memory is WC capable, ask to WC memory) to user
> > space module entities, such as DPDK, for example.
> >
> > This topic has been previously discussed in [1], [2] and [3], but
> > there was no follow-up.
> >
> > This capability is very useful for DPDK, specifically to the DPDK
> > ENA driver that uses vfio-pci, which requires memory to be WC on the
> > TX path. Without WC, higher CPU utilization and performance
> > degradation are observed.
> >
> > In the above mentioned discussions, three options were suggested:
> > sysfs, ioctl, mmap extension (extra attributes).
> > 
> > Was there any progress on this area? Is there someone who's looking
> > into this?

IIRC, much of the discussion was related to VM use cases on ARM and
they may have found alternate ways to do things more like x86.  I'm not
aware of any current development towards a uAPI change to enable this.
Thanks,

Alex


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-08-05 17:26 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <d42f195bffa444719065f4e84098fe0c@EX13D47EUB004.ant.amazon.com>
2022-08-05 16:05 ` vfio/pci - uAPI for WC Bjorn Helgaas
2022-08-05 17:26   ` Alex Williamson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).