Merge branch 'Extend XFRM core to allow packet offload configuration' (89ae6573) · Commits · EulixOS / Software / Kernel

Documentation/networking/xfrm_device.rst

+53 −9

Original line number	Original line	Diff line number	Diff line
	@@ -5,6 +5,7 @@ XFRM device - offloading the IPsec computations
	===============================================		===============================================

	Shannon Nelson <shannon.nelson@oracle.com>		Shannon Nelson <shannon.nelson@oracle.com>
			Leon Romanovsky <leonro@nvidia.com>


	Overview		Overview
	@@ -18,10 +19,21 @@ can radically increase throughput and decrease CPU utilization. The XFRM
	Device interface allows NIC drivers to offer to the stack access to the		Device interface allows NIC drivers to offer to the stack access to the
	hardware offload.		hardware offload.

			Right now, there are two types of hardware offload that kernel supports.
			* IPsec crypto offload:
			* NIC performs encrypt/decrypt
			* Kernel does everything else
			* IPsec packet offload:
			* NIC performs encrypt/decrypt
			* NIC does encapsulation
			* Kernel and NIC have SA and policy in-sync
			* NIC handles the SA and policies states
			* The Kernel talks to the keymanager

	Userland access to the offload is typically through a system such as		Userland access to the offload is typically through a system such as
	libreswan or KAME/raccoon, but the iproute2 'ip xfrm' command set can		libreswan or KAME/raccoon, but the iproute2 'ip xfrm' command set can
	be handy when experimenting. An example command might look something		be handy when experimenting. An example command might look something
	like this::		like this for crypto offload:

	ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0x07 mode transport \		ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0x07 mode transport \
	reqid 0x07 replay-window 32 \		reqid 0x07 replay-window 32 \
	@@ -29,6 +41,17 @@ like this::
	sel src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp \		sel src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp \
	offload dev eth4 dir in		offload dev eth4 dir in

			and for packet offload

			ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0x07 mode transport \
			reqid 0x07 replay-window 32 \
			aead 'rfc4106(gcm(aes))' 0x44434241343332312423222114131211f4f3f2f1 128 \
			sel src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp \
			offload packet dev eth4 dir in

			ip x p add src 14.0.0.70 dst 14.0.0.52 offload packet dev eth4 dir in
			tmpl src 14.0.0.70 dst 14.0.0.52 proto esp reqid 10000 mode transport

	Yes, that's ugly, but that's what shell scripts and/or libreswan are for.		Yes, that's ugly, but that's what shell scripts and/or libreswan are for.


	@@ -40,17 +63,24 @@ Callbacks to implement

	/* from include/linux/netdevice.h */		/* from include/linux/netdevice.h */
	struct xfrmdev_ops {		struct xfrmdev_ops {
			/* Crypto and Packet offload callbacks */
	int (xdo_dev_state_add) (struct xfrm_state x);		int (xdo_dev_state_add) (struct xfrm_state x);
	void (xdo_dev_state_delete) (struct xfrm_state x);		void (xdo_dev_state_delete) (struct xfrm_state x);
	void (xdo_dev_state_free) (struct xfrm_state x);		void (xdo_dev_state_free) (struct xfrm_state x);
	bool (xdo_dev_offload_ok) (struct sk_buff skb,		bool (xdo_dev_offload_ok) (struct sk_buff skb,
	struct xfrm_state *x);		struct xfrm_state *x);
	void (xdo_dev_state_advance_esn) (struct xfrm_state x);		void (xdo_dev_state_advance_esn) (struct xfrm_state x);

			/* Solely packet offload callbacks */
			void (xdo_dev_state_update_curlft) (struct xfrm_state x);
			int (xdo_dev_policy_add) (struct xfrm_policy x);
			void (xdo_dev_policy_delete) (struct xfrm_policy x);
			void (xdo_dev_policy_free) (struct xfrm_policy x);
	};		};

	The NIC driver offering ipsec offload will need to implement these		The NIC driver offering ipsec offload will need to implement callbacks
	callbacks to make the offload available to the network stack's		relevant to supported offload to make the offload available to the network
	XFRM subsystem. Additionally, the feature bits NETIF_F_HW_ESP and		stack's XFRM subsystem. Additionally, the feature bits NETIF_F_HW_ESP and
	NETIF_F_HW_ESP_TX_CSUM will signal the availability of the offload.		NETIF_F_HW_ESP_TX_CSUM will signal the availability of the offload.


	@@ -79,7 +109,8 @@ and an indication of whether it is for Rx or Tx. The driver should

	=========== ===================================		=========== ===================================
	0 success		0 success
	-EOPNETSUPP offload not supported, try SW IPsec		-EOPNETSUPP offload not supported, try SW IPsec,
			not applicable for packet offload mode
	other fail the request		other fail the request
	=========== ===================================		=========== ===================================

	@@ -96,6 +127,7 @@ will serviceable. This can check the packet information to be sure the
	offload can be supported (e.g. IPv4 or IPv6, no IPv4 options, etc) and		offload can be supported (e.g. IPv4 or IPv6, no IPv4 options, etc) and
	return true of false to signify its support.		return true of false to signify its support.

			Crypto offload mode:
	When ready to send, the driver needs to inspect the Tx packet for the		When ready to send, the driver needs to inspect the Tx packet for the
	offload information, including the opaque context, and set up the packet		offload information, including the opaque context, and set up the packet
	send accordingly::		send accordingly::
	@@ -139,13 +171,25 @@ the stack in xfrm_input().
	In ESN mode, xdo_dev_state_advance_esn() is called from xfrm_replay_advance_esn().		In ESN mode, xdo_dev_state_advance_esn() is called from xfrm_replay_advance_esn().
	Driver will check packet seq number and update HW ESN state machine if needed.		Driver will check packet seq number and update HW ESN state machine if needed.

			Packet offload mode:
			HW adds and deletes XFRM headers. So in RX path, XFRM stack is bypassed if HW
			reported success. In TX path, the packet lefts kernel without extra header
			and not encrypted, the HW is responsible to perform it.

	When the SA is removed by the user, the driver's xdo_dev_state_delete()		When the SA is removed by the user, the driver's xdo_dev_state_delete()
	is asked to disable the offload. Later, xdo_dev_state_free() is called		and xdo_dev_policy_delete() are asked to disable the offload. Later,
	from a garbage collection routine after all reference counts to the state		xdo_dev_state_free() and xdo_dev_policy_free() are called from a garbage
			collection routine after all reference counts to the state and policy
	have been removed and any remaining resources can be cleared for the		have been removed and any remaining resources can be cleared for the
	offload state. How these are used by the driver will depend on specific		offload state. How these are used by the driver will depend on specific
	hardware needs.		hardware needs.

	As a netdev is set to DOWN the XFRM stack's netdev listener will call		As a netdev is set to DOWN the XFRM stack's netdev listener will call
	xdo_dev_state_delete() and xdo_dev_state_free() on any remaining offloaded		xdo_dev_state_delete(), xdo_dev_policy_delete(), xdo_dev_state_free() and
	states.		xdo_dev_policy_free() on any remaining offloaded states.

			Outcome of HW handling packets, the XFRM core can't count hard, soft limits.
			The HW/driver are responsible to perform it and provide accurate data when
			xdo_dev_state_update_curlft() is called. In case of one of these limits
			occuried, the driver needs to call to xfrm_state_check_expire() to make sure
			that XFRM performs rekeying sequence.

