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
Attachment:
signature.asc
Description: PGP signature
