Re: SATA "target mode" (or "Channel-to-Channel" comm mode)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mark Lord wrote:
Guys,

Within the next couple of weeks, I would like to submit patches
for 2.6.30 for a simple form of what Marvell likes to call "target mode",
or C2C (channel-to-channel communications).

This is for sata_mv.

The question is, how to expose an interface to actually access it?

Quick background on Marvell C2C:

1. C2C is only for Gen2 and Gen2e chipsets.

2. Requires a special SATA cross-over (simple twist) cable
   between two SATA ports.  Ports can be on the same host
   adaptor or on separate adaptors and/or machines.

3. Each sata_mv port can be either a (0) normal SATA host,
   or (1) special SATA C2C initiator, or (2) a SATA target device.

4. A Gen2e mode (2) target can connect/communicate with either
   a mode (0) host or a mode (1) initiator.  I'm not yet sure
   whether an older Gen2 target can connect with a mode (0) host.

5. Mode (1) initiator appears to relax requirements such as waiting
   for a device BUSY bit to clear etc., and is intended for simple
   channel-to-channel communications.

6. A boot/module parameter seems to be the best way to enable
   this feature, as otherwise libata wastes a lot of time and
   effort probing for non-existant drives and slowing down
   the boot process.

7. Initially, all that we want is a way to use two SATA ports
   (on the same or different machines) as a simple byte-stream
   communications channel, between a mode (1) inititiator
   and a mode (2) target.  This is used in real-life as a high-speed
   local comm channel between halves of split server machines.

8. Transparently emulating a SATA drive is possible on Gen2e chips
   at least, and perhaps also on Gen2 chips.  This is not being
   worked on at this time.

9. Using two ports in tandem, one mode (0) host and one mode (2) target,
   one can construct a quite capable SATA capture/analyzer device
   which could be inserted in between any other SATA host and device.
   Quite useful, and something I intend to work on later this year.

So, starting with simple stuff, I want to expose an interface for
point 7 above.  The thought is to use netlink for this, on both ends.

An alternative might be to tie it into the SCSI Target Framework (tgt).
But that is more for full target device emulation than for simple comms.
And SATA is not SCSI, so it could really restrict/prevent us from doing
a full SATA emulation (eg. point 9) in the end.

Time is short, so I'd like to spend it on something that Jeff would
actually accept.  Thus this email.

It depends on the task.

The miscdev (i.e. chrdev) interface found in drivers/scsi/scsi_tgt_if.c of repo [1] seems pretty generic, simple, small and applicable to portions of the problem presented here... The basic task in scsi_tgt_if's case is just shoveling packets to/from userspace.

The interface is going to depend on the implementations that wind up in the field, for each task.

SATA packet capture: highly useful, but implies _copying_ the packets before passing them on to regular channels. So, does this imply packets will be copied kernel->userspace->kernel ? kernel->kernel? The interface will be vastly different in each case.

SATA target: again, userspace or kernel? Presumably scsi_tgt_if.c is applicable to this task.

Also, in general, it sounds like we need a general way to put a port into a specific mode (initiator, target, vendor special) during runtime. Then create a module parameter that allows boot-time initialization of this port mode selector.

	Jeff



[1] http://www.kernel.org/git/?p=linux/kernel/git/tomo/linux-2.6-target.git;a=summary

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux