Subject: Querry !

From: Kaushik Datta <[email-masked]>
Date: Fri, 09 Nov 2001 20:51:00 +0530

Hello all,

       We are a group of Engineers working on an idea related to the
   scsi subsystem in FreeBSD.We have approached this project from the
   perspective of iscsi.The project revolves around using iscsi target
   stack on FreeBSD and the changes  that (we feel) can be made to the
   scsi subsystem in FreeBSD.As we all know that the FreeBSD scsi
   system adheres to the CAM architecture model, wherein we have an
   upper layer of driver pertaining to different kinds of devices, disk,
   tape etc.Now this upper layer drivers or Peripheral modules(PM) takes
   the task of forming the scsi CDB and passes it on to the CAM transport
   layer or the XPT layer.This transport layer then forms a CCB and
   passes it further on to the lower layer SIM HBA driver.
   Now iscsi pdu carry scsi cdb as a part of it.But in the existing
   scsi subsystem in FreeBSD, the PM layer takes care of forming the
   scsi pdu in case of a normal I/O operation.Now assuming iscsi
   target stack running on the machine, won't it be feasible if we
   can write a pseudo driver that takes care of the fetching the
   scsi cdb as such and passing it on to the SIM driver ? In a
   way we will get away from the PM functionality which forms the
   scsi CDB in case of a normal I/O.Now where exactly this driver
   should fit ? Should this use the xpt transport layer functionality
   which takes care of the routing decision and device initialization?

   Any ideas related to the design will be of great help.Also we would
   like to know if any group is working on implementing iscsi stack
   on FreeBSD.

   Thanks for your patience !
   Kaushik

---

From: Stephen Bailey <[email-masked]>
Date: Sun, 11 Nov 2001 16:22:40 -0500

Kaushik,

I'm not quite sure what your proposing here, but something seems
wrong.  Just fyi, I have worked on several CAM-based initiators (who
was it that was saying CAM was never implemented?).

You have mentioned `iSCSI target stack' several times.  Are you trying
to make FreeBSD behave like a storage target?  If so, you should
probably not be using CAM at all.  CAM is about implementing
initiators.  It does define a target mode path, but it is relatively
limited in scope.  CAM target mode is good for implementing a SCSI
processor target (for things like cluster communication and bus
pinging), but I don't think it was intended for a richer target
(e.g. a storage target).  It's defined for connectivity, but not
performance in the target role.

If you are trying to make a FreeBSD iSCSI initiator, then what your
saying here:

> won't it be feasible if we can write a pseudo driver that takes care
> of the fetching the scsi cdb as such and passing it on to the SIM
> driver ? In a way we will get away from the PM functionality which
> forms the scsi CDB in case of a normal I/O.

doesn't make sense to me.  You don't want to `get away' from the
periperal drivers, since the are your ultimate clients.  The whole
design of CAM is to allow peripheral drivers (disk, tape, etc, for the
unCAM-oriented) and SIMs (SCSI Interface Modules, aka adapter drivers)
to be independent so that the same PDs work no matter what SIM.

To make a FreeBSDI iSCSI initiator, you need to write an iSCSI SIM.
To do that, you probably shouldn't start with an iSCSI target stack.

One trick doing this with CAM is that it didn't really anticipate the
different addressing characteristics of the various SCSI transports (a
problem not unique to CAM).  CAM was designed anticipating lots of
different ||SCSI adapters, rather than adapters with completely
different transports.  The standard solution to this (done in FCP, for
example), is to store some transport-specific translation state in
your SIM to map, say, target xx to a particular transport address (an
FC WWN, or iSCSI socket address).

Another trick will be getting to the network stack from the SCSI
stack, and vice versa.  Not impossible, but you may have to be careful
calling the network stack from the storage stack, as they're typically
in different synchronization domains.  Sometimes trying to get
synchronized on both domains simultaneously can lead to surprising
deadlocks.

Steph