From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: SATA "target mode" (or "Channel-to-Channel" comm mode) Date: Tue, 03 Mar 2009 09:37:19 -0500 Message-ID: <49AD409F.6040102@rtr.ca> References: <49AD34F4.8090008@rtr.ca> <49AD3BA5.3080603@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from rtr.ca ([76.10.145.34]:56804 "EHLO mail.rtr.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755020AbZCCOhX (ORCPT ); Tue, 3 Mar 2009 09:37:23 -0500 In-Reply-To: <49AD3BA5.3080603@pobox.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jeff Garzik Cc: Tejun Heo , Alan Cox , IDE/ATA development list Jeff Garzik wrote: > 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. .. Except it's rather SCSI specific, and the userspace frontend even more so. The code expects a SCSI command block, LUN, TAG, and other fields that a SATA FIS won't have. Seems clumsy, particularly when we (in theory) are trying to decouple libata from SCSI. But if that's the way, then I can clumsily wrap each FIS in a fake ATA_16 header or something. > 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. .. Absolutely, which is why I'm leaving that for (much) later, and looking for a simple (userspace) comms method to begin with, using the special (non-SATA compliant) "initiator" on one end, and a "target" on the other end. This is different from the SATA interceptor/emulator configurations. .. > 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. .. That part's easy, and already implemented: module parameter + sysfs attrs. Cheers