On 2/14/24 13:43, Xavier Simonart wrote:
> When a ct element was cleaned, the cmap could be shrinked, potentially
> causing some elements to be skipped in the flush iteration.
>
> Signed-off-by: Xavier Simonart <xsimo...@redhat.com>
> ---
> lib/conntrack.c | 14 ++++---------
> lib/conntrack.h | 1 +
> tests/system-traffic.at | 45 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index 013709bd6..6d02eaba8 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -2637,25 +2637,19 @@ conntrack_dump_start(struct conntrack *ct, struct
> conntrack_dump *dump,
>
> dump->ct = ct;
> *ptot_bkts = 1; /* Need to clean up the callers. */
> + dump->cursor = cmap_cursor_start(&ct->conns);
> return 0;
> }
>
> int
> conntrack_dump_next(struct conntrack_dump *dump, struct ct_dpif_entry *entry)
> {
> - struct conntrack *ct = dump->ct;
> long long now = time_msec();
>
> - for (;;) {
> - struct cmap_node *cm_node = cmap_next_position(&ct->conns,
> - &dump->cm_pos);
> - if (!cm_node) {
> - break;
> - }
> - struct conn_key_node *keyn;
> - struct conn *conn;
> + struct conn_key_node *keyn;
> + struct conn *conn;
>
> - INIT_CONTAINER(keyn, cm_node, cm_node);
> + CMAP_CURSOR_FOR_EACH_CONTINUE (keyn, cm_node, &dump->cursor) {
> if (keyn->dir != CT_DIR_FWD) {
> continue;
> }
> diff --git a/lib/conntrack.h b/lib/conntrack.h
> index 0a888be45..2eb0870c2 100644
> --- a/lib/conntrack.h
> +++ b/lib/conntrack.h
> @@ -103,6 +103,7 @@ struct conntrack_dump {
> union {
> struct cmap_position cm_pos;
> struct hmap_position hmap_pos;
> + struct cmap_cursor cursor;
> };
> bool filter_zone;
> uint16_t zone;
> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
> index e68fe7e18..99979844e 100644
> --- a/tests/system-traffic.at
> +++ b/tests/system-traffic.at
> @@ -8329,6 +8329,51 @@ AT_CHECK([ovs-pcap client.pcap | grep
> 000000002010000000002000], [0], [dnl
> OVS_TRAFFIC_VSWITCHD_STOP
> AT_CLEANUP
>
> +AT_SETUP([conntrack - Flush many conntrack entries by port])
> +CHECK_CONNTRACK()
> +OVS_TRAFFIC_VSWITCHD_START()
> +
> +ADD_NAMESPACES(at_ns0, at_ns1)
> +
> +ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
> +ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
> +
> +AT_DATA([flows.txt], [dnl
> +priority=100,in_port=1,udp,action=ct(zone=1,commit),2
> +])
> +
> +AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt])
> +
> +# 20 packets from port 1 and 1 packet from port 2.
dnl comments are preferred. We're actually surprisingly only have
a few # comments in this file.
> +for i in $(seq 1 20); do
> + d=$(printf "%02x" $i)
> + AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 "in_port=1
> packet=50540000000a50540000000908004500001c000000000011a4cd0a0101010a010102000100${d}00080000
> actions=resubmit(,0)"])
> +done
> +AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 "in_port=1
> packet=50540000000a50540000000908004500001c000000000011a4cd0a0101010a0101020002000100080000
> actions=resubmit(,0)"])
Can we use 'ovs-ofctl compose-packet --bare' for these?
I know, it is not available on older branches, but we can swap it
back while backporting, I think.
Or at least, define a variable for the whole packet and use
it for the packet-out, so we have shorter lines.
What do you think?
> +
> +: > conntrack
> +
> +for i in $(seq 1 20); do
> + d=$(printf "%d" $i)
> + echo
> "udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=1,dport=${d}),reply=(src=10.1.1.2,dst=10.1.1.1,sport=${d},dport=1),zone=1"
> >> conntrack
> +done
> +echo
> "udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=2,dport=1),reply=(src=10.1.1.2,dst=10.1.1.1,sport=1,dport=2),zone=1"
> >> conntrack
> +
> +sort conntrack > expout
> +
> +AT_CHECK([ovs-appctl dpctl/dump-conntrack | grep -F "src=10.1.1.1," | sort
> ], [0], [expout])
> +
> +# Check that flushing conntrack by port 1 flush all ct for port 1 but keeps
> ct for port 2.
> +AT_CHECK([ovs-appctl dpctl/flush-conntrack 'ct_nw_proto=17,ct_tp_src=1'])
> +AT_CHECK([ovs-appctl dpctl/dump-conntrack | grep -F "src=10.1.1.1," | sort
> ], [0], [dnl
> +udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=2,dport=1),reply=(src=10.1.1.2,dst=10.1.1.1,sport=1,dport=2),zone=1
> +])
> +
> +OVS_TRAFFIC_VSWITCHD_STOP(["dnl
> +/could not create datapath/d
> +/(Cannot allocate memory) on packet/d"])
Where are these errors are coming from in this test? I don't
think we expect any of the operations in this test to fail.
> +AT_CLEANUP
> +
> AT_BANNER([IGMP])
>
> AT_SETUP([IGMP - flood under normal action])
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