drivers/net/ethernet/chelsio/inline_crypto/ch_ipsec/chcr_ipsec.c

+4 −0

Original line number	Original line	Diff line number	Diff line
	@@ -283,6 +283,10 @@ static int ch_ipsec_xfrm_add_state(struct xfrm_state *x)
	pr_debug("Cannot offload xfrm states with geniv other than seqiv\n");		pr_debug("Cannot offload xfrm states with geniv other than seqiv\n");
	return -EINVAL;		return -EINVAL;
	}		}
			if (x->xso.type != XFRM_DEV_OFFLOAD_CRYPTO) {
			pr_debug("Unsupported xfrm offload\n");
			return -EINVAL;
			}

	sa_entry = kzalloc(sizeof(*sa_entry), GFP_KERNEL);		sa_entry = kzalloc(sizeof(*sa_entry), GFP_KERNEL);
	if (!sa_entry) {		if (!sa_entry) {

drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c

+5 −0

Original line number	Original line	Diff line number	Diff line
	@@ -585,6 +585,11 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
	return -EINVAL;		return -EINVAL;
	}		}

			if (xs->xso.type != XFRM_DEV_OFFLOAD_CRYPTO) {
			netdev_err(dev, "Unsupported ipsec offload type\n");
			return -EINVAL;
			}

	if (xs->xso.dir == XFRM_DEV_OFFLOAD_IN) {		if (xs->xso.dir == XFRM_DEV_OFFLOAD_IN) {
	struct rx_sa rsa;		struct rx_sa rsa;

drivers/net/ethernet/intel/ixgbevf/ipsec.c

+5 −0

Original line number	Original line	Diff line number	Diff line
	@@ -280,6 +280,11 @@ static int ixgbevf_ipsec_add_sa(struct xfrm_state *xs)
	return -EINVAL;		return -EINVAL;
	}		}

			if (xs->xso.type != XFRM_DEV_OFFLOAD_CRYPTO) {
			netdev_err(dev, "Unsupported ipsec offload type\n");
			return -EINVAL;
			}

	if (xs->xso.dir == XFRM_DEV_OFFLOAD_IN) {		if (xs->xso.dir == XFRM_DEV_OFFLOAD_IN) {
	struct rx_sa rsa;		struct rx_sa rsa;

drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c

+4 −0

Original line number	Original line	Diff line number	Diff line
	@@ -253,6 +253,10 @@ static inline int mlx5e_xfrm_validate_state(struct xfrm_state *x)
	netdev_info(netdev, "Cannot offload xfrm states with geniv other than seqiv\n");		netdev_info(netdev, "Cannot offload xfrm states with geniv other than seqiv\n");
	return -EINVAL;		return -EINVAL;
	}		}
			if (x->xso.type != XFRM_DEV_OFFLOAD_CRYPTO) {
			netdev_info(netdev, "Unsupported xfrm offload type\n");
			return -EINVAL;
			}
	return 0;		return 0;
	}		}