On 9/21/05, Sean Hefty <[EMAIL PROTECTED]> wrote:
Given that purpose I can envision an IB-aware application that needed
to use IP addresses and wanted to take charge of caching the translation.
But viewing this in a wider scope raises a second question. Shouldn't
iSER be using the same routines to establish connections?
Caitlin Bestler wrote:
> That's certainly an acceptably low overhead for iWARP IHVs,
> provided there are applications that want this control and
> *not* also need even more IB-specific CM control. I still
> have the same skepticism I had for the IT-API's exposing
> of paths via a transport neutral API. Namely, is there
> really any basis to select amongst multiple paths from
> transport neutral code? The same applies to caching of
> address translations on a transport neutral basis. Is
> it really possible to do in any way that makes sense?
> Wouldn't caching at a lower layer, with transport/device
> specific knowledge, make more sense?
I guess I view this API slightly differently than being just a transport neutral
connection interface. I also see it as a way to connect over IB using IP
addresses, which today is only possible if using ib_at. That is, the API could
do both.
Given that purpose I can envision an IB-aware application that needed
to use IP addresses and wanted to take charge of caching the translation.
But viewing this in a wider scope raises a second question. Shouldn't
iSER be using the same routines to establish connections?
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
