[openib-general] ib_req_ncomp_notif in core_ layer

[Sean Hefty]

On Thu, 12 Aug 2004 00:23:40 +0300
"Michael S. Tsirkin" <mst at mellanox.co.il> wrote:

> Currently some things are unclear:
> 
> If you get an event and do req_comp_notif 
> immediately, without polling - do you expect to get an event immediately?

The call for ib_req_notify_cq() is intended to map to the semantics mentioned in the spec.  For the example mentioned, calling ib_req_notify_cq() without polling arms the CQ, but will not generate an event until a new completion of the specified type is added to the CQ.

> What currently happends as far as I can see, is:
> for req_comp_notif you dont, for req_ncomp_notif you do.
> For n=1 the behaviour of req_ncomp_notif probably does not
> make sence ...
>
> If you dont for req_ncomp_notif, what would you expect?

ib_req_n_notify_cq() is outside of the spec, so needs to be defined.  My expectation would be that it behaves similar to ib_req_notify_cq(), in that it generates an event after wc_cnt (or one solicited) *new* completions are added to the CQ.
 
> Looks good.
> As I see it any hardware has an upper bound on the max legal value
> for wc_cnt

If there would be an upper bound, then I think it makes sense to replace the device_cap_flag with a max_notify_cnt (or whatever), that can be set to 1 if needed.

> I'd also like to see another option in addition to IB_CQ_SOLICITED and
> IB_CQ_NEXT_COMP  - something like IB_CQ_WQE, where the user labels work
> request for completion of which he wants to get event, and the event generated
> which such a work request is completed or of there is a solicited or error
> completion.

The receive work request has some unused recv_flags that could be used for this purpose.  Can current hardware support such an option?