[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877c5undbg.fsf@kurt.kurt.home>
Date: Thu, 13 Feb 2025 15:12:35 +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 Thu Feb 13 2025, Abdul Rahim, Faizal wrote:
> 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.
I think so. After switching the Tx mode mqprio will basically be a
special case of taprio with a dummy Qbv schedule. Also the driver
currently rejects mqprio with hardware offloading and preemptible_tcs
set. So, I do not see any issues in merging your fpe series first. I can
handle the mqprio part afterwards.
Thanks,
Kurt
Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)
Powered by blists - more mailing lists