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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
