From: Carolina Jubran <cjubran@nvidia.com>
To: Simon Horman <horms@kernel.org>, Tariq Toukan <tariqt@nvidia.com>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Mark Bloch <mbloch@nvidia.com>,
Sabrina Dubroca <sd@queasysnail.net>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, Gal Pressman <gal@nvidia.com>,
Dragos Tatulea <dtatulea@nvidia.com>,
Jianbo Liu <jianbol@nvidia.com>
Subject: Re: [PATCH mlx5-next 2/3] net/mlx5: Refactor MACsec WQE metadata shifts
Date: Mon, 15 Sep 2025 09:23:04 +0300 [thread overview]
Message-ID: <153b22be-3cd4-4ae8-9091-923e4e0018f2@nvidia.com> (raw)
In-Reply-To: <20250912154926.GG30363@horms.kernel.org>
On 12/09/2025 18:49, Simon Horman wrote:
> On Thu, Sep 11, 2025 at 10:10:18AM +0300, Tariq Toukan wrote:
>> From: Carolina Jubran <cjubran@nvidia.com>
>>
>> Introduce MLX5_ETH_WQE_FT_META_SHIFT as a shared base offset for
>> features that use the lower 8 bits of the WQE flow_table_metadata
>> field, currently used for timestamping, IPsec, and MACsec.
>>
>> Define MLX5_ETH_WQE_FT_META_MACSEC_FS_ID_MASK so that fs_id occupies
>> bits 2–5, making it clear that fs_id occupies bits in the metadata.
>>
>> Set MLX5_ETH_WQE_FT_META_MACSEC_MASK as the OR of the MACsec flag and
>> MLX5_ETH_WQE_FT_META_MACSEC_FS_ID_MASK, corresponding to the original
>> 0x3E mask.
>>
>> Update the fs_id macro to right-shift the MACsec flag by
>> MLX5_ETH_WQE_FT_META_SHIFT and update the RoCE modify-header action to
>> use it.
>>
>> Introduce the helper macro MLX5_MACSEC_TX_METADATA(fs_id) to compose
>> the full shifted MACsec metadata value.
>>
>> These changes make it explicit exactly which metadata bits carry MACsec
>> information, simplifying future feature exclusions when multiple
>> features share the WQE flowtable metadata.
>>
>> In addition, drop the incorrect “RX flow steering” comment, since this
>> applies to TX flow steering.
>>
>> Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
>> Reviewed-by: Jianbo Liu <jianbol@nvidia.com>
>> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
>> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> Hi Carolina, Tariq, all,
>
> I'm wondering if dropping _SHIFT and making use of FIELD_PREP
> would lead to a cleaner and more idiomatic implementation.
>
> I'm thinking that such an approach would involve
> updating MLX5_ETH_WQE_FT_META_MACSEC_MASK rather
> than MLX5_ETH_WQE_FT_META_MACSEC_SHIFT in the following patch.
>
> I'm thinking of something along the lines of following incremental patch.
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c
> index 9ec450603176..58c0ff4af78f 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c
> @@ -2218,7 +2218,7 @@ static int mlx5_macsec_fs_add_roce_rule_tx(struct mlx5_macsec_fs *macsec_fs, u32
> MLX5_SET(set_action_in, action, data,
> mlx5_macsec_fs_set_tx_fs_id(fs_id));
> MLX5_SET(set_action_in, action, offset,
> - MLX5_ETH_WQE_FT_META_MACSEC_SHIFT);
> + __bf_shf(MLX5_ETH_WQE_FT_META_MACSEC_MASK));
> MLX5_SET(set_action_in, action, length, 32);
>
> modify_hdr = mlx5_modify_header_alloc(mdev, MLX5_FLOW_NAMESPACE_RDMA_TX_MACSEC,
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.h b/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.h
> index 15acaff43641..402840cb3110 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.h
> @@ -13,18 +13,15 @@
> #define MLX5_MACSEC_RX_METADAT_HANDLE(metadata) ((metadata) & MLX5_MACSEC_RX_FS_ID_MASK)
>
> /* MACsec TX flow steering */
> -#define MLX5_ETH_WQE_FT_META_MACSEC_MASK \
> - (MLX5_ETH_WQE_FT_META_MACSEC | MLX5_ETH_WQE_FT_META_MACSEC_FS_ID_MASK)
> -#define MLX5_ETH_WQE_FT_META_MACSEC_SHIFT MLX5_ETH_WQE_FT_META_SHIFT
> +#define MLX5_ETH_WQE_FT_META_MACSEC_MASK GENMASK(7, 0)
>
> /* MACsec fs_id handling for steering */
> #define mlx5_macsec_fs_set_tx_fs_id(fs_id) \
> - (((MLX5_ETH_WQE_FT_META_MACSEC) >> MLX5_ETH_WQE_FT_META_MACSEC_SHIFT) \
> - | ((fs_id) << 2))
> + (MLX5_ETH_WQE_FT_META_IPSEC | (fs_id) << 2)
>
> #define MLX5_MACSEC_TX_METADATA(fs_id) \
> - (mlx5_macsec_fs_set_tx_fs_id(fs_id) << \
> - MLX5_ETH_WQE_FT_META_MACSEC_SHIFT)
> + FIELD_PREP(MLX5_ETH_WQE_FT_META_MACSEC_MASK, \
> + mlx5_macsec_fs_set_tx_fs_id(fs_id))
>
> /* MACsec fs_id uses 4 bits, supports up to 16 interfaces */
> #define MLX5_MACSEC_NUM_OF_SUPPORTED_INTERFACES 16
> diff --git a/include/linux/mlx5/qp.h b/include/linux/mlx5/qp.h
> index b21be7630575..5546c7bd2c83 100644
> --- a/include/linux/mlx5/qp.h
> +++ b/include/linux/mlx5/qp.h
> @@ -251,14 +251,9 @@ enum {
> MLX5_ETH_WQE_SWP_OUTER_L4_UDP = 1 << 5,
> };
>
> -/* Base shift for metadata bits used by timestamping, IPsec, and MACsec */
> -#define MLX5_ETH_WQE_FT_META_SHIFT 0
> -
> enum {
> - MLX5_ETH_WQE_FT_META_IPSEC = BIT(0) << MLX5_ETH_WQE_FT_META_SHIFT,
> - MLX5_ETH_WQE_FT_META_MACSEC = BIT(1) << MLX5_ETH_WQE_FT_META_SHIFT,
> - MLX5_ETH_WQE_FT_META_MACSEC_FS_ID_MASK =
> - GENMASK(5, 2) << MLX5_ETH_WQE_FT_META_SHIFT,
> + MLX5_ETH_WQE_FT_META_IPSEC = BIT(0),
> + MLX5_ETH_WQE_FT_META_MACSEC = BIT(1),
> };
>
> struct mlx5_wqe_eth_seg {
Hi Simon,
Thanks for the suggestion!
The goal with this patch was to clearly show which bits are used for
each feature in the metadata field, rather than compressing everything
under a single mask. That’s why we chose to explicitly define MACsec,
FS_ID_MASK, and the shift separately. This way, its easy to see at a
glance that MACsec uses bit 1, and bits 2–5 are reserved for the fs_id.
Using FIELD_PREP can work, but it hides the bit layout behind one
mask, which makes it harder to reason about when multiple features
share the same 32-bit field. We wanted to keep things more readable
and maintainable by showing the bit assignments explicitly.
Carolina
next prev parent reply other threads:[~2025-09-15 6:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-11 7:10 [PATCH mlx5-next 0/3] mlx5-next updates 2025-09-11 Tariq Toukan
2025-09-11 7:10 ` [PATCH mlx5-next 1/3] net/mlx5: Remove VLAN insertion fields from WQE Ether segment Tariq Toukan
2025-09-15 19:14 ` Simon Horman
2025-09-11 7:10 ` [PATCH mlx5-next 2/3] net/mlx5: Refactor MACsec WQE metadata shifts Tariq Toukan
2025-09-12 15:49 ` Simon Horman
2025-09-15 6:23 ` Carolina Jubran [this message]
2025-09-15 19:13 ` Simon Horman
2025-09-11 7:10 ` [PATCH mlx5-next 3/3] net/mlx5e: Prevent WQE metadata conflicts between timestamping and offloads Tariq Toukan
2025-09-15 19:14 ` Simon Horman
2025-09-17 8:42 ` [PATCH mlx5-next 0/3] mlx5-next updates 2025-09-11 Leon Romanovsky
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=153b22be-3cd4-4ae8-9091-923e4e0018f2@nvidia.com \
--to=cjubran@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=jianbol@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=sd@queasysnail.net \
--cc=tariqt@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.