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


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