> -----Original Message----- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 21, 2005 9:40 AM > To: Caitlin Bestler > Cc: Guy German; Openib > Subject: Re: [openib-general][PATCH][RFC]: CMA IB implementation > > Caitlin Bestler wrote: > > Any split in the API needs to allow iWARP providers to > implement the > > first part as a nop. iWARP is defined on top of IP > transports, and in > > fact frequently is cleanly layered over at least the IP layer (full > > clean separation from the TCP layer being a bit less > common). So the > > iWARP implementation may literally have no access to ARP data. > > If you look at the modified version of the API that I sent > it, the iWarp implementation is limited to allocating a data > structure, and copying the source and destination IP > addresses. If a provider has a requirement to do something > different they can. >
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? _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
