[openib-general] Re: A Couple of User CM Questions

Libor Michalek libor at topspin.com
Tue May 10 17:53:42 PDT 2005


On Mon, May 09, 2005 at 03:32:20PM -0400, Hal Rosenstock wrote:
> On Mon, 2005-05-09 at 14:39, Libor Michalek wrote: 
> > On Mon, May 09, 2005 at 01:22:17PM -0400, Hal Rosenstock wrote:
> > > Hi Libor,
> > > 
> > > I have a couple of questions pertaining to the user CM.
> > > 
> > > 1. It appears that device (and port) are not supported either incoming
> > > or outgoing. So if that is correct, I presume only the first device
> > > (first port) is the only one which can be expected to work. Correct ?
> > > If so, that should be added to README as a current limitation.
> 
> So I am presuming this is a current limitation.

  No, since the REQ event will be delivered to the user CM listener 
regardless of the device/port on which it is received.

> > > 2. Any idea on how device would be supported ? Would this just be with
> > > an IB device number or a string like "mthca0" ?
> > 
> >   I was thinking that the destination GID in the req_event path record
> > would be sufficient to identify the local device/port, but I had not
> > taken a look at sidr_req_event. I think this is the correct GID to use
> > for creating the QP, but I have not taken a look at how easy it is to
> > turn a GID into a suitable device/portin user verbs. Thoughts?
> 
> and source GID (in the REQ primary path) on the active side ? 
>
> That seems like it would work but wouldn't you need to walk the GID
> tables on each port on each IB device until you find the match ? Sounds
> a little expensive but would only be done once per connection.

  Yes, the kernel CM already behaves this way, Sean made the change to
support the user CM a littel while ago. It use to rely on the QP's
device/port, but now it relies on the source GID and no QP is needed
just the QPN. Sorry for the delayed response. The only question I had
was how to bind the user QP to the device/port based on the source or
destination GID based on the REQ send or REQ event respectively. I'm
only just now looking at this...

-Libor



More information about the general mailing list