Hi Jingbo, On Tue, 2024-05-28 at 16:40 +0800, Jingbo Xu wrote: > External email: Use caution opening links or attachments > > > Hi Peter-Jan, > > Thanks for the amazing work! Glad to see it is upstreamed. We are > also > planning distribute virtiofs on DPU. Great to hear that virtio-fs is getting more attention with this powerful approach :) > > BTW I have some questions when reading the patch, appreciate if you > could give a hint. > > > On 5/1/24 11:38 PM, Peter-Jan Gootzen wrote: > > Virtio-fs devices might allocate significant resources to virtio > > queues > > such as CPU cores that busy poll on the queue. The device indicates > > how > > many request queues it can support and the driver should initialize > > the > > number of queues that they want to utilize. > > I'm okay with truncating the num_request_queues to nr_cpu_ids if the > number of the available queues exceeds nr_cpu_ids, as generally 1:1 > mapping between cpus and queues is enough and we can not make use more > queues in this case. > > I just don't understand the above commit message as how this relates > to > the resource footprint at the device side. When the the number of the > queues actually used by the driver (e.g. nr_cpu_ids is 6) is less than > the amount (e.g. 8) that is advertised by the driver, will the device > side reclaim the resources allocated for the remaining unused queues? > The driver has no way notifying how many queues it actually utilizes. The device resources allocated to queues is device implementation specific. So the cost of the driver creating more queues than it will ultimately use, is dependent on how the specific device handles these unsused queues. A smart device could at some point decide to spend less polling resources on a queue if it sees that it is unused (reclaiming the resources as you put it). But in my opinion, the driver should not allocate more than it will use. The new scheme tries to map every core to a queue, so we know that we will not use >nr_cpu_ids queues. - Peter-Jan
