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:
 <PAWPR08MB8909F2373F84E4951F74A79C9F132@PAWPR08MB8909.eurprd08.prod.outlook.com>
Date: Thu, 9 Jan 2025 00:34:31 +0000
From: Wathsala Wathawana Vithanage <wathsala.vithanage@....com>
To: Jason Gunthorpe <jgg@...dia.com>, Jeremy Linton <Jeremy.Linton@....com>
CC: 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 Wed, Jan 08, 2025 at 01:59:35PM -0600, Jeremy Linton 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?

> 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?


--wathsala