linux-kernel - Re: [RFC 0/2] GENL interface for ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250109133815.GV5556@nvidia.com>
Date: Thu, 9 Jan 2025 09:38:15 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Wathsala Wathawana Vithanage <wathsala.vithanage@....com>
Cc: Jeremy Linton <Jeremy.Linton@....com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"acpica-devel@...ts.linux.dev" <acpica-devel@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"robert.moore@...el.com" <robert.moore@...el.com>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"wei.huang2@....com" <wei.huang2@....com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@....com>,
	Dhruv Tripathi <Dhruv.Tripathi@....com>,
	Rob Herring <Rob.Herring@....com>, nd <nd@....com>
Subject: Re: [RFC 0/2] GENL interface for ACPI _DSM methods

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