[RFC 0/2] IB/core: Add ESP Crypto Flow Steering support

[RFC 0/2] IB/core: Add ESP Crypto Flow Steering support

[Boris Pismenny]

From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

The purpose of this RFC is to suggest an API for specifying
ESP crypto offload via flow steering. This API will allow users
to control the crypto offload functionality offered by new NICs,
such as Mellanox Innova IPsec.

Applications can request ESP encryption offload for transmission of
well-formed plaintext ESP packets, or decryption offload for
well-fromed ciphertext ESP packets. Packets are encrypted/decrypted
according to the direction of the flow.

In order to create an ESP crypto offload specification, the user has
to add it to a flow with the Security Association selectors.

borisp (2):
  Introduce egress IB flow steering flag
  IB/core: ESP AES-GCM crypto offload action

 include/rdma/ib_verbs.h | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 1/2] Introduce egress IB flow steering flag

[Boris Pismenny]

From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

This commit introduces egress flow steering. Egress flow steering
is useful for specifying actions that might be applied by hardware
to outgoing flows on a specific QP.

Signed-off-by: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 include/rdma/ib_verbs.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 99e4423..6c1c867 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1679,7 +1679,8 @@ enum ib_flow_domain {
 
 enum ib_flow_flags {
 	IB_FLOW_ATTR_FLAGS_DONT_TRAP = 1UL << 1, /* Continue match, no steal */
-	IB_FLOW_ATTR_FLAGS_RESERVED  = 1UL << 2  /* Must be last */
+	IB_FLOW_ATTR_FLAGS_EGRESS = 1UL << 2, /* Egress steering rule */
+	IB_FLOW_ATTR_FLAGS_RESERVED  = 1UL << 3  /* Must be last */
 };
 
 struct ib_flow_eth_filter {
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 2/2] IB/core: ESP AES-GCM crypto offload action

[Boris Pismenny]

From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

This patch introduces the flow steering specification for IPsec
AES-GCM crypto offload to HW. If a user creates a flow with
this specification, then all packets that hit this flow will
have their payload encrypted and authenticated according to
the key and the salt in this specification as defined in RFC4303.

Signed-off-by: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 include/rdma/ib_verbs.h | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 6c1c867..e4e33e4 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1658,10 +1658,12 @@ enum ib_flow_spec_type {
 	/* L4 headers*/
 	IB_FLOW_SPEC_TCP		= 0x40,
 	IB_FLOW_SPEC_UDP		= 0x41,
+	IB_FLOW_SPEC_ESP		= 0x42,
 	IB_FLOW_SPEC_VXLAN_TUNNEL	= 0x50,
 	IB_FLOW_SPEC_INNER		= 0x100,
 	/* Actions */
 	IB_FLOW_SPEC_ACTION_TAG         = 0x1000,
+	IB_FLOW_SPEC_ACTION_ESP_AES_GCM         = 0x1001,
 };
 #define IB_FLOW_SPEC_LAYER_MASK	0xF0
 #define IB_FLOW_SPEC_SUPPORT_LAYERS 8
@@ -1770,6 +1772,20 @@ struct ib_flow_spec_tcp_udp {
 	struct ib_flow_tcp_udp_filter mask;
 };
 
+struct ib_flow_esp_filter {
+		__be32	spi;
+		__be32  seq;
+		/* Must be last */
+		u8	real_sz[0];
+};
+
+struct ib_flow_spec_esp {
+	u32                           type;
+	u16			      size;
+	struct ib_flow_esp_filter     val;
+	struct ib_flow_esp_filter     mask;
+};
+
 struct ib_flow_tunnel_filter {
 	__be32	tunnel_id;
 	u8	real_sz[0];
@@ -1791,6 +1807,16 @@ struct ib_flow_spec_action_tag {
 	u32                           tag_id;
 };
 
+struct ib_flow_spec_action_esp_aes_gcm {
+	enum ib_flow_spec_type	      type;
+	u16			      size;
+	__u8                          key[32];
+	__u8                          key_length; /* 16, 24 or 32 bytes */
+	__u8                          salt[4]; /* salt according to RFC4106 */
+	__u8                          seqiv_salt[8];
+	__u8			      seq_hi[4];
+};
+
 union ib_flow_spec {
 	struct {
 		u32			type;
@@ -1802,7 +1828,9 @@ struct ib_flow_spec_action_tag {
 	struct ib_flow_spec_tcp_udp	tcp_udp;
 	struct ib_flow_spec_ipv6        ipv6;
 	struct ib_flow_spec_tunnel      tunnel;
+	struct ib_flow_spec_esp		esp;
 	struct ib_flow_spec_action_tag  flow_tag;
+	struct ib_flow_spec_action_esp_aes_gcm  esp_aes_gcm;
 };
 
 struct ib_flow_attr {
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 0/2] IB/core: Add ESP Crypto Flow Steering support

[Steve Wise]

> Subject: [RFC 0/2] IB/core: Add ESP Crypto Flow Steering support
> 
> From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> 
> The purpose of this RFC is to suggest an API for specifying
> ESP crypto offload via flow steering. This API will allow users
> to control the crypto offload functionality offered by new NICs,
> such as Mellanox Innova IPsec.
> 
> Applications can request ESP encryption offload for transmission of
> well-formed plaintext ESP packets, or decryption offload for
> well-fromed ciphertext ESP packets. Packets are encrypted/decrypted
> according to the direction of the flow.
> 
> In order to create an ESP crypto offload specification, the user has
> to add it to a flow with the Security Association selectors.
>

Hey Boris,  

Do you have any applications that utilize this and other flow steering APIs?  It
would be nice to see example usage. 

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 0/2] IB/core: Add ESP Crypto Flow Steering support

[Boris Pismenny]

> 
> Do you have any applications that utilize this and other flow steering APIs?  It
> would be nice to see example usage.
> 

Our DPDK PMD already utilizes flow steering and it will use this API.

Also, we have support for this offload in XFRM, but it doesn't use flow steering at the moment. In the future, XFRM NDO will use flow steering through our driver.
Patches for the kernel XFRM code can be found here:	
https://patchwork.ozlabs.org/patch/752707/
Our driver support for this framework in XFRM can be found here:
https://github.com/Mellanox/ipsec-offload
XFRM is programmed with iproute2. You can find code for it here:
https://github.com/Mellanox/iproute2

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/2] IB/core: Add ESP Crypto Flow Steering support

[Jason Gunthorpe]

On Thu, Apr 20, 2017 at 03:24:39PM +0000, Boris Pismenny wrote:
> > 
> > Do you have any applications that utilize this and other flow steering APIs?  It
> > would be nice to see example usage.
> > 
> 
> Our DPDK PMD already utilizes flow steering and it will use this API.

Your patches didn't change any uapi headers - how does this get
exported to user space?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 0/2] IB/core: Add ESP Crypto Flow Steering support

[Boris Pismenny]

> Your patches didn't change any uapi headers - how does this get exported to
> user space?

Right. Sorry about that. The intent is to export both ib_flow_spec_action_esp_aes_gcm and
ib_flow_spec_esp to user space.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/2] Introduce egress IB flow steering flag

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On Thu, Apr 20, 2017 at 02:00:09PM +0300, Boris Pismenny wrote:
> From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> This commit introduces egress flow steering. Egress flow steering
> is useful for specifying actions that might be applied by hardware
> to outgoing flows on a specific QP.
>

