> On Mon, 2005-05-09 at 15:32, 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. > > > > > > 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. > > > > The advantage of GID is this would be common across all IB > devices. Not > > sure what else could be other than a deterministic numbering of IB > > devices locally which I believe does not currently exist. > > ib_verbs does have a way to get_devices (ibv_get_devices) and specify > expose a pointer to a struct ibv_device. That would be another > alternative to using GIDs. That would make it similar to the > kernel CM. > > -- Hal
I would recommend GIDs, no searching is necessary and a GID based approach would work for both user and kernel CM. ibv_device would have challenges for user space listeners. Todd Rimmer _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
