On 11/09/2017 03:50 AM, Sagi Grimberg wrote: > Thomas, > >>> Because the user sometimes knows better based on statically assigned >>> loads, or the user wants consistency across kernels. It's great that the >>> system is better at allocating this now, but we also need to allow for a >>> user to change it. Like anything on Linux, a user wanting to blow off >>> his/her own foot, should be allowed to do so. >> >> That's fine, but that's not what the managed affinity facility provides. If >> you want to leverage the spread mechanism, but avoid the managed part, then >> this is a different story and we need to figure out how to provide that >> without breaking the managed side of it. >> >> As I said it's possible, but I vehemently disagree, that this is a bug in >> the core code, as it was claimed several times in this thread. >> >> The real issue is that the driver was converted to something which was >> expected to behave differently. That's hardly a bug in the core code, at >> most it's a documentation problem. > > I disagree here, this is not a device specific discussion. The question > of exposing IRQ affinity assignment knob to user-space holds for every > device (NICs, HBAs and alike). The same issue could have been raised on > any other device using managed affinitization (and we have quite a few > of those now). I can't see any reason why its OK for device X to use it > while its not OK for device Y to use it. > > If the resolution is "YES we must expose a knob to user-space" then the > managed facility is unusable in its current form for *any* device. If > the answer is "NO, user-space can't handle all the stuff the kernel can" > then we should document it. This is really device independent.
Completely agree, and honestly I'm pretty baffled we're even having to argue this point. -- Jens Axboe