How will user know which flow actions are applicable for egress traffic,
for both ingress/egress and for ingress only?

I think separate structure for ingress vs. egress are better approach,
than blind global flag.


> Signed-off-by: borisp <borisp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

Please configure your git, "Signed-off-by" line is a legal document and
supposed to have proper author name.

Thanks

> ---
>  include/rdma/ib_verbs.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 99e4423..6c1c867 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -1679,7 +1679,8 @@ enum ib_flow_domain {
>
>  enum ib_flow_flags {
>  	IB_FLOW_ATTR_FLAGS_DONT_TRAP = 1UL << 1, /* Continue match, no steal */
> -	IB_FLOW_ATTR_FLAGS_RESERVED  = 1UL << 2  /* Must be last */
> +	IB_FLOW_ATTR_FLAGS_EGRESS = 1UL << 2, /* Egress steering rule */
> +	IB_FLOW_ATTR_FLAGS_RESERVED  = 1UL << 3  /* Must be last */
>  };
>
>  struct ib_flow_eth_filter {
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: [RFC 1/2] Introduce egress IB flow steering flag

[Boris Pismenny]

> > This commit introduces egress flow steering. Egress flow steering is
> > useful for specifying actions that might be applied by hardware to
> > outgoing flows on a specific QP.
> >
> 
> How will user know which flow actions are applicable for egress traffic, for
> both ingress/egress and for ingress only?
The implementation could return an error when a device doesn't support a certain action.
For example, we may not support crypto offload for encapsulation of IPsec packets, and we
will return an error if such a flow specification is provided.

Did you have any specific action that is not supported in some direction? AFAIK, we 
support all action for egress as well as ingress.

> 
> I think separate structure for ingress vs. egress are better approach, than
> blind global flag.
I thought of using a direction flag in the action itself, but decided against it , because all flow
specification refer to a certain direction and not the action alone. Moreover, there are other
actions that will be based on this flag, like encapsulation actions.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html