From: Jingbo Xu <jefflexu@linux.alibaba.com>
To: Peter-Jan Gootzen <pgootzen@nvidia.com>,
"vgoyal@redhat.com" <vgoyal@redhat.com>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"miklos@szeredi.hu" <miklos@szeredi.hu>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>
Cc: Max Gurtovoy <mgurtovoy@nvidia.com>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"mst@redhat.com" <mst@redhat.com>, Yoray Zack <yorayz@nvidia.com>
Subject: Re: [PATCH 1/2] virtio-fs: limit number of request queues
Date: Tue, 28 May 2024 17:13:24 +0800 [thread overview]
Message-ID: <cfcaeedc-e375-4024-8abd-8a88aa4e4014@linux.alibaba.com> (raw)
In-Reply-To: <91722cfc27ff57a0963d4f55f5ac241a5e407f84.camel@nvidia.com>
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
next prev parent reply other threads:[~2024-05-28 9:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 15:38 [PATCH 0/2] virtio-fs: introduce multi-queue support Peter-Jan Gootzen
2024-05-01 15:38 ` [PATCH 1/2] virtio-fs: limit number of request queues Peter-Jan Gootzen
2024-05-06 19:10 ` Stefan Hajnoczi
2024-05-28 8:40 ` Jingbo Xu
2024-05-28 9:05 ` Peter-Jan Gootzen
2024-05-28 9:13 ` Jingbo Xu [this message]
2024-05-01 15:38 ` [PATCH 2/2] virtio-fs: add multi-queue support Peter-Jan Gootzen
2024-05-28 8:51 ` Jingbo Xu
2024-05-28 11:59 ` Miklos Szeredi
2024-05-28 12:39 ` Peter-Jan Gootzen
2024-05-28 13:22 ` Miklos Szeredi
2024-05-28 13:35 ` Jingbo Xu
2024-05-28 14:21 ` Peter-Jan Gootzen
2024-05-29 1:52 ` Jingbo Xu
2024-05-29 9:27 ` Peter-Jan Gootzen
2024-05-06 19:52 ` [PATCH 0/2] virtio-fs: introduce " Stefan Hajnoczi
2024-05-10 11:05 ` Michael S. Tsirkin
2024-05-10 11:41 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cfcaeedc-e375-4024-8abd-8a88aa4e4014@linux.alibaba.com \
--to=jefflexu@linux.alibaba.com \
--cc=dgilbert@redhat.com \
--cc=mgurtovoy@nvidia.com \
--cc=miklos@szeredi.hu \
--cc=mst@redhat.com \
--cc=pgootzen@nvidia.com \
--cc=stefanha@redhat.com \
--cc=vgoyal@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=yorayz@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.