-----Original Message----- > Is this intended to handle multiple applications subscribing/unsubscribing > for the same report ?
Yes. This is based on Sean's old patches to the ib_sa which added support for multiplexing traps/notices to multiple client apps and which provided "ib_usa" to expose this capability to user space. I had originally submitted his code as-is for acceptance into OFED and the upstream kernel, but we got hung up on what the application API would be. These headers are meant to address that part of the conversation. Once we get that out of the way we can decide what needs to change in ib_sa and ib_usa to meet the API needs. > Why aren't traps 144 and 145 also defined ? Only because the existing ib_usa patch doesn't support them and I forgot to add them. That can be done. > Nit: If trap_number is in network byte order, shouldn't it be ib_net16_t > below ? Done. > Shouldn't there be more granularity in this API in terms of what can be > subscribed for ? IMO trap number is insufficient for registration and > this API should contain a trap specific variable with a component mask > indicating what fields are valid in that variable. I don't think I understand what you're getting at. You subscribe to the individual traps that you are interested in. When a trap is generated, you get an "event" which contains the entire message. > Also, this API should be able to support registering for "all" traps. That capability is already present: IBV_SA_SM_TRAP_ALL = __constant_cpu_to_be16(0xFFFF) > What does releasing SA registration mean exactly ? Is it purely a local > operation or does it also do the deregistration with the SA ? I can't > tell for sure from the description above but suspect this API causes the > SA deregistration to occur as well. No, this is strictly local. Registering and deregistering with the SM depends on the patched ib_sa module and I don't think it unregisters with the module till it unloads. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
