On 10/30/18 10:02 AM, Keith Busch wrote: > On Tue, Oct 30, 2018 at 09:18:05AM -0600, Jens Axboe wrote: >> On 10/30/18 9:08 AM, Keith Busch wrote: >>> On Tue, Oct 30, 2018 at 08:53:37AM -0600, Jens Axboe wrote: >>>> The sum of the set can't exceed the nvecs passed in, the nvecs passed in >>>> should be the less than or equal to nvecs. Granted this isn't enforced, >>>> and perhaps that should be the case. >>> >>> That should at least initially be true for a proper functioning >>> driver. It's not enforced as you mentioned, but that's only related to >>> the issue I'm referring to. >>> >>> The problem is pci_alloc_irq_vectors_affinity() takes a range, min_vecs >>> and max_vecs, but a range of allowable vector allocations doesn't make >>> sense when using sets. >> >> I feel like we're going in circles here, not sure what you feel the >> issue is now? The range is fine, whoever uses sets will need to adjust >> their sets based on what pci_alloc_irq_vectors_affinity() returns, >> if it didn't return the passed in desired max. > > Sorry, let me to try again. > > pci_alloc_irq_vectors_affinity() starts at the provided max_vecs. If > that doesn't work, it will iterate down to min_vecs without returning to > the caller. The caller doesn't have a chance to adjust its sets between > iterations when you provide a range. > > The 'masks' overrun problem happens if the caller provides min_vecs > as a smaller value than the sum of the set (plus any reserved). > > If it's up to the caller to ensure that doesn't happen, then min and > max must both be the same value, and that value must also be the same as > the set sum + reserved vectors. The range just becomes redundant since > it is already bounded by the set. > > Using the nvme example, it would need something like this to prevent the > 'masks' overrun: OK, now I hear what you are saying. And you are right, the callers needs to provide minvec == maxvec for sets, and then have a loop around that to adjust as needed. I'll make that change in nvme. -- Jens Axboe
