[ovs-dev] [PATCH v3 00/10] Add support for offloading CT datapath rules to TC

[Ilya Maximets]

> 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.