HI Fiona > -----Original Message----- > From: Trahe, Fiona <fiona.tr...@intel.com> > Sent: Tuesday, May 14, 2019 9:00 PM > To: Shally Verma <shal...@marvell.com>; dev@dpdk.org > Cc: akhil.go...@nxp.com; Ashish Gupta <ashi...@marvell.com>; Daly, Lee > <lee.d...@intel.com>; Sunila Sahu <ss...@marvell.com>; sta...@dpdk.org; > Trahe, Fiona <fiona.tr...@intel.com> > Subject: RE: [PATCH v2] doc/compress: clarify error handling on data-plane > > Hi Shally, > > Although we're close to agreement on this, I'm reconsidering. > I think the difficulty we've had finding the best wording highlights the > confusion > an app developer will have in figuring out how to handle errors on enqueue. > So I'm proposing to drop this - which was intended to allow some optimisation > - > and instead propose a more robust approach, i.e. add this to the doc: > > Operation status after enqueue / dequeue > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Some of the above values may arise in the op after an > ``rte_compressdev_enqueue_burst()``. If number ops enqueued < number > ops requested then > the app should check the op.status of nb_enqd+1. If status is > RTE_COMP_OP_STATUS_NOT_PROCESSED, it likely indicates a full-queue > case for a hardware device > and a retry after dequeuing some ops is likely to be successful. If the > op holds > any other status, e.g. > RTE_COMP_OP_STATUS_INVALID_ARGS, a retry with the same op is unlikely > to be successful. > > > I know this adds an extra fork, so is less optimal, but once there's even a > small > chance that an error may occur on the enqueue, a robust application should > probably check anyway. > What do you think? > If you agree, I'll send the doc update and a perf tool update to add the > status > check on the enqueue.
[Shally] Yup This looks absolutely perfect to me. So it is acked by me. > > Btw - this doesn't stop PMDs from minimising those cases, just means they're > not bound by the API to do it. > > Fiona
