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.
