On 10/13/23 03:00, Bart Van Assche wrote: > On 10/11/23 18:02, Damien Le Moal wrote: >> Some have stated interest in CDL in NVMe-oF context, which could >> imply that combining CDL and lifetime may be something useful to do >> in that space... > > We are having this discussion because bi_ioprio is sixteen bits wide and > because we don't want to make struct bio larger. How about expanding the > bi_ioprio field from 16 to 32 bits and to use separate bits for CDL > information and data lifetimes? I guess we could do that as well. User side aio_reqprio field of struct aiocb, which is used by io_uring and libaio, is an int, so 32-bits also. Changing bi_ioprio to match that should not cause regressions or break user space I think. Kernel uapi ioprio.h will need some massaging though. > This patch does not make struct bio bigger because it changes a three > byte hole with a one byte hole: Yeah, but if the kernel is compiled with struct randomization, that does not really apply, doesn't it ? Reading Niklas's reply to Kanchan, I was reminded that using ioprio hint for the lifetime may have one drawback: that information will be propagated to the device only for direct IOs, no ? For buffered IOs, the information will be lost. The other potential disadvantage of the ioprio interface is that we cannot define ioprio+hint per file (or per inode really), unlike the old write_hint that you initially reintroduced. Are these points blockers for the user API you were thinking of ? How do you envision the user specifying lifetime ? Per file ? Or are you thinking of not relying on the user to specify that but rather the FS (e.g. f2fs) deciding on its own ? If it is the latter, I think ioprio+hint is fine (it is simple). But if it is the former, the ioprio API may not be the best suited for the job at hand. -- Damien Le Moal Western Digital Research
