All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hitoshi Mitake <mitake.hitoshi@gmail.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: mitake.hitoshi@gmail.com, stgt@vger.kernel.org,
	mitake.hitoshi@lab.ntt.co.jp
Subject: Re: [PATCH RFC] tgtd: send/recv iSCSI PDUs in worker threads
Date: Sun, 10 Nov 2013 17:39:07 +0900	[thread overview]
Message-ID: <871u2ok5w4.wl%mitake.hitoshi@gmail.com> (raw)
In-Reply-To: <8738n4khfb.wl%mitake.hitoshi@gmail.com>

At Sun, 10 Nov 2013 13:30:00 +0900,
Hitoshi Mitake wrote:
> 
> At Thu, 7 Nov 2013 16:11:17 +0900,
> FUJITA Tomonori wrote:
> > 
> > On Wed, 06 Nov 2013 10:04:42 +0900
> > Hitoshi Mitake <mitake.hitoshi@gmail.com> wrote:
> > 
> > > At Tue, 05 Nov 2013 23:28:45 +0900 (JST),
> > > FUJITA Tomonori wrote:
> > > > 
> > > > On Mon,  4 Nov 2013 14:13:16 +0900
> > > > Hitoshi Mitake <mitake.hitoshi@gmail.com> wrote:
> > > > 
> > > > > From: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
> > > > > 
> > > > > Current tgtd sends and receives iSCSI PDUs in its main event
> > > > > loop. This design can cause bottleneck when many iSCSI clients connect
> > > > > to single tgtd process. For example, we need multiple tgtd processes
> > > > > for utilizing fast network like 10 GbE because typical single
> > > > > processor core isn't fast enough for processing bunch of requests.
> > > > > 
> > > > > This patch lets tgtd send/receive iSCSI PDUs and check digests in its
> > > > > worker threads. After applying this patch, the bottleneck in the main
> > > > > event loop is removed and the performance is improved.
> > > > > 
> > > > > The improvement can be seen even if tgtd and iSCSI initiator are
> > > > > running on a single host. Below is a snippet of fio result on my
> > > > > laptop. The workload is 128MB random RW. Backingstore is sheepdog.
> > > > > 
> > > > > original tgtd:
> > > > >   read : io=65392KB, bw=4445.2KB/s, iops=1111, runt= 14711msec
> > > > >   write: io=65680KB, bw=4464.8KB/s, iops=1116, runt= 14711msec
> > > > > 
> > > > > tgtd with this patch:
> > > > >   read : io=65392KB, bw=5098.9KB/s, iops=1274, runt= 12825msec
> > > > >   write: io=65680KB, bw=5121.3KB/s, iops=1280, runt= 12825msec
> > > > > 
> > > > > This change will be more effective when a number of iSCSI clients
> > > > > increases. I'd like to hear your comments on this change.
> > > > > 
> > > > > Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
> > > > > ---
> > > > >  usr/iscsi/iscsi_tcp.c | 291 +++++++++++++++++++++++++++++++++++++++++++++++---
> > > > >  usr/iscsi/iscsid.c    |  61 +++++++----
> > > > >  usr/iscsi/iscsid.h    |   4 +
> > > > >  3 files changed, 322 insertions(+), 34 deletions(-)
> > > > 
> > > > This change doesn't affect our complicated logic to handle outstanding
> > > > commands with tcp disconnection (e.g. conn_close() in conn.c)?
> > > 
> > > I think it doesn't affect the closing logic. Because any procedure
> > > other than send/recv and digest checking are not delegated to worker
> > > threads. Task queuing, connection closing, etc are done in main
> > > thread even now.
> > 
> > I've not read the patch but conn_close() has the code to handle a
> > response to be being sent when a tcp connection is closed.
> 
> Sorry, the above description is not correct. As you say, some
> send/recv would be done in the main event loop
> (e.g. iscsi_free_cmd_task()). But it wouldn't matter because
> the logic of connection closing is preserved, and connection closing
> isn't an event which affects performance of tgtd.

On the second thought, this patch cannot handle the case when
conn_close() doesn't release a connection. As you say, this would
conflict with the closing logic. I'll fix it and send v2 later.

Thanks,
Hitoshi

      reply	other threads:[~2013-11-10  8:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04  5:13 [PATCH RFC] tgtd: send/recv iSCSI PDUs in worker threads Hitoshi Mitake
2013-11-05 13:33 ` Hitoshi Mitake
2013-11-05 14:28 ` FUJITA Tomonori
2013-11-06  1:04   ` Hitoshi Mitake
2013-11-07  7:11     ` FUJITA Tomonori
2013-11-10  4:30       ` Hitoshi Mitake
2013-11-10  8:39         ` Hitoshi Mitake [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=871u2ok5w4.wl%mitake.hitoshi@gmail.com \
    --to=mitake.hitoshi@gmail.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=mitake.hitoshi@lab.ntt.co.jp \
    --cc=stgt@vger.kernel.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.