<br><br><div><span class="gmail_quote">On 9/21/05, <b class="gmail_sendername">Sean Hefty</b> <<a href="mailto:mshefty@ichips.intel.com">mshefty@ichips.intel.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Caitlin Bestler wrote:<br>> That's certainly an acceptably low overhead for iWARP IHVs,<br>> provided there are applications that want this control and<br>> *not* also need even more IB-specific CM control. I still
<br>> have the same skepticism I had for the IT-API's exposing<br>> of paths via a transport neutral API. Namely, is there<br>> really any basis to select amongst multiple paths from<br>> transport neutral code? The same applies to caching of
<br>> address translations on a transport neutral basis. Is<br>> it really possible to do in any way that makes sense?<br>> Wouldn't caching at a lower layer, with transport/device<br>> specific knowledge, make more sense?
<br><br>I guess I view this API slightly differently than being just a transport neutral<br>connection interface.  I also see it as a way to connect over IB using IP<br>addresses, which today is only possible if using ib_at.  That is, the API could
<br>do both.</blockquote><div><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?<br>
<br>
</div><br></div><br>