Re: [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC

[Vladimir Oltean]

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.