summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/atheros
diff options
context:
space:
mode:
authorYannick Vignon <yannick.vignon@nxp.com>2021-05-11 20:18:29 +0300
committerDavid S. Miller <davem@davemloft.net>2021-05-13 23:08:00 +0300
commit13511704f8d7591faf19fdb84f0902dff0535ccb (patch)
treefecca9e5abb42df190690bf36a7b119e4add19d8 /drivers/net/ethernet/atheros
parentd8654f4f9300e5e7cf8d5e7885978541cf61326b (diff)
downloadlinux-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