From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 21:51:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2FBB16A4CE for ; Thu, 23 Sep 2004 21:51:53 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 496AB43D45 for ; Thu, 23 Sep 2004 21:51:53 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 9036 invoked by uid 89); 23 Sep 2004 21:51:52 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 23 Sep 2004 21:51:52 -0000 Received: (qmail 9013 invoked by uid 89); 23 Sep 2004 21:51:51 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 23 Sep 2004 21:51:51 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8NLpnmt074069; Thu, 23 Sep 2004 17:51:50 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <41533E0D.9000908@elischer.org> References: <41508FEB.6030203@elischer.org><20040923191423.GE61631@FreeBSD.org> <41532FA0.6030405@elischer.org><41533E0D.9000908@elischer.org> Content-Type: text/plain Message-Id: <1095976309.53798.8390.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 17:51:49 -0400 Content-Transfer-Encoding: 7bit cc: Sam cc: re@freebsd.org cc: "freebsd-arch@freebsd.org" Subject: Re: AoE for 4.x X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2004 21:51:54 -0000 Since a complete disk operation in AoE is encapsulated in a single Ethernet request/response pair - The data size of a read/write operation is smaller than a single page. I don't think any existing framework can deal with this efficiently. Stephan On Thu, 2004-09-23 at 17:20, Julian Elischer wrote: > you could look at the sbp driver that is part of the firewire code.. > I think that may be the closest analog. > > > Sam wrote: > > > On Thu, 23 Sep 2004, Julian Elischer wrote: > > > >> I think that if you have a working driver we can assign you a number. > >> I do have some questions however.. > >> > >> this is AoE.. is it not possible at all to combne it with either the CAM > >> framework (such as the atapicam stuff) or the existing ATA stuff.. > >> Don't take this the wrong way.. it's just a question.. > >> CAM is being used to talk to drives over firewire, usb, ata, scsi, > >> fibrechannel. > >> it would seem that to unify this would be something that we should > >> look at.. > >> Of course CAM itslef is showing its age in soem places and it could > >> do with some work itself.. > > > > > > It might be possible to plug into the CAM; I only briefly > > glanced at it and it didn't appear appropriate. The ATA > > layer definitely isn't as parts of ATA don't make sense > > in this context (Read DMA, Read Multiple, eg) and AoE > > devices don't conform to the simple hardware probe/attach > > methodology (as I understand it). > > > > I would love to be proved wrong. I'm always willing to > > try a new approach if it's demonstrably better. > > > > Sam > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >