Thread (9 messages) flat view 9 messages, 4 authors, 2016-10-28

Re: [Intel-wired-lan] [net-next PATCH 3/3] net: Add support for XPS with QoS via traffic classes

From: John Fastabend <john.fastabend@gmail.com>
Date: 2016-10-28 15:49:52
Also in: intel-wired-lan

On 16-10-28 07:58 AM, Alexander Duyck wrote:
On Thu, Oct 27, 2016 at 7:38 PM, Tom Herbert [off-list ref] wrote:
quoted
On Thu, Oct 27, 2016 at 8:40 AM, Alexander Duyck
[off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help