[ofiwg] the send credit thread that will not die

[Hefty, Sean]

Thanks, Bob!  I do think this is helpful and captures the discussion.

> The proposal was to have a query function in which a prototype
> of the work request (i.e., a representative work request as
> it would be built by the app) could be given to the provider
> which would return a number to the app that would be the number of
> credits required by that work request in an ibv_post_send
> and/or ibv_post_recv (depending on the opcode).
> The work request should indicate the opcode, all relevant flags
> and sge list items, etc., with a "nominal" length in each sge.
> The app would save the resulting credit number along with each
> work request type, so that when the app wanted to use a work request
> of that type, it would know the number of credits it needs in order
> to successfully post it without getting an EAGAIN error back.

As part of continuing this discussion, after thinking about this more, I do see one possible disadvantage.  (It's hard to know for sure until some final API has been proposed.)  Anyway, I do have a concern that the use of a generic query function may not be significantly easy enough for application developers to use well, or that the workload will be known well enough in advance.

I keep thinking back to an email Doug sent on this way, way back where he suggested using some sort of enum.  While I think that's simple, I have concern about how easily new providers can fit into that model without requiring application changes.