On Thu, Feb 13, 2025 at 11:00:32AM +0200, Vladimir Oltean wrote: > On Thu, Feb 13, 2025 at 02:12:47PM +0800, Abdul Rahim, Faizal wrote: > > I was planning to enable fpe + mqprio separately since it requires extra > > effort to explore mqprio with preemptible rings, ring priorities, and > > testing to ensure it works properly and there are no regressions. > > > > I’m really hoping that fpe + mqprio doesn’t have to be enabled together in > > this series to keep things simple. It could be added later—adding it now > > would introduce additional complexity and delay this series further, which > > is focused on enabling basic, working fpe on i226. > > > > Would that be okay with you? > > But why would the mqprio params of taprio be handled differently than > the dedicated mqprio qdisc? Why isn't the additional complexity you > mention also needed for taprio? When I got convinced to expose > preemptible TCs through separate UAPI in mqprio in taprio, it wasn't my > understanding that drivers would be reacting differently depending on > which Qdisc the configuration comes from. If you want to reduce the complexity of individual patch sets, I guess you can keep this one for just the MAC Merge layer (ethtool), and then group common handling of preemptible traffic classes (both mqprio and taprio) in the next one.
