>>Would we be okay with extending the IOCTL interface to allow multicast joins, >>notice registration, and event reporting? Or would it be acceptable to >>change >>the ib_umad read/write interface to add a command? > > > What do you have in mind here ?
I was thinking of one of two possibilities here. Currently there are IOCTL calls to register/unregister with the MAD layer. Additional IOCTL calls could be added to join/leave multicast groups and register/unregister for SA events. Multicast and SA events would need to be reported through another IOCTL of some sort. The alternative basically rewrites the ib_umad interface to allow read and write to carry some sort of command, rather than mapping them directly to sending and receiving a MAD. This is how most of the RDMA kernel to user interfaces are written. For example, let read return an event type (MAD received, multicast event, etc.), along with the event data (the MAD, etc.). >>>As an alternative, a new kernel userspace SA module could be created to >>>explicitly interface with the kernel ib_sa. > > IMO, this is the best way to go. This was my original approach a couple of months back, but wasn't accepted as mer gable upstream because it increased the size of the user to kernel interface. If we can agree that this approach is usable, we can discuss more specific implementation details. - Sean _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
