netdev - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87o7qiu9y0.fsf@kurt>
Date:   Sat, 28 Jan 2023 13:20:55 +0100
From:   Kurt Kanzenbach <kurt@...utronix.de>
To:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc:     Vinicius Costa Gomes <vinicius.gomes@...el.com>
Subject: Re: [RFC PATCH net-next 00/15] taprio fixprovements

On Sat Jan 28 2023, Vladimir Oltean wrote:
> 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.

Thanks for investing the time and improving the software
scheduling. Especially the calculations of TC durations and
incorporating the max. frame lengths in a better way. I went over this
series and it looks good to me. Except for one patch.

Thanks,
Kurt

Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)