Message-ID: <874j0wrjk2.fsf@kurt.kurt.home>
Date: Fri, 14 Feb 2025 09:56:29 +0100
From: Kurt Kanzenbach <kurt@...utronix.de>
To: "Abdul Rahim, Faizal" <faizal.abdul.rahim@...ux.intel.com>, Vladimir
 Oltean <vladimir.oltean@....com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>, Przemek Kitszel
 <przemyslaw.kitszel@...el.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S . Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>, Simon Horman
 <horms@...nel.org>, Russell King <linux@...linux.org.uk>, Alexei
 Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Jesper Dangaard Brouer <hawk@...nel.org>, John Fastabend
 <john.fastabend@...il.com>, Furong Xu <0x1207@...il.com>, Russell King
 <rmk+kernel@...linux.org.uk>, Serge Semin <fancer.lancer@...il.com>,
 Xiaolei Wang <xiaolei.wang@...driver.com>, Suraj Jaiswal
 <quic_jsuraj@...cinc.com>, Kory Maincent <kory.maincent@...tlin.com>, Gal
 Pressman <gal@...dia.com>, Jesper Nilsson <jesper.nilsson@...s.com>,
 Andrew Halaney <ahalaney@...hat.com>, Choong Yong Liang
 <yong.liang.choong@...ux.intel.com>, Kunihiko Hayashi
 <hayashi.kunihiko@...ionext.com>, Vinicius Costa Gomes
 <vinicius.gomes@...el.com>, intel-wired-lan@...ts.osuosl.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, bpf@...r.kernel.org
Subject: Re: [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption
 feature in IGC

On Fri Feb 14 2025, Abdul Rahim, Faizal wrote:
> On 14/2/2025 3:12 am, Kurt Kanzenbach wrote:
>> On Thu Feb 13 2025, Vladimir Oltean wrote:
>>> So, confusingly to me, it seems like one operating mode is fundamentally
>>> different from the other, and something will have to change if both will
>>> be made to behave the same. What will change? You say mqprio will behave
>>> like taprio, but I think if anything, mqprio is the one which does the
>>> right thing, in igc_tsn_tx_arb(), and taprio seems to use the default Tx
>>> arbitration scheme?
>> 
>> Correct. taprio is using the default scheme. mqprio configures it to
>> what ever the user provided (in igc_tsn_tx_arb()).
>> 
>>> I don't think I'm on the same page as you guys, because to me, it is
>>> just odd that the P traffic classes would be the first ones with
>>> mqprio, but the last ones with taprio.
>> 
>> I think we are on the same page here. At the end both have to behave the
>> same. Either by using igc_tsn_tx_arb() for taprio too or only using the
>> default scheme for both (and thereby keeping broken_mqprio). Whatever
>> Faizal implements I'll match the behavior with mqprio.
>> 
>
> Hi Kurt & Vladimir,
>
> After reading Vladimir's reply on tc, hw queue, and socket priority mapping 
> for both taprio and mqprio, I agree they should follow the same priority 
> scheme for consistency—both in code and command usage (i.e., taprio, 
> mqprio, and fpe in both configurations). Since igc_tsn_tx_arb() ensures a 
> standard mapping of tc, socket priority, and hardware queue priority, I'll 
> enable taprio to use igc_tsn_tx_arb() in a separate patch submission.

There's one point to consider here: igc_tsn_tx_arb() changes the mapping
between priorities and Tx queues. I have no idea how many people rely on
the fact that queue 0 has always the highest priority. For example, it
will change the Tx behavior for schedules which open multiple traffic
classes at the same time. Users may notice.

OTOH changing mqprio to the broken_mqprio model is easy, because AFAIK
there's only one customer using this.

Thanks,
Kurt

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

Powered by blists - more mailing lists