Kanevsky, Arkady wrote:
So what you are proposing is that Listener will specify IETF port (2 bytes). CM will generate an IB SID to listen on. That SID will have wildcarding for 24 bits. The requestor will specify: version, IP version, SRC port and DST port. Based on that CM will generate the SID to send request to.
No, the listener or requester generate the SID, not the IB CM - the same way SDP works today.
It will also encode IP addresses into Private data based on IP version. This makes IP addresses, SIDs and private data format interdependent and not orthogonal which it is now. It also changes the meaning of SID which currently has a meaning of TCP port.
I'm not proposing this. I'm merely stating that is is a valid option to consider. The private data format and SIDs are not orthogonal anyway. The port number's embedded in the SID, and the SID indicates the format of the private data. They are interdependent by definition.
If it's okay to put the destination port number in the SID, why not the protocol type, or IP version?
It also does not allow to use the private data formating for other SIDs.
Private data is private. It should not be owned, set, interpreted, modified, or touched by the CM. It's up to the service to define and use.
What's this proposal defines is basically a 65th bit for the service ID. If the new 65 bit SID is:
1 <anything> - private data has this format 0 <anything> - private data format is unknown Why do we need this 65th bit?
It looks like a big hack. Is it worth it for extra 4 bytes of private data for Consumers?
It's a trade off between SID space and private data. Consumers need to decide how important those extra 4 bytes are.
- 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
