DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pablo de Lara <pablo.de.lara.guarch@intel.com>
To: declan.doherty@intel.com
Cc: dev@dpdk.org, Pablo de Lara <pablo.de.lara.guarch@intel.com>
Subject: [dpdk-dev] [PATCH] examples/l2fwd-crypto: fix incorrect padding addition
Date: Thu,  9 Feb 2017 12:27:45 +0000	[thread overview]
Message-ID: <1486643265-244932-1-git-send-email-pablo.de.lara.guarch@intel.com> (raw)

L2fwd-crypto app was padding an incoming buffer,
to be aligned with the algorithm block size, in all cases.
This was not the right approach, as padding is only necessary
when using block cipher algorithms, such as AES-CBC.
In case of using a stream cipher algorithm, such as SNOW3G UEA2,
there is no need to include padding and increase the buffer size.

Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
 examples/l2fwd-crypto/main.c | 36 +++++++++++++++++++++++++++---------
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 43fef59..320fb0b 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -432,7 +432,8 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
 	struct ether_hdr *eth_hdr;
 	struct ipv4_hdr *ip_hdr;
 
-	unsigned ipdata_offset, pad_len, data_len;
+	uint32_t ipdata_offset, data_len;
+	uint32_t pad_len = 0;
 	char *padding;
 
 	eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
@@ -455,16 +456,33 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
 	if (cparams->do_hash && cparams->hash_verify)
 		data_len -= cparams->digest_length;
 
-	pad_len = data_len % cparams->block_size ? cparams->block_size -
-			(data_len % cparams->block_size) : 0;
+	if (cparams->do_cipher) {
+		/*
+		 * Following algorithms are block cipher algorithms,
+		 * and might need padding
+		 */
+		switch (cparams->cipher_algo) {
+		case RTE_CRYPTO_CIPHER_AES_CBC:
+		case RTE_CRYPTO_CIPHER_AES_ECB:
+		case RTE_CRYPTO_CIPHER_DES_CBC:
+		case RTE_CRYPTO_CIPHER_3DES_CBC:
+		case RTE_CRYPTO_CIPHER_3DES_ECB:
+			if (data_len % cparams->block_size)
+				pad_len = cparams->block_size -
+					(data_len % cparams->block_size);
+			break;
+		default:
+			pad_len = 0;
+		}
 
-	if (pad_len) {
-		padding = rte_pktmbuf_append(m, pad_len);
-		if (unlikely(!padding))
-			return -1;
+		if (pad_len) {
+			padding = rte_pktmbuf_append(m, pad_len);
+			if (unlikely(!padding))
+				return -1;
 
-		data_len += pad_len;
-		memset(padding, 0, pad_len);
+			data_len += pad_len;
+			memset(padding, 0, pad_len);
+		}
 	}
 
 	/* Set crypto operation data parameters */
-- 
2.7.4

             reply	other threads:[~2017-02-09 12:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 12:27 Pablo de Lara [this message]
2017-02-09 18:22 ` Zhang, Roy Fan
2017-02-10  0:37   ` De Lara Guarch, Pablo

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=1486643265-244932-1-git-send-email-pablo.de.lara.guarch@intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@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).