This epic tracks all the effort needed to deliver the solution related to the bug described below.

 Problem Description: Clearly explain the issue.

FDP-1538 identified some OVS issues when using flows such as

meter(),pop_vlan,check_pkt_len(size=1456,gt(meter(),set(eth),set(arp)2),le(meter(),set(eth),set(arp),2).

Such flows are somehow unexpected as both branches of gt() are the same.

OVN is responsible of building the openflows which get translated by OVS in such flows. 

OVN should not create those un-optimal flows.

 Impact Assessment: Describe the severity and impact (e.g., network down,availability of a workaround, etc.).

Low as it does not seem that fixing this would workaround all cases hit by FDP-1538.

 Software Versions: Specify the exact versions in use (e.g.,openvswitch3.1-3.1.0-147.el8fdp).

Reproduced on main.

  Issue Type: Indicate whether this is a new issue or a regression (if a regression, state the last known working version).

Not a regression.

 Reproducibility: Confirm if the issue can be reproduced consistently. If not, describe how often it occurs.

Can be reproduced consistently.

 Reproduction Steps: Provide detailed steps or scripts to replicate the issue.

No easy steps, but using db from FDP-1538 (using gateway_mtu) and simulating arp_request towards arp_tpa=10.25.21.245

 Expected Behavior: Describe what should happen under normal circumstances.

• No check_pkt_len flows for ARP packets
• Flows with check_pkt_len should have different actions for both paths.

 Observed Behavior: Explain what actually happens.

Un-optimal flow created. Such flow then hits FDP-1538 issue.

 Troubleshooting Actions: Outline the steps taken to diagnose or resolve the issue so far.

Flows checking REGBIT_PKT_LARGER bit are matching on ip4 or ip6. Hence, there is no need to set this bit for ARP (it is not checked anyhow).

 Logs: If you collected logs please provide them (e.g. sos report, /var/log/openvswitch/* , testpmd console)