| Message ID | 20191203134534.32056-1-roid@mellanox.com |
|---|---|
| Headers | show |
| Series | Add support for offloading CT datapath rules to TC | expand |
On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: > The following patchset introduces hardware offload of OVS connection > tracking datapath rules. > > OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() > matches to support connection tracking. > > The datapath rules are in the form of: > > recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) > recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 > > This patchset will translate ct_state() and recirc_id() matches to tc > ct_state and chain matches respectively. The datapath actions ct() and recirc() > will be translated to tc actions ct and goto chain respectively. > > The tc equivalent commands for the above rules are: > > $ tc filter add dev dev1 ingress \ > prio 1 chain 0 proto ip \ > flower tcp ct_state -trk \ > action ct pipe \ > action goto chain 2 > > $ tc filter add dev dev1 ingress \ > prio 1 chain 2 proto ip \ > flower tcp ct_state +trk+est \ > action mirred egress redirect dev dev2 Hi Roi, I understand that this patchset handles adding rules as described above. But do we also need a patchset to enable offload of NF flowtable, so conntrack entries are offloaded? Kind regards, Simon
On 12/3/2019 6:41 PM, Simon Horman wrote: > On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: >> The following patchset introduces hardware offload of OVS connection >> tracking datapath rules. >> >> OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() >> matches to support connection tracking. >> >> The datapath rules are in the form of: >> >> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) >> recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 >> >> This patchset will translate ct_state() and recirc_id() matches to tc >> ct_state and chain matches respectively. The datapath actions ct() and recirc() >> will be translated to tc actions ct and goto chain respectively. >> >> The tc equivalent commands for the above rules are: >> >> $ tc filter add dev dev1 ingress \ >> prio 1 chain 0 proto ip \ >> flower tcp ct_state -trk \ >> action ct pipe \ >> action goto chain 2 >> >> $ tc filter add dev dev1 ingress \ >> prio 1 chain 2 proto ip \ >> flower tcp ct_state +trk+est \ >> action mirred egress redirect dev dev2 > Hi Roi, > > I understand that this patchset handles adding rules as described above. > But do we also need a patchset to enable offload of NF flowtable, > so conntrack entries are offloaded? Yes it would be added to tc, then a upcoming kernel patchset you describe will actually offloaded this via act ct -> nf flow table offload like what nft currently does. We will submitting that to linux kernel soon. > > Kind regards, > Simon
On Wed, Dec 04, 2019 at 08:10:10AM +0000, Paul Blakey wrote: > > On 12/3/2019 6:41 PM, Simon Horman wrote: > > On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: > >> The following patchset introduces hardware offload of OVS connection > >> tracking datapath rules. > >> > >> OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() > >> matches to support connection tracking. > >> > >> The datapath rules are in the form of: > >> > >> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) > >> recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 > >> > >> This patchset will translate ct_state() and recirc_id() matches to tc > >> ct_state and chain matches respectively. The datapath actions ct() and recirc() > >> will be translated to tc actions ct and goto chain respectively. > >> > >> The tc equivalent commands for the above rules are: > >> > >> $ tc filter add dev dev1 ingress \ > >> prio 1 chain 0 proto ip \ > >> flower tcp ct_state -trk \ > >> action ct pipe \ > >> action goto chain 2 > >> > >> $ tc filter add dev dev1 ingress \ > >> prio 1 chain 2 proto ip \ > >> flower tcp ct_state +trk+est \ > >> action mirred egress redirect dev dev2 > > Hi Roi, > > > > I understand that this patchset handles adding rules as described above. > > But do we also need a patchset to enable offload of NF flowtable, > > so conntrack entries are offloaded? > > Yes it would be added to tc, then a upcoming kernel patchset you > describe will actually offloaded this via act ct -> nf flow table > offload like what nft currently does. > > We will submitting that to linux kernel soon. Thanks, my follow-up question is what is the run-time effect of applying this patch-set (and all corresponding kernel patches) but not the follow-up described above? Are flows offloaded/not-offloaded in a manner that allows the system to work as it would (offload aside) without this patchset?
On 12/4/2019 2:26 PM, Simon Horman wrote: > On Wed, Dec 04, 2019 at 08:10:10AM +0000, Paul Blakey wrote: >> On 12/3/2019 6:41 PM, Simon Horman wrote: >>> On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: >>>> The following patchset introduces hardware offload of OVS connection >>>> tracking datapath rules. >>>> >>>> OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() >>>> matches to support connection tracking. >>>> >>>> The datapath rules are in the form of: >>>> >>>> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) >>>> recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 >>>> >>>> This patchset will translate ct_state() and recirc_id() matches to tc >>>> ct_state and chain matches respectively. The datapath actions ct() and recirc() >>>> will be translated to tc actions ct and goto chain respectively. >>>> >>>> The tc equivalent commands for the above rules are: >>>> >>>> $ tc filter add dev dev1 ingress \ >>>> prio 1 chain 0 proto ip \ >>>> flower tcp ct_state -trk \ >>>> action ct pipe \ >>>> action goto chain 2 >>>> >>>> $ tc filter add dev dev1 ingress \ >>>> prio 1 chain 2 proto ip \ >>>> flower tcp ct_state +trk+est \ >>>> action mirred egress redirect dev dev2 >>> Hi Roi, >>> >>> I understand that this patchset handles adding rules as described above. >>> But do we also need a patchset to enable offload of NF flowtable, >>> so conntrack entries are offloaded? >> Yes it would be added to tc, then a upcoming kernel patchset you >> describe will actually offloaded this via act ct -> nf flow table >> offload like what nft currently does. >> >> We will submitting that to linux kernel soon. > Thanks, my follow-up question is what is the run-time effect of applying > this patch-set (and all corresponding kernel patches) but not the follow-up > described above? Are flows offloaded/not-offloaded in a manner that > allows the system to work as it would (offload aside) without this > patchset? You mean if it would be just in tc (the nf flow table -> driver part doesn't exists/enabled or driver doesn't support it)? Then tc will handle the connection tracking, similar to OvS, and there should be no issues. It will just be not hardware offloaded, same as if we set the ovs tc policy to software only.
On Thu, Dec 05, 2019 at 12:31:39PM +0000, Paul Blakey wrote: > > On 12/4/2019 2:26 PM, Simon Horman wrote: > > On Wed, Dec 04, 2019 at 08:10:10AM +0000, Paul Blakey wrote: > >> On 12/3/2019 6:41 PM, Simon Horman wrote: > >>> On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: > >>>> The following patchset introduces hardware offload of OVS connection > >>>> tracking datapath rules. > >>>> > >>>> OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() > >>>> matches to support connection tracking. > >>>> > >>>> The datapath rules are in the form of: > >>>> > >>>> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) > >>>> recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 > >>>> > >>>> This patchset will translate ct_state() and recirc_id() matches to tc > >>>> ct_state and chain matches respectively. The datapath actions ct() and recirc() > >>>> will be translated to tc actions ct and goto chain respectively. > >>>> > >>>> The tc equivalent commands for the above rules are: > >>>> > >>>> $ tc filter add dev dev1 ingress \ > >>>> prio 1 chain 0 proto ip \ > >>>> flower tcp ct_state -trk \ > >>>> action ct pipe \ > >>>> action goto chain 2 > >>>> > >>>> $ tc filter add dev dev1 ingress \ > >>>> prio 1 chain 2 proto ip \ > >>>> flower tcp ct_state +trk+est \ > >>>> action mirred egress redirect dev dev2 > >>> Hi Roi, > >>> > >>> I understand that this patchset handles adding rules as described above. > >>> But do we also need a patchset to enable offload of NF flowtable, > >>> so conntrack entries are offloaded? > >> Yes it would be added to tc, then a upcoming kernel patchset you > >> describe will actually offloaded this via act ct -> nf flow table > >> offload like what nft currently does. > >> > >> We will submitting that to linux kernel soon. > > Thanks, my follow-up question is what is the run-time effect of applying > > this patch-set (and all corresponding kernel patches) but not the follow-up > > described above? Are flows offloaded/not-offloaded in a manner that > > allows the system to work as it would (offload aside) without this > > patchset? > > You mean if it would be just in tc (the nf flow table -> driver part > doesn't exists/enabled or driver doesn't support it)? > > Then tc will handle the connection tracking, similar to OvS, and there > should be no issues. > > It will just be not hardware offloaded, same as if we set the ovs tc > policy to software only. Thanks, I believe that answers my question and there will be no regression caused by adding this series. From my side I'd be grateful of some acks before applying this series.
> On Thu, Dec 05, 2019 at 12:31:39PM +0000, Paul Blakey wrote: >> >> On 12/4/2019 2:26 PM, Simon Horman wrote: >> > On Wed, Dec 04, 2019 at 08:10:10AM +0000, Paul Blakey wrote: >> >> On 12/3/2019 6:41 PM, Simon Horman wrote: >> >>> On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: >> >>>> The following patchset introduces hardware offload of OVS connection >> >>>> tracking datapath rules. >> >>>> >> >>>> OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() >> >>>> matches to support connection tracking. >> >>>> >> >>>> The datapath rules are in the form of: >> >>>> >> >>>> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) >> >>>> recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 >> >>>> >> >>>> This patchset will translate ct_state() and recirc_id() matches to tc >> >>>> ct_state and chain matches respectively. The datapath actions ct() and recirc() >> >>>> will be translated to tc actions ct and goto chain respectively. >> >>>> >> >>>> The tc equivalent commands for the above rules are: >> >>>> >> >>>> $ tc filter add dev dev1 ingress \ >> >>>> prio 1 chain 0 proto ip \ >> >>>> flower tcp ct_state -trk \ >> >>>> action ct pipe \ >> >>>> action goto chain 2 >> >>>> >> >>>> $ tc filter add dev dev1 ingress \ >> >>>> prio 1 chain 2 proto ip \ >> >>>> flower tcp ct_state +trk+est \ >> >>>> action mirred egress redirect dev dev2 >> >>> Hi Roi, >> >>> >> >>> I understand that this patchset handles adding rules as described above. >> >>> But do we also need a patchset to enable offload of NF flowtable, >> >>> so conntrack entries are offloaded? >> >> Yes it would be added to tc, then a upcoming kernel patchset you >> >> describe will actually offloaded this via act ct -> nf flow table >> >> offload like what nft currently does. >> >> >> >> We will submitting that to linux kernel soon. >> > Thanks, my follow-up question is what is the run-time effect of applying >> > this patch-set (and all corresponding kernel patches) but not the follow-up >> > described above? Are flows offloaded/not-offloaded in a manner that >> > allows the system to work as it would (offload aside) without this >> > patchset? >> >> You mean if it would be just in tc (the nf flow table -> driver part >> doesn't exists/enabled or driver doesn't support it)? >> >> Then tc will handle the connection tracking, similar to OvS, and there >> should be no issues. >> >> It will just be not hardware offloaded, same as if we set the ovs tc >> policy to software only. > > Thanks, I believe that answers my question and there will be no regression > caused by adding this series. From my side I'd be grateful of some acks > before applying this series. FYI, I have an unanswered comment for this patch-set here: https://mail.openvswitch.org/pipermail/ovs-dev/2019-December/365459.html And it actually doesn't compile: https://travis-ci.org/ovsrobot/ovs/builds/620138967 Best regards, Ilya Maximets.
On 12/6/2019 11:46 AM, Simon Horman wrote: > On Thu, Dec 05, 2019 at 12:31:39PM +0000, Paul Blakey wrote: >> On 12/4/2019 2:26 PM, Simon Horman wrote: >>> On Wed, Dec 04, 2019 at 08:10:10AM +0000, Paul Blakey wrote: >>>> On 12/3/2019 6:41 PM, Simon Horman wrote: >>>>> On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: >>>>>> The following patchset introduces hardware offload of OVS connection >>>>>> tracking datapath rules. >>>>>> >>>>>> OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() >>>>>> matches to support connection tracking. >>>>>> >>>>>> The datapath rules are in the form of: >>>>>> >>>>>> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) >>>>>> recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 >>>>>> >>>>>> This patchset will translate ct_state() and recirc_id() matches to tc >>>>>> ct_state and chain matches respectively. The datapath actions ct() and recirc() >>>>>> will be translated to tc actions ct and goto chain respectively. >>>>>> >>>>>> The tc equivalent commands for the above rules are: >>>>>> >>>>>> $ tc filter add dev dev1 ingress \ >>>>>> prio 1 chain 0 proto ip \ >>>>>> flower tcp ct_state -trk \ >>>>>> action ct pipe \ >>>>>> action goto chain 2 >>>>>> >>>>>> $ tc filter add dev dev1 ingress \ >>>>>> prio 1 chain 2 proto ip \ >>>>>> flower tcp ct_state +trk+est \ >>>>>> action mirred egress redirect dev dev2 >>>>> Hi Roi, >>>>> >>>>> I understand that this patchset handles adding rules as described above. >>>>> But do we also need a patchset to enable offload of NF flowtable, >>>>> so conntrack entries are offloaded? >>>> Yes it would be added to tc, then a upcoming kernel patchset you >>>> describe will actually offloaded this via act ct -> nf flow table >>>> offload like what nft currently does. >>>> >>>> We will submitting that to linux kernel soon. >>> Thanks, my follow-up question is what is the run-time effect of applying >>> this patch-set (and all corresponding kernel patches) but not the follow-up >>> described above? Are flows offloaded/not-offloaded in a manner that >>> allows the system to work as it would (offload aside) without this >>> patchset? >> You mean if it would be just in tc (the nf flow table -> driver part >> doesn't exists/enabled or driver doesn't support it)? >> >> Then tc will handle the connection tracking, similar to OvS, and there >> should be no issues. >> >> It will just be not hardware offloaded, same as if we set the ovs tc >> policy to software only. > Thanks, I believe that answers my question and there will be no regression > caused by adding this series. From my side I'd be grateful of some acks > before applying this series. sure, thanks.
The following patchset introduces hardware offload of OVS connection tracking datapath rules. OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() matches to support connection tracking. The datapath rules are in the form of: recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 This patchset will translate ct_state() and recirc_id() matches to tc ct_state and chain matches respectively. The datapath actions ct() and recirc() will be translated to tc actions ct and goto chain respectively. The tc equivalent commands for the above rules are: $ tc filter add dev dev1 ingress \ prio 1 chain 0 proto ip \ flower tcp ct_state -trk \ action ct pipe \ action goto chain 2 $ tc filter add dev dev1 ingress \ prio 1 chain 2 proto ip \ flower tcp ct_state +trk+est \ action mirred egress redirect dev dev2 Thanks, Roi Paul Blakey (10): match: Add match_set_ct_zone_masked helper compat: Add tc ct action and flower matches defines for older kernels tc: Introduce tcf_id to specify a tc filter netdev-offload-tc: Implement netdev tc flush via tc filter del dpif: Add support to set user features tc: Move tunnel_key unset action before output ports netdev-offload-tc: Add recirculation support via tc chains netdev-offload-tc: Add conntrack support netdev-offload-tc: Add conntrack label and mark support netdev-offload-tc: Add conntrack nat support datapath/linux/compat/include/linux/openvswitch.h | 3 + include/linux/automake.mk | 3 +- include/linux/pkt_cls.h | 46 +- include/linux/tc_act/tc_ct.h | 41 ++ include/openvswitch/match.h | 2 + lib/dpif-netdev.c | 1 + lib/dpif-netlink.c | 64 ++- lib/dpif-provider.h | 2 + lib/dpif.c | 9 + lib/dpif.h | 2 + lib/match.c | 10 +- lib/netdev-linux.c | 6 +- lib/netdev-offload-tc.c | 628 ++++++++++++++++------ lib/netdev-offload.h | 2 +- lib/tc.c | 442 ++++++++++++--- lib/tc.h | 112 +++- 16 files changed, 1079 insertions(+), 294 deletions(-) create mode 100644 include/linux/tc_act/tc_ct.h