On 1/31/23 11:49, Martin K. Petersen wrote: > > Damien, > >> Makes sense. Though I think it will be hard to define a set of QoS >> hints that are useful for a wide range of applications, and even >> harder to convert the defined hint classes to CDL descriptors. I fear >> that we may end up with the same issues as IO hints/streams. > > Hints mainly failed because non-Linux OSes had very different > expectations about how this was going to work. So that left device > vendors in a situation where they had to essentially support 3 different > approaches all implemented using the same protocol. > > The challenge of being a general purpose OS is to come up with concepts > that are applicable in a variety of situations. Twiddling protocol > fields is the easy part. > > I have a couple of experienced CDL users that I'd like to talk to and > try to get a better idea of what a suitable set of defaults might look > like. > >> This hint applies to all priority classes and levels, that is, for the >> CDL case, we can enrich any priority with a hint that specifies the >> CDL index to use for an IO. > > Yeah, I like that approach better. Of note is that even though the IOPRIO_XXX macros in include/uapi/linux/ioprio.h assume a 16bits value for the priority class + data, of which only 6 bits are usable (3 for the class, 3 for the level), all syscall and kernel internal interface has ioprio defined as an int. So we have in fact 32 bits to play with. We could keep the lower 16 bits for ioprio as it was, and have the upper 16bits used for QOS hints. More room that the 10 bits between the prio class and level. The only place that will need changing is struct bio since bi_ioprio is defined as an unsigned short. To solve this, as Bart suggested, we could add another unsigned short in the bio struct hole for the qos hints (bi_iohint or bi_ioqoshint). But if we can define a sensible set of hints that covers at least CDL with the 10 free bits we have in the current ioprio, that would be even better I think (less changes needed in the block layer). -- Damien Le Moal Western Digital Research
