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. > - 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? 🤔 > > We need to do something about the fact that with sysfs taking > > rtnl_lock xps_map_mutex is now entirely pointless. I guess its value > > eroded over the years since Tom's initial design so we can just get > > rid of it. > > We should be able to remove the mutex (I'll double check as more > functions are involved). If so, I can send a patch to net-next.
