On 5/28/24 5:05 PM, Peter-Jan Gootzen wrote: > 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. Okay got it. Many thanks for the reply. -- Thanks, Jingbo
