From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Anoob Joseph <anoobj@marvell.com>,
Akhil Goyal <akhil.goyal@nxp.com>,
"Nicolau, Radu" <radu.nicolau@intel.com>
Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Lukas Bartosik <lbartosik@marvell.com>,
Narayana Prasad Raju Athreya <pathreya@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: increase number of qps to lcore_params
Date: Fri, 31 Jan 2020 16:32:04 +0000 [thread overview]
Message-ID: <SN6PR11MB2558616D5298DF7AD522D6F19A070@SN6PR11MB2558.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MN2PR18MB2877A1FAFD7CF5D5F0242CABDF040@MN2PR18MB2877.namprd18.prod.outlook.com>
> >
> > ----------------------------------------------------------------------
> >
> >
> > >
> > > Currently only one qp will be used for one core. The number of qps can
> > > be increased to match the number of lcore params.
> >
> > I don't really understand the purpose of that patch....
> > As I understand, all it does - unconditionally increases number of crypto-queues
> > mapped to the same lcore.
>
> [Anoob] With the current code, we will have only crypto qp mapped to one lcore. So even if you have large number of crypto qps, you
> would be only using as much as the number of lcores.
>
> This is an inefficient model as a fat flow(say with large packet sizes) on one eth queue hitting one core can starve another flow which
> happens to hit the same core, because both flows would get queued to the same qp.
> And, we cannot just randomly submit to multiple qps
> from the same core as then the ordering would be messed up.
No-one suggesting that one I believe.
So the best possible usage model would be to map one eth queue to one
> crypto qp. That way, the core wouldn't be unnecessarily pipeline the crypto processing.
I doubt it is really the 'best possible usage model'.
There could be cases when forcing lcore to use/manage more crypto-queues will lead to
negative effects: perf drop, not enough crypto queues for all eth queues, etc.
If your HW/SW requires to match each eth queue with a separate crypto-queue,
then I think it should be an optional feature, while keeping default behavior intact.
>
> > The question is what for?
> > All these extra queues woulnd't be used by current poll mode data-path anyway.
> > Plus in some cases hash_lookup() would fail to find existing mapping.
>
> [Anoob] It was an issue with v1 that we have addressed with v2. I'll send v2 shortly. Please do check that see if you have more comments.
>
> > I understand that for your eventdev implementation you need one crypto queue
> > for each eth device.
> > But I think it could be done in less intrusive way (see my previous mail as one
> > possible option).
>
> [Anoob] If this suggestion is agreeable, then we can solve both qp number requirement (for inline) and default nb_mbuf calculation in a
> much more sensible way. If this doesn't fly, I'll probably go back to your suggestion, but then there would be more code just to handle these
> cases. And the nb_mbuf calculation could turn slightly complicated.
Don't see how it affects number of required mbufs...
Wouldn't it just be:
<num_of_eth_queues> * <eth_rxd_num + eth+txd_num> + <num_of_crypto_queues> *<crq_desc_num> +
<lcore_num>*<lcore_cache+reassemble_table_size>+....
?
>
> > Konstantin
> >
> > >
> > > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > > ---
> > > examples/ipsec-secgw/ipsec-secgw.c | 39 +++++++++++++++++++--------------
> > -----
> > > examples/ipsec-secgw/ipsec.h | 4 +++-
> > > 2 files changed, 23 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > > b/examples/ipsec-secgw/ipsec-secgw.c
> > > index 3b5aaf6..d8c435e 100644
> > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > @@ -1709,6 +1709,8 @@ add_mapping(struct rte_hash *map, const char
> > *str, uint16_t cdev_id,
> > > unsigned long i;
> > > struct cdev_key key = { 0 };
> > >
> > > + key.port_id = params->port_id;
> > > + key.queue_id = params->queue_id;
> > > key.lcore_id = params->lcore_id;
> > > if (cipher)
> > > key.cipher_algo = cipher->sym.cipher.algo; @@ -1721,23
> > +1723,17 @@
> > > add_mapping(struct rte_hash *map, const char *str, uint16_t cdev_id,
> > > if (ret != -ENOENT)
> > > return 0;
> > >
> > > - for (i = 0; i < ipsec_ctx->nb_qps; i++)
> > > - if (ipsec_ctx->tbl[i].id == cdev_id)
> > > - break;
> > > -
> > > - if (i == ipsec_ctx->nb_qps) {
> > > - if (ipsec_ctx->nb_qps == MAX_QP_PER_LCORE) {
> > > - printf("Maximum number of crypto devices assigned to
> > "
> > > - "a core, increase MAX_QP_PER_LCORE
> > value\n");
> > > - return 0;
> > > - }
> > > - ipsec_ctx->tbl[i].id = cdev_id;
> > > - ipsec_ctx->tbl[i].qp = qp;
> > > - ipsec_ctx->nb_qps++;
> > > - printf("%s cdev mapping: lcore %u using cdev %u qp %u "
> > > - "(cdev_id_qp %lu)\n", str, key.lcore_id,
> > > - cdev_id, qp, i);
> > > + i = ipsec_ctx->nb_qps;
> > > + if (ipsec_ctx->nb_qps == MAX_QP_PER_LCORE) {
> > > + printf("Maximum number of crypto devices assigned to a core, "
> > > + "increase MAX_QP_PER_LCORE value\n");
> > > + return 0;
> > > }
> > > + ipsec_ctx->tbl[i].id = cdev_id;
> > > + ipsec_ctx->tbl[i].qp = qp;
> > > + ipsec_ctx->nb_qps++;
> > > + printf("%s cdev mapping: lcore %u using cdev %u qp %u "
> > > + "(cdev_id_qp %lu)\n", str, key.lcore_id, cdev_id, qp, i);
> > >
> > > ret = rte_hash_add_key_data(map, &key, (void *)i);
> > > if (ret < 0) {
> > > @@ -1785,8 +1781,10 @@ add_cdev_mapping(struct rte_cryptodev_info
> > *dev_info, uint16_t cdev_id,
> > > continue;
> > >
> > > if (i->sym.xform_type == RTE_CRYPTO_SYM_XFORM_AEAD) {
> > > - ret |= add_mapping(map, str, cdev_id, qp, params,
> > > + ret = add_mapping(map, str, cdev_id, qp, params,
> > > ipsec_ctx, NULL, NULL, i);
> > > + if (ret)
> > > + return ret;
> > > continue;
> > > }
> > >
> > > @@ -1801,12 +1799,15 @@ add_cdev_mapping(struct rte_cryptodev_info
> > *dev_info, uint16_t cdev_id,
> > > if (j->sym.xform_type !=
> > RTE_CRYPTO_SYM_XFORM_AUTH)
> > > continue;
> > >
> > > - ret |= add_mapping(map, str, cdev_id, qp, params,
> > > + ret = add_mapping(map, str, cdev_id, qp, params,
> > > ipsec_ctx, i, j, NULL);
> > > + if (ret)
> > > + return ret;
> > > + continue;
> > > }
> > > }
> > >
> > > - return ret;
> > > + return 0;
> > > }
> > >
> > > /* Check if the device is enabled by cryptodev_mask */ diff --git
> > > a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h index
> > > 8e07521..92fd5eb 100644
> > > --- a/examples/ipsec-secgw/ipsec.h
> > > +++ b/examples/ipsec-secgw/ipsec.h
> > > @@ -200,7 +200,9 @@ struct ipsec_ctx { };
> > >
> > > struct cdev_key {
> > > - uint16_t lcore_id;
> > > + uint16_t port_id;
> > > + uint8_t queue_id;
> > > + uint8_t lcore_id;
> > > uint8_t cipher_algo;
> > > uint8_t auth_algo;
> > > uint8_t aead_algo;
> > > --
> > > 2.7.4
next prev parent reply other threads:[~2020-01-31 16:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-10 14:46 Anoob Joseph
2020-01-29 22:12 ` Ananyev, Konstantin
2020-01-30 16:28 ` Anoob Joseph
2020-01-31 16:32 ` Ananyev, Konstantin [this message]
2020-01-31 17:04 ` Anoob Joseph
2020-01-31 18:49 ` Ananyev, Konstantin
2020-02-03 9:05 ` Anoob Joseph
2020-02-03 9:15 ` Akhil Goyal
2020-02-03 9:22 ` Anoob Joseph
2020-02-06 10:46 ` Anoob Joseph
2020-02-06 11:30 ` Akhil Goyal
2020-02-06 11:32 ` Thomas Monjalon
2020-01-30 16:38 ` [dpdk-dev] [PATCH v2] " Anoob Joseph
2020-01-31 17:39 ` Ananyev, Konstantin
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=SN6PR11MB2558616D5298DF7AD522D6F19A070@SN6PR11MB2558.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=anoobj@marvell.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=lbartosik@marvell.com \
--cc=pathreya@marvell.com \
--cc=radu.nicolau@intel.com \
/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).