<html>
<body>
<font size=3>At 05:30 PM 9/21/2005, Caitlin Bestler wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">On 9/21/05, <b>Sean Hefty</b>
<<a href="mailto:mshefty@ichips.intel.com">mshefty@ichips.intel.com</a>
</font>> wrote:<br>
<dl>
<dd>Caitlin Bestler wrote:<br>
<dd>> That's certainly an acceptably low overhead for iWARP IHVs,<br>
<dd>> provided there are applications that want this control and<br>
<dd>> *not* also need even more IB-specific CM control. I still <br>
<dd>> have the same skepticism I had for the IT-API's exposing<br>
<dd>> of paths via a transport neutral API. Namely, is there<br>
<dd>> really any basis to select amongst multiple paths from<br>
<dd>> transport neutral code? The same applies to caching of <br>
<dd>> address translations on a transport neutral basis. Is<br>
<dd>> it really possible to do in any way that makes sense?<br>
<dd>> Wouldn't caching at a lower layer, with transport/device<br>
<dd>> specific knowledge, make more sense? <br><br>
<dd>I guess I view this API slightly differently than being just a
transport neutral<br>
<dd>connection interface. I also see it as a way to connect over IB
using IP<br>
<dd>addresses, which today is only possible if using ib_at. That
is, the API could <br>
<dd>do both.<br><br>
</dl><br>
Given that purpose I can envision an IB-aware application that
needed<br>
to use IP addresses and wanted to take charge of caching the
translation.<br><br>
But viewing this in a wider scope raises a second question.
Shouldn't<br>
iSER be using the same routines to establish
connections?</blockquote><br>
While many applications do use IP addresses, unless one goes the route of
defining an IP address per path (something that iSCSI does comprehend
today), IB multi-path (and I suspect eventually Ethernet's multi-path
support) will require interconnect specific interfaces. Ideally,
applications / ULP define the destination and QoS requirements - what we
used to call an address vector. Middleware maps those to a
interconnect-specific path on behalf of the application / ULP. This
is done underneath the API as part of the OS / RDMA
infrastructure. Such an approach works quite well for many
applications / ULP however it should not be the only one supported as it
assumes that the OS / RDMA infrastructure is sufficiently robust to apply
policy management decisions in conjunction with the fabric management
being deployed. Given IB SM will vary in robustness, there must
also exist API that allow applications / ULP to comprehend the set of
paths and select accordingly. I can envision how to construct such
a knowledge that is interconnect independent but it requires more
"standardization" about what defines the QoS requirements -
latency, bandwidth, service rate, no single point of failure, etc. What I
see so far does not address these issues.<br><br>
Mike</body>
</html>