Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp5003662imd; Tue, 30 Oct 2018 10:28:41 -0700 (PDT) X-Google-Smtp-Source: AJdET5d6G+PylPdrFnFavGi8+s8L3+cFPn5mHMUex0H00uI4ayha8BHKJDRXF9kgMzTTdYvg5fZx X-Received: by 2002:a65:6447:: with SMTP id s7mr18725012pgv.226.1540920521641; Tue, 30 Oct 2018 10:28:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540920521; cv=none; d=google.com; s=arc-20160816; b=Y2nFId7d97TQp5kTFe3pKZmRIm6xZEIVsvkj8DFISS4kE2hjOdfU3+p0MsJUeGUiQ7 zMTwhzbOKf15ynKeI72GE1T8MyiYa2ddGMEjbXZ/aOITKMEQ9H2A7VMzQ40fPPES1emB LzCWgUBcJV5EFChoCx9tYz5R9k5VOJtQYgrglfecBIGkY8AN3Bxvv2wxXV/im36izMce SjXQaeOBwEN4m/lpM5OBXgvgyqkVRVZ9mjkvoI4QjR/Xtq4IYPAMW/uW30FkGSEzj+1e LL3Ism5wiqSizwzT4C+/sgR7P/RNBLP3u/IFKrDhod2gAWZyGHj5RrFA8bLiin8LXqnO MijA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=FVQ2i0WFUByEa5yNPyytjcTNnHWFIS8Fm/rS5T48mhI=; b=s7a6lFurSns1Q355FDfarkCvHRRhLKZujeFCOl1EbCGvjmEJxZgBvufnMfwBIRkjLK X2qvkoRuybPByrkbwVImgP9s9bshqbb5T5cS7bBYteUJOwYo7djO9GO2yfdJQPNyMTH1 hZMSfDK8U3XTG3Zbfkv6ddQnIJVjpAx3p4a2OoEJBQ27dGrdcKmb1JQWTax0/vS5q2a/ 0CVP3VjlP4gj+gimEvPV21J2Igs1Rs/BcEhZ9Tf1wQJQ8y90bd5sphrtXaW0/fYfDYMA Wer0VScrFOOP0pUEITGUM4r6uLL93VGVW4swWbOIvEzg8EDMiaHqwGzR7FSQfKYh6q1m uChg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10-v6si13773406pgt.206.2018.10.30.10.28.21; Tue, 30 Oct 2018 10:28:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728064AbeJaCUQ (ORCPT + 99 others); Tue, 30 Oct 2018 22:20:16 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:54402 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727621AbeJaCUQ (ORCPT ); Tue, 30 Oct 2018 22:20:16 -0400 Received: from tmo-115-37.customers.d1-online.com ([80.187.115.37] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gHXm1-0003bD-0P; Tue, 30 Oct 2018 18:25:49 +0100 Date: Tue, 30 Oct 2018 18:25:47 +0100 (CET) From: Thomas Gleixner To: Jens Axboe cc: Keith Busch , linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 11/14] irq: add support for allocating (and affinitizing) sets of IRQs In-Reply-To: <27c1017a-9560-80cb-038d-f64727a162c3@kernel.dk> Message-ID: References: <20181029163738.10172-1-axboe@kernel.dk> <20181029163738.10172-12-axboe@kernel.dk> <20181030142601.GA18906@localhost.localdomain> <20181030144527.GB18906@localhost.localdomain> <46dbcbcd-799f-9970-a68f-de7e96b1a6bb@kernel.dk> <20181030150840.GC18906@localhost.localdomain> <20181030160242.GD18906@localhost.localdomain> <27c1017a-9560-80cb-038d-f64727a162c3@kernel.dk> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jens, On Tue, 30 Oct 2018, Jens Axboe wrote: > On 10/30/18 10:02 AM, Keith Busch wrote: > > 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. But then we should enforce it in the core code, right? Thanks, tglx