Simon Horman <[email protected]> writes:

> On Wed, Sep 27, 2023 at 11:31:22AM -0400, Aaron Conole wrote:
>> From: Peng He <[email protected]>
>> 
>> The patch avoids the extra allocation for nat_conn.
>> Currently, when doing NAT, the userspace conntrack will use an extra
>> conn for the two directions in a flow. However, each conn has actually
>> the two keys for both orig and rev directions. This patch introduces a
>> key_node[CT_DIRS] member as per Aaron's suggestion in the conn which
>> consists of a key, direction, and a cmap_node for hash lookup so
>> addressing the feedback received by the original patch [0].
>> 
>> With this adjustment, we also remove the assertion that connections in
>> the table are DEFAULT while updating connection state and/or removing
>> connections.
>> 
>> [0]
>> https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/
>> 
>> [Aaron resolved numerous conflicts due to lack of multiple commits]
>
> Hi Aaron,
>
> unfortunately I see numerous failures flagged in CI with this change
> applied. And I was able to see similar failures locally.
>
> For test #98, the key in the logs of my local run seemed to be:
>
> 2023-10-02T12:02:50Z|00001|unixctl|WARN|error communicating with
> unix:.../tests/system-userspace-testsuite.dir/098/ovs-vswitchd.813454.ctl:
> End of file
> ovs-appctl: ovs-vswitchd: transaction error (End of file)
> ./system-traffic.at:4206: exit code was 1, expected 0

Yes - I see that it looks like we are having an issue dropping the xons
and that is causing an issue during cleanup.

I'm looking into it.

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to