Re: [PATCH] fuse: cleanup request queuing towards virtiofs

d this patch could show some benefit at those higher message rates. So although I would have hoped for some performance increase already with this setup, I still think this is a good patch and a logical optimization for high performance virtio-fs devices that might show a benefit in the future. Tested-by: Peter-Jan Gootzen Reviewed-by: Peter-Jan Gootzen

Re: Addressing architectural differences between FUSE driver and fs - Re: virtio-fs tests between host(x86) and dpu(arm64)

On Tue, 2024-06-04 at 11:18 +0200, Miklos Szeredi wrote: > External email: Use caution opening links or attachments > > > On Tue, 4 Jun 2024 at 11:08, Peter-Jan Gootzen > wrote: > > > Option 2 is detectable if fuse_init_out.minor < CANON_ARCH_MINOR, > >

Re: Addressing architectural differences between FUSE driver and fs - Re: virtio-fs tests between host(x86) and dpu(arm64)

On Tue, 2024-06-04 at 10:45 +0200, Miklos Szeredi wrote: > External email: Use caution opening links or attachments > > > On Tue, 4 Jun 2024 at 10:28, Peter-Jan Gootzen > wrote: > > > Will the FUSE_CANON_ARCH then be default/required in init_in from >

Re: Addressing architectural differences between FUSE driver and fs - Re: virtio-fs tests between host(x86) and dpu(arm64)

n Mon, Jun 3, 2024 at 3:44 PM Stefan Hajnoczi > > > wrote: > > > > > > > > On Mon, Jun 03, 2024 at 11:06:19AM +0200, Miklos Szeredi wrote: > > > > > On Mon, 3 Jun 2024 at 10:53, Peter-Jan Gootzen > > > > > wrote: >

Re: Addressing architectural differences between FUSE driver and fs - Re: virtio-fs tests between host(x86) and dpu(arm64)

On Mon, 2024-06-03 at 10:24 +0200, Miklos Szeredi wrote: > On Mon, 3 Jun 2024 at 10:02, Peter-Jan Gootzen > wrote: > > > We would like to make a proposal regarding our idea for solving this > > issue before sending in a patch: > > Use a uint32_t from the unused a

Addressing architectural differences between FUSE driver and fs - Re: virtio-fs tests between host(x86) and dpu(arm64)

Hi Xiaoguang and others, You have identified an issue that we are also running into and had also planned to address with the community. We currently solve this by explicitly telling the virtio-fs device which architecture is running on the host through a side-channel so that it can correctly

Re: [PATCH] fuse: cleanup request queuing towards virtiofs

On Wed, 2024-05-29 at 14:32 -0400, Stefan Hajnoczi wrote: > On Wed, May 29, 2024 at 05:52:07PM +0200, Miklos Szeredi wrote: > > Virtiofs has its own queing mechanism, but still requests are first > > queued > > on fiq->pending to be immediately dequeued and queued onto the > > virtio > > queue. >

Re: [PATCH 2/2] virtio-fs: add multi-queue support

On Wed, 2024-05-29 at 09:52 +0800, Jingbo Xu wrote: > External email: Use caution opening links or attachments > > > On 5/28/24 10:21 PM, Peter-Jan Gootzen wrote: > > On Tue, 2024-05-28 at 21:35 +0800, Jingbo Xu wrote: > > > External email: Use caution o

Re: [PATCH 2/2] virtio-fs: add multi-queue support

On Tue, 2024-05-28 at 21:35 +0800, Jingbo Xu wrote: > External email: Use caution opening links or attachments > > > On 5/28/24 7:59 PM, Miklos Szeredi wrote: > > On Tue, 28 May 2024 at 10:52, Jingbo Xu > > wrote: > > > > > > Hi Peter-Jan, > > > > > > Thanks for the amazing work. > > > > > >

Re: [PATCH 2/2] virtio-fs: add multi-queue support

On Tue, 2024-05-28 at 13:59 +0200, Miklos Szeredi wrote: > External email: Use caution opening links or attachments > > > On Tue, 28 May 2024 at 10:52, Jingbo Xu > wrote: > > > > Hi Peter-Jan, > > > > Thanks for the amazing work. > > > > I'd just like to know if you have any plan of making

Re: [PATCH 1/2] virtio-fs: limit number of request queues

t 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 reso

[PATCH 0/2] virtio-fs: change handling of failure at request enqueue

not be another completion to trigger retrying the enqueue. Note that this patch series is a revival of my patch that was last discussed in the mailing list on 2023-08-16. Peter-Jan Gootzen (2): virtio-fs: let -ENOMEM bubble up or burst gently virtio-fs: improved request latencies when Virtio queue

[PATCH 2/2] virtio-fs: improved request latencies when Virtio queue is full

of the Virtio queue and a DPU-powered virtio-fs device (NVIDIA BlueField DPU). Signed-off-by: Peter-Jan Gootzen Reviewed-by: Max Gurtovoy Reviewed-by: Yoray Zack --- fs/fuse/virtio_fs.c | 34 +++--- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/fs/fuse

[PATCH 1/2] virtio-fs: let -ENOMEM bubble up or burst gently

, and by dropping the operation in case of a forget. This behavior matches that of the FUSE layer above, and also simplifies the error handling. The latter will come in handy for upcoming patches that optimize the retrying of operations in case of -ENOSPC. Signed-off-by: Peter-Jan Gootzen Reviewed-by: Max

[PATCH 2/2] virtio-fs: add multi-queue support

| +---=---+--+---+ Signed-off-by: Peter-Jan Gootzen Signed-off-by: Yoray Zack Signed-off-by: Max Gurtovoy --- fs/fuse/virtio_fs.c | 70 +++-- 1 file changed, 62 insertions(+), 8 deletions(-) diff --git a/fs/fuse

[PATCH 1/2] virtio-fs: limit number of request queues

of initialized request queues to the number of CPUs, to limit the resource consumption on the device-side and to prepare for the upcoming multi-queue patch. Signed-off-by: Peter-Jan Gootzen Signed-off-by: Yoray Zack Suggested-by: Max Gurtovoy Reviewed-by: Max Gurtovoy --- fs/fuse/virtio_fs.c | 3

[PATCH 0/2] virtio-fs: introduce multi-queue support

message of the second patch for performance results. Peter-Jan Gootzen (2): virtio-fs: limit number of request queues virtio-fs: add multi-queue support fs/fuse/virtio_fs.c | 73 - 1 file changed, 65 insertions(+), 8 deletions(-) -- 2.34.1