On 17 Sep 2026 at 03:54:07 PM, Aaron Conole via dev <[email protected]> wrote:
> Eli Britstein <[email protected]> writes: > >> From: Tim Rozet <[email protected]> >> >> The userspace datapath applies a connection's existing NAT mapping to >> a packet in the new state when a bare ct(nat) action is executed. This >> differs from the Linux datapath, which leaves a new packet untranslated >> unless the current action explicitly requests source or destination >> NAT. >> >> The kernel's nf_ct_nat() infers the NAT direction from conntrack status >> only when the connection state is not IP_CT_NEW. For IP_CT_NEW, the >> action must provide the manipulation direction: >> >> https://github.com/torvalds/linux/blob/master/net/netfilter/nf_nat_ovs.c >> >> Pass the current NAT action into handle_nat() and use its source or >> destination flags to decide whether NAT may run for a new packet. This >> also applies the same behavior to the userspace fast path. >> >> Add a system test that sends the same UDP packet twice without a reply. >> It verifies that bare NAT leaves the second new packet untranslated so >> it reaches an explicit DNAT action. Run the test against both kernel >> and userspace datapaths. >> >> Fixes: 286de2729955 ("dpdk: Userspace Datapath: Introduce NAT Support.") >> Assisted-by: GPT-5, Codex >> Co-authored-by: Tim Rozet <[email protected]> >> Signed-off-by: Tim Rozet <[email protected]> >> Signed-off-by: Eli Britstein <[email protected]> >> --- > > It needs to be documented that previously a +new+trk packet that got > recirculated through a second zone would have mapping applied for a bare > ct(...nat,...) call. That is no longer the case after this patch. We > need to make sure the documentation and NEWS reflect this so users are > aware. > On top of this, even in the same zone, from ovs-actions(7): "A bare nat argument with no options will only translate the packet being processed in the way the connection has been set up with an earlier, committed ct action. [...]" The documentation does not mention or special-case packets with +new, so perhaps this is a historical documentation inaccuracy, in which case it should at least be updated. There is also a chance that this is unintended kernel-module behavior. Either way, there is a risk of breaking some assumptions. About the previous discussion, I agree that not everything that diverges from the kernel is necessarily a fix. As you said, there are multiple differences. It may at least it sounds more plausible there, given that they should act as separate domains, but for the same zone, I'm not sure. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
