Quoting Jakub Kicinski (2020-12-23 21:11:10) > On Wed, 23 Dec 2020 20:36:33 +0100 Antoine Tenart wrote: > > Quoting Jakub Kicinski (2020-12-23 19:27:29) > > > On Tue, 22 Dec 2020 08:12:28 -0800 Alexander Duyck wrote: > > > > On Tue, Dec 22, 2020 at 1:21 AM Antoine Tenart <aten...@kernel.org> > > > > wrote: > > > > > > > > > If I understood correctly, as things are a bit too complex now, you > > > > > would prefer that we go for the solution proposed in v1? > > > > > > > > Yeah, that is what I am thinking. Basically we just need to make sure > > > > the num_tc cannot be updated while we are reading the other values. > > > > > > Yeah, okay, as much as I dislike this approach 300 lines may be a little > > > too large for stable. > > > > > > > > I can still do the code factoring for the 2 sysfs show operations, but > > > > > that would then target net-next and would be in a different series. > > > > > So I > > > > > believe we'll use the patches of v1, unmodified. > > > > > > Are you saying just patch 3 for net-next? > > > > The idea would be to: > > > > - For net, to take all 4 patches from v1. If so, do I need to resend > > them? > > Yes, please.
Will do. > > - 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... Antoine
