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