From: Kurt Kanzenbach <kurt@linutronix.de>
To: Vladimir Oltean <vladimir.oltean@nxp.com>, netdev@vger.kernel.org
Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Subject: Re: [RFC PATCH net-next 00/15] taprio fixprovements
Date: Sat, 28 Jan 2023 13:20:55 +0100 [thread overview]
Message-ID: <87o7qiu9y0.fsf@kurt> (raw)
In-Reply-To: <20230128010719.2182346-1-vladimir.oltean@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
prev parent reply other threads:[~2023-01-28 12:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-28 1:07 [RFC PATCH net-next 00/15] taprio fixprovements Vladimir Oltean
2023-01-28 1:07 ` [RFC PATCH net-next 01/15] net/sched: taprio: delete peek() implementation Vladimir Oltean
2023-01-28 11:59 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 02/15] net/sched: taprio: continue with other TXQs if one dequeue() failed Vladimir Oltean
2023-01-28 11:59 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 03/15] net/sched: taprio: refactor one skb dequeue from TXQ to separate function Vladimir Oltean
2023-01-28 11:59 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 04/15] net/sched: taprio: avoid calling child->ops->dequeue(child) twice Vladimir Oltean
2023-01-28 12:00 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 05/15] net/sched: taprio: give higher priority to higher TCs in software dequeue mode Vladimir Oltean
2023-01-28 12:04 ` Kurt Kanzenbach
2023-01-29 13:17 ` Vladimir Oltean
2023-01-31 9:37 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 06/15] net/sched: taprio: calculate tc gate durations Vladimir Oltean
2023-01-28 12:05 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 07/15] net/sched: taprio: rename close_time to end_time Vladimir Oltean
2023-01-28 12:05 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 08/15] net/sched: taprio: calculate budgets per traffic class Vladimir Oltean
2023-01-28 12:05 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 09/15] net/sched: taprio: calculate guard band against actual TC gate close time Vladimir Oltean
2023-01-28 12:05 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 10/15] net/sched: make stab available before ops->init() call Vladimir Oltean
2023-01-28 12:06 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 11/15] net/sched: taprio: warn about missing size table Vladimir Oltean
2023-01-28 12:06 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 12/15] net/sched: keep the max_frm_len information inside struct sched_gate_list Vladimir Oltean
2023-01-28 12:06 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 13/15] net/sched: taprio: automatically calculate queueMaxSDU based on TC gate durations Vladimir Oltean
2023-01-28 12:06 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 14/15] net/sched: taprio: split segmentation logic from qdisc_enqueue() Vladimir Oltean
2023-01-28 12:07 ` Kurt Kanzenbach
2023-01-28 1:07 ` [RFC PATCH net-next 15/15] net/sched: taprio: don't segment unnecessarily Vladimir Oltean
2023-01-28 12:07 ` Kurt Kanzenbach
2023-01-28 12:20 ` Kurt Kanzenbach [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o7qiu9y0.fsf@kurt \
--to=kurt@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=vinicius.gomes@intel.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).