[PATCH v3 0/2] nvme-tcp: NIC topology aware I/O queue scaling and queue info export

[Nilay Shroff]

On 10/30/26 12:39 PM, Hannes Reinecke wrote:
> On 10/29/26 5:59 PM, Nilay Shroff wrote:
>> On 10/29/26 9:41 PM, Daniel Wagner wrote:
>>> On Mon, Oct 26, 2026 at 06:03:21PM +0530, Nilay Shroff wrote:
>>>> Following the feedback, the logic for determining the number of fabric I/O
>>>> queues (nr-io-queues) has been moved to userspace in nvme-cli [2]. As a
>>>> result, the first two patches from the previous series, which implemented
>>>> this logic in the kernel driver, have been dropped. This series contains
>>>> the remaining two patches, which export NVMe/TCP I/O queue information
>>>> through debugfs to facilitate host-side network tuning.
>>>>
>>>> The first patch introduces debugfs helper functions that can be used by
>>>> drivers to export debugfs attributes.
>>>
>>> What is the expectation, what's the use case here? Should this
>>> information be available in a productive system? In this case debugfs
>>> might not be the right choice.
>>
>> Ideally, this information should be available on production systems to
>> facilitate network stack tuning.
>>
>> Would you recommend exposing it through sysfs rather than debugfs? During
>> the last LSFMM, I received feedback suggesting debugfs, so I implemented
>> the interface accordingly in this patch series. However, I'm open to moving
>> it to sysfs if we agree that it is the more appropriate interface.
>>
> Hmm. This matches what netdevs do with their tx/rx queue mapping, and that is in sysfs. Typically I would prefer debugfs for this, but here
> I really don't mind as it's somewhere in the middle between generally
> useful and being a niche usecase.
> Alright, then I'll move this under sysfs and spin a new version.

Thanks,
--Nilay