Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > Subject: RE: Re: RFC: e2e credits > > >> As far as I can tell, it doesn't do anything. Flow control is a parameter > >> of > >> the IB CM REQ/REP messages, so are exposed to the user. > >> > >> I don't see how a user can make use of it in any practical way, however. > >> It > >> isn't used to configure anything on the QP from what I can tell. > > > >So we can either add an ability to enable flow control per RQ, > >or remove this option altogether. > > I'm fine with doing this, but it requires changes to the spec wrt to the > definition of the flow control field in the CM messages.
I thought about this, and I noted that with current CM the flow control flag is already set by ULP, per connection. I currently don't see this as spec violation: there's no compliance statement that requires this bit to have the same value for all connections. The spec says: "Signifies whether the local CA actually implements End-to-End Flow Control (1), or instead always advertises .invalid credits.(0)." and we just take this meaning, with a clarification: "for this connection". Anyway, we have two options: removing this field from CM/CMA, and adding it as a low-level driver module option, or adding it to ib_qp_init_attr? In the later case, I think we can avoid ABI breakage by packing this flag in unused space near other flags. Personally, I think the second option is the less disruptive: it moves the policy of using the hardware flow control out to the ULPs, even if I can't come up with an example where this is useful - there's close to zero overhead to have it either. And I think me and Roland share an aversion to module options - they tend to get out of hand pretty quickly. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
