From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: SATA "target mode" (or "Channel-to-Channel" comm mode) Date: Tue, 03 Mar 2009 09:16:05 -0500 Message-ID: <49AD3BA5.3080603@pobox.com> References: <49AD34F4.8090008@rtr.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:48559 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752017AbZCCOQU (ORCPT ); Tue, 3 Mar 2009 09:16:20 -0500 In-Reply-To: <49AD34F4.8090008@rtr.ca> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Mark Lord Cc: Tejun Heo , Alan Cox , IDE/ATA development list 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