Christophe Varoqui [christophe.varoqui@xxxxxxxxx] wrote: > > > 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 ? I don't think so. Your reasoning is right. How about this: 1. Set DEFAULT_MINIO to -1 2. If bio based mapping and the value is -1, set it to 1000 (DEFAULT_BIO_MINIO) 3. If request based mapping, set it to DEFAULT_REQUEST_MINIO. Note that devices can't have individual hardware default for request based mappings in this method and I think that should be OK. They are allowed to individual hardware based default for BIO based mappings as they have now. I will code it up if everyone agrees. Thanks, Malahal. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
