[ofiwg] the send credit thread that will not die

[Liran Liss]

Thanks for the summary.

I would add an additional requirement for "convexity", in the sense that higher value of some parameter immediately implies that the returned credits are at least as much as for the same call with a lower value.
For example:
- More inline data <= iff => more credits
- More scatter/gather entries <= iff => more credits

Applications can use this as follows.
Consider an app that has 2 use cases: (1) small messages that only have one SGE (2) large messages that can have any number of SGEs from 1 to, say, 10.
In this case the app could issue only 2 credit queries:
- 1 SGE to cover (1)
- 10 SGEs to cover (2)

The provider guarantee is that any posted message with < 10 SGEs would consume less credits than what was returned for (2).
Thus, for workloads that mostly comprise small messages, queue usage would be optimized.

The amount of distinct queries depends on how much the application is aware of its workload and the level of optimization.
--Liran


> -----Original Message-----
> From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-
> bounces at lists.openfabrics.org] On Behalf Of Hefty, Sean
> Sent: Monday, November 10, 2014 10:52 PM
> To: Robert D. Russell; ofiwg at lists.openfabrics.org
> Subject: Re: [ofiwg] the send credit thread that will not die
> 
> 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.
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg