From: Emeel Hakim <ehakim@nvidia.com>
To: <davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>,
<edumazet@google.com>, <sd@queasysnail.net>
Cc: <netdev@vger.kernel.org>, <leon@kernel.org>,
Emeel Hakim <ehakim@nvidia.com>
Subject: [PATCH net-next v4 0/5] Support MACsec VLAN
Date: Sat, 8 Apr 2023 13:57:30 +0300 [thread overview]
Message-ID: <20230408105735.22935-1-ehakim@nvidia.com> (raw)
Dear maintainers,
This patch series introduces support for hardware (HW) offload MACsec
devices with VLAN configuration. The patches address both scenarios
where the VLAN header is both the inner and outer header for MACsec.
The changes include:
1. Adding MACsec offload operation for VLAN.
2. Considering VLAN when accessing MACsec net device.
3. Currently offloading MACsec when it's configured over VLAN with
current MACsec TX steering rules would wrongly insert the MACsec sec tag
after inserting the VLAN header. This resulted in an ETHERNET | SECTAG |
VLAN packet when ETHERNET | VLAN | SECTAG is configured. The patche
handles this issue when configuring steering rules.
4. Adding MACsec rx_handler change support in case of a marked skb and a
mismatch on the dst MAC address.
Please review these changes and let me know if you have any feedback or
concerns.
Updates since v1:
- Consult vlan_features when adding NETIF_F_HW_MACSEC.
- Allow grep for the functions.
- Add helper function to get the macsec operation to allow the compiler
to make some choice.
Updates since v2:
- Don't use macros to allow direct navigattion from mdo functions to its
implementation.
- Make the vlan_get_macsec_ops argument a const.
- Check if the specific mdo function is available before calling it.
- Enable NETIF_F_HW_MACSEC by default when the lower device has it enabled
and in case the lower device currently has NETIF_F_HW_MACSEC but disabled
let the new vlan device also have it disabled.
Updates since v3:
- Split patch ("vlan: Add MACsec offload operations for VLAN interface")
to prevent mixing generic vlan code changes with driver changes.
- Add mdo_open, stop and stats to support drivers which have those.
- Don't fail if macsec offload operations are available but a specific
function is not, to support drivers which does not implement all
macsec offload operations.
- Don't call find_rx_sc twice in the same loop, instead save the result
in a parameter and re-use it.
- Completely remove _BUILD_VLAN_MACSEC_MDO macro, to prevent returning
from a macro.
- Reorder the functions inside struct macsec_ops to match the struct
decleration.
Emeel Hakim (5):
vlan: Add MACsec offload operations for VLAN interface
net/mlx5: Enable MACsec offload feature for VLAN interface
net/mlx5: Support MACsec over VLAN
net/mlx5: Consider VLAN interface in MACsec TX steering rules
macsec: Add MACsec rx_handler change support
.../mellanox/mlx5/core/en_accel/macsec.c | 42 +--
.../mellanox/mlx5/core/en_accel/macsec_fs.c | 7 +
.../net/ethernet/mellanox/mlx5/core/en_main.c | 1 +
drivers/net/macsec.c | 16 +-
net/8021q/vlan_dev.c | 242 ++++++++++++++++++
5 files changed, 290 insertions(+), 18 deletions(-)
--
2.21.3
next reply other threads:[~2023-04-08 10:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-08 10:57 Emeel Hakim [this message]
2023-04-08 10:57 ` [PATCH net-next v4 1/5] vlan: Add MACsec offload operations for VLAN interface Emeel Hakim
2023-04-08 10:57 ` [PATCH net-next v4 2/5] net/mlx5: Enable MACsec offload feature " Emeel Hakim
2023-04-08 10:57 ` [PATCH net-next v4 3/5] net/mlx5: Support MACsec over VLAN Emeel Hakim
2023-04-08 10:57 ` [PATCH net-next v4 4/5] net/mlx5: Consider VLAN interface in MACsec TX steering rules Emeel Hakim
2023-04-08 10:57 ` [PATCH net-next v4 5/5] macsec: Add MACsec rx_handler change support Emeel Hakim
2023-04-12 14:58 ` Sabrina Dubroca
2023-04-13 6:38 ` Emeel Hakim
2023-04-13 8:35 ` Sabrina Dubroca
2023-04-13 8:54 ` Emeel Hakim
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=20230408105735.22935-1-ehakim@nvidia.com \
--to=ehakim@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
/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).