From: Dima Chumak <dchumak@nvidia.com>
To: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>
Cc: <netdev@vger.kernel.org>, Jiri Pirko <jiri@resnulli.us>,
Leon Romanovsky <leon@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
Dima Chumak <dchumak@nvidia.com>
Subject: [PATCH net-next V2 0/4] devlink: Add port function attributes
Date: Fri, 21 Apr 2023 13:48:57 +0300 [thread overview]
Message-ID: <20230421104901.897946-1-dchumak@nvidia.com> (raw)
Introduce hypervisor-level control knobs to set the functionality of PCI
VF devices passed through to guests. The administrator of a hypervisor
host may choose to change the settings of a port function from the
defaults configured by the device firmware.
The software stack has two types of IPsec offload - crypto and packet.
Specifically, the ip xfrm command has sub-commands for "state" and
"policy" that have an "offload" parameter. With ip xfrm state, both
crypto and packet offload types are supported, while ip xfrm policy can
only be offloaded in packet mode.
The series introduces two new boolean attributes of a port function:
ipsec_crypto and ipsec_packet. The goal is to provide a similar level of
granularity for controlling VF IPsec offload capabilities, which would
be aligned with the software model. This will allow users to decide if
they want both types of offload enabled for a VF, just one of them, or
none at all (which is the default).
At a high level, the difference between the two knobs is that with
ipsec_crypto, only XFRM state can be offloaded. Specifically, only the
crypto operation (Encrypt/Decrypt) is offloaded. With ipsec_packet, both
XFRM state and policy can be offloaded. Furthermore, in addition to
crypto operation offload, IPsec encapsulation is also offloaded. For
XFRM state, choosing between crypto and packet offload types is
possible. From the HW perspective, different resources may be required
for each offload type.
Examples of when a user prefers to enable IPsec packet offload for a VF
when using switchdev mode:
$ devlink port show pci/0000:06:00.0/1
pci/0000:06:00.0/1: type eth netdev enp6s0pf0vf0 flavour pcivf pfnum 0 vfnum 0
function:
hw_addr 00:00:00:00:00:00 roce enable migratable disable ipsec_crypto disable ipsec_packet disable
$ devlink port function set pci/0000:06:00.0/1 ipsec_packet enable
$ devlink port show pci/0000:06:00.0/1
pci/0000:06:00.0/1: type eth netdev enp6s0pf0vf0 flavour pcivf pfnum 0 vfnum 0
function:
hw_addr 00:00:00:00:00:00 roce enable migratable disable ipsec_crypto disable ipsec_packet enable
This enables the corresponding IPsec capability of the function before
it's enumerated, so when the driver reads the capability from the device
firmware, it is enabled. The driver is then able to configure
corresponding features and ops of the VF net device to support IPsec
state and policy offloading.
---
v1 -> v2:
- improve docs of ipsec_crypto vs ipsec_packet devlink attribues
- also see patches 2,4 for the changelog.
Dima Chumak (4):
devlink: Expose port function commands to control IPsec crypto
offloads
net/mlx5: Implement devlink port function cmds to control ipsec_crypto
devlink: Expose port function commands to control IPsec packet
offloads
net/mlx5: Implement devlink port function cmds to control ipsec_packet
.../ethernet/mellanox/mlx5/switchdev.rst | 16 +
.../networking/devlink/devlink-port.rst | 55 +++
.../net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
.../net/ethernet/mellanox/mlx5/core/devlink.c | 8 +-
.../mellanox/mlx5/core/en_accel/ipsec.c | 18 +
.../ethernet/mellanox/mlx5/core/esw/ipsec.c | 388 ++++++++++++++++++
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 34 ++
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 31 ++
.../mellanox/mlx5/core/eswitch_offloads.c | 208 ++++++++++
.../ethernet/mellanox/mlx5/core/lib/ipsec.h | 41 ++
include/linux/mlx5/driver.h | 1 +
include/linux/mlx5/mlx5_ifc.h | 3 +
include/net/devlink.h | 42 ++
include/uapi/linux/devlink.h | 4 +
net/devlink/leftover.c | 110 +++++
15 files changed, 959 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/esw/ipsec.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/ipsec.h
--
2.40.0
next reply other threads:[~2023-04-21 10:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 10:48 Dima Chumak [this message]
2023-04-21 10:48 ` [PATCH net-next V2 1/4] devlink: Expose port function commands to control IPsec crypto offloads Dima Chumak
2023-04-21 10:48 ` [PATCH net-next V2 2/4] net/mlx5: Implement devlink port function cmds to control ipsec_crypto Dima Chumak
2023-04-23 16:30 ` Leon Romanovsky
2023-04-23 17:41 ` Simon Horman
2023-04-21 10:49 ` [PATCH net-next V2 3/4] devlink: Expose port function commands to control IPsec packet offloads Dima Chumak
2023-04-21 10:49 ` [PATCH net-next V2 4/4] net/mlx5: Implement devlink port function cmds to control ipsec_packet Dima Chumak
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=20230421104901.897946-1-dchumak@nvidia.com \
--to=dchumak@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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).