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:
 <PAWPR08MB89099DA1BF11CACBA14E21359F132@PAWPR08MB8909.eurprd08.prod.outlook.com>
Date: Thu, 9 Jan 2025 13:42:50 +0000
From: Wathsala Wathawana Vithanage <wathsala.vithanage@....com>
To: Jason Gunthorpe <jgg@...dia.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

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

Sounds good, I like that idea.

--wathsala