Quoting Jakub Kicinski (2020-12-23 21:43:15) > On Wed, 23 Dec 2020 21:35:15 +0100 Antoine Tenart wrote: > > > > - For net-next, to resend patches 2 and 3 from v2 (they'll have to be > > > > slightly reworked, to take into account the review from Alexander and > > > > the rtnl lock). The patches can be sent once the ones for net land in > > > > net-next. > > > > > > If the direction is to remove xps_map_mutex, why would we need patch 2? > > > 🤔 > > > > Only the patches for net are needed to fix the race conditions. > > > > In addition to use the xps_map mutex, patches 2 and 3 from v2 factorize > > the code into a single function, as xps_cpus_show and xps_rxqs_show > > share the same logic. That would improve maintainability, but isn't > > mandatory. > > > > Sorry, it was not very clear... > > I like the cleanup, sorry I'm net very clear either. > > My understanding was that patch 2 was only needed to have access to the > XPS lock, if we don't plan to use that lock netif_show_xps_queue() can > stay in the sysfs file, right? I'm all for the cleanup and code reuse > for rxqs, I'm just making sure I'm not missing anything. I wasn't > seeing a reason to move netif_show_xps_queue(), that's all.
You understood correctly, the only reason to move this code out of sysfs was to access the xps_map lock. Without the need, the code can stay in sysfs. Patch 2 is not only moving the code out of sysfs, but also reworking xps_cpus_show. I think I now see where the confusion comes from: the reason patches 2 and 3 were in two different patches was because they were targeting net and different kernel versions. They could be squashed now. Antoine
