> From: Caitlin Bestler [ mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 04, 2005 11:18 AM
>
> On 5/4/05, Fab Tillier <[EMAIL PROTECTED]> wrote:
> > > From: Dan Bar Dov [ mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, May 04, 2005 1:00 AM
> > >
> > > Voltair's IB based ISER indeed uses kDAPL so it will be very simple to
> > > atapt it to iWARP.
> > >
> > > Voltaire's kDAPL supports FMR using PLATFORM registration type, and it
> > > is used by the ISER implementation.
> > >
> >
> > Why doesn't iSER just use a single un-translated MR for all of physical
> > memory (like the other kernel ULPs)? It would then just call the DMA
> > mapping functions and be done with it - no registration at all is going
> > to be faster than FMRs.
> >
>
>
> An FMR can be used to advertise a target buffer that is being read into
> as a single logical buffer. Using physical memory would require
>
> a) exporting the physical page list of where your buffers were (making
> the buffer advertisement larger and more complex)
>
> b) Trusting whoever is on the other end of the connection with access
> to your entire physical memory.
I assume that iSER (like SRP) supports scatter gather in I/O requests, so a)
shouldn't matter - that is, I expect that the storage subsystem hands the
iSER driver a list of physical addresses and a SCSI-like command. Copying
the page list is far simpler than getting a virtual address.
I see no issue with trusting I/O controllers on the fabric. They are no
more a threat than local I/O controllers. This addresses issue b).
In the future world of virtualized environments, I can assure that we trust no device or fabric even for local I/O. Fabrics like IB are no different in this regard and are subject to more types of errors / attacks. As such, people need to agree on what is the scope of a given trust domain and determine whether the proposed solution is sufficient or not. What has been discussed here may be fine for some environments but I can think of enterprise environments where it would not be trusted to the same extent.
Mike
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
