Linux Device Mapper development
 help / color / mirror / Atom feed
From: Malahal Naineni <malahal@us.ibm.com>
To: dm-devel@redhat.com
Subject: Re: multipath: change the DEFAULT_MINIO for the request based multipath
Date: Tue, 25 Jan 2011 18:23:07 -0800	[thread overview]
Message-ID: <20110126022307.GA512@us.ibm.com> (raw)
In-Reply-To: <4D3E9020.6010009@ce.jp.nec.com>

Jun'ichi Nomura [j-nomura@ce.jp.nec.com] wrote:
> >> 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.
> 
> Do we really need [2]?
> 
> Currently, there seem only 3 minio values in per-hardware default:
>   - 1000 (DEFAULT_MINIO)
>   - 128
>   - 100
> 
> I think both 128 and 100 are based on that, in many systems/cases,
> max request size (max_sectors) is 512KB and BIO submission
> is done in page-size unit (4KB).
> 
> If there isn't strong reason for the current default (1000)
> (and I think there isn't), it seems we can remove [2]
> after changing the default to 128 (or 100).
> 
> > 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.
> 
> Does it mean users can't change rr_min_io value for request-based dm?
> I suspect it is possible that someone wants to set non-default
> value to minio for request-based dm.

Your reading is correct that my proposal doesn't allow it. If we get away
with [2] above (hwatable.c based values), then we can have something
like this:

1. Remove it from hwentry structure or set it to -1
2. If rr_minio is specified in the conf file (either through default or
   device section etc), use it.
3. If not specified in the config file, use DEFAULT_BIO_MINIO or
   DEFAULT_REQUEST_MINIO based on the multipath module version.

In other words, every device out there uses DEFAULT_BIO_MINIO or
DEFAULT_REQUEST_MINIO if not specified by the administrator.
Admin can override it in /etc/multipath.conf file.

CON: No per device controller default  (aka hwtable entry value)

Thanks, Malahal.

  reply	other threads:[~2011-01-26  2:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19 21:30 [PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath Malahal Naineni
2011-01-20  7:32 ` Hannes Reinecke
2011-01-20 16:07   ` Mike Snitzer
2011-01-21  7:03     ` Jun'ichi Nomura
2011-01-21  8:47       ` Christophe Varoqui
2011-01-21 14:12         ` Mike Snitzer
2011-01-21 14:46           ` Christophe Varoqui
2011-01-21 17:39             ` Malahal Naineni
2011-01-25  8:56               ` Jun'ichi Nomura
2011-01-26  2:23                 ` Malahal Naineni [this message]
2011-01-26 17:27                   ` nishant mungse
2011-01-27 15:16                     ` nishant mungse
2011-01-31 23:53                   ` Christophe Varoqui
2011-02-01  2:21                     ` Malahal Naineni
2011-02-01  3:13                       ` Mike Snitzer
2011-02-01  8:14                         ` Malahal Naineni
2011-02-01  8:13                     ` Malahal Naineni
2011-02-01  9:00                       ` Christophe Varoqui
2011-02-01  9:51                         ` Malahal Naineni
2011-01-21 13:26       ` Mike Snitzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110126022307.GA512@us.ibm.com \
    --to=malahal@us.ibm.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox