[openib-general] RDMA connection and address translation API

Fab Tillier ftillier at silverstorm.com
Wed Aug 24 10:03:53 PDT 2005


> From: Roland Dreier [mailto:rolandd at cisco.com]
> Sent: Wednesday, August 24, 2005 9:27 AM
> 
>     Tom> I think I understand, but the purpose of specifying the IP
>     Tom> address in the listen is not to filter incoming connect
>     Tom> requests, but rather to determine which devices I listen
>     Tom> on. I think this works for the IB case as well. So the
>     Tom> utility of the IP address specified in the listen is only to
>     Tom> determine which devices the sid is created on. Does this make
>     Tom> sense or am I missing something?
> 
> Well, that's not what I would expect.  Suppose I have a device
> configured with local addresses 192.168.11.12 and 192.168.98.99 and I
> start listening for some service at the address 192.168.11.12.  I
> don't think I should see a connection request if a remote system tries
> to connect to 192.168.98.99 (even though it's the same network
> interface as 192.168.11.12).

I think the IB CM needs to be able to do two things.  It needs to allow a listen
to be bound to a specific port - using the port GUID or the LID or something
along those lines.  The Windows CM currently take a port GUID as input to allow
binding requests to a local IB port.  Incoming MADs are matched based on which
port they came in on.  This does introduce the limitation that sending CM MADs
to a port other than the one you wish to connect to won't have the desired
result if the ULP performs port filtering.  I don't think this is a big deal.

Knowledge of actual IP addresses would be up to the consumer.  However, the IB
CM can facilitate checks by allowing the user to specify an offset and length in
the private data to match to for incoming requests.  ULPs that would want to
distinguish between IP addresses on a given port would put the IP in their
private data, and instruct the CM to compare a specific value at a specific
offset and length for every incoming REQ.  The Windows CM does this - a listen
takes as input a private data compare buffer, buffer length, and offset within
the REQ private data to perform the comparison.

Without the CM performing the private data comparison for the client, there is
no way for the CM to route to the proper person based on something like IP.
Using a generic private data compare mechanism enables the users to do whatever
they feel like, without putting knowledge of IP addresses and whatnot into the
IB CM or dictating how clients must use their private data.

A lookup of a listen for an incoming request changes from just being based on
SID to taking as additional parameters the port GUID on which the REQ was
received and the REQ's private data in case a private data compare needs to be
performed.

- Fab




More information about the general mailing list