[openib-general] FMR and how they work

Michael Krause krause at cup.hp.com
Wed May 4 13:59:55 PDT 2005


At 11:31 AM 5/4/2005, Fab Tillier wrote:
> > From: Caitlin Bestler [mailto:caitlin.bestler at gmail.com]
> > Sent: Wednesday, May 04, 2005 11:18 AM
> >
> > On 5/4/05, Fab Tillier <ftillier at infiniconsys.com> wrote:
> > > > From: Dan Bar Dov [mailto:danb at voltaire.com]
> > > > 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050504/b296f9c2/attachment.html>


More information about the general mailing list