This ticket is tracking the QE verification effort for the solution to the problem described below.
Description of problem:
mlx5_core driver: ping ovs bridge ip address failed when vf configure trust off

Version-Release number of selected component (if applicable):
5.14.0-284.92.1.el9_2.x86_64
openvswitch3.1-3.1.0-140.el9fdp
openvswitch3.3-3.3.0-62.el9fdp
openvswitch3.4-3.4.0-18.el9fdp

How reproducible:
Steps to Reproduce:
760-09 cx6 card <-directy connect--> 740-03 cx6 card
on 740-03:
systemctl restart openvswitch
ovs-vsctl del-br ovsbr0
echo 0 > /sys/devices/pci0000:5d/0000:5d:02.0/0000:5f:00.0/sriov_numvfs
echo 1 > /sys/devices/pci0000:5d/0000:5d:02.0/0000:5f:00.0/sriov_numvfs
ip link set ens2f0np0 vf 0 trust on
ovs-vsctl add-br ovsbr0
ovsbr_mac=`ifconfig ovsbr0 | grep ether | awk '

{print $2}'`
ip link set ens2f0np0 vf 0 mac ${ovsbr_mac}
ovs-vsctl add-port ovsbr0 ens2f0v0
ip link set ovsbr0 up
ip addr add 20.0.0.1/24 dev ovsbr0

on 760-09:
systemctl restart openvswitch
ovs-vsctl del-br ovsbr0
echo 0 > /sys/devices/pci0000:9f/0000:9f:01.0/0000:a0:00.0/sriov_numvfs
echo 1 > /sys/devices/pci0000:9f/0000:9f:01.0/0000:a0:00.0/sriov_numvfs
ip link set ens5f0np0 vf 0 trust on
ovs-vsctl add-br ovsbr0
ovsbr_mac=`ifconfig ovsbr0 | grep ether | awk '{print $2}

'`
ip link set ens5f0np0 vf 0 mac ${ovsbr_mac}
ovs-vsctl add-port ovsbr0 ens5f0v0
ip link set ovsbr0 up
ip addr add 20.0.0.2/24 dev ovsbr0
ping 20.0.0.1

Actual results:
root@dell-per760-09 ~]# ping 20.0.0.1 -c 2
PING 20.0.0.1 (20.0.0.1) 56(84) bytes of data.
From 20.0.0.2 icmp_seq=1 Destination Host Unreachable
From 20.0.0.2 icmp_seq=2 Destination Host Unreachable

[root@dell-per740-03 ~]# tcpdump -i ovsbr0 -vven
dropped privs to tcpdump
tcpdump: listening on ovsbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
02:19:13.420434 42:fa:e9:47:cc:49 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 20.0.0.1 tell 20.0.0.2, length 46
02:19:13.420446 de:88:3b:f1:c9:4b > 42:fa:e9:47:cc:49, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 20.0.0.1 is-at de:88:3b:f1:c9:4b, length 28
02:19:14.401381 ee:b5:bd:29:77:fa > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: (flowlabel 0x30980, hlim 255, next-header ICMPv6 (58) payload length: 8) fe80::7bcb:92a4:c9cb:a2ba > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 8
02:19:14.474217 42:fa:e9:47:cc:49 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 20.0.0.1 tell 20.0.0.2, length 46
02:19:14.474231 de:88:3b:f1:c9:4b > 42:fa:e9:47:cc:49, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 20.0.0.1 is-at de:88:3b:f1:c9:4b, length 28
02:19:15.498207 42:fa:e9:47:cc:49 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 20.0.0.1 tell 20.0.0.2, length 46
02:19:15.498222 de:88:3b:f1:c9:4b > 42:fa:e9:47:cc:49, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 20.0.0.1 is-at de:88:3b:f1:c9:4b, length 28
02:19:17.084404 ee:b5:bd:29:77:fa > Broadcast, ethertype IPv4 (0x0800), length 334: (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 320)

For mlx5_core driver, when configure the vf trust on, it ping successfully, but ping failed when vf trust off.
For i40e driver, Whether vf trust on or vf trust off, it ping successfully.

Expected results:
For mlx5_core drive, it can ping successfully when vf trust off.

Additional info:
This issue not a regression bug, it also exist on older ovs version, such as openvswitch3.1-3.1.0-94.el9fdp.