DPDK patches and discussions
 help / color / mirror / Atom feed
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

             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).