Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3675893pxb; Sun, 24 Oct 2021 08:17:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPqQ9CBSc8jPTkjPrDlHJcsTUIP/rElXT6C63FeAowFNSes/1Csm/uH4BppHW40tmsuk1Q X-Received: by 2002:a17:906:4759:: with SMTP id j25mr10548492ejs.433.1635088676342; Sun, 24 Oct 2021 08:17:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635088676; cv=none; d=google.com; s=arc-20160816; b=MXAcZpr4F8hAQpStmMQer6pArqgIm5u6Ymk3ydnOEiYYXiIRqdEyS3mvdL5tVp8gaq FwgcjphbQjMg5ztf9oHU9ZRChBO/dFFXvc3xYhIVS4rmIG0RjKvj3mwQOgoAGXX3gxHn jyBCIFciSlbHypZaUC+/iK3+oFD+SAZB3Y+BEAf9ACPfQYQJTQuJQ1+EhlGm3W3c5ycf QPgtYsIARM/nbH+VtRHfxkYppdTCHFLZPU+xZNDsOOKyOoDjkzZMnW1cPkt7qvwjysiQ MtdYhziQ6nVFBKZYGZcR0tTRimuxkUi+W+Erjy2AvtUkYdwHiNK29iGaZvrocbLisOPU NJsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Sd2F/rv0/rYPqdyLkTSI2b2h2/QE9BM0Qe4Pjpyf4UM=; b=CX924hFq7GWl3ODR5AD02ZthETCEpZqfgcVkHH3zZGIaEP94DV1mICWuOU45O2vBZq IkH4jRNDKfPmrxApfj0jxNuhRjcZqSIIFJSMaAjv5cer96Ao7b3vsTO1bq1qlXYhiTsI U8LncvaBnClEcdgnVxBgeZwJ9nBop5gXyQzjxvcjrM4zDLfidzlLOVpxkB5S2VD5RyvW UraPz1iqFfuR2cPKwphPdaJ7p+ORBPrOW0QXwvq5WlhcWoeglsEF2mAjepCF2ps7KYZM I+OvbF0sySQeEACVZHDiJ4sJmMo+JcvOTYoJCSih7Wnpp2YZp82ieEJAV3oepdV4P+6w tmJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hd1q1KND; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f12si18502869edc.363.2021.10.24.08.17.31; Sun, 24 Oct 2021 08:17:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hd1q1KND; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231440AbhJXPOV (ORCPT + 99 others); Sun, 24 Oct 2021 11:14:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:49530 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230358AbhJXPOU (ORCPT ); Sun, 24 Oct 2021 11:14:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635088319; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Sd2F/rv0/rYPqdyLkTSI2b2h2/QE9BM0Qe4Pjpyf4UM=; b=hd1q1KNDbG+43Mdrfl6JMaC4POgcu6FiRsXLRAFOOXtoY3LUbUeVSr0GDw6Awgb2xKvGpg QuQXD3ivxlnsoM5M5xywEJ88dIWYjH66HdqyPnjhqKI/4eQk4j/9LdtEW8dcCW0+SKh/GB o8dsOjyKMyZE7vkp1gSZQqyWLd1e0L0= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-466-39inwkcoP4eRWriaB6sZYg-1; Sun, 24 Oct 2021 11:11:57 -0400 X-MC-Unique: 39inwkcoP4eRWriaB6sZYg-1 Received: by mail-ed1-f72.google.com with SMTP id k28-20020a508adc000000b003dd5e21da4bso55067edk.11 for ; Sun, 24 Oct 2021 08:11:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Sd2F/rv0/rYPqdyLkTSI2b2h2/QE9BM0Qe4Pjpyf4UM=; b=Ycd3EBmMvxNISM5XvujjB0SeZDbSFVsevGOQEVbqsnHsOjYxJvr5FTyuZ3xkZbKNYY dfSetlkL4Wia80YuuUWhxCnqmmg5McCZqI4pp7oBV8j8mmngg+M8e7cRdzGzlWFLZlyS 9AU5Mjij9UEngX3rbIetvgt6QDEO+TGIwPRj/Cc/qX8eLffdPcK4Iyi5bw1Br/zelRFb L/OvOxxusNOO6q0Ud1qWA2+X3MsO6t5oD/F4XPVzYv0Xe9hbp+W/pcNkJ4J2YvAOUx8p 7atDfzeR9sAvH8dL4JOjgXQwVEyAVK7hzcVHW5bmUr+m0Pl5CCISsteJOAUCyNtqHQS7 xkaA== X-Gm-Message-State: AOAM53066hxpMh8F8KF867ICTo9vtFguppWxDrVUAOlhJf3cWirAWh8s hqKH4GWxGWdJ4Tr4hRJ2gt3joiAD6BRu/+rnGCDU04YqNtQOOsyxDO2jzbHOEPGay1h1REZtC/A HWwOeu7uLa6l48zdudApo42+r X-Received: by 2002:a17:906:2346:: with SMTP id m6mr15112449eja.512.1635088316552; Sun, 24 Oct 2021 08:11:56 -0700 (PDT) X-Received: by 2002:a17:906:2346:: with SMTP id m6mr15112407eja.512.1635088316246; Sun, 24 Oct 2021 08:11:56 -0700 (PDT) Received: from redhat.com ([2.55.151.113]) by smtp.gmail.com with ESMTPSA id gb3sm4479930ejc.81.2021.10.24.08.11.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Oct 2021 08:11:55 -0700 (PDT) Date: Sun, 24 Oct 2021 11:11:51 -0400 From: "Michael S. Tsirkin" To: Max Gurtovoy Cc: linux-kernel@vger.kernel.org, Jason Wang , Paolo Bonzini , Stefan Hajnoczi , Jens Axboe , virtualization@lists.linux-foundation.org, linux-block@vger.kernel.org Subject: Re: [PATCH] virtio_blk: allow 0 as num_request_queues Message-ID: <20211024105841-mutt-send-email-mst@kernel.org> References: <20211024135412.1516393-1-mst@redhat.com> <855eb993-074b-24b9-a184-d479bd0b342b@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <855eb993-074b-24b9-a184-d479bd0b342b@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 24, 2021 at 05:19:33PM +0300, Max Gurtovoy wrote: > > On 10/24/2021 4:54 PM, Michael S. Tsirkin wrote: > > The default value is 0 meaning "no limit". However if 0 > > is specified on the command line it is instead silently > > converted to 1. Further, the value is already validated > > at point of use, there's no point in duplicating code > > validating the value when it is set. > > > > Simplify the code while making the behaviour more consistent > > by using plain module_param. > > > > Fixes: 1a662cf6cb9a ("virtio-blk: add num_request_queues module parameter") > > Cc: Max Gurtovoy > > Signed-off-by: Michael S. Tsirkin > > --- > > drivers/block/virtio_blk.c | 14 +------------- > > 1 file changed, 1 insertion(+), 13 deletions(-) > > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 6318134aab76..c336d9bb9105 100644 > > --- a/drivers/block/virtio_blk.c > > +++ b/drivers/block/virtio_blk.c > > @@ -30,20 +30,8 @@ > > #define VIRTIO_BLK_INLINE_SG_CNT 2 > > #endif > > -static int virtblk_queue_count_set(const char *val, > > - const struct kernel_param *kp) > > -{ > > - return param_set_uint_minmax(val, kp, 1, nr_cpu_ids); > > -} > > - > > -static const struct kernel_param_ops queue_count_ops = { > > - .set = virtblk_queue_count_set, > > - .get = param_get_uint, > > -}; > > - > > static unsigned int num_request_queues; > > -module_param_cb(num_request_queues, &queue_count_ops, &num_request_queues, > > - 0644); > > +module_param(num_request_queues, uint, 0644); > > Not the best solution. > > You can set the param to 1024 but in practice nr_cpu_ids can be 32 for > example. Well your patch does make it possible to know what nr_cpu_ids is. But does it matter? The actual number of queues is still capped by the num_queues of the device. And I'm concerned that some userspace comes to depend on reading back nr_cpu_ids from there, which will cement this as part of ABI instead of being an implementation detail. Exposing the actual number of queues in sysfs might make more sense ... Generally you suggested embedded as a use-case, and I don't really see lots of embedded userspace poking at this parameter in sysfs. What I'd like to see, and attempted to achieve here: - avoid code duplication - consistency: some way to specify the parameter but still make it have the default value Better suggestions are welcome. > > > MODULE_PARM_DESC(num_request_queues, > > "Limit the number of request queues to use for blk device. " > > "0 for no limit. "