[openib-general] [PATCH] [CM] add private data comparison tomatch REQs with listens

Fabian Tillier ftillier at silverstorm.com
Fri Dec 2 15:51:03 PST 2005


On 12/2/05, Caitlin Bestler <caitlinb at broadcom.com> wrote:
> Fab Tillier wrote:
>
> > To sum up, it is simpler to add the private data compare
> > functionality to the IB CM than to add it to every client
> > that wants it.  The changes required don't complicate the API
> > significantly, certainly within the grasp of someone
> > interfacing to verbs.  I know this from experience because
> > I've done it before.
> >
> >> Or conversely, if you truly think this is of general utility, why not
> >> implement it in INETD as well?
> >
> > I wasn't making the case that it has general utility, just
> > that it has utility within the realm of IB connection
> > management.  Someone else is welcome to expand the scope if
> > they see fit, but that's not what I'm advocating.
> >
>
> But if your justification is MPI Ranks then you have already
> exceed the scope "IB connection management".

Why shouldn't an MPI implementation that interfaces directly to IB
verbs use the IB CM functionality?  Why should it restrict itself to
TCP connection semantics when IB can provide it with something richer?

> There is an *existing* solution on how the remote end
> establishes multiple connections to the same service
> but with different instances.
>
> That solution has been around for a very long time,
> literally decades. Needing to restructure your code
> slightly to preserve an existing interface that has
> been around that long does not seem inapropriate.

The IB CM is not an existing interface.  I'M TALKING ABOUT
I-N-F-I-N-I-B-A-N-D.  INFINIBAND.  Not IP, not TCP, not sockets, not
iWarp.  Show me the IB CM API that has existed for decades.

> Are you claiming that there is something in the
> definition of the protocol that *requires* IB to
> handle this differently than other networks do?

IB listen semantics are different from socket listen semantics. 
Again, IB is not Ethernet, not iWarp, not IP, not TCP.  This is an
important point that I feel you keep missing.

- Fab



More information about the general mailing list