From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: Shally Verma <shallyv@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
Ashish Gupta <ashishg@marvell.com>,
"Daly, Lee" <lee.daly@intel.com>, Sunila Sahu <ssahu@marvell.com>,
"stable@dpdk.org" <stable@dpdk.org>,
"Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-stable] [PATCH v2] doc/compress: clarify error handling on data-plane
Date: Tue, 14 May 2019 15:29:34 +0000 [thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B43589767E7F@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <BN6PR1801MB2052292587357A6DFC6C1020AD330@BN6PR1801MB2052.namprd18.prod.outlook.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
next prev parent reply other threads:[~2019-05-14 15:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 16:14 [dpdk-stable] [PATCH] " Fiona Trahe
2019-04-09 14:55 ` [dpdk-stable] [PATCH v2] " Fiona Trahe
2019-04-18 12:12 ` Shally Verma
2019-04-30 16:33 ` Trahe, Fiona
2019-05-07 17:14 ` Shally Verma
2019-05-07 18:24 ` Trahe, Fiona
2019-05-08 12:41 ` Shally Verma
2019-05-08 14:00 ` Trahe, Fiona
2019-05-09 8:58 ` Akhil Goyal
2019-05-09 10:44 ` Shally Verma
2019-05-14 15:29 ` Trahe, Fiona [this message]
2019-05-14 15:37 ` Shally Verma
2019-05-15 11:16 ` [dpdk-stable] [PATCH v3] " Fiona Trahe
2019-05-15 11:43 ` Jozwiak, TomaszX
2019-05-15 12:03 ` Shally Verma
2019-06-19 14:57 ` Akhil Goyal
2019-04-16 15:02 [dpdk-stable] [PATCH v2] " Akhil Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=348A99DA5F5B7549AA880327E580B43589767E7F@IRSMSX101.ger.corp.intel.com \
--to=fiona.trahe@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=ashishg@marvell.com \
--cc=dev@dpdk.org \
--cc=lee.daly@intel.com \
--cc=shallyv@marvell.com \
--cc=ssahu@marvell.com \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).