[openib-general][PATCH][RFC]: CMA IB implementation
Caitlin Bestler
caitlinb at broadcom.com
Wed Sep 21 09:45:03 PDT 2005
> -----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?
More information about the general
mailing list