[openib-general] ib_req_ncomp_notif in core_ layer

Michael S. Tsirkin mst at mellanox.co.il
Wed Aug 11 16:01:46 PDT 2004


Hello!
Quoting r. Sean Hefty (mshefty at ichips.intel.com) "Re: [openib-general] ib_req_ncomp_notif in core_ layer":
> 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.

This can be done but it will require a poll to be done on existing hardware.
But what if the event was, say, because of completion with error?


> > 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.

Sounds good.

> > 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?

Yes.

mst



More information about the general mailing list