All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Barton <eeb@whamcloud.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] discontiguous kiov pages
Date: Thu, 9 Jun 2011 15:38:11 +0100	[thread overview]
Message-ID: <00f101cc26b2$dce80890$96b819b0$@com> (raw)
In-Reply-To: <58BFE163-3240-4C11-9088-6ABB05EB4646@whamcloud.com>

It seems to me that Jay's suggestion to put the niobufs into
separate RPCs is a good one - particularly since writing the 2nd
niobuf should only be attempted after the first to ensure the
file size is set correctly (BTW this means the 2nd RPC cannot
be posted until the first has completed - otherwise the RPCs
could get re-ordered in the network or at the server).  

However it would be nice to aggregate small, possibly unrelated
I/Os and if/when we do that this issue will crop up again.  If
we stick with the rule that MDs cannot have internal partial pages,
we're forced to use 1 MD for each niobuf.  Putting several of these
in 1 RPC requires separate matchbits for each niobuf to ensure
correct match of source and sink buffers independent of races in
the network.  This must be more efficient than scheduling multiple 
concurrent RPCs each with 1 niobuf, but by how much isn't clear,
since the bulk transfer phases of both schemes should cause identical
network traffic.  

So aggregation will probably require LNET/LND support for MDs with
internal partial pages.  At a guess, this will have strict limits
for some LNDs and probably can't be done without reducing the total
number of fragments in such messages.  Also, the interaction with
LNET routers needs to be considered since mismatched RDMA descriptors
can potentially double the number of actual RDMA fragments on the
wire.

          Cheers,
                   Eric

      reply	other threads:[~2011-06-09 14:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02  2:33 [Lustre-devel] discontiguous kiov pages wang
2011-06-02 13:19 ` Eric Barton
2011-06-07 23:57   ` Oleg Drokin
2011-06-08 16:08     ` Nic Henke
2011-06-08 20:09       ` Jinshan Xiong
2011-06-09  8:37         ` Peter Jones
2011-06-09  3:16       ` Oleg Drokin
2011-06-09 14:38         ` Eric Barton [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='00f101cc26b2$dce80890$96b819b0$@com' \
    --to=eeb@whamcloud.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.