On 16-10-28 07:58 AM, Alexander Duyck wrote: > On Thu, Oct 27, 2016 at 7:38 PM, Tom Herbert <t...@herbertland.com> wrote: >> On Thu, Oct 27, 2016 at 8:40 AM, Alexander Duyck >> <alexander.h.du...@intel.com> wrote: >>> This patch adds support for setting and using XPS when QoS via traffic >>> classes is enabled. With this change we will factor in the priority and >>> traffic class mapping of the packet and use that information to correctly >>> select the queue. >>> >>> This allows us to define a set of queues for a given traffic class via >>> mqprio and then configure the XPS mapping for those queues so that the >>> traffic flows can avoid head-of-line blocking between the individual CPUs >>> if so desired. >>> >> Does this change the sys API for XPS? Is it up the user to know which >> are priority queues in sys? > > The idea was to keep the change transparent. So for now the only > change in relation to XPS from the XPS point of view is that the map > for a given queue is invalidated when either the dev->num_tcs changes > or if the queue is moved into a dev->tx_to_txq mapping. Otherwise the > interface should behave exactly the same as before. > > One thing I could look at doing is adding a read-only sysfs value that > the user could use to identify which traffic class a given queue > belongs to. Then at least that way they would be able to dump both > the XPS map and the tc to determine how the traffic will flow through > the device. >
I could see some value in a sysfs read-only tc-queue mapping might be especially for devices that are negotiating these things using firmware. .John
