Redirecting to br-ex happens even if there is a single hardware offloaded
port on hypervisor. Still can't find the actual reason.
Increasing mac-aging-time and mac-table-size did not help also.

By the way, it is bidirectional storage(ceph) traffic.



On Wed, May 14, 2025 at 1:39 PM Ilya Maximets <[email protected]> wrote:

> On 5/8/25 4:15 PM, Serhat Rıfat Demircan via discuss wrote:
> > Hello Everyone,
> >
> > I've been testing OVS hardware offloaded ports with Openstack for a
> while.
> > I have ConnectX-5 and ConnectX-6 cards in my lab. Iperf tests are looking
> > promising, but when I try to use hardware offloaded ports for krbd
> traffic,
> > after some time, traffic falls back to the software path. Another
> interesting
> > thing for me is without changing anything, it can also switch back to the
> > hardware path. I could not find the real reason.
> >
> > I'm not sure if this is a configuration issue or if I'm hitting to cards
> limit.
> > If any of you guys are experienced with this all ideas are more than
> welcome.
> >
> > Openstack version: Caracal
> > Operation System: Ubuntu 22.04
> > OVS version: 3.3.0
> >
> > I see tc flow change:
> >
> > *From Offloaded:*
> > $ tc filter show dev ens37f0npf0vf6 ingress
> > filter protocol ip pref 2 flower chain 0
> > filter protocol ip pref 2 flower chain 0 handle 0x1
> >   dst_mac 00:1c:73:aa:bb:cc
> >   src_mac fa:16:7e:2e:8c:f0
> >   eth_type ipv4
> >   ip_flags nofrag
> >   skip_sw
> >   in_hw in_hw_count 1
> > action order 1: vlan  push id 111 protocol 802.1Q priority 0 pipe
> > index 4 ref 1 bind 1
> > no_percpu
> > used_hw_stats delayed
> >
> > action order 2: mirred (Egress Redirect to device openstack) stolen
> > index 4 ref 1 bind 1
> > cookie 605b82e5b94ef3fa63c3e78349851a27
> > no_percpu
> > used_hw_stats delayed
> >
> > *To software path:*
> > $ tc filter show dev ens37f0npf0vf6 ingress
> > filter protocol ip pref 2 flower chain 0
> > filter protocol ip pref 2 flower chain 0 handle 0x1
> >   dst_mac 00:1c:73:aa:bb:cc
> >   src_mac fa:16:7e:2e:8c:f0
> >   eth_type ipv4
> >   ip_flags nofrag
> >   not_in_hw
> > action order 1: vlan  push id 111 protocol 802.1Q priority 0 pipe
> > index 4 ref 1 bind 1
> > no_percpu
> >
> > action order 2: skbedit  ptype host pipe
> > index 11 ref 1 bind 1
> >
> > action order 3: mirred (Ingress Mirror to device br-ex) pipe
> > index 13 ref 1 bind 1
> > cookie 5037716e444e83b81c4ef9844df2377d
> > no_percpu
> >
> > action order 4: mirred (Egress Redirect to device openstack) stolen
> > index 15 ref 1 bind 1
> > cookie 5037716e444e83b81c4ef9844df2377d
> > no_percpu
>
> Here you can see that traffic is getting broadcasted on all ports in the
> br-ex bridge, and since some of these ports are virtual, this operation
> cannot be offloaded to hardware.
>
> I would guess, after some time the FDB entry expires and OVS no longer
> knows on which port the traffic supposed to be sent out.  Is that a
> unidirection traffic?  i.e. are you also sending traffic in the opposite
> direction?  If not, are you sending some periodic ARP requests for the
> bridge to learn where the destination is?
>
> If the traffic is bidirectional, then it might be a NIC driver/firmware
> issue not providing updated stats.
>
> Best regards, Ilya Maximets.
>
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to