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

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

On 1/27/23 16:40, Damien Le Moal wrote:
> On 1/28/23 02:23, Bart Van Assche wrote:
>> I hope that I have it made it clear that I think that the proposed user
>> space API will be very painful to use for application developers.
> 
> I completely disagree. Reusing the prio class/level API made it easy to allow
> applications to use the feature. fio support for CDL requires exactly *one line*
> change, to allow for the CDL class number 4. That's it. From there, one can use
> the --cmdprio_class=4 nd --cmdprio=idx options to exercise a drive. The value of
> "idx" here of course depends on how the descriptors are set on the drive. But
> back to the point above. This depends on the application goals and the
> descriptors are set accordingly for that goal. There is no real discovery needed
> by the application. The application expect a certain set of CDL limits for its
> use case, and checking that this set is the one currently defined on the drive
> is easy to do from an application with the sysfs interface we added.
> 
> Many users out there have deployed and using applications taking advantage of
> ATA NCQ priority feature, using class RT for high priority IOs. The new CDL
> class does not require many application changes to be enabled for next gen
> drives that will have CDL.
  As I mentioned before, the new I/O priority class IOPRIO_CLASS_DL 
makes it impossible to use a single I/O priority class across devices 
that support CDL and devices that do not support CDL. I'm surprised that 
you keep denying that IOPRIO_CLASS_DL is a royal pain for users who have 
to support devices that support CDL and devices that do not support CDL.

Bart.