From: "Coyle, David" <david.coyle@intel.com>
To: Anoob Joseph <anoobj@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Ji, Kai" <kai.ji@intel.com>,
"O'Sullivan, Kevin" <kevin.osullivan@intel.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: RE: [EXT] [PATCH v2 0/2] crypto/scheduler: add support for security protocols
Date: Mon, 11 Sep 2023 16:02:16 +0000 [thread overview]
Message-ID: <CH3PR11MB7252003026FD67B6C435BD7EE3F2A@CH3PR11MB7252.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR18MB46727FBD0837DC67BCDD03D3DF10A@PH0PR18MB4672.namprd18.prod.outlook.com>
Hi Anoob,
Thank you for that feedback - I was on extended leave so only just getting back to it now.
See replies below.
Regards,
David
> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Friday, August 11, 2023 12:09 PM
> To: Coyle, David <david.coyle@intel.com>; dev@dpdk.org
> Cc: Ji, Kai <kai.ji@intel.com>; O'Sullivan, Kevin <kevin.osullivan@intel.com>;
> Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: RE: [EXT] [PATCH v2 0/2] crypto/scheduler: add support for security
> protocols
>
> Hi David,
>
> While it is desirable to add security under crypto/scheduler, would it be
> functionally possible if the PMDs perform stateful processing? For example,
> with lookaside protocol mode of IPsec, fields such as seq no & AR defines how
> the crypto operation can be performed. Without two PMDs sharing this
> (actively), how can the load balancing happen?
[DC] So if some fields such as seq numbers are maintained within the PMDs for some protocols, then yes you are right - this would not work without some synchronization across PMD instances which I think we'd want to avoid at this point.
I tried to find some cases where a crypto PMD that supports IPSec, for example, maintains some global stateful parameters, but I could not find these cases.
I'm not at all familiar with these PMDs (cnxk, mvsam, dpaa_sec, dpaa2_sec) though, so maybe you could guide me as to where they are maintained?
>
> Said that, I agree utility of scheduler for stateless operations. My
> understanding is, PDCP offload that is available today is not stateful and that
> can leverage this. I'm not sure of DOCSIS and MACsec.
[DC] I notice that the PDCP security xform struct has a seq number related field, which would also suggest it could be stateful, but I could be wrong.
From a google search MACSec is stateless, but again I'm not an expert.
The protocol I am familiar with is DOCSIS, and it is for this protocol that we have added security support to the cryptodev scheduler.
DOCSIS is 100% stateless, so will work no problem with the scheduler.
>
> Should we make it such that only specific security sessions would be eligible for
> scheduler operation?
[DC] Do you think it would be acceptable to limit the scheduler to the DOCSIS protocol only for now, and let the IPSec, MACSec and PDCP experts add these later if applicable?
If you think this would be ok, I can easily make that change.
>
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: David Coyle <david.coyle@intel.com>
> > Sent: Friday, August 11, 2023 3:54 PM
> > To: dev@dpdk.org
> > Cc: kai.ji@intel.com; kevin.osullivan@intel.com; David Coyle
> > <david.coyle@intel.com>
> > Subject: [EXT] [PATCH v2 0/2] crypto/scheduler: add support for
> > security protocols
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > This patchset adds support to the cryptodev scheduler PMD and unit
> > tests for the existing security protocols in the security library,
> > namely IPSec, MACSec, PDCP and DOCSIS.
> >
> > v2:
> > * Improve inclusion of rte_security header files
> > * Fix typo in commit message
> >
> > David Coyle (2):
> > crypto/scheduler: support security protocols
> > test/crypto: add security tests for cryptodev scheduler
> >
> > app/test/test_cryptodev.c | 14 +-
> > doc/guides/rel_notes/release_23_11.rst | 3 +
> > drivers/crypto/scheduler/meson.build | 2 +-
> > .../scheduler/rte_cryptodev_scheduler.c | 229 ++++++++++-
> > drivers/crypto/scheduler/scheduler_failover.c | 12 +-
> > .../crypto/scheduler/scheduler_multicore.c | 10 +-
> > .../scheduler/scheduler_pkt_size_distr.c | 54 +--
> > drivers/crypto/scheduler/scheduler_pmd.c | 33 ++
> > drivers/crypto/scheduler/scheduler_pmd_ops.c | 375
> > +++++++++++++----- .../crypto/scheduler/scheduler_pmd_private.h | 148
> ++++---
> > .../crypto/scheduler/scheduler_roundrobin.c | 6 +-
> > 11 files changed, 656 insertions(+), 230 deletions(-)
> >
> > --
> > 2.25.1
next prev parent reply other threads:[~2023-09-11 16:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 10:14 [PATCH " David Coyle
2023-08-09 10:14 ` [PATCH 1/2] crypto/scheduler: support " David Coyle
2023-08-09 10:14 ` [PATCH 2/2] test/crypto: add security tests for cryptodev scheduler David Coyle
2023-08-11 10:23 ` [PATCH v2 0/2] crypto/scheduler: add support for security protocols David Coyle
2023-08-11 10:24 ` [PATCH v2 1/2] crypto/scheduler: support " David Coyle
2023-08-11 10:24 ` [PATCH v2 2/2] test/crypto: add security tests for cryptodev scheduler David Coyle
2023-08-11 11:09 ` [EXT] [PATCH v2 0/2] crypto/scheduler: add support for security protocols Anoob Joseph
2023-09-11 16:02 ` Coyle, David [this message]
2023-09-13 7:02 ` Anoob Joseph
2023-09-14 15:22 ` [PATCH v3 0/2] crypto/scheduler: add support for DOCSIS security protocol David Coyle
2023-09-14 15:22 ` [PATCH v3 1/2] crypto/scheduler: support " David Coyle
2023-09-18 11:02 ` [EXT] " Anoob Joseph
2023-09-19 14:16 ` Coyle, David
2023-09-14 15:22 ` [PATCH v3 2/2] test/crypto: add DOCSIS security tests for cryptodev scheduler David Coyle
2023-09-15 10:18 ` [PATCH v3 0/2] crypto/scheduler: add support for DOCSIS security protocol Power, Ciara
2023-09-15 14:02 ` Power, Ciara
2023-09-19 14:14 ` [PATCH v4 " David Coyle
2023-09-19 14:14 ` [PATCH v4 1/2] crypto/scheduler: support " David Coyle
2023-09-19 14:14 ` [PATCH v4 2/2] test/crypto: add DOCSIS security tests for cryptodev scheduler David Coyle
2023-09-20 5:45 ` [EXT] [PATCH v4 0/2] crypto/scheduler: add support for DOCSIS security protocol Anoob Joseph
2023-09-21 7:18 ` Akhil Goyal
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=CH3PR11MB7252003026FD67B6C435BD7EE3F2A@CH3PR11MB7252.namprd11.prod.outlook.com \
--to=david.coyle@intel.com \
--cc=anoobj@marvell.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=kai.ji@intel.com \
--cc=kevin.osullivan@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).