Netdev List
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeedm@nvidia.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Leon Romanovsky <leonro@nvidia.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	linux-netdev <netdev@vger.kernel.org>,
	Raed Salem <raeds@nvidia.com>
Subject: Re: [PATCH net-next v1 13/17] net/mlx5: Simplify IPsec capabilities logic
Date: Fri, 22 Apr 2022 15:42:57 -0700	[thread overview]
Message-ID: <20220422224257.pa7p2uuo4qau5ezi@sx1> (raw)
In-Reply-To: <f47d197be948ce44772baf3276a1a855ad2f210a.1650363043.git.leonro@nvidia.com>

On 19 Apr 13:13, Leon Romanovsky wrote:
>From: Leon Romanovsky <leonro@nvidia.com>
>
>Reduce number of hard-coded IPsec capabilities by making sure
>that mlx5_ipsec_device_caps() sets only supported bits.
>
>As part of this change, remove _accel_ notations from the names
>and prepare the code to IPsec full offload mode.
>

Can you explain why remove __accel__ notation ?
__accel__ notation and decoupling from other common netdev features is done
for modularity purpose, en_accel directories are separated so we can
implement complex/stateful accelerations while avoid contaminating/affecting
common data-path performance sensitives flows.

I think keeping __accel__ notations is a must here for the above reasons,
unless you have a more strong reason to remove it.. 

>Reviewed-by: Raed Salem <raeds@nvidia.com>
>Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
>---
> .../mellanox/mlx5/core/en_accel/ipsec.c       | 16 ++------------
> .../mellanox/mlx5/core/en_accel/ipsec.h       |  9 +++-----
> .../mlx5/core/en_accel/ipsec_offload.c        | 22 +++++++++----------
> 3 files changed, 16 insertions(+), 31 deletions(-)
>
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
>index Clean IPsec FS add/delete rules28729b1cc6e6..be7650d2cfd3 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
>@@ -215,7 +215,7 @@ static inline int mlx5e_xfrm_validate_state(struct xfrm_state *x)
> 		return -EINVAL;
> 	}
> 	if (x->props.flags & XFRM_STATE_ESN &&
>-	    !(mlx5_ipsec_device_caps(priv->mdev) & MLX5_ACCEL_IPSEC_CAP_ESN)) {
>+	    !(mlx5_ipsec_device_caps(priv->mdev) & MLX5_IPSEC_CAP_ESN)) {
> 		netdev_info(netdev, "Cannot offload ESN xfrm states\n");
> 		return -EINVAL;
> 	}
>@@ -262,11 +262,6 @@ static inline int mlx5e_xfrm_validate_state(struct xfrm_state *x)
> 		netdev_info(netdev, "Cannot offload xfrm states with geniv other than seqiv\n");
> 		return -EINVAL;
> 	}
>-	if (x->props.family == AF_INET6 &&
>-	    !(mlx5_ipsec_device_caps(priv->mdev) & MLX5_ACCEL_IPSEC_CAP_IPV6)) {
>-		netdev_info(netdev, "IPv6 xfrm state offload is not supported by this device\n");
>-		return -EINVAL;
>-	}
> 	return 0;
> }
>
>@@ -457,12 +452,6 @@ void mlx5e_ipsec_build_netdev(struct mlx5e_priv *priv)
> 	if (!mlx5_ipsec_device_caps(mdev))
> 		return;
>
>-	if (!(mlx5_ipsec_device_caps(mdev) & MLX5_ACCEL_IPSEC_CAP_ESP) ||
>-	    !MLX5_CAP_ETH(mdev, swp)) {
>-		mlx5_core_dbg(mdev, "mlx5e: ESP and SWP offload not supported\n");
>-		return;
>-	}
>-
> 	mlx5_core_info(mdev, "mlx5e: IPSec ESP acceleration enabled\n");
> 	netdev->xfrmdev_ops = &mlx5e_ipsec_xfrmdev_ops;
> 	netdev->features |= NETIF_F_HW_ESP;
>@@ -476,8 +465,7 @@ void mlx5e_ipsec_build_netdev(struct mlx5e_priv *priv)
> 	netdev->features |= NETIF_F_HW_ESP_TX_CSUM;
> 	netdev->hw_enc_features |= NETIF_F_HW_ESP_TX_CSUM;
>
>-	if (!(mlx5_ipsec_device_caps(mdev) & MLX5_ACCEL_IPSEC_CAP_LSO) ||
>-	    !MLX5_CAP_ETH(mdev, swp_lso)) {
>+	if (!MLX5_CAP_ETH(mdev, swp_lso)) {
> 		mlx5_core_dbg(mdev, "mlx5e: ESP LSO not supported\n");
> 		return;
> 	}
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.h b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.h
>index af1467cbb7c7..97c55620089d 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.h
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.h
>@@ -102,12 +102,9 @@ struct mlx5_accel_esp_xfrm_attrs {
> 	u8 is_ipv6;
> };
>
>-enum mlx5_accel_ipsec_cap {
>-	MLX5_ACCEL_IPSEC_CAP_DEVICE		= 1 << 0,
>-	MLX5_ACCEL_IPSEC_CAP_ESP		= 1 << 1,
>-	MLX5_ACCEL_IPSEC_CAP_IPV6		= 1 << 2,
>-	MLX5_ACCEL_IPSEC_CAP_LSO		= 1 << 3,
>-	MLX5_ACCEL_IPSEC_CAP_ESN		= 1 << 4,
>+enum mlx5_ipsec_cap {
>+	MLX5_IPSEC_CAP_CRYPTO		= 1 << 0,
>+	MLX5_IPSEC_CAP_ESN		= 1 << 1,
> };
>
> struct mlx5e_priv;
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_offload.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_offload.c
>index 817747d5229e..b44bce3f4ef1 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_offload.c
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_offload.c
>@@ -7,7 +7,7 @@
>
> u32 mlx5_ipsec_device_caps(struct mlx5_core_dev *mdev)
> {
>-	u32 caps;
>+	u32 caps = 0;
>
> 	if (!MLX5_CAP_GEN(mdev, ipsec_offload))
> 		return 0;
>@@ -19,23 +19,23 @@ u32 mlx5_ipsec_device_caps(struct mlx5_core_dev *mdev)
> 	    MLX5_HCA_CAP_GENERAL_OBJECT_TYPES_IPSEC))
> 		return 0;
>
>-	if (!MLX5_CAP_IPSEC(mdev, ipsec_crypto_offload) ||
>-	    !MLX5_CAP_ETH(mdev, insert_trailer))
>-		return 0;
>-
> 	if (!MLX5_CAP_FLOWTABLE_NIC_TX(mdev, ipsec_encrypt) ||
> 	    !MLX5_CAP_FLOWTABLE_NIC_RX(mdev, ipsec_decrypt))
> 		return 0;
>
>-	caps = MLX5_ACCEL_IPSEC_CAP_DEVICE | MLX5_ACCEL_IPSEC_CAP_IPV6 |
>-	       MLX5_ACCEL_IPSEC_CAP_LSO;
>+	if (!MLX5_CAP_IPSEC(mdev, ipsec_crypto_esp_aes_gcm_128_encrypt) ||
>+	    !MLX5_CAP_IPSEC(mdev, ipsec_crypto_esp_aes_gcm_128_decrypt))
>+		return 0;
>
>-	if (MLX5_CAP_IPSEC(mdev, ipsec_crypto_esp_aes_gcm_128_encrypt) &&
>-	    MLX5_CAP_IPSEC(mdev, ipsec_crypto_esp_aes_gcm_128_decrypt))
>-		caps |= MLX5_ACCEL_IPSEC_CAP_ESP;
>+	if (MLX5_CAP_IPSEC(mdev, ipsec_crypto_offload) &&
>+	    MLX5_CAP_ETH(mdev, insert_trailer) && MLX5_CAP_ETH(mdev, swp))
>+		caps |= MLX5_IPSEC_CAP_CRYPTO;
>+
>+	if (!caps)
>+		return 0;
>
> 	if (MLX5_CAP_IPSEC(mdev, ipsec_esn))
>-		caps |= MLX5_ACCEL_IPSEC_CAP_ESN;
>+		caps |= MLX5_IPSEC_CAP_ESN;
>
> 	/* We can accommodate up to 2^24 different IPsec objects
> 	 * because we use up to 24 bit in flow table metadata
>-- 
>2.35.1
>

  reply	other threads:[~2022-04-22 23:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 10:13 [PATCH net-next v1 00/17] Extra IPsec cleanup Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 01/17] net/mlx5: Simplify IPsec flow steering init/cleanup functions Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 02/17] net/mlx5: Check IPsec TX flow steering namespace in advance Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 03/17] net/mlx5: Don't hide fallback to software IPsec in FS code Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 04/17] net/mlx5: Reduce useless indirection in IPsec FS add/delete flows Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 05/17] net/mlx5: Store IPsec ESN update work in XFRM state Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 06/17] net/mlx5: Remove useless validity check Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 07/17] net/mlx5: Merge various control path IPsec headers into one file Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 08/17] net/mlx5: Remove indirections from esp functions Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 09/17] net/mlx5: Simplify HW context interfaces by using SA entry Leon Romanovsky
2022-04-22 22:19   ` Saeed Mahameed
2022-05-01  8:56     ` Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 10/17] net/mlx5: Clean IPsec FS add/delete rules Leon Romanovsky
2022-04-22 22:25   ` Saeed Mahameed
2022-05-01  8:52     ` Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 11/17] net/mlx5: Make sure that no dangling IPsec FS pointers exist Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 12/17] net/mlx5: Don't advertise IPsec netdev support for non-IPsec device Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 13/17] net/mlx5: Simplify IPsec capabilities logic Leon Romanovsky
2022-04-22 22:42   ` Saeed Mahameed [this message]
2022-05-01  8:42     ` Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 14/17] net/mlx5: Remove not-supported ICV length Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 15/17] net/mlx5: Cleanup XFRM attributes struct Leon Romanovsky
2022-04-22 22:45   ` Saeed Mahameed
2022-05-01  8:05     ` Leon Romanovsky
2022-04-19 10:13 ` [PATCH net-next v1 16/17] net/mlx5: Allow future addition of IPsec object modifiers Leon Romanovsky
2022-04-22 22:46   ` Saeed Mahameed
2022-04-19 10:13 ` [PATCH net-next v1 17/17] net/mlx5: Don't perform lookup after already known sec_path Leon Romanovsky
2022-04-22 17:49 ` [PATCH net-next v1 00/17] Extra IPsec cleanup Leon Romanovsky
2022-04-22 17:55   ` Saeed Mahameed

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=20220422224257.pa7p2uuo4qau5ezi@sx1 \
    --to=saeedm@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=jgg@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=leonro@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=raeds@nvidia.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