[ofiwg] event queue overflow handling?

[Reese Faucette (rfaucett)]

Since there is a eq_readerr call, may not really need to be an explicit entry reserved?  Errors could be essentially be "out-of-band" with same semantics as cq_read / cq_readerr ?  i.e. cq_read returns ERRAVAIL == need to call eq_readerr.  So, the EQ could still be "in hardware" but with metadata in host possibly indicating overflow.

> -----Original Message-----
> From: Hefty, Sean [mailto:sean.hefty at intel.com]
> Sent: Monday, October 20, 2014 4:04 PM
> To: Reese Faucette (rfaucett); ofiwg at lists.openfabrics.org
> Subject: RE: event queue overflow handling?
> 
> > Simple question - if an internal event occurs that would like to
> > generate an EQ entry, but the EQ if full, is the provider expected to
> > do its best to queue this event for later delivery to the EQ, or
> > simply generate an OVERFLOW error on the EQ ?  If provider is expected
> > to queue the event internally, this is sort of requiring EQs to be
> > effectively infinitely large, yes?  I'd pick "generate OVERFLOW error"
> > so that the user has more control over memory used for queueing events
> > and can be alerted if algorithms need to be adjusted...
> 
> I think in the working group, we discussed that a provider could reserve a
> single entry in the EQ for reporting an overflow error.  Now whether that's
> achievable for an EQ placed in HW is another matter...