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.
