Re: [PATCH v3 01/18] block: introduce duration-limits priority class

[Bart Van Assche <bvanassche@acm.org>]

On 1/26/23 05:53, Niklas Cassel wrote:
> On Thu, Jan 26, 2023 at 09:24:12AM +0900, Damien Le Moal wrote:
>> But again, the difficulty with this overloading is that we *cannot* implement a
>> solid level-based scheduling in IO schedulers because ordering the CDLs in a
>> meaningful way is impossible. So BFQ handling of the RT class would likely not
>> result in the most ideal scheduling (that would depend heavily on how the CDL
>> descriptors are defined on the drive). Hence my reluctance to overload the RT
>> class for CDL.
> 
> Well, if CDL were to reuse IOPRIO_CLASS_RT, then the user would either have to
> disable the IO scheduler, so that lower classdata levels wouldn't be prioritized
> over higher classdata levels, or simply use an IO scheduler that does not care
> about the classdata level, e.g. mq-deadline.

How about making the information about whether or not CDL has been 
enabled available to the scheduler such that the scheduler can include 
that information in its decisions?

> However, for CDL, things are not as simple as setting a single bit in the
> command, because of all the different descriptors, so we must let the classdata
> represent the device side priority level, and not the host side priority level
> (as we cannot have both, and I agree with you, it is very hard define an order
> between the descriptors.. e.g. should a 20 ms policy 0xf descriptor be ranked
> higher or lower than a 20 ms policy 0xd descriptor?).

How about only supporting a subset of the standard such that it becomes 
easy to map CDLs to host side priority levels?

If users really need the ability to use all standardized CDL features 
and if there is no easy way to map CDL levels to an I/O priority, is the 
I/O priority mechanism really the best basis for a user space interface 
for CDLs?

Thanks,

Bart.