netdev - Re: [PATCH net-next 00/12] mlxsw: Preparations for XDP support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250215081043.063e995a@kernel.org>
Date: Sat, 15 Feb 2025 08:10:43 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Simon Horman <horms@...nel.org>
Cc: Amit Cohen <amcohen@...dia.com>, Alexei Starovoitov
 <alexei.starovoitov@...il.com>, Petr Machata <petrm@...dia.com>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo
 Abeni <pabeni@...hat.com>, Andrew Lunn <andrew+netdev@...n.ch>, Network
 Development <netdev@...r.kernel.org>, Ido Schimmel <idosch@...dia.com>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>, John
 Fastabend <john.fastabend@...il.com>, bpf <bpf@...r.kernel.org>, mlxsw
 <mlxsw@...dia.com>
Subject: Re: [PATCH net-next 00/12] mlxsw: Preparations for XDP support

On Sat, 15 Feb 2025 14:02:52 +0000 Simon Horman wrote:
> > TBH I also feel a little ambivalent about adding advanced software
> > features to mlxsw. You have a dummy device off which you hang the NAPIs,
> > the page pools, and now the RXQ objects. That already works poorly with
> > our APIs. How are you going to handle the XDP side? Program per port, 
> > I hope? But the basic fact remains that only fallback traffic goes thru
> > the XDP program which is not the normal Linux model, routing is after
> > XDP.
> > 
> > On one hand it'd be great if upstream switch drivers could benefit from
> > the advanced features. On the other the HW is clearly not capable of
> > delivering in line with how NICs work, so we're signing up for a stream
> > of corner cases, bugs and incompatibility. Dunno.  
> 
> FWIIW, I do think that as this driver is actively maintained by the vendor,
> and this is a grey zone, it is reasonable to allow the vendor to decide if
> they want the burden of this complexity to gain some performance.

Yes, I left this series in PW for an extra couple of days expecting
a discussion but I suppose my email was taken as a final judgment.

The object separation can be faked more accurately, and analyzed
(in the cover letter) to give us more confidence that the divergence
won't create problems.

The "actively maintained" part is true and very much appreciated, but
it's both something that may easily change, and is hard to objectively
adjudicate. Reporting results to the upstream CI would be much more
objective and hopefully easier to maintain, were the folks supporting
mlxsw to "join a startup", or otherwise disengage.