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

Paul Blakey paulb at mellanox.com
Thu Dec 5 12:31:39 UTC 2019


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.




More information about the dev mailing list