Message-ID: <1c981aa1-e796-4c53-9853-3eae517f2f6d@linux.intel.com>
Date: Thu, 13 Feb 2025 21:54:00 +0800
From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@...ux.intel.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Kurt Kanzenbach <kurt@...utronix.de>,
 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 13/2/2025 9:00 pm, Vladimir Oltean wrote:
> On Thu, Feb 13, 2025 at 08:54:18PM +0800, Abdul Rahim, Faizal wrote:
>>> Well, my idea was to move the current mqprio offload implementation from
>>> legacy TSN Tx mode to the normal TSN Tx mode. Then, taprio and mqprio
>>> can share the same code (with or without fpe). I have a draft patch
>>> ready for that. What do you think about it?
>>
>> Hi Kurt,
>>
>> I’m okay with including it in this series and testing fpe + mqprio, but I’m
>> not sure if others might be concerned about adding different functional
>> changes in this fpe series.
>>
>> Hi Vladimir,
>> Any thoughts on this ?
> 
> Well, what do you think of my split proposal from here, essentially
> drawing the line for the first patch set at just ethtool mm?
> https://lore.kernel.org/netdev/20250213110653.iqy5magn27jyfnwh@skbuf/
> 

Honestly, after reconsidering, I’d prefer to keep the current series as is 
(without Kurt’s patch), assuming you’re okay with enabling mqprio + fpe 
later rather than at the same time as taprio + fpe. There likely won’t be 
any additional work needed for mqprio + fpe after Kurt’s patch is accepted, 
since it will mostly reuse the taprio code flow.

If I were to split it, the structure would look something like this:
First part of fpe series:
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 the 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 of fpe:
igc: Add support for preemptible traffic class in taprio

I don’t think Kurt’s patch should be included in my second part of fpe, as 
it’s not logically related. Another approach would be to wait for Kurt’s 
patch to be accepted first, then submit the second part and verify both 
taprio + mqprio. However, that would delay i226 from having a basic fpe 
feature working as a whole, which I'd really like to avoid.

Powered by blists - more mailing lists