AoE for 4.x

Stephan Uphoff ups at tree.com
Thu Sep 23 14:51:54 PDT 2004


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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 
> 



More information about the freebsd-arch mailing list