Caitlin Bestler wrote:
[EMAIL PROTECTED] wrote:
I am working on a uDAPL layer for Open MPI. The situation is
if I have more than one port/HCA my users may want to be
selective in what is used and to do this they would need to
provide some information regarding which port/HCA to use. So
my thought is that the users are more familar with the output
from "ifconfig", for example ib0, ib1, etc, and I was trying
to find a way to correlate that to what is available from the
uDAPL API. Maybe I need to reprogram them to look at dat.conf.
-DON
You definitely do not want to parse dat.conf, you want to see
what the dat_registry has loaded. dat.conf is static, Providers
are allowed to dynamically adapt how they register themselves.
I don't believe that is an active concern, but it's simpler to
take advantage of the existing code and be safe in case somebody
comes along later and decides to do dynamic registration only.
But you hit the nail on the head in terms of needing to correlate
devices as reported by "ifconfig" and the Interface Adapter that
you try to open.
Which brings us back to one of my original questions which was "is there
a way to get the entire dat.conf entry from the uDAPL API". And what I
am hearing is no, not yet anyway.
Just to take this one more step, and talking about the ofed dat.conf
example now.
Example:
OpenIB-cma u1.2 nonthreadsafe default /usr/local/lib64/libdaplcma.so
dapl.1.2 "ib0 0" ""
Since I can get the first field, in this example "OpenIB-cma", from the
ia name attribute of the uDAPL API was the data in the 6th field,
example "ib0 0" considered for the first entry? Or does that just not
make sense?
-DON
Basically, the intent has always been that the correlation between
an Interface Adapter and an "ifconfig" entry should be so obvious
that a complete idiot could figure out which went with which.
Once that linkage is clear then you merely use the RDMA device/port
implied by the routing of the device listed by ifconfig.
Which brings us back to one of my orginal questions
To the best of my knowledge, for every DAPL provider ever created
the correlation with the IP layer device has indeed been so obvious
that any idiot could figure it out -- unfortuantely software can only
hope to someday reach that degree of intelligence, and other than
configuring the links there really isn't much that can be done.
Once there is a link between the RDMA device and the IP layer device,
you could use the routing tables to determine which port a connection
request could be received on, which ports could originate a packet with
a given IP address and which ports could send a packet to a given IP
destination. Given that, you want the matching RDMA device.
Such a linkage would allow the application to correctly determine
the exact DAPL Provider that needed to be opened, and only only
that one. Without it the application has to scan the registry list
and essentially do a serial search. The good news is that it won't
be a very long serial search and it doesn't have to be performed
that often.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
