Re: [dpdk-dev] [PATCH v2] doc/compress: clarify error handling on data-plane

["Trahe, Fiona" <fiona.trahe@intel.com>]

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