diff options
author | Yannick Vignon <yannick.vignon@nxp.com> | 2021-05-11 20:18:29 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2021-05-13 23:08:00 +0300 |
commit | 13511704f8d7591faf19fdb84f0902dff0535ccb (patch) | |
tree | fecca9e5abb42df190690bf36a7b119e4add19d8 /drivers/net/ethernet/atheros | |
parent | d8654f4f9300e5e7cf8d5e7885978541cf61326b (diff) | |
download | linux-13511704f8d7591faf19fdb84f0902dff0535ccb.tar.xz |
net: taprio offload: enforce qdisc to netdev queue mapping
Even though the taprio qdisc is designed for multiqueue devices, all the
queues still point to the same top-level taprio qdisc. This works and is
probably required for software taprio, but at least with offload taprio,
it has an undesirable side effect: because the whole qdisc is run when a
packet has to be sent, it allows packets in a best-effort class to be
processed in the context of a task sending higher priority traffic. If
there are packets left in the qdisc after that first run, the NET_TX
softirq is raised and gets executed immediately in the same process
context. As with any other softirq, it runs up to 10 times and for up to
2ms, during which the calling process is waiting for the sendmsg call (or
similar) to return. In my use case, that calling process is a real-time
task scheduled to send a packet every 2ms, so the long sendmsg calls are
leading to missed timeslots.
By attaching each netdev queue to its own qdisc, as it is done with
the "classic" mq qdisc, each traffic class can be processed independently
without touching the other classes. A high-priority process can then send
packets without getting stuck in the sendmsg call anymore.
Signed-off-by: Yannick Vignon <yannick.vignon@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/atheros')
0 files changed, 0 insertions, 0 deletions