On 3/29/23 12:00, Abhiram Sangana wrote:
>>>> @@ -896,6 +904,26 @@ put_local_common_flows(uint32_t dp_key,
>>>> pb->header_.uuid.parts[0], &match, ofpacts_p,
>>>> &pb->header_.uuid);
>>>>
>>>> + if (zone_ids->drop) {
>>>> + /* Table 39, Priority 1.
>>>> + * =======================
>>>> + *
>>>> + * Clear the logical registers (for consistent behavior with
>>>> packets
>>>> + * that get tunneled) except MFF_LOG_ACL_DROP_ZONE. */
>>>> + match_init_catchall(&match);
>>>> + ofpbuf_clear(ofpacts_p);
>>>> + match_set_metadata(&match, htonll(dp_key));
>>>> + for (int i = 0; i < MFF_N_LOG_REGS; i++) {
>>>> + if ((MFF_REG0 + i) != MFF_LOG_ACL_DROP_ZONE) {
>>>> + put_load(0, MFF_REG0 + i, 0, 32, ofpacts_p);
>>>> + }
>>>> + }
>> Why do we need this? Don't we load the CT zone anyway for "to-lport"
>> ACLs? Can't we also load the drop zone in the same place?
> Yes, we are loading the drop zone (reg 9) in the same place as CT zone
> for “to-lport” ACLs (reg 13) but this happens before table=39 where
> registers 0 to 9 are cleared.
Oh, I see now, it's because the drop zone is stored in reg9. I wanted
to suggest not allowing reg9 to be used as logical register anymore but
that's not really easy because it's used in the router pipeline:
/* Register to store the result of check_pkt_larger action. */
#define REGBIT_PKT_LARGER "reg9[1]"
#define REGBIT_LOOKUP_NEIGHBOR_RESULT "reg9[2]"
#define REGBIT_LOOKUP_NEIGHBOR_IP_RESULT "reg9[3]"
#define REGBIT_DST_NAT_IP_LOCAL "reg9[4]"
#define REGBIT_KNOWN_ECMP_NH "reg9[5]"
#define REGBIT_KNOWN_LB_SESSION "reg9[6]"
[...]
#define REG_ORIG_TP_DPORT_ROUTER "reg9[16..31]"
Can we reuse one of the router-specific zones registers instead?
#define MFF_LOG_DNAT_ZONE MFF_REG11 /* conntrack dnat zone for gateway
router
* (32 bits). */
#define MFF_LOG_SNAT_ZONE MFF_REG12 /* conntrack snat zone for gateway
router
* (32 bits). */
Regards,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
