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
