[openib-general] [RFC] [PATCH 1/3] RDMA CM: addrdma_get/set_optioncalls to get/set path records

[Caitlin Bestler]

Sean Hefty wrote:
>> What about for IB HCAs? Are there a large number of options that have
>> not yet been exposed but which are device independent and *might* be
>> desirable to control? If not, then why introduce a "catchall"
>> interface as opposed to specific interfaces that have to justified
>> on a per method basis?
> 
> Sockets provides setsockopt/getsockopt calls, and there is an
> attempt here to emulate sockets.  These calls provide a very
> simple way to extend functionality without needing to modify
> the user to kernel transition code with every feature.
> 
> Functionality that I would like to add through these calls in the
> short term include:
> 
> * Bind to a device based on IB specific addresses (e.g. GIDs).
> * Getting usable path records between two nodes.
> * Setting primary and alternate paths for a connection.
> * Modify an alternate path for a connection.
> * Joining a multicast group identified by an IP address.
> * Leaving a multicast group identified by an IP address.
> * Joining a multicast group identified by an MCMemberRecord.
> * Leaving a multicast group identified by an MCMemberRecord.
> 
> - Sean

Those all seem reasonable and on-topic. What you want to avoid
is implying that you are creating a general purpose interface
for peaking under the hood. All of the cases cited are either
fairly naturally transport independent, or clearly relevant only
to a specific protocol. More importantly they are all describable
in the problem-domain without reference to presumed implementation
algorithms. If you scan the list of sockopts for tcp sockets you'll
see that those distinctions don't necessarily hold up in the long
run (such as specifying the TCP receive buffer).

But on the latter set, aren't there already UDP interfaces that
supply that supply the required controls?