On 24/03/17 12:52, Trahe, Fiona wrote:
Hi Declan,
-----Original Message-----
From: Doherty, Declan
Sent: Friday, March 24, 2017 10:53 AM
To: Trahe, Fiona <fiona.tr...@intel.com>; dev@dpdk.org; De Lara Guarch,
Pablo <pablo.de.lara.gua...@intel.com>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: add API note
On 23/03/2017 5:36 PM, Fiona Trahe wrote:
Add note to cryptodev API that chained mbufs
are not supported in DOCSISBPI mode.
Signed-off-by: Fiona Trahe <fiona.tr...@intel.com>
---
...
Hey Fiona,
Is this really a limitation of DOCSISBPI mode or just the PMDs which
currently support these operations. I don't see any reason why DOCSISBPI
mode cipher operation precludes scatter gather operations on the source
payload.
The DOCSISBPI spec in section I.12 Fragmented Packet Encryption
https://apps.cablelabs.com/specification/CM-SP-SECv3.1
says "When a packet is fragmented, each fragment is independently encrypted using
CBC mode with residual block processing"
Of course that doesn't guarantee that an application won't take one of those
fragments and split it across multiple mbufs. But I checked with some subject
matter experts who didn't see a use-case for it.
Due to the nature of DOCSIS there would be a performance impact in
dereferencing through chained mbufs to get the address of the residual block,
on that basis it seems like a better idea to preclude this on the API rather
than having every PMD separately document a limitation or implement a
less-performant path that's unlikely to be used.
Ok, thanks for clarifying that. So the only time this could possibly
happen is if the mbufs themselves where not big enough to fit the packet
MTU and the NIC port had the scatter rx path enabled.
If there is some fundamental reason why scatter gather operations can't
be supported I think documenting this in the rte_crypto_cipher_algorithm
enumeration comments make more sense than in the rte_crypto_sym_op
structure, as we already specify extra requirements
RTE_CRYPTO_CIPHER_AES_GCM and RTE_CRYPTO_CIPHER_AES_CCM there.
It seems to me that this constraint is similar to the notes on many of the
other fields
in rte_crypto_sym_op.
The CCM/GCM comments on the other hand would not fit so well on the xform struct
as they're linking fields on both auth and cipher xforms so the comment would
have to
be duplicated in 2 places, so works better on the enum.
But I don't feel strongly about where it goes, if you still prefer (and agree
it's ok to add this constraint on the API) I can move it to the enum.
I you want to go ahead and place this restriction on these algorithms
then to my mind it probably makes sense to document it with the
algorithm definition in the enumeration definition.
