Re: [PATCH] fuse: make foffset alignment opt-in for optimum backend performance

[Jingbo Xu <jefflexu@linux.alibaba.com>]

On 8/29/24 3:51 PM, Miklos Szeredi wrote:
> On Fri, 5 Jul 2024 at 14:00, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
>> I'm okay with resuing max_pages as the alignment constraint.  They are
>> the same in our internal scenarios.  But I'm not sure if it is the case
>> in other scenarios.
> 
> max_pages < alignment makes little sense.
> 
> max_pages = n * alignment could make sense, i.e. allow writes that are
> whole multiples of the alignment.

Agreed.

> 
> I'm not against adding a separate alignment, but it could be just
> uint8_t to take up less space in init_out.   We could have done that
> with max_stack_depth too.   Oh well...

Make sense, as the new added fuse_init_out.opt_alignment is already
log2(byte alignment).  I think uint8_t is already adequate in this case.
(Actually I'm going to rename @opt_alignment field of fuse_init_out to
something like @log_opt_align to indicate it's actually a log2() value
as Berned previously suggested)

Besides, I'm not sure if it's worth adding a new init flag, i.e.
FUSE_OPT_ALIGNMENT, as the init flag bits are continually consumed.
Maybe we could stipulate that a zero log_opt_align indicates no
alignment constraint (the default behavior), while a non-zero
log_opt_align indicates an alignment constraint.  However IIUC the user
daemon may or may not zero the unused fields of fuse_init_out.  Thus if
a fuse server not supporting opt_alignment doesn't zero
fuse_init_out.unused, then the kernel side will enforce an alignment
constraint unexpectedly.


-- 
Thanks,
Jingbo