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