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

[Hannes Reinecke]

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.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich