Re: An alternative way to handle IO engine options

[Jens Axboe <axboe@kernel.dk>]

On 2011-11-01 21:16, Steven Lang wrote:
> This isn't quite ready to be a patch yet, but I wanted to get some
> feedback before I put in time polishing it to patch level.
> 
> The idea has been bouncing around in my head that some IO engines have
> unique parameters.  However, fio has no way to make engine specific
> parameters, aside from doing special cases in the options parsing, or
> using some option in a convoluted way it wasn't intended for.  For
> example, the libaio:userspace_reap option, and the net IO engine
> turning the filename into a series of fields you have to know the
> correct syntax and order for.
> 
> Neither of these options seem ideal to me; the first requires special
> casing and limits it to a single option, the second results in
> potentially cryptic requirements.
> 
> At the same time, though, there is only one place in the config
> parsing/management which assumes there is a single config
> (options_mem_dupe) - everything else is told what the options are and
> treats the data as a mostly opaque block of memory, even though it is
> just a single global variable and a fixed config structure.  This
> seems like it is just begging to be re-used within the IO engine
> framework to parse custom options.  So that is what I have done.  For
> now in this code just the libaio userspace_reap option has been
> changed, but it would make sense to apply the same treatment to the
> net IO engine.
> 
> The basic idea is it looks through the config section and makes note
> of any unrecognized options, rather than reporting them right away.
> Then it loads the requested IO engine and runs through the unknown
> options against the IO engine config.  At that point, any unknown
> options are reported.
> 
> There are a few things not finished yet...
> 1. Right now it is conf parsing only; command line parsing never sees
> the new options (But I have a plan, with the restriction that the IO
> engine must be named before its options can be used)
> 2. Documentation for the userspace_reap option will need to be changed.
> 3. There's currently no way to handle IO engine options in the [global] section.
> 
> Do you see any problems with this approach to handling options that
> are specific to a single IO engine?

I like this a lot, I've been thinking about private options in the past
and things like userspace_reap is indeed just a nasty hack. It would be
very nice to handle this in a more generic fashion. We would need to
solve the generic vs global name space problem though, otherwise that's
just a problem waiting to happen. Apart from that, I would not have any
problems merging this feature.

-- 
Jens Axboe