[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5c5d7ed-9f47-4af1-aee4-4632099bd546@linux.intel.com>
Date: Fri, 14 Feb 2025 12:50:04 +0800
From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@...ux.intel.com>
To: Kurt Kanzenbach <kurt@...utronix.de>,
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 14/2/2025 12:20 pm, 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.
>
> I'll split the changes based on Vladimir's suggestion.
>
> First part - ethtool-mm related:
> igc: Add support to get frame preemption statistics via ethtool
> igc: Add support to get MAC Merge data via ethtool
> igc: Add support to set tx-min-frag-size
> igc: Add support for frame preemption verification
> igc: Set the RX packet buffer size for TSN mode
> igc: Optimize TX packet buffer utilization
> igc: Rename xdp_get_tx_ring() for non-XDP usage
> net: ethtool: mm: Extract stmmac verification logic into a common library
>
> Second part:
> igc: Add support for preemptible traffic class in taprio and mqprio
> igc: Use igc_tsn_tx_arb() for taprio queue priority scheme
> igc: Kurt's patch on mqprio to use normal TSN Tx mode
>
> Kurt can keep igc_tsn_tx_arb() for his mqprio patch, so preemptible tc
> should work the same for both taprio and mqprio.
>
> I'm suggesting to include Kurt's patch in the second part since there's
> some dependency and potential code conflict, even though it mixes different
> functional changes in the same series.
I forgot that the second part patch:
igc: Add support for preemptible traffic class in taprio and mqprio
depends on the first part ethtool-mm, which would delay Kurt's patch.
So Kurt, if you'd prefer to submit yours first, that's okay too.
Powered by blists - more mailing lists