[ovs-dev] [PATCH v3 9/9] ofproto-dpif-xlate: Translate timeout policy in ct action
yihung.wei at gmail.com
Tue Aug 13 21:33:40 UTC 2019
On Tue, Aug 13, 2019 at 11:43 AM Darrell Ball <dlu998 at gmail.com> wrote:
> Sure, circling back to this part....
> yep, it is the Linux In-tree kernel module rather than OVS tree module
> dball at ubuntu:~/ovs$ modinfo openvswitch
> filename: /lib/modules/5.0.0-23-generic/kernel/net/openvswitch/openvswitch.ko
> alias: net-pf-16-proto-16-family-ovs_ct_limit
> alias: net-pf-16-proto-16-family-ovs_meter
> alias: net-pf-16-proto-16-family-ovs_packet
> alias: net-pf-16-proto-16-family-ovs_flow
> alias: net-pf-16-proto-16-family-ovs_vport
> alias: net-pf-16-proto-16-family-ovs_datapath
> license: GPL
> description: Open vSwitch switching datapath
> srcversion: 12850657561FB87D174A001
> depends: nf_conntrack,nf_nat,nf_conncount,libcrc32c,nf_nat_ipv6,nf_nat_ipv4,nf_defrag_ipv6,nsh
> retpoline: Y
> intree: Y
> name: openvswitch
> vermagic: 5.0.0-23-generic SMP mod_unload
> signat: PKCS#7
> sig_hashalgo: md4
> btw, similarly
> make 'check-kernel' fails for the same reasons.
> Ostensibly, I would have expected 5.0 to be ok.
> I can dig more on this part later if you wish.
The ct timeout feature is introduced in 5.2 kernel, so 'make
check-kernel' is expected to fail on 5.0 kernel. The upstream kernel
support for ct timeout feature is documented at
"Documentation/faq/releases.rst" in the patch 4.
> btw, I think a timeout policy not being applied should not result in packet blackholing.
> I think we need to make this better.
Sure, we can definitely make it better. I am focusing on some other
issue now, but I will have a follow up patch that only translate the
ct timeout attribute when the datapath does support that.
> A timeout policy is just a nice to have 'thingy' after all.
> That being said, I would like to see Xenial working (with OVS in-tree module) with higher priority.
> Thanks Darrell
More information about the dev