[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250617121742.64no35fvb2bbnppf@skbuf>
Date: Tue, 17 Jun 2025 15:17:42 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
Faizal Rahim <faizal.abdul.rahim@...ux.intel.com>,
faizal.abdul.rahim@...el.com, chwee.lin.choong@...el.com,
horms@...nel.org, vitaly.lifshits@...el.com,
dima.ruinskiy@...el.com, Mor Bar-Gabay <morx.bar.gabay@...el.com>,
davem@...emloft.net, edumazet@...gle.com, andrew+netdev@...n.ch,
netdev@...r.kernel.org, kuba@...nel.org
Subject: Re: [PATCH net-next 5/7] igc: add private flag to reverse TX queue
priority in TSN mode
Hi Paolo,
On Tue, Jun 17, 2025 at 12:06:14PM +0200, Paolo Abeni wrote:
> On 6/11/25 8:03 PM, Tony Nguyen wrote:
> > To harmonize TX queue priority behavior between taprio and mqprio, and
> > to fix these issues without breaking long-standing taprio use cases,
> > this patch adds a new private flag, called reverse-tsn-txq-prio, to
> > reverse the TX queue priority. It makes queue 3 the highest and queue 0
> > the lowest, reusing the TX arbitration logic already used by mqprio.
> Isn't the above quite the opposite of what Vladimir asked in
> https://lore.kernel.org/all/20250214113815.37ttoor3isrt34dg@skbuf/ ?
>
> """
> I would expect that for uniform behavior, you would force the users a
> little bit to adopt the new TX scheduling mode in taprio, otherwise any
> configuration with preemptible traffic classes would be rejected by the
> driver.
> """
>
> I don't see him commenting on later version, @Vladimir: does this fits you?
Indeed, sorry for disappearing from the patch review process.
I don't see the discrepancy between what Faizal implemented and what we
discussed. Specifically on the bit you quoted - patch "igc: add
preemptible queue support in taprio" refuses taprio schedules with
preemptible TCs if the user hasn't explicitly opted into
IGC_FLAG_TSN_REVERSE_TXQ_PRIO. If that private flag isn't set,
everything works as currently documented, just the new features are
gated.
The name of the private flag is debatable IMHO, because it's taprio
specific and the name doesn't reflect that (mqprio uses the "reverse"
priority assignment to TX queues by default, and this flag doesn't
change that). Also, "reverse" compared to what? Both operating modes can
equally be named "reverse". Maybe "taprio-standard-txq-priority" would
have been clearer regarding what the flag really does. Anyway, I don't
want to stir up a huge debate around naming if functionality-wise it's
the same thing, they have to maintain it, I don't.
Is there something I'm missing? It feels like it.
Powered by blists - more mailing lists