netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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).