DPDK patches and discussions
 help / color / mirror / Atom feed
From: Anoob Joseph <anoobj@marvell.com>
To: Akhil Goyal <gakhil@marvell.com>,
	Declan Doherty <declan.doherty@intel.com>,
	Fan Zhang <roy.fan.zhang@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>
Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	Ankur Dwivedi <adwivedi@marvell.com>,
	Tejasree Kondoj <ktejasree@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>, Anoob Joseph <anoobj@marvell.com>,
	Archana Muniganti <marchana@marvell.com>
Subject: Re: [dpdk-dev] [PATCH 2/2] lib/security: add SA lifetime configuration
Date: Tue, 20 Jul 2021 06:20:04 +0000	[thread overview]
Message-ID: <PH0PR18MB467298EAC951CA2F57C42D27DFE29@PH0PR18MB4672.namprd18.prod.outlook.com> (raw)
In-Reply-To: <1626759974-334-3-git-send-email-anoobj@marvell.com>

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

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-20  6:20 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 [this message]
2021-07-26 13:50     ` Ananyev, Konstantin
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=PH0PR18MB467298EAC951CA2F57C42D27DFE29@PH0PR18MB4672.namprd18.prod.outlook.com \
    --to=anoobj@marvell.com \
    --cc=adwivedi@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=konstantin.ananyev@intel.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).