Re: [RFC 0/2] GENL interface for ACPI _DSM methods

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Jan 09, 2025 at 12:34:31AM +0000, Wathsala Wathawana Vithanage wrote:

> > > I'm under the impression this is a similar problem to cpu/irq/numa
> > > affinity where the driver/subsystem should be making the choice, but
> > > the user is provided the opportunity to override the defaults if they
> > > think there is benefit in their environment.
> > 
> > Which I think has been proven to have been a mistake. Instead over overriding irq
> > affinity though proc/irq under the covers of the driver and hoping for the best the
> > driver itself should have the opportinuty to set the affinity for its objects directly.
> 
> Do you mean that the driver should handle affinity requests from the user directly
> as per its policy?

Yes, not every driver has tidy mappings of objects to interrupts
vectors.
 
> > Lets us not repeat this mistake with steering tag. The driver should always be
> > involved in this stuff, if you want it to work with DPDK then go through the kernel
> > driver that DPDK is running on top of (VFIO or RDMA)
>
> This RFC is only about acquiring the steering tag from the ACPI _DSM, which the DPDK
> user space driver will set in the queue context of the device it manages.
> Setting of the steering tag part happens in the DPDK device driver.
> Are you suggesting that I should instead pass a CPU and a cache ID to VFIO and let VFIO
> decide what's right for the application?

I think that would be better, yes. Get VFIO to give you the steering
tag information, and any related control of the config space you may
need, via an IOCTL.

Jason