From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Anoob Joseph <anoobj@marvell.com>,
Akhil Goyal <gakhil@marvell.com>,
"Doherty, Declan" <declan.doherty@intel.com>,
"Zhang, Roy Fan" <roy.fan.zhang@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>
Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Ankur Dwivedi <adwivedi@marvell.com>,
Tejasree Kondoj <ktejasree@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Archana Muniganti <marchana@marvell.com>
Subject: Re: [dpdk-dev] [PATCH 2/2] lib/security: add SA lifetime configuration
Date: Mon, 26 Jul 2021 13:50:18 +0000 [thread overview]
Message-ID: <DM6PR11MB449186E8C4A7D44873F1CAA79AE89@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR18MB467298EAC951CA2F57C42D27DFE29@PH0PR18MB4672.namprd18.prod.outlook.com>
Hi Anoob,
>
> Hi Akhil, Declan, Fan, Hemant, Konstantin,
>
> This patch & and a patch submitted by Archana earlier (http://patches.dpdk.org/project/dpdk/patch/20210630111248.746-1-
> marchana@marvell.com/), aims at extending rte_crypto_op so that it can be used to communicate any warnings from the rte_security
> offload, such as,
>
> 1. Soft expiry : application requires a notification to renegotiate SA
> 2. L3/L4 checksum : when application offloads checksum verification of plain packet after IPsec processing. This need not be treated as an
> error as IPsec operation was successful and checksum generation/verification can be redone in software, especially if the checksum
> operation failed due to some limitations of the underlying device.
>
> Both the above will be an IPsec operation completed successfully but with additional information that PMD can pass on to application for
> indicating status of offloads.
>
> There are two options that we considered,
> 1. Extend the enum, rte_crypto_op_status, to cover warnings [1]
> 2. There are reserved fields in rte_cryto_op structure. So we can use bits in them to indicate various cases. [2]
>
> Both the submitted patches follow approach 1 (following how it's done currently), but we can switch to approach 2 if we think there can be
> more such "warnings" that can occur simultaneously. Can you share your thoughts on how we should extend the library to handle such
> cases?
>
> [1] https://doc.dpdk.org/api/rte__crypto_8h.html#afe16508b77c2a8dc5caf74a4e9850171
> [2] https://doc.dpdk.org/api/rte__crypto_8h_source.html
My vote would probably be for option #2 (use one of the reserved fields for it).
That way - existing code wouldn't need to be changed.
Again these warnings, it probably needs to be a bit-flags, correct?
Konstantin
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: Anoob Joseph <anoobj@marvell.com>
> > Sent: Tuesday, July 20, 2021 11:16 AM
> > To: Akhil Goyal <gakhil@marvell.com>; Declan Doherty
> > <declan.doherty@intel.com>; Fan Zhang <roy.fan.zhang@intel.com>;
> > Konstantin Ananyev <konstantin.ananyev@intel.com>
> > Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>; Tejasree
> > Kondoj <ktejasree@marvell.com>; dev@dpdk.org
> > Subject: [PATCH 2/2] lib/security: add SA lifetime configuration
> >
> > Add SA lifetime configuration to register soft and hard expiry limits.
> > Expiry can be in units of number of packets or bytes. Crypto op status is also
> > updated to cover warnings indicating soft expiry in case of lookaside protocol
> > operations.
> >
> > In case of soft expiry, the packets are successfully IPsec processed but the
> > soft expiry would indicate that SA needs to be reconfigured. For inline
> > protocol capable ethdev, this would result in an eth event while for lookaside
> > protocol capable cryptodev, this can be communicated via
> > `rte_crypto_op.status` field.
> >
> > In case of hard expiry, the packets will not be IPsec processed and would
> > result in error.
> >
> > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > ---
> > examples/ipsec-secgw/ipsec.c | 2 +-
> > examples/ipsec-secgw/ipsec.h | 2 +-
> > lib/cryptodev/rte_crypto.h | 7 +++++++
> > lib/security/rte_security.h | 28 ++++++++++++++++++++++++++--
> > 4 files changed, 35 insertions(+), 4 deletions(-)
> >
> > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> > index 5b032fe..4868294 100644
> > --- a/examples/ipsec-secgw/ipsec.c
> > +++ b/examples/ipsec-secgw/ipsec.c
> > @@ -49,7 +49,7 @@ set_ipsec_conf(struct ipsec_sa *sa, struct
> > rte_security_ipsec_xform *ipsec)
> > }
> > /* TODO support for Transport */
> > }
> > - ipsec->esn_soft_limit = IPSEC_OFFLOAD_ESN_SOFTLIMIT;
> > + ipsec->life.packets_soft_limit = IPSEC_OFFLOAD_PKTS_SOFTLIMIT;
> > ipsec->replay_win_sz = app_sa_prm.window_size;
> > ipsec->options.esn = app_sa_prm.enable_esn;
> > ipsec->options.udp_encap = sa->udp_encap; diff --git
> > a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h index
> > ae5058d..90c81c1 100644
> > --- a/examples/ipsec-secgw/ipsec.h
> > +++ b/examples/ipsec-secgw/ipsec.h
> > @@ -23,7 +23,7 @@
> >
> > #define MAX_DIGEST_SIZE 32 /* Bytes -- 256 bits */
> >
> > -#define IPSEC_OFFLOAD_ESN_SOFTLIMIT 0xffffff00
> > +#define IPSEC_OFFLOAD_PKTS_SOFTLIMIT 0xffffff00
> >
> > #define IV_OFFSET (sizeof(struct rte_crypto_op) + \
> > sizeof(struct rte_crypto_sym_op))
> > diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h index
> > fd5ef3a..c5a0897 100644
> > --- a/lib/cryptodev/rte_crypto.h
> > +++ b/lib/cryptodev/rte_crypto.h
> > @@ -52,6 +52,13 @@ enum rte_crypto_op_status {
> > /**< Operation failed due to invalid arguments in request */
> > RTE_CRYPTO_OP_STATUS_ERROR,
> > /**< Error handling operation */
> > + RTE_CRYPTO_OP_STATUS_WAR = 128,
> > + /**<
> > + * Operation completed successfully with warnings.
> > + * Note: All the warnings starts from here.
> > + */
> > + RTE_CRYPTO_OPSTATUS_WAR_SOFT_EXPIRY,
> > + /**< Operation completed successfully with soft expiry of lifetime */
> > };
> >
> > /**
> > diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h index
> > d61a55d..d633c8d 100644
> > --- a/lib/security/rte_security.h
> > +++ b/lib/security/rte_security.h
> > @@ -206,6 +206,30 @@ enum rte_security_ipsec_sa_direction { };
> >
> > /**
> > + * Configure soft and hard lifetime of an IPsec SA
> > + *
> > + * Lifetime of an IPsec SA would specify the maximum number of packets
> > +or bytes
> > + * that can be processed. IPsec operations would start failing once any
> > +hard
> > + * limit is reached.
> > + *
> > + * Soft limits can be specified to generate notification when the SA is
> > + * approaching hard limits for lifetime. For inline operations,
> > +reaching soft
> > + * expiry limit would result in raising an eth event for the same. For
> > +lookaside
> > + * operations, this would result in a warning returned in
> > + * ``rte_crypto_op.status``.
> > + */
> > +struct rte_security_ipsec_lifetime {
> > + uint64_t packets_soft_limit;
> > + /**< Soft expiry limit in number of packets */
> > + uint64_t bytes_soft_limit;
> > + /**< Soft expiry limit in bytes */
> > + uint64_t packets_hard_limit;
> > + /**< Soft expiry limit in number of packets */
> > + uint64_t bytes_hard_limit;
> > + /**< Soft expiry limit in bytes */
> > +};
> > +
> > +/**
> > * IPsec security association configuration data.
> > *
> > * This structure contains data required to create an IPsec SA security
> > session.
> > @@ -225,8 +249,8 @@ struct rte_security_ipsec_xform {
> > /**< IPsec SA Mode - transport/tunnel */
> > struct rte_security_ipsec_tunnel_param tunnel;
> > /**< Tunnel parameters, NULL for transport mode */
> > - uint64_t esn_soft_limit;
> > - /**< ESN for which the overflow event need to be raised */
> > + struct rte_security_ipsec_lifetime life;
> > + /**< IPsec SA lifetime */
> > uint32_t replay_win_sz;
> > /**< Anti replay window size to enable sequence replay attack
> > handling.
> > * replay checking is disabled if the window size is 0.
> > --
> > 2.7.4
next prev parent reply other threads:[~2021-07-26 13:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-20 5:46 [dpdk-dev] [PATCH 0/2] Improvements to rte_security Anoob Joseph
2021-07-20 5:46 ` [dpdk-dev] [PATCH 1/2] lib/security: add IV generation Anoob Joseph
2021-07-20 5:46 ` [dpdk-dev] [PATCH 2/2] lib/security: add SA lifetime configuration Anoob Joseph
2021-07-20 6:20 ` Anoob Joseph
2021-07-26 13:50 ` Ananyev, Konstantin [this message]
2021-07-26 15:50 ` Akhil Goyal
2021-07-27 11:40 ` Ananyev, Konstantin
2021-07-27 19:29 ` Akhil Goyal
2021-07-28 10:59 ` Ananyev, Konstantin
2021-07-28 12:58 ` Akhil Goyal
2021-07-28 14:38 ` Anoob Joseph
2021-07-29 10:23 ` Ananyev, Konstantin
2021-08-02 7:07 ` Anoob Joseph
2021-08-03 11:51 ` Ananyev, Konstantin
2021-08-03 12:03 ` Anoob Joseph
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=DM6PR11MB449186E8C4A7D44873F1CAA79AE89@DM6PR11MB4491.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=adwivedi@marvell.com \
--cc=anoobj@marvell.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=gakhil@marvell.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=ktejasree@marvell.com \
--cc=marchana@marvell.com \
--cc=roy.fan.zhang@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).