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.
Btw - this doesn't stop PMDs from minimising those cases, just means they're
not bound by the API to do it.
Fiona
