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? _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
