All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Akhil Goyal <akhil.goyal@nxp.com>,
	"Iremonger, Bernard" <bernard.iremonger@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped for inline crypto
Date: Tue, 23 Apr 2019 14:04:30 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772580148A9B10E@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <VI1PR04MB4893B72E0C0CC702C42F67B9E6230@VI1PR04MB4893.eurprd04.prod.outlook.com>



> >
> > >
> > > > -----Original Message-----
> > > > From: Akhil Goyal
> > > > Sent: Thursday, April 18, 2019 7:21 PM
> > > > To: Bernard Iremonger <bernard.iremonger@intel.com>; dev@dpdk.org;
> > > > konstantin.ananyev@intel.com
> > > > Cc: stable@dpdk.org
> > > > Subject: RE: [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped
> > for
> > > > inline crypto
> > > >
> > > > Hi Bernard,
> > > >
> > > > > -       RTE_LOG_DP(DEBUG, IPSEC, "Create session for SA spi %u on
> > cryptodev "
> > > > > -                       "%u qp %u\n", sa->spi,
> > > > > -                       ipsec_ctx->tbl[cdev_id_qp].id,
> > > > > -                       ipsec_ctx->tbl[cdev_id_qp].qp);
> > > > > +       if ((sa == NULL) || (pool == NULL))
> > > > > +               return -EINVAL;
> > > > >
> > > > > -       if (sa->type != RTE_SECURITY_ACTION_TYPE_NONE) {
> > > > > -               struct rte_security_session_conf sess_conf = {
> > > > > +       struct rte_security_session_conf sess_conf = {
> > > > >                         .action_type = sa->type,
> > > > >                         .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
> > > > >                         {.ipsec = {
> > > > > @@ -90,247 +65,340 @@ create_session(struct ipsec_ctx *ipsec_ctx,
> > struct
> > > > > ipsec_sa *sa)
> > > > >                         } },
> > > > >                         .crypto_xform = sa->xforms,
> > > > >                         .userdata = NULL,
> > > > > -
> > > > >                 };
> > > > >
> > > > > -               if (sa->type ==
> > > > RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL)
> > > > > {
> > > > > -                       struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> > > > > -                                                       rte_cryptodev_get_sec_ctx(
> > > > > -                                                       ipsec_ctx->tbl[cdev_id_qp].id);
> > > > > -
> > > > > -                       /* Set IPsec parameters in conf */
> > > > > -                       set_ipsec_conf(sa, &(sess_conf.ipsec));
> > > > > -
> > > > > -                       sa->sec_session = rte_security_session_create(ctx,
> > > > > -                                       &sess_conf, ipsec_ctx->session_pool);
> > > > > -                       if (sa->sec_session == NULL) {
> > > > > -                               RTE_LOG(ERR, IPSEC,
> > > > > -                               "SEC Session init failed: err: %d\n", ret);
> > > > > -                               return -1;
> > > > > -                       }
> > > > > -               } else if (sa->type ==
> > RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)
> > > > {
> > > > > -                       struct rte_flow_error err;
> > > > > -                       struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> > > > > -                                                       rte_eth_dev_get_sec_ctx(
> > > > > -                                                       sa->portid);
> > > > > -                       const struct rte_security_capability *sec_cap;
> > > > > -                       int ret = 0;
> > > > > -
> > > > > -                       sa->sec_session = rte_security_session_create(ctx,
> > > > > -                                       &sess_conf, ipsec_ctx->session_pool);
> > > > > -                       if (sa->sec_session == NULL) {
> > > > > -                               RTE_LOG(ERR, IPSEC,
> > > > > -                               "SEC Session init failed: err: %d\n", ret);
> > > > > -                               return -1;
> > > > > -                       }
> > > > > +       if (sa->type ==
> > RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) {
> > > > > +               ctx = (struct rte_security_ctx *)
> > > > > +                               rte_eth_dev_get_sec_ctx(sa->portid);
> > > >
> > > > This is breaking the lookaside mode. Ctx was retrieved using the ipsec_ctx-
> > >tbl
> > > > struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> > > > 				rte_cryptodev_get_sec_ctx(
> > > > 				ipsec_ctx->tbl[cdev_id_qp].id);
> > > >
> > > > I am looking into it, but I don't have time left to get it integrated in RC2. So
> > this
> > > > has to be pushed to RC3
> > >
> > > It looks like there are multiple issues in this patch wrt lookaside and none cases.
> > Only the inline cases seem to be working.
> > >
> > > 1. the patch removes the cdev_mapping concept completely. Cdev_id_qp is
> > not getting used.
> >
> > Not exactly.
> > cdev_id_qp is still setup, and is still used to decide to which crypto-dev to
> > enqueuer the crypto-op:
> > ipsec_enqueue(...)
> > {
> >    ...
> >    enqueue_cop(&ipsec_ctx->tbl[sa->cdev_id_qp], &priv->cop);
> 
> I don't see anybody filling "sa->cdev_id_qp". Please let me know if I have missed it somewhere.
> It is memset to 0 I guess.


Yep, true we lost it somewhere during the rework.  

> 
> >
> >
> > Same in ipsec_process().
> >
> > For initialization, yes cdev_id_qp is not used anymore.
> > As discussed here:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp
> > dk.org%2Farchives%2Fdev%2F2019-
> > March%2F127725.html&amp;data=02%7C01%7Cakhil.goyal%40nxp.com%7C04
> > 194193cfc04c0b629008d6c7eea247%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> > 7C0%7C0%7C636916225072561313&amp;sdata=ga9IiqhYRWOz9QkRDIXNiigInk
> > soVGgu1E5EetqvE%2FA%3D&amp;reserved=0
> >
> > I think the problem you are hitting with lookaside-proto is that for it
> > we use 2 different values here:
> > a) In create_sec_session we use portid (it also should be
> > rte_cryptodev_get_sec_ctx() here)
> >     if (sa->type == RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) {
> >                 ctx = (struct rte_security_ctx *)
> >                                 rte_eth_dev_get_sec_ctx(sa->portid);
> It should be rte_cryptodev_get_sec_ctx in the first place. And it needs a cdev_id as input based on the cdev mapping done while initializing
> the cryptodev and neither the portid and nor cdev_id_qp.
> > b) in enqueue() we use cdev_id_qp
> >
> > Right now these values could be different.
> > As I understand we need to make sure that fro lookaside-proto cdev_id_qp ==
> > portid provided by user, correct?
> No it is not the case. Right now for lookaside there is no use of portid in case of lookaside case.
> As the cdev/qp/core mappings are managed internally and the user cannot tweak it from cfg file.
> 


Hmm, then at least that line  is wrong here:
https://doc.dpdk.org/guides/sample_app_ug/ipsec_secgw.html

sa out 5 cipher_algo aes-128-cbc cipher_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \
auth_algo sha1-hmac auth_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \
mode ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 \
type lookaside-protocol-offload port_id 4

And probably:
"Port/device ID of the ethernet/crypto accelerator for which the SA is configured."
Need to be rephrased to remove crypto accelerator notice.

Another question - why you guys don't consider using portid for lookaside-proto?
As I can see add_mapping(function that  fills cdev_id_qp) doesn't bother to check
which rte_security protocols are supported (only crypto capabilities are checked).
So not sure does current code will work ok with a mix of lookaside-none/lookaside-proto devices.
Forcing user to specify crypto-dev id for lookaside-proto (via portid or so)
will simplify things significantly. 

Konstantin


  reply	other threads:[~2019-04-23 14:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 13:51 [dpdk-dev] [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped for inline crypto Akhil Goyal
2019-04-18 14:58 ` Iremonger, Bernard
2019-04-18 15:23   ` Iremonger, Bernard
2019-04-23 11:14 ` Akhil Goyal
2019-04-23 13:21   ` Ananyev, Konstantin
2019-04-23 13:32     ` Akhil Goyal
2019-04-23 14:04       ` Ananyev, Konstantin [this message]
2019-04-24  6:34         ` Akhil Goyal
2019-04-24 10:40           ` Iremonger, Bernard
2019-05-13 14:29             ` Ananyev, Konstantin
2019-05-27  8:58               ` Iremonger, Bernard
  -- strict thread matches above, loose matches on Subject: below --
2019-04-22  6:25 Akhil Goyal
2019-04-04 13:28 [PATCH v3 0/2] examples/ipsec-secgw: fix 1st pkt dropped Bernard Iremonger
2019-04-17 13:42 ` [dpdk-dev] [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped for inline crypto Bernard Iremonger

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=2601191342CEEE43887BDE71AB9772580148A9B10E@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.