From: Fiona Trahe <fiona.trahe@intel.com>
To: dev@dpdk.org
Cc: pablo.de.lara.guarch@intel.com, fiona.trahe@intel.com,
john.griffin@intel.com, michalx.k.jastrzebski@intel.com,
arkadiuszx.kusztal@intel.com
Subject: [dpdk-dev] [PATCH] crypto: remove unused digest-appended feature
Date: Thu, 17 Nov 2016 17:33:16 +0000 [thread overview]
Message-ID: <1479403997-15437-1-git-send-email-fiona.trahe@intel.com> (raw)
The cryptodev API had specified that if the digest address field was
left empty on an authentication operation, then the PMD would assume
the digest was appended to the source or destination data.
This case was not handled at all by most PMDs and incorrectly handled
by the QAT PMD.
As no bugs were raised, it is assumed to be not needed, so this patch
removes it, rather than add handling for the case on all PMDs.
The digest can still be appended to the data, but its
address must now be provided in the op.
I've added this cover letter to pre-empt the question which will arise
in chained-mbuf case.
(Chained-mbuf support will be added in next few weeks for 17.02)
In a chained-mbuf case, if the digest is appended to the data, it could
in theory end up split across the last 2 mbufs. Using the digest address
field only works for the case where the digest is in a flat buffer. The
digest-appended feature would have provided one way of handling this,
pushing the responsibility down to the PMD to follow the chain to find
the digest address and handle it whether in 1 or 2 mbufs.
However, this is adding extra cycles on the data path in all PMDs
to handle a case which may not arise in many applications.
The alternative is to give the application the responsibility
to make sure the digest is in a flat buffer.
Specifically if an application knows cases of a digest spanning
buffers can arise, then it can check for this case and memcpy the partial
start of the digest from the second last buffer into the last buffer
so it's no longer split.
Does anyone see a problem with this?
Fiona Trahe (1):
crypto: remove unused digest-appended feature
drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 2 ++
drivers/crypto/qat/qat_crypto.c | 18 +-----------------
lib/librte_cryptodev/rte_crypto_sym.h | 10 +---------
3 files changed, 4 insertions(+), 26 deletions(-)
--
2.5.0
next reply other threads:[~2016-11-17 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-17 17:33 Fiona Trahe [this message]
2016-11-17 17:33 ` Fiona Trahe
2016-11-18 18:15 ` John Griffin
2016-11-30 15:16 ` De Lara Guarch, Pablo
2016-11-17 17:52 ` Trahe, Fiona
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=1479403997-15437-1-git-send-email-fiona.trahe@intel.com \
--to=fiona.trahe@intel.com \
--cc=arkadiuszx.kusztal@intel.com \
--cc=dev@dpdk.org \
--cc=john.griffin@intel.com \
--cc=michalx.k.jastrzebski@intel.com \
--cc=pablo.de.lara.guarch@intel.com \
/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).