[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190129180715.GW10660@localhost.localdomain>
Date: Tue, 29 Jan 2019 16:07:15 -0200
From: Marcelo Leitner <mleitner@...hat.com>
To: Paul Blakey <paulb@...lanox.com>
Cc: Guy Shattah <sguy@...lanox.com>, Aaron Conole <aconole@...hat.com>,
John Hurley <john.hurley@...ronome.com>,
Simon Horman <simon.horman@...ronome.com>,
Justin Pettit <jpettit@....org>,
Gregory Rose <gvrose8192@...il.com>,
Eelco Chaudron <echaudro@...hat.com>,
Flavio Leitner <fbl@...hat.com>,
Florian Westphal <fwestpha@...hat.com>,
Jiri Pirko <jiri@...nulli.us>, Rashid Khan <rkhan@...hat.com>,
Sushil Kulkarni <sukulkar@...hat.com>,
Andy Gospodarek <andrew.gospodarek@...adcom.com>,
Roi Dayan <roid@...lanox.com>,
Yossi Kuperman <yossiku@...lanox.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Rony Efraim <ronye@...lanox.com>,
"davem@...emloft.net" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next 0/6 v2] connection tracking in tc and OVS
offload
On Tue, Jan 29, 2019 at 09:59:07AM +0200, Paul Blakey wrote:
> Hi,
> As you may know, we are working on connection tracking for a while, and we already
> had patches for tc that matched our connection tracking offload RFC.
>
> Marcelo already shared his tc patches for a similar action ct and flower match on ct_info state,
> and this patches are pretty close to his. We would like to share ours and see what's the difference
> so maybe we can merge the two.
>
> I think the main difference here is that we propose the usage of a new metadata that resembles
> ovs recirc id, so one can use tc recirculation in a similar way that ovs does.
This is a very interesting approach. Seems it can avoid the necessity
of offloading multiple chains at all and, with that, we don't need a
special fallback path for when chain X is not present in HW: it will
be just another miss. Such skb may have an extra meta data, but no
need to look for a special chain and so.
Two points on it for further discussion. I'll reply on the specific
patches.
>
> The plan is to support offloading of OVS rules to tc, so this recirculation id will
> be shared with and from OVS.
>
> The following is an example using the recirc id metadata (aa_rep and bb_rep are two veth devices)
>
> tc qdisc add dev bb_rep ingress
> tc qdisc add dev aa_rep ingress
> tc filter add dev aa_rep ingress prio 1 chain 0 proto ip flower match 'meta(tc_recirc mask 0xffffffff eq 0x1)' ct_state +trk+est ip_proto tcp action mirred egress redirect dev bb_rep
> tc filter add dev aa_rep ingress prio 1 chain 0 proto ip flower ct_state -trk ip_proto tcp action ct recirc 1 reclassify
> tc filter add dev aa_rep ingress prio 1 chain 0 proto ip flower match 'meta(tc_recirc mask 0xffffffff eq 0x1)' ct_state +trk+new ip_proto tcp action ct commit pipe action mirred egress redirect dev bb_rep
>
> tc filter add dev bb_rep ingress prio 1 chain 0 proto ip flower ct_state -trk ip_proto tcp action ct recirc 2 reclassify
> tc filter add dev bb_rep ingress prio 1 chain 0 proto ip flower match 'meta(tc_recirc mask 0xffffffff eq 0x2)' ct_state +trk+est ip_proto tcp action mirred egress redirect dev aa_rep
>
> of course, goto chain instead of reclassify will also work.
>
> There might be some difference in how we handle action ct and I'll follow up on that.
>
>
> Changelog:
> v1->v2:
> Missed first patch :|
> Added netdev mailing list
>
> Paul Blakey (6):
> net/sched: Introduce act_ct
> net/sched: cls_flower: add match on ct info
> net/sched: cls_flower: Add ematch support
> net: Add new tc recirc id skb extension
> net/sched: em_meta: add match on tc recirc id skb extension
> net/sched: act_ct: Add tc recirc id set/del support
>
> include/linux/skbuff.h | 1 +
> include/net/tc_act/tc_ct.h | 2 +
> include/uapi/linux/pkt_cls.h | 19 ++++
> include/uapi/linux/tc_act/tc_ct.h | 2 +
> include/uapi/linux/tc_ematch/tc_em_meta.h | 1 +
> net/core/skbuff.c | 2 +
> net/sched/act_ct.c | 18 ++++
> net/sched/cls_flower.c | 148 ++++++++++++++++++++++++++++--
> net/sched/em_meta.c | 8 ++
> 9 files changed, 194 insertions(+), 7 deletions(-)
>
> --
> 1.8.3.1
>
Powered by blists - more mailing lists