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

[Caitlin Bestler]

ftillier.sst at gmail.com wrote:
> 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

Socket listen semantics have nothing to do with Ethernet.
They are Unix/POSIX. In fact a major point of socket semantics
is that they worked over multiple networks.

Sockets are part of the problem when it comes to transferring
data once a connection is established, which is why we have
QPs and CQs.

But there is a very simple transport neutral definition of
passive side connectin setup. The server issues a listen.
The server receives connection requests. The service can
optionally hand off the connection request, accept it
or reject it.

That model is a natural extension of both TCP connection
setup and the InfiniBand CM. It allows the server to deal
with destination multiplexing. DAPL and IT-API both already
work this way.

Are you opposed to transport neutral connection establishment?