netdev - [RFC PATCH net-next 00/15] taprio fixprovements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 28 Jan 2023 03:07:04 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     netdev@...r.kernel.org
Cc:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Kurt Kanzenbach <kurt@...utronix.de>
Subject: [RFC PATCH net-next 00/15] taprio fixprovements

I started to pull on a small thread and the whole thing unraveled :(

While trying to ignite a more serious discussion about how the i225/i226
hardware prioritization model seems to have affected the generic taprio
software implementation (patch 05/15), I noticed 2 things:
- taprio_peek() is dead code (patch 01/15)
- taprio has a ridiculously low iperf3 performance when all gates are
  open and it behave as a work-conserving qdisc. Patches 06/15 -> 09/15
  and 13/15 -> 15/15 collectively work to address some of that.

I had to put a hard stop for today (and at the patch limit of 15), but
now that taprio calculates the durations of contiguously open TC gates,
part 2 would be the communication of this information to offloading
drivers via ndo_setup_tc(), and the deletion of duplicated logic from
vsc9959_tas_guard_bands_update(). But that's for another day - I'm not
quite sure how that's going to work out. The gate durations change at
each link speed change, and this might mean that reoffloading is
necessary.

Another huge issue I'm seeing at small intervals with software
scheduling is simply the amount of RCU stalls. I can't get Kurt's
schedule from commit 497cc00224cf ("taprio: Handle short intervals
and large packets") to work reliably on my system even without these
patches. Eventually the system dies unless I increase the entry
intervals from the posted 500 us - my CPUs just don't do much of
anything else. Maybe someone has any idea what to do.

Almost forgot to mention, this patch set only applies on top of another
one:
https://patchwork.kernel.org/project/netdevbpf/cover/20230127001516.592984-1-vladimir.oltean@nxp.com/

Vladimir Oltean (15):
  net/sched: taprio: delete peek() implementation
  net/sched: taprio: continue with other TXQs if one dequeue() failed
  net/sched: taprio: refactor one skb dequeue from TXQ to separate
    function
  net/sched: taprio: avoid calling child->ops->dequeue(child) twice
  net/sched: taprio: give higher priority to higher TCs in software
    dequeue mode
  net/sched: taprio: calculate tc gate durations
  net/sched: taprio: rename close_time to end_time
  net/sched: taprio: calculate budgets per traffic class
  net/sched: taprio: calculate guard band against actual TC gate close
    time
  net/sched: make stab available before ops->init() call
  net/sched: taprio: warn about missing size table
  net/sched: keep the max_frm_len information inside struct
    sched_gate_list
  net/sched: taprio: automatically calculate queueMaxSDU based on TC
    gate durations
  net/sched: taprio: split segmentation logic from qdisc_enqueue()
  net/sched: taprio: don't segment unnecessarily

 net/sched/sch_api.c    |  29 +--
 net/sched/sch_taprio.c | 548 ++++++++++++++++++++++++++++-------------
 2 files changed, 383 insertions(+), 194 deletions(-)

-- 
2.34.1