<html>
<body>
<font size=3>At 11:31 AM 5/4/2005, Fab Tillier wrote:<br>
<blockquote type=cite class=cite cite="">> From: Caitlin Bestler
[<a href="mailto:caitlin.bestler@gmail.com" eudora="autourl">
mailto:caitlin.bestler@gmail.com</a>]<br>
> Sent: Wednesday, May 04, 2005 11:18 AM<br>
> <br>
> On 5/4/05, Fab Tillier <ftillier@infiniconsys.com> wrote:<br>
> > > From: Dan Bar Dov
[<a href="mailto:danb@voltaire.com" eudora="autourl">
mailto:danb@voltaire.com</a>]<br>
> > > Sent: Wednesday, May 04, 2005 1:00 AM<br>
> > ><br>
> > > Voltair's IB based ISER indeed uses kDAPL so it will be
very simple to<br>
> > > atapt it to iWARP.<br>
> > > <br>
> > > Voltaire's kDAPL supports FMR using PLATFORM registration
type, and it<br>
> > > is used by the ISER implementation.<br>
> > ><br>
> ><br>
> > Why doesn't iSER just use a single un-translated MR for all of
physical<br>
> > memory (like the other kernel ULPs)? It would then just
call the DMA<br>
> > mapping functions and be done with it - no registration at all
is going<br>
> > to be faster than FMRs.<br>
> ><br>
> <br>
> <br>
> An FMR can be used to advertise a target buffer that is being read
into<br>
> as a single logical buffer. Using physical memory would require<br>
> <br>
> a) exporting the physical page list of where your buffers were
(making<br>
> the buffer advertisement larger and more
complex)<br>
> <br>
> b) Trusting whoever is on the other end of the connection with
access<br>
> to your entire physical memory.<br><br>
I assume that iSER (like SRP) supports scatter gather in I/O requests, so
a)<br>
shouldn't matter - that is, I expect that the storage subsystem hands
the<br>
iSER driver a list of physical addresses and a SCSI-like command.
Copying<br>
the page list is far simpler than getting a virtual address.<br><br>
I see no issue with trusting I/O controllers on the fabric. They
are no<br>
more a threat than local I/O controllers. This addresses issue
b).</blockquote><br>
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.<br><br>
Mike</font></body>
</html>