Should the user registration check that RMPP is allowed for that management class (being registered) ? (It seems to me that allowing the user to enable RMPP on a management class which does not support RMPP might be dangerous).
If so, the list would be SA (class 3) and vendor range 2 (0x30-0x4f). Correct ?
I'm not sure that letting a user take over a management class that doesn't usually support RMPP would necessarily be dangerous; it just may not work for the user.
I'm not sure either but...
There's a difference between doesn't usually support it and isn't supposed to support it.
Good point. I think that it makes sense to check against this for classes that aren't supposed to support it, and make sure that ones that do ask for it.
So do you think nothing bad would happen (other than perhaps to that user) ? I was concerned about both transmit and receive and whether it is just better to protect against this. There's a downside in that if additional classes support RMPP then the code needs updating...
I thought about the receive side as well, but figured that receivers should handle mis-formatted MADs. So, I _think_ that the user would just fail to communicate with anyone...
One consideration is that for the two class sets (SA and vendor2) that support RMPP, both have defined extra header information that must be duplicated in each MAD. If another RMPP class comes along and needs to add addition header information, it will result in code changes anyway...
One possible solution around this would be for clients to specify the size of the common header when registering. I didn't think it was worth changing the API for this though.
- 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
