[dpdk-dev] [PATCH v4 04/10] lib: introduce ipsec library

Ananyev, Konstantin konstantin.ananyev at intel.com
Thu Dec 20 19:17:22 CET 2018


> > > +
> > > +static int
> > > +fill_crypto_xform(struct crypto_xform *xform,
> > > +	const struct rte_ipsec_sa_prm *prm)
> > > +{
> > > +	struct rte_crypto_sym_xform *xf;
> > > +
> > > +	memset(xform, 0, sizeof(*xform));
> > > +
> > > +	for (xf = prm->crypto_xform; xf != NULL; xf = xf->next) {
> > > +		if (xf->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
> > > +			if (xform->auth != NULL)
> > > +				return -EINVAL;
> > > +			xform->auth = &xf->auth;
> > > +		} else if (xf->type == RTE_CRYPTO_SYM_XFORM_CIPHER) {
> > > +			if (xform->cipher != NULL)
> > > +				return -EINVAL;
> > > +			xform->cipher = &xf->cipher;
> > > +		} else if (xf->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
> > > +			if (xform->aead != NULL)
> > > +				return -EINVAL;
> > > +			xform->aead = &xf->aead;
> > > +		} else
> > > +			return -EINVAL;
> > > +	}
> > > +
> > > +	return check_crypto_xform(xform);
> > > +}
> > how is this function handling the inbound and outbound cases.
> > In inbound first xform is auth and then cipher.
> > In outbound first is cipher and then auth. I think this should be
> > checked in the lib.
> 
> Interesting, I didn't know about such limitation.
> My understanding was that the any order (<auth,cipher>, <cipher,auth>)
> for both inbound and outbound is acceptable.
> Is that order restriction is documented somewhere?
> 

Actually, if such restriction really exists, and cryptodev framework obeys it,
then crypto session creation will fail anyway.

> > Here for loop should not be there, as there would be at max only 2 xforms.


More information about the dev mailing list