From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Mark Bloch <mbloch@nvidia.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Saeed Mahameed <saeedm@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, Vlad Dogaru <vdogaru@nvidia.com>,
Yevgeny Kliteynik <kliteyn@nvidia.com>
Subject: Re: [PATCH net 1/5] net/mlx5e: Use custom tunnel header for vxlan gbp
Date: Wed, 23 Apr 2025 12:34:08 +0200 [thread overview]
Message-ID: <aAjCIE/DMAlLZXGA@mev-dev.igk.intel.com> (raw)
In-Reply-To: <20250423083611.324567-2-mbloch@nvidia.com>
On Wed, Apr 23, 2025 at 11:36:07AM +0300, Mark Bloch wrote:
> From: Vlad Dogaru <vdogaru@nvidia.com>
>
> Symbolic (e.g. "vxlan") and custom (e.g. "tunnel_header_0") tunnels
> cannot be combined, but the match params interface does not have fields
> for matching on vxlan gbp. To match vxlan bgp, the tc_tun layer uses
> tunnel_header_0.
>
> Allow matching on both VNI and GBP by matching the VNI with a custom
> tunnel header instead of the symbolic field name.
>
> Matching solely on the VNI continues to use the symbolic field name.
>
> Fixes: 74a778b4a63f ("net/mlx5: HWS, added definers handling")
> Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com>
> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
> ---
> .../mellanox/mlx5/core/en/tc_tun_vxlan.c | 32 +++++++++++++++++--
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
> index 5c762a71818d..7a18a469961d 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
> @@ -165,9 +165,6 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
> struct flow_match_enc_keyid enc_keyid;
> void *misc_c, *misc_v;
>
> - misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria, misc_parameters);
> - misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, misc_parameters);
> -
> if (!flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_KEYID))
> return 0;
>
> @@ -182,6 +179,30 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
> err = mlx5e_tc_tun_parse_vxlan_gbp_option(priv, spec, f);
> if (err)
> return err;
> +
> + /* We can't mix custom tunnel headers with symbolic ones and we
> + * don't have a symbolic field name for GBP, so we use custom
> + * tunnel headers in this case. We need hardware support to
> + * match on custom tunnel headers, but we already know it's
> + * supported because the previous call successfully checked for
> + * that.
> + */
> + misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria,
> + misc_parameters_5);
> + misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
> + misc_parameters_5);
> +
> + /* Shift by 8 to account for the reserved bits in the vxlan
> + * header after the VNI.
> + */
> + MLX5_SET(fte_match_set_misc5, misc_c, tunnel_header_1,
> + be32_to_cpu(enc_keyid.mask->keyid) << 8);
> + MLX5_SET(fte_match_set_misc5, misc_v, tunnel_header_1,
> + be32_to_cpu(enc_keyid.key->keyid) << 8);
> +
> + spec->match_criteria_enable |= MLX5_MATCH_MISC_PARAMETERS_5;
> +
> + return 0;
> }
>
> /* match on VNI is required */
> @@ -195,6 +216,11 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
> return -EOPNOTSUPP;
> }
>
> + misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria,
> + misc_parameters);
> + misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
> + misc_parameters);
> +
> MLX5_SET(fte_match_set_misc, misc_c, vxlan_vni,
> be32_to_cpu(enc_keyid.mask->keyid));
> MLX5_SET(fte_match_set_misc, misc_v, vxlan_vni,
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> --
> 2.34.1
next prev parent reply other threads:[~2025-04-23 10:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-23 8:36 [PATCH net 0/5] mlx5 misc fixes 2025-04-23 Mark Bloch
2025-04-23 8:36 ` [PATCH net 1/5] net/mlx5e: Use custom tunnel header for vxlan gbp Mark Bloch
2025-04-23 10:34 ` Michal Swiatkowski [this message]
2025-04-23 8:36 ` [PATCH net 2/5] net/mlx5: E-Switch, Initialize MAC Address for Default GID Mark Bloch
2025-04-23 10:31 ` Michal Swiatkowski
2025-04-23 11:20 ` Mark Bloch
2025-04-23 12:00 ` Michal Swiatkowski
2025-04-23 8:36 ` [PATCH net 3/5] net/mlx5e: TC, Continue the attr process even if encap entry is invalid Mark Bloch
2025-04-23 8:36 ` [PATCH net 4/5] net/mlx5e: Fix lock order in mlx5e_tx_reporter_ptpsq_unhealthy_recover Mark Bloch
2025-04-23 8:36 ` [PATCH net 5/5] net/mlx5: E-switch, Fix error handling for enabling roce Mark Bloch
2025-04-23 10:17 ` Michal Swiatkowski
2025-04-25 19:01 ` [PATCH net 0/5] mlx5 misc fixes 2025-04-23 patchwork-bot+netdevbpf
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=aAjCIE/DMAlLZXGA@mev-dev.igk.intel.com \
--to=michal.swiatkowski@linux.intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kliteyn@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=vdogaru@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.