diff mbox series

[net-next,ct-offload,03/13] net/sched: act_ct: Support restoring conntrack info on skbs

Message ID 1583422468-8456-4-git-send-email-paulb@mellanox.com
State Changes Requested
Delegated to: David Miller
Headers show
Series Introduce connection tracking offload | expand

Commit Message

Paul Blakey March 5, 2020, 3:34 p.m. UTC 
Provide an API to restore the ct state pointer.

This may be used by drivers to restore the ct state if they
miss in tc chain after they already did the hardware connection
tracking action (ct_metadata action).

For example, consider the following rule on chain 0 that is in_hw,
however chain 1 is not_in_hw:

$ tc filter add dev ... chain 0 ... \
  flower ... action ct pipe action goto chain 1

Packets of a flow offloaded (via nf flow table offload) by the driver
hit this rule in hardware, will be marked with the ct metadata action
(mark, label, zone) that does the equivalent of the software ct action,
and when the packet jumps to hardware chain 1, there would be a miss.

CT was already processed in hardware. Therefore, the driver's miss
handling should restore the ct state on the skb, using the provided API,
and continue the packet processing in chain 1.

Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
 include/net/flow_offload.h |  1 +
 include/net/tc_act/tc_ct.h |  7 +++++++
 net/sched/act_ct.c         | 15 +++++++++++++++
 3 files changed, 23 insertions(+)

Comments

Edward Cree March 6, 2020, 1:16 p.m. UTC | #1 
On 05/03/2020 15:34, Paul Blakey wrote:
> Provide an API to restore the ct state pointer.
>
> This may be used by drivers to restore the ct state if they
> miss in tc chain after they already did the hardware connection
> tracking action (ct_metadata action).
>
> For example, consider the following rule on chain 0 that is in_hw,
> however chain 1 is not_in_hw:
>
> $ tc filter add dev ... chain 0 ... \
>   flower ... action ct pipe action goto chain 1
>
> Packets of a flow offloaded (via nf flow table offload) by the driver
> hit this rule in hardware, will be marked with the ct metadata action
> (mark, label, zone) that does the equivalent of the software ct action,
> and when the packet jumps to hardware chain 1, there would be a miss.
>
> CT was already processed in hardware. Therefore, the driver's miss
> handling should restore the ct state on the skb, using the provided API,
> and continue the packet processing in chain 1.
IMNSHO this demonstrates why hardware should do all-or-nothingoffload,
 in the cases where it can't perform the whole filtering it should
 provide the unmodified packet so that SW can start over from a clean
 state.
But as long as these epicycles don't affect drivers for such HW, I guess
 I can't object too hard to them being added.
diff mbox series

Patch

diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
index f7215fa..9670f15 100644
--- a/include/net/flow_offload.h
+++ b/include/net/flow_offload.h
@@ -199,6 +199,7 @@  struct flow_action_entry {
 			u16 zone;
 		} ct;
 		struct {
+			unsigned long cookie;
 			u32 mark;
 			u32 labels[4];
 			u16 zone;
diff --git a/include/net/tc_act/tc_ct.h b/include/net/tc_act/tc_ct.h
index cf3492e..735da59 100644
--- a/include/net/tc_act/tc_ct.h
+++ b/include/net/tc_act/tc_ct.h
@@ -55,6 +55,13 @@  static inline int tcf_ct_action(const struct tc_action *a)
 static inline int tcf_ct_action(const struct tc_action *a) { return 0; }
 #endif /* CONFIG_NF_CONNTRACK */
 
+#if IS_ENABLED(CONFIG_NET_ACT_CT)
+void tcf_ct_flow_table_restore_skb(struct sk_buff *skb, unsigned long cookie);
+#else
+static inline void
+tcf_ct_flow_table_restore_skb(struct sk_buff *skb, unsigned long cookie) { }
+#endif
+
 static inline bool is_tcf_ct(const struct tc_action *a)
 {
 #if defined(CONFIG_NET_CLS_ACT) && IS_ENABLED(CONFIG_NF_CONNTRACK)
diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
index 0773456..47cdba6 100644
--- a/net/sched/act_ct.c
+++ b/net/sched/act_ct.c
@@ -175,6 +175,7 @@  static void tcf_ct_flow_table_add_action_meta(struct nf_conn *ct,
 {
 	struct nf_conn_labels *ct_labels;
 	struct flow_action_entry *entry;
+	enum ip_conntrack_info ctinfo;
 	u32 *act_ct_labels;
 
 	entry = tcf_ct_flow_table_flow_action_get_next(action);
@@ -183,6 +184,10 @@  static void tcf_ct_flow_table_add_action_meta(struct nf_conn *ct,
 #if IS_ENABLED(CONFIG_NF_CONNTRACK_MARK)
 	entry->ct_metadata.mark = ct->mark;
 #endif
+	ctinfo = dir == IP_CT_DIR_ORIGINAL ? IP_CT_ESTABLISHED :
+					     IP_CT_ESTABLISHED_REPLY;
+	/* aligns with the CT reference on the SKB nf_ct_set */
+	entry->ct_metadata.cookie = (unsigned long)ct | ctinfo;
 
 	act_ct_labels = entry->ct_metadata.labels;
 	ct_labels = nf_ct_labels_find(ct);
@@ -1517,6 +1522,16 @@  static void __exit ct_cleanup_module(void)
 	destroy_workqueue(act_ct_wq);
 }
 
+void tcf_ct_flow_table_restore_skb(struct sk_buff *skb, unsigned long cookie)
+{
+	enum ip_conntrack_info ctinfo = cookie & NFCT_INFOMASK;
+	struct nf_conn *ct = (struct nf_conn *)(cookie & NFCT_PTRMASK);
+
+	nf_conntrack_get(&ct->ct_general);
+	nf_ct_set(skb, ct, ctinfo);
+}
+EXPORT_SYMBOL_GPL(tcf_ct_flow_table_restore_skb);
+
 module_init(ct_init_module);
 module_exit(ct_cleanup_module);
 MODULE_AUTHOR("Paul Blakey <paulb@mellanox.com>");