On Fri, Feb 14, 2025 at 07:20:08PM +0800, Abdul Rahim, Faizal wrote: > Okay. I can look into this in a separate patch submission, but just an > FYI—this adds another dependency to the second part of the igc fpe > submission (preemptible tc on taprio + mqprio). This new patch > (driver-specific priv flag to control 2 different priority scheme) would > need to be accepted first before the second part of igc fpe can be > submitted. So perhaps now you're starting to understand why I had initially suggested you'd better draw the line now at just the MAC Merge layer and focus on harmonizing taprio and mqprio TX scheduling in a separate patch set. I would expect that for uniform behavior, you would force the users a little bit to adopt the new TX scheduling mode in taprio, otherwise any configuration with preemptible traffic classes would be rejected by the driver. So, if preemption is used, then the scheduling model is the same between mqprio and taprio, and you don't have to handle preemptible traffic classes over the old scheduling model. I would also expect that you replace the current patch which handles preemptible traffic classes in taprio with another one which explicitly returns -EOPNOTSUPP if preemptible traffic classes exist - just like mqprio. When Kurt added that condition in mqprio, it wasn't strictly necessary, because mqprio_parse_tc_entries() already checks ethtool_dev_mm_supported() in the core and rejects the configuration. But after your MAC Merge series is accepted, you still won't be able to handle preemptible traffic classes even though the core will let you, so you will have to impose the restriction yourself, just like Kurt did. I'm not trying to be negative, but it's imaginable that there's a chance you won't succeed to bring the whole feature set to completion right away, and if you do abandon things in the middle (MAC Merge layer supported but preemptible traffic classes unsupported), it would be good if the driver at least rejected a configuration it doesn't support, instead of accepting it and not acting on it. Because if a significant amount of time passes in such an inconsistent state, it would be very difficult for anybody else to pick up from that position and not change the behavior in incompatible ways that are user-visible.
