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