From: Marcelo Leitner <mleitner@redhat.com>
To: Paul Blakey <paulb@mellanox.com>
Cc: Guy Shattah <sguy@mellanox.com>,
Aaron Conole <aconole@redhat.com>,
John Hurley <john.hurley@netronome.com>,
Simon Horman <simon.horman@netronome.com>,
Justin Pettit <jpettit@ovn.org>,
Gregory Rose <gvrose8192@gmail.com>,
Eelco Chaudron <echaudro@redhat.com>,
Flavio Leitner <fbl@redhat.com>,
Florian Westphal <fwestpha@redhat.com>,
Jiri Pirko <jiri@resnulli.us>, Rashid Khan <rkhan@redhat.com>,
Sushil Kulkarni <sukulkar@redhat.com>,
Andy Gospodarek <andrew.gospodarek@broadcom.com>,
Roi Dayan <roid@mellanox.com>,
Yossi Kuperman <yossiku@mellanox.com>,
Or Gerlitz <ogerlitz@mellanox.com>,
Rony Efraim <ronye@mellanox.com>,
"davem@davemloft.net" <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH net-next 0/6 v2] connection tracking in tc and OVS offload
Date: Tue, 29 Jan 2019 16:07:15 -0200 [thread overview]
Message-ID: <20190129180715.GW10660@localhost.localdomain> (raw)
In-Reply-To: <1548748753-22540-1-git-send-email-paulb@mellanox.com>
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
>
prev parent reply other threads:[~2019-01-29 18:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 7:59 [RFC PATCH net-next 0/6 v2] connection tracking in tc and OVS offload Paul Blakey
2019-01-29 18:07 ` Marcelo Leitner [this message]
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=20190129180715.GW10660@localhost.localdomain \
--to=mleitner@redhat.com \
--cc=aconole@redhat.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=davem@davemloft.net \
--cc=echaudro@redhat.com \
--cc=fbl@redhat.com \
--cc=fwestpha@redhat.com \
--cc=gvrose8192@gmail.com \
--cc=jiri@resnulli.us \
--cc=john.hurley@netronome.com \
--cc=jpettit@ovn.org \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=paulb@mellanox.com \
--cc=rkhan@redhat.com \
--cc=roid@mellanox.com \
--cc=ronye@mellanox.com \
--cc=sguy@mellanox.com \
--cc=simon.horman@netronome.com \
--cc=sukulkar@redhat.com \
--cc=yossiku@mellanox.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