[openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3
mshefty at ichips.intel.com
Fri Nov 11 09:42:32 PST 2005
Kanevsky, Arkady wrote:
> So what you are proposing is that Listener will specify IETF port (2
> 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
> It will also encode IP addresses into Private data based on IP version.
> This makes IP addresses, SIDs and private data format interdependent and
> orthogonal which it is now.
> It also changes the meaning of SID which currently has a meaning of TCP
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
> for Consumers?
It's a trade off between SID space and private data. Consumers need to decide
how important those extra 4 bytes are.
More information about the general