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