On Fri, Mar 24, 2023 at 5:14 PM Dumitru Ceara <[email protected]> wrote:
> On 3/9/23 14:14, Simon Horman wrote:
> > On Thu, Mar 09, 2023 at 07:21:44AM +0100, Ales Musil wrote:
> >> Currently, there is one ct.est flow per LB VIP,
> >> that was required to keep track if we need to
> >> pass the "skip_snat" or "force_snat" flags.
> >> However since c1d6b8ac ("northd: Store skip_snat and force_snat in
> ct_label/mark")
> >> the flags are carried in the ct entry and
> >> we can use match on them the same way we do
> >> for related traffic.
> >>
> >> Simplify the logic for established
> >> traffic through load balancers, by removing
> >> the requirement for one ct.est flow per VIP
> >> and replacing them with three generic ct.est flows:
> >> match=(ct.est && !ct.rel && !ct.new && ct_mark.natted), action=(next;)
> >> match=(ct.est && !ct.rel && !ct.new && ct_mark.natted &&
> ct_mark.force_snat == 1), action=(flags.force_snat_for_lb = 1; next;)
> >> match=(ct.est && !ct.rel && !ct.new && ct_mark.natted &&
> ct_mark.skip_snat == 1), action=(flags.skip_snat_for_lb = 1; next;)
> >>
> >> This allows us avoiding of matching on L4
> >> in defrag stage by not storing the L3 and L4
> >> destination in registers. Match directly on
> >> L3 and L4 destination for ct.new in DNAT stage.
> >>
> >> Populate the registers in LB affinity check stage
> >> as they are needed for LB affinity learn.
> >>
> >> Reported-at: https://bugzilla.redhat.com/2172048
> >> Reported-at: https://bugzilla.redhat.com/2170885
> >> Signed-off-by: Ales Musil <[email protected]>
> >
> > Reviewed-by: Simon Horman <[email protected]>
> >
>
> Thanks, Ales and Simon!
>
> >> @@ -10475,10 +10485,21 @@ build_distr_lrouter_nat_flows_for_lb(struct
> lrouter_nat_lb_flows_ctx *ctx,
> >> enum lrouter_nat_lb_flow_type
> type,
> >> struct ovn_datapath *od)
> >> {
> >> - char *gw_action = od->is_gw_router ? "ct_dnat;" :
> "ct_dnat_in_czone;";
> >> + char *undnat_action;
> >
> > nit: I think this could be const.
> > nit: Maybe a blank line here.
> >
>
> I fixed this up and also adapted the tests in ovn-northd.at (after
> recent changes that went in) and then applied it to the main branch.
>
Thanks!
>
> Ales, does this patch need a backport? If so, can you please prepare a
> backport patch, I see some conflicts when cherry picking to 23.03.
>
I'll prepare patch for 23.03.
>
> Thanks,
> Dumitru
>
>
Thanks,
Ales
--
Ales Musil
Senior Software Engineer - OVN Core
Red Hat EMEA <https://www.redhat.com>
[email protected] IM: amusil
<https://red.ht/sig>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
