Re: multipath: change the DEFAULT_MINIO for the request based multipath

[Christophe Varoqui <christophe.varoqui@gmail.com>]

> I'm not following why we'd need a different configuration parameter.
> It is just that the default rr_min_io that would be used would be
> conditional on the multipath target version being >= 1.1.0.
> 
Defaults are layered. For current minio, we have :
[1] one top level default (hardcoded, superseded by config)
[2] per hardware default (hardcoded, superseded by config)
[3] per multipath value (none hardcoded, defined by config)

You suggest multipath-tools to adapt only the top level minio default
depending on dm-rq availability [1], but what of the hwtable defaults
[2] ? Should we provide vendors with a way to describe a with-rq minio
default *and* a without-rq minio default (a new parameter in the hwentry
struct) ? If so, we should also provide a new config file keyword to
override this new hwentry parameter hardcoded value ... then the
reasoning cascades to the mpentry struct minio setting [3].

Actually, [1] is hardly the common case : only unknown hardware resort
to these defaults.

Is my reasoning flawed ?