DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
To: Akhil Goyal <gakhil@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Power, Ciara" <ciara.power@intel.com>
Subject: RE: [EXTERNAL] [PATCH] app/crypto-perf-test: fix unset crc algorithm
Date: Fri, 15 Mar 2024 09:56:03 +0000	[thread overview]
Message-ID: <PH0PR11MB501331DFD30AB3C8591702829F282@PH0PR11MB5013.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CO6PR18MB4484912F33B032B78C536D10D8292@CO6PR18MB4484.namprd18.prod.outlook.com>



> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, March 14, 2024 1:50 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Power, Ciara <ciara.power@intel.com>
> Subject: RE: [EXTERNAL] [PATCH] app/crypto-perf-test: fix unset crc algorithm
> 
> > > Subject: RE: [EXTERNAL] [PATCH] app/crypto-perf-test: fix unset crc
> > > algorithm
> > >
> > > > Because net crc api is not thread-safe, setting crc algorithm by
> > > > the application will prevent race condition in the calc function.
> > > > Race condition still may occur when any of the threads will call
> > > > this function again. Function is called with the highest possible
> > > > SIMD extension, which is AVX512, but if this is not found, CRC API
> > > > will pick the other highest possible extension, or scalar if no
> > > > SIMD available.
> > > >
> > > > Fixes: f8be1786b1b8 ("app/crypto-perf: introduce performance test
> > > > application")
> > > >
> > > > Signed-off-by: Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
> > > > ---
> > > >  app/test-crypto-perf/main.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/app/test-crypto-perf/main.c
> > > > b/app/test-crypto-perf/main.c index 40c0b4b54f..58496797d7 100644
> > > > --- a/app/test-crypto-perf/main.c
> > > > +++ b/app/test-crypto-perf/main.c
> > > > @@ -11,6 +11,7 @@
> > > >  #include <rte_eal.h>
> > > >  #include <rte_errno.h>
> > > >  #include <rte_cryptodev.h>
> > > > +#include <rte_net_crc.h>
> > > >  #ifdef RTE_CRYPTO_SCHEDULER
> > > >  #include <rte_cryptodev_scheduler.h>  #endif @@ -599,6 +600,8 @@
> > > > main(int argc, char **argv)
> > > >  		goto err;
> > > >  	}
> > > >
> > > > +	rte_net_crc_set_alg(RTE_NET_CRC_AVX512);
> > > > +
> > > >  	ret = cperf_verify_devices_capabilities(&opts, enabled_cdevs,
> > > >  			nb_cryptodevs);
> > > >  	if (ret) {
> > > > --
> > > Not sure what is the use of this API here.
> > > Which calc function is it fixing.
> >
> > Yes, this deserves some explanation, rte_net_crc_calc function, when
> > alg not set, will first try to set it during the first run.
> > Yet it is done in thread-unsafe manner, causing perf-test to most
> > likely segfault because of that, when more than one thread used.
> >
> Still it is not clear. Which use case of test-crypto-perf need setting this?
`-optype docsis` currently, so I can narrow down it to docsis only.
> If it is specific to a usecase, then it should be under checks or it should be inside
> PMD.
It would be the best to have it inside the PMD, the problem is that it changes algorithm for entire process,
so until changes made to the API, it should be under user control.
> 
> > >
> > > Also will it ever pick neon handler?
> >
> > No, it won't, currently only qat is using this api though.
> > This api needs to be fixed, so eventually this will look different,
> > but for now, not many choices available.

  reply	other threads:[~2024-03-15  9:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 14:54 Arkadiusz Kusztal
2024-03-13 18:22 ` [EXTERNAL] " Akhil Goyal
2024-03-13 22:15   ` Kusztal, ArkadiuszX
2024-03-14 12:49     ` Akhil Goyal
2024-03-15  9:56       ` Kusztal, ArkadiuszX [this message]
2024-03-15 10:44 ` [PATCH v2] " Arkadiusz Kusztal
2024-03-15 10:49   ` Power, Ciara

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=PH0PR11MB501331DFD30AB3C8591702829F282@PH0PR11MB5013.namprd11.prod.outlook.com \
    --to=arkadiuszx.kusztal@intel.com \
    --cc=ciara.power@intel.com \
    --cc=dev@dpdk.org \
    --cc=gakhil@marvell.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).