On Sat, Feb 15, 2025 at 08:10:43AM -0800, Jakub Kicinski wrote: > 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. Yes, I was trying to spur that discussion. > 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. A good point. Things can change. And that may leave upstream maintainers caring the can.
