From: Jakub Kicinski <kuba@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
linux-rdma@vger.kernel.org, Maor Gottlieb <maorg@nvidia.com>,
Mark Zhang <markzhang@nvidia.com>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Patrisious Haddad <phaddad@nvidia.com>,
Raed Salem <raeds@nvidia.com>, Saeed Mahameed <saeedm@nvidia.com>,
Simon Horman <horms@kernel.org>
Subject: Re: [PATCH mlx5-next v1 00/14] mlx5 MACsec RoCEv2 support
Date: Wed, 9 Aug 2023 16:09:45 -0700 [thread overview]
Message-ID: <20230809160945.386168f9@kernel.org> (raw)
In-Reply-To: <cover.1691569414.git.leon@kernel.org>
On Wed, 9 Aug 2023 11:29:12 +0300 Leon Romanovsky wrote:
> This series extends previously added MACsec offload support
> to cover RoCE traffic either.
>
> In order to achieve that, we need configure MACsec with offload between
> the two endpoints, like below:
>
> REMOTE_MAC=10:70:fd:43:71:c0
>
> * ip addr add 1.1.1.1/16 dev eth2
> * ip link set dev eth2 up
> * ip link add link eth2 macsec0 type macsec encrypt on
> * ip macsec offload macsec0 mac
> * ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16
> * ip macsec add macsec0 rx port 1 address $REMOTE_MAC
> * ip macsec add macsec0 rx port 1 address $REMOTE_MAC sa 0 pn 1 on key 01 ead3664f508eb06c40ac7104cdae4ce5
> * ip addr add 10.1.0.1/16 dev macsec0
> * ip link set dev macsec0 up
>
> And in a similar manner on the other machine, while noting the keys order
> would be reversed and the MAC address of the other machine.
>
> RDMA traffic is separated through relevant GID entries and in case of IP ambiguity
> issue - meaning we have a physical GIDs and a MACsec GIDs with the same IP/GID, we
> disable our physical GID in order to force the user to only use the MACsec GID.
Can you explain why you need special code to handle this?
MACsec is L2, RDMA is L4.
next prev parent reply other threads:[~2023-08-09 23:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 8:29 [PATCH mlx5-next v1 00/14] mlx5 MACsec RoCEv2 support Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 01/14] macsec: add functions to get macsec real netdevice and check offload Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 02/14] net/mlx5e: Move MACsec flow steering operations to be used as core library Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 03/14] net/mlx5: Remove dependency of macsec flow steering on ethernet Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 04/14] net/mlx5e: Rename MACsec flow steering functions/parameters to suit core naming style Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 05/14] net/mlx5e: Move MACsec flow steering and statistics database from ethernet to core Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 06/14] net/mlx5: Remove netdevice from MACsec steering Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 07/14] net/mlx5: Maintain fs_id xarray per MACsec device inside macsec steering Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 08/14] RDMA/mlx5: Implement MACsec gid addition and deletion Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 09/14] net/mlx5: Add MACsec priorities in RDMA namespaces Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 10/14] IB/core: Reorder GID delete code for RoCE Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 11/14] net/mlx5: Configure MACsec steering for egress RoCEv2 traffic Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 12/14] net/mlx5: Configure MACsec steering for ingress " Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 13/14] net/mlx5: Add RoCE MACsec steering infrastructure in core Leon Romanovsky
2023-08-09 8:29 ` [PATCH mlx5-next v1 14/14] RDMA/mlx5: Handles RoCE MACsec steering rules addition and deletion Leon Romanovsky
2023-08-09 23:09 ` Jakub Kicinski [this message]
2023-08-09 23:10 ` [PATCH mlx5-next v1 00/14] mlx5 MACsec RoCEv2 support Jakub Kicinski
2023-08-09 23:53 ` Jason Gunthorpe
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=20230809160945.386168f9@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jgg@nvidia.com \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=maorg@nvidia.com \
--cc=markzhang@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=phaddad@nvidia.com \
--cc=raeds@nvidia.com \
--cc=saeedm@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;
as well as URLs for NNTP newsgroup(s).