[openib-general][PATCH][RFC]: CMA IB implementation

[Caitlin Bestler]

> -----Original Message-----
> From: Sean Hefty [mailto:mshefty at ichips.intel.com] 
> 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?