DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: "Trahe, Fiona" <fiona.trahe@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	Pablo de Lara <pablo.de.lara.guarch@intel.com>,
	"anoobj@marvell.com" <anoobj@marvell.com>,
	"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>
Cc: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] examples: add multi process crypto application
Date: Sat, 4 Jul 2020 18:29:08 +0000	[thread overview]
Message-ID: <VI1PR04MB31683B80450C9D5E4CE9CC04E66B0@VI1PR04MB3168.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <SN6PR11MB28801F0D6AA4B6F75E8EBFC7E46A0@SN6PR11MB2880.namprd11.prod.outlook.com>

> > >
> > > This multi process app is only taking care of  crypto queues while others are
> > > for NICs.
> > > Is it not worth to have crypto+NIC multi process app instead of this app?
> > [Arek] - initially main purpose was to check PMD behavior when:
> > 1) configure cryptodev, sessions, queues and do enqueue/dequeue from
> another different processes
> > 2) run enqueue/dequeue from different processes on the same queue pair.
> > If it can be done with one app I think it is ok.
> > > I believe most common usecases of crypto are with network traffic.
> > > Can we modify l2fwd-crypto for multi process?
> [Fiona] Yes, it would be a good idea to do that sample app too.
> However this app allows standalone validation of cryptodev lib and PMDs,
> running in multiple processes, without introducing dependencies on
> ethdev APIs, traffic generator, NIC, etc. I think this is useful as is.
> One consideration is whether it would be better to treat this as a test tool
> and move to the test directory - as you're right, it's not showing
> a typical complete application, just allowing to play around with the crypto part.
> My preference is to move to under the examples/multi-process, but up to you.
Example applications are also not close to real work application. But they should
Have end to end functionality available with some missing processing in between.
I would say:
- modifying l2fwd-crypto can be preference 1
- moving multiprocess crypto to test app can be preference 2 as it is just a unit test application for multi process.
- moving to examples/multi-process will be preference 3.

      reply	other threads:[~2020-07-04 18:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 14:23 Arek Kusztal
2020-06-24 14:23 ` Arek Kusztal
2020-07-02 19:29 ` Akhil Goyal
2020-07-03  7:47   ` Kusztal, ArkadiuszX
2020-07-03 15:16     ` Trahe, Fiona
2020-07-04 18:29       ` Akhil Goyal [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR04MB31683B80450C9D5E4CE9CC04E66B0@VI1PR04MB3168.eurprd04.prod.outlook.com \
    --to=akhil.goyal@nxp.com \
    --cc=anatoly.burakov@intel.com \
    --cc=anoobj@marvell.com \
    --cc=arkadiuszx.kusztal@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=ruifeng.wang@arm.com \


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