All of lore.kernel.org
 help / color / mirror / Atom feed
From: Isaac Huang <He.Huang@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Credits, peer credits and concurrent sends
Date: Tue, 24 Feb 2009 14:09:16 -0500	[thread overview]
Message-ID: <20090224190916.GA12305@sun.com> (raw)
In-Reply-To: <FCCFA143-03D6-45C3-93EC-61F106BF8193@myri.com>

On Tue, Feb 24, 2009 at 01:32:25PM -0500, Scott Atchley wrote:
> Hi all,
> 
> I am updating MXLND. I am looking at O2IBLND as a reference and I am  
> wondering what is the difference between the above module parameters?
> 
> The o2iblnd_modparams.c file has:
> 
> static int credits = 64;
> CFS_MODULE_PARM(credits, "i", int, 0444,
>                  "# concurrent sends");
> 
> static int peer_credits = 8;
> CFS_MODULE_PARM(peer_credits, "i", int, 0444,
>                  "# concurrent sends to 1 peer");

These two controls LNet-layer send credits - how many LNet messages
could be sent concurrently over a NI and a peer, respectively.

> #if IBLND_MAP_ON_DEMAND
> static int concurrent_sends = IBLND_RX_MSGS;
> #else
> static int concurrent_sends = IBLND_MSG_QUEUE_SIZE;
> #endif
> CFS_MODULE_PARM(concurrent_sends, "i", int, 0444,
>                  "send work-queue sizing");
> 
> where IBLND_MSG_QUEUE_SIZE is 8.

The concurrent_sends controls the number of o2iblnd messages that
could be posted to a connection (and its QP) concurrently.

The difference between LNet messages and o2iblnd messages is: 1. A
LNet message is usually transfered by several o2iblnd messages (e.g.
setting up RDMA transfer). 2. Some o2iblnd messages have nothing to do
with LNet-layer messages (e.g. NOOP, which carries LND credits and
keepalive data).

The reason why we must limit the number of concurrent o2iblnd messages 
posted to a connection is very specific to this LND - it has something
to do with RDMA fragments and QP and CQ sizing. I wouldn't elaborate,
unless you're very interested, because it only applies to the o2iblnd
and probably wouldn't be an issue for the MXLND.

The peer_credits alone couldn't limit the concurrent o2iblnd messages
because some o2iblnd messages (like PUT_ACK, GET_DONE) are responses
to peer's requests and are thus not limited by LNet peer tx credits at
my side.

That's why we had to add concurrent_sends.

> Can anyone elaborate on differences and relationships (e.g. what does  
> it mean if concurrent_sends is greater than peer_credits or is that  
> not allowed)?

In theory, it's possible. It simply means that concurrent o2iblnd
messages allowed is more than concurrent LNet messages allowed.

On the other hand, some LNDs (like the o2iblnd) also implements
LND-layer tx credits, which seems very confusing together with the
LNet tx credits. One important difference between the two is, LNet tx
credits are returned when send operations complete locally and the
local message buffer could be reused, while LND tx credits are returned
by peers over the wire when my peers have reposted their receive buffers.
In short, LND tx credits usually protects remote buffers and LNet tx
credits prevent LNet from overcommitting an interface or a peer.

Hope this helps,
Isaac

      reply	other threads:[~2009-02-24 19:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24 18:32 [Lustre-devel] Credits, peer credits and concurrent sends Scott Atchley
2009-02-24 19:09 ` Isaac Huang [this message]

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=20090224190916.GA12305@sun.com \
    --to=he.huang@sun.com \
    --cc=lustre-devel@lists.lustre.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.