Fab Tillier wrote:
If my understanding is correct, the bit would have meaning to this higher-level
connection management protocol, and not to the lower level IB connection
management protocol. Defining a range of service IDs for protocols that use
this feature creates a bound group that then requires a rev of the spec anytime
someone else wants in on the fun. I think defining the higher level protocol
without restricting the scope of service IDs would be beneficial.
I'll use the first bit in the 2nd byte in my service ID to indicate this then.
That bit's reserved. :)
Using a bit in the REQ means that the higher level connection management
protocol needs to receive and process CM REQs. How does the REQ get routed to
the higher level CM? If it's based on service ID, then why is the bit needed at
all? If I'm routing based on this bit, then I could just as easily define this
protocol to exist on a single service ID, and still route on service ID. The
upper level CM can then demultiplex to the correct application based on the
addresses found in the private data.
Using a reserved bit is essentially adding a 65th bit to the service ID.
In any case, I don't see how defining this private data format without
specifying which service IDs use it is all that useful.
- 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
