DPDK patches and discussions
 help / color / mirror / Atom feed
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


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