Thanks for suggestion. Created issue https://github.com/spdk/spdk/issues/1378. Regards, -Wenhua On 4/29/20, 9:38 PM, "Yang, Ziye" <ziye.yang(a)intel.com&gt; wrote: Hi Wenhua, Could you submit a github issue in : https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.... ? We just had a community meeting and discussed this issue. And we would change it in SPDK code and target for 20.07 release. Best Regards Ziye Yang -----Original Message----- From: Wenhua Liu <liuw(a)vmware.com&gt; Sent: Thursday, April 30, 2020 11:59 AM To: Storage Performance Development Kit <spdk(a)lists.01.org&gt; Subject: [SPDK] The parameter max_qpairs_per_ctrlr is misleading When creating nvmf transport using command “rpc.py nvmf_create_transport”, there is a parameter max_qpairs_per_ctrlr. It means number of IO queues plus admin queue per controller. But when people talk about number of queues, usually it means number of IO queues. When someone creates nvmf transport, if he/she knows what max_qpairs_per_ctrlr mean and wants to have 8 IO queues, he/she will set this parameter to 9. If given 8, he/she will get only 7 IO queues. In the worst case, if someone gives one to this parameter, he won’t get any IO queue !!! I would suggest SPDK NVMF target changes the definition of this parameter and treat it as number of IO queues. Internally, SPDK should allow one extra qpair be created for admin queue. Thanks, -Wenhua Liu _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org