All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: SCSI Mailing List <linux-scsi@vger.kernel.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH RFC] modify iscsi layer to support software iscsi targets
Date: Wed, 23 Aug 2006 23:09:07 -0400	[thread overview]
Message-ID: <44ED1853.3000603@cs.wisc.edu> (raw)

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

The attached patch, from Tomo, takes a older version of the open-iscsi
initiator code and modifies it so that a software target that hooks into
tgt could reuse the data patch and transport class code.

After talking with several people at OLS, we realized that many people
do not agree as to where to implement a software iscsi target.

There is the do it completely in userspace camp. This can be done and
with net channels, network kevents or net splice on the horizon this
option is appealing.

The other option is to do it completely in the kernel. This has already
been rejected with the IET submission and scst discussion and the tgt
framework already pushes most of that code to userspace so there is no
point in pursing this right now.

And the last option would be something that hooks into iscsi layer in
mainline and tgt. This is what the attached patch implements. It has the
benefit that we can use the iscsi layer that is already in the kernel
with little modification. That iscsi layer is optimized to run from the
network sofirq and to be zero copy for the larger data transfers. The
tgt framework provides zero copy on the target side so we get to take
advantage of all that code. The disadvantage to this is that, probably
in the future tgt should work with the kevent and other async apis that
are being proposed so we should be working twords that goal right from
the beginning. Also, where we feel we would be using the iscsi kernel
code sort of how you would open a TCP socket and read and write to it
from userspace today, many people feel that any target code that can be
done in userspace should be done there. And for that argument we do not
have answer. As we said below we can do this in userspace, but we wanted
to reuse the initiator code when possible.

The attached path was made against a older iscsi tree so do not bother
reviewing it. I only attach it incase someone really wants to see the
code. I wanted to get feedback from others before I either port it to
the upstream iscsi code or reject it and help out on a completely
userspace software iscsi target.

[-- Attachment #2: add-iscsi-tgt.patch.bz2 --]
[-- Type: application/x-bzip, Size: 13657 bytes --]

                 reply	other threads:[~2006-08-24  4:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=44ED1853.3000603@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-scsi@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.