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.

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.

Thanks,
Dumitru

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

Reply via email to