Hal Rosenstock wrote:
I'm trying to understand who would use this field and what it would contain.
From discussions so far, it looks like only an IP to IB address translation
mechanism would need it. And the only value that's required seems to be the
pkey. Other values could be returned as well to possibly simplify things, but
not sure that anything else is required.
Also, ib_device and port as well as PKey.
The device and port can be retrieved by looking up the GID in a local device
list, though it's a little inefficient. I agree that these 3 values are ideal,
but not sure that having them helps. (And returning the device pointer could
actually lead to misuse.)
What's still not clear to me is how an ib_device pointer would be used with
respect to device removal. Ultimately a client needs to get a pointer to an
ib_device that they can use for QP allocation, etc. I think that we need to
examine the problem from a ULP's perspective, versus going up a single layer in
the stack.
For example, currently the CMA queries an address translation service to convert
an IP address into a GID. The CMA searches its device list until it finds a
match on the GID. This permits synchronization with device removal.
Given the current device registration interface, it seems that a search through
a device list is needed at some point. The only alternative that I can think of
is to make use of a more complex reference counting scheme.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
