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.
