Hal Rosenstock wrote:
Since user-mode requires a data copy anyway, I'm wondering if it makes more sense for all user-mode clients to register in the kernel to snoop MADs, rather than to receive them. The user-mode interface could then be modified to support more flexible filtering options.
Would this allow richer filtering options or also allow multiple receivers for the same MAD ?
Yes to both. The filtering options would be dependent on the user-mode API and the user_mad implementation in the kernel. I wouldn't think that the kernel MAD implementation would need to change. I was just trying to point out that the main benefit to the API in the kernel doesn't apply in user-mode.
Any idea on what the interface would look like ? Would it support attribute ID ? What else ?
I haven't given this more than two e-mails worth of thought, but it could be as simple as adding an attribute ID mask to something similar to the existing API. A different approach could be to provide a mask over an entire MAD header.
Are there any compelling reasons to do this ?
*shrugs* The disadvantage is that two applications would both receive the same request, so they would need to have some sort of coordination between them to know which one should generate a response. (The "coordination" could be that they're coding to respond to different MADs.)
- Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
