[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250213110653.iqy5magn27jyfnwh@skbuf>
Date: Thu, 13 Feb 2025 13:06:53 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: "Abdul Rahim, Faizal" <faizal.abdul.rahim@...ux.intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Simon Horman <horms@...nel.org>,
Russell King <linux@...linux.org.uk>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Furong Xu <0x1207@...il.com>,
Russell King <rmk+kernel@...linux.org.uk>,
Serge Semin <fancer.lancer@...il.com>,
Xiaolei Wang <xiaolei.wang@...driver.com>,
Suraj Jaiswal <quic_jsuraj@...cinc.com>,
Kory Maincent <kory.maincent@...tlin.com>,
Gal Pressman <gal@...dia.com>,
Jesper Nilsson <jesper.nilsson@...s.com>,
Andrew Halaney <ahalaney@...hat.com>,
Choong Yong Liang <yong.liang.choong@...ux.intel.com>,
Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, bpf@...r.kernel.org
Subject: Re: [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption
feature in IGC
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.
Powered by blists - more mailing lists