Hi Ajit, It seem that the flows which are related with broadcast DMAC are appear on bridges which are connected to PF/VF like below.
admin@controller01:~$ sudo ovs-appctl dpif/dump-flows type=all br-provider recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=84:16:0c:f0:47:2b,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=84:16:0c:f0:23:97,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=84:16:0c:f0:47:2a,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=84:16:0c:f0:23:96,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=00:03:0f:bb:80:db,dst=01:80:c2:00:00:02),eth_type(0x8809), packets:198547, bytes:24619828, used:0.419s, actions:drop recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=84:16:0c:f0:2d:62,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth(src=84:16:0c:f0:2d:63,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(src=00:03:0f:bb:80:db,dst=01:80:c2:00:00:02),eth_type(0x8809), packets:198547, bytes:24619828, used:0.419s, actions:drop admin@controller01:~$ sudo ovs-appctl dpif/dump-flows type=all br-int tunnel(tun_id=0x0,src=10.10.203.13,dst=10.10.203.11,geneve(),flags(-df+csum+key)),recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),udp(dst=3784), packets:226653, bytes:14959098, used:0.370s, actions:userspace(pid=0,slow_path(bfd)) tunnel(tun_id=0x0,src=10.10.203.17,dst=10.10.203.11,geneve(),flags(-df+csum+key)),recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),udp(dst=3784), packets:156086, bytes:10301676, used:0.088s, actions:userspace(pid=0,slow_path(bfd)) tunnel(tun_id=0x0,src=10.10.203.16,dst=10.10.203.11,geneve(),flags(-df+csum+key)),recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),udp(dst=3784), packets:225335, bytes:14872110, used:0.449s, actions:userspace(pid=0,slow_path(bfd)) tunnel(tun_id=0x0,src=10.10.203.15,dst=10.10.203.11,geneve(),flags(-df+csum+key)),recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),udp(dst=3784), packets:224925, bytes:14845050, used:0.766s, actions:userspace(pid=0,slow_path(bfd)) tunnel(tun_id=0x0,src=10.10.203.18,dst=10.10.203.11,geneve(),flags(-df+csum+key)),recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),udp(dst=3784), packets:226408, bytes:14942928, used:0.093s, actions:userspace(pid=0,slow_path(bfd)) admin@controller01:~$ sudo ovs-appctl dpif/dump-flows type=all br-tun recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=bc:97:e1:05:60:90,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=bc:97:e1:05:60:71,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=4e:fd:17:56:20:4d,dst=02:41:ed:5e:e4:4f),eth_type(0x8100),vlan(vid=1203,pcp=0),encap(eth_type(0x0800),ipv4(dst=10.10.203.11,proto=17,frag=no),udp(dst=6081)), packets:225346, bytes:27041520, used:0.349s, actions:pop_vlan,tnl_pop(1) recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=e4:3d:1a:dc:4c:00,dst=01:80:c2:00:00:02),eth_type(0x8809), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=26:a0:81:bc:46:41,dst=02:41:ed:5e:e4:4f),eth_type(0x8100),vlan(vid=1203,pcp=0),encap(eth_type(0x0800),ipv4(dst=10.10.203.11,proto=17,frag=no),udp(dst=6081)), packets:7170, bytes:860400, used:0.708s, actions:pop_vlan,tnl_pop(1) recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=3e:79:4e:a0:a0:4b,dst=02:41:ed:5e:e4:4f),eth_type(0x8100),vlan(vid=1203,pcp=0),encap(eth_type(0x0800),ipv4(dst=10.10.203.11,proto=17,frag=no),udp(dst=6081)), packets:226664, bytes:27199680, used:0.530s, actions:pop_vlan,tnl_pop(1) recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=bc:97:e1:05:56:50,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=00:03:0f:bb:ce:f4,dst=01:80:c2:00:00:02),eth_type(0x8809), packets:197484, bytes:24488016, used:0.302s, actions:drop recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=e4:3d:1a:dc:48:80,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth(src=bc:97:e1:05:60:70,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth(src=00:03:0f:bb:ce:f4,dst=01:80:c2:00:00:02),eth_type(0x8809), packets:197484, bytes:24488016, used:0.300s, actions:drop recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth(src=e4:3d:1a:dc:4c:01,dst=01:80:c2:00:00:02),eth_type(0x8809), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth(src=e4:3d:1a:dc:48:81,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth(src=76:89:8a:f2:21:4d,dst=02:41:ed:5e:e4:4f),eth_type(0x8100),vlan(vid=1203,pcp=0),encap(eth_type(0x0800),ipv4(dst=10.10.203.11,proto=17,frag=no),udp(dst=6081)), packets:224935, bytes:26992200, used:0.957s, actions:pop_vlan,tnl_pop(1) recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth(src=32:d6:39:8c:36:45,dst=02:41:ed:5e:e4:4f),eth_type(0x8100),vlan(vid=1203,pcp=0),encap(eth_type(0x0800),ipv4(dst=10.10.203.11,proto=17,frag=no),udp(dst=6081)), packets:226197, bytes:27143640, used:0.012s, actions:pop_vlan,tnl_pop(1) recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth(src=bc:97:e1:05:60:91,dst=01:80:c2:00:00:0e),eth_type(0x88cc), packets:0, bytes:0, used:never, actions:drop It seems that they are default flows of LLDP and LACP related frames since there is LACP and LLDP on PFs and switches. I have tried to set other_config : forward-bpdu=true, but it doesn't get rid of those flows, just change the flow action. So they will always return errors of the rte_is_valid_assigned_ether_addr() function. Best regards. On Thu, Feb 16, 2023 at 5:20 AM Ajit Khaparde <ajit.khapa...@broadcom.com> wrote: > Hi, > The PMD has two paths which can parse the RTE_FLOW items, items, etc.. > The path which is returning the error is considered legacy. > The other path is initialized depending on a firmware setting. > Since the NIC you are using is running an older version, the newer > RTE_FLOW offload path is not getting initialized. > > I am trying to get the link to the appropriate FW image for you to > download. > I will share it soon. > > Thanks > Ajit > > On Tue, Feb 14, 2023 at 10:56 PM Lazuardi Nasution <mrxlazuar...@gmail.com> > wrote: > >> Hi Ajit, >> >> Is there any update on this? If it is firmware matter, what is suggested >> firmware for enabling flow offload with OVN? >> >> Best regards. >> >> On Thu, Feb 9, 2023, 12:17 PM Lazuardi Nasution <mrxlazuar...@gmail.com> >> wrote: >> >>> Hi Ajit, >>> >>> I'm using firmware version 219.0.144.0.of >>> >>> I'm not sure that the problem is about the capability of the firmware. >>> By digging the source code of bnxt PMD, it seems that this problem is >>> related to bnxt_validate_and_parse_flow_type() function which throws an >>> error if the destination Ethernet address is broadcast Ethernet address. >>> I'm using the following URL as reference. >>> >>> >>> https://github.com/DPDK/dpdk/blob/v21.11/drivers/net/bnxt/bnxt_flow.c#L228 >>> >>> From what I can understand of David statement, it should not throw an >>> RTE error but just leave an incompatible flow non-offloaded. >>> >>> Best regards. >>> >>> On Thu, Feb 9, 2023 at 12:14 AM Ajit Khaparde < >>> ajit.khapa...@broadcom.com> wrote: >>> >>>> Hi, >>>> From what I can see, it looks like the offload is being attempted on a >>>> card which does not have offload functionality enabled. >>>> Can you share the FW version on the NICs? >>>> >>>> If needed, will it be possible for you to update the firmware on the >>>> NICs? >>>> >>>> For the warning regarding flow control setting, let me check and get >>>> back. >>>> >>>> Thanks >>>> Ajit >>>> >>>> On Wed, Feb 8, 2023 at 4:14 AM Lazuardi Nasution < >>>> mrxlazuar...@gmail.com> wrote: >>>> > >>>> > Hi Ajit, >>>> > >>>> > Have you find the way to overcome this problem? Would you mind to >>>> explain why this reserved Ethernet addresses throw error on offloading the >>>> flows and not just make related flows non-offloaded? >>>> > >>>> > Another think, but not so important is bnxt PMD logs warning about >>>> cannot do flow control on VF even though I have used none, true or false of >>>> interface flow control setting. This warning always appear on OVS >>>> restarting. >>>> > >>>> > Best regards. >>>> > >>>> > On Tue, Feb 7, 2023, 12:21 AM Lazuardi Nasution < >>>> mrxlazuar...@gmail.com> wrote: >>>> >> >>>> >> Hi Ajit, >>>> >> >>>> >> I'm using the following versions. >>>> >> >>>> >> dpdk_version : "DPDK 21.11.2" >>>> >> ovs_version : "3.0.1" >>>> >> >>>> >> Best regards. >>>> >> >>>> >> On Tue, Feb 7, 2023 at 12:12 AM Ajit Khaparde < >>>> ajit.khapa...@broadcom.com> wrote: >>>> >>> >>>> >>> On Mon, Feb 6, 2023 at 9:02 AM Lazuardi Nasution < >>>> mrxlazuar...@gmail.com> wrote: >>>> >>> > >>>> >>> > Hi David, >>>> >>> > >>>> >>> > I think I can understand your opinion. So your target is to >>>> prevent frames with those ethernet addresses from reaching CP, right? FYI, >>>> I'm using bonded VFs of bonded PFs as OVS-DPDK interfaces, so offcourse >>>> LACP should be handled by bonded PFs only. >>>> >>> What is the version of DPDK & OVS used here, BTW? Thanks >>>> >>> >>>> >>> > >>>> >>> > Best regards, >>>> >>> > >>>> >>> > On Mon, Feb 6, 2023 at 11:54 PM David Marchand < >>>> david.march...@redhat.com> wrote: >>>> >>> >> >>>> >>> >> On Mon, Feb 6, 2023 at 5:46 PM Lazuardi Nasution < >>>> mrxlazuar...@gmail.com> wrote: >>>> >>> >> > >>>> >>> >> > HI David, >>>> >>> >> > >>>> >>> >> > Don't you think that offload of reserved Ethernet address >>>> should be disabled by default? >>>> >>> >> >>>> >>> >> What OVN requests in this trace (dropping) makes sense to me if >>>> those >>>> >>> >> lacp frames are to be ignored at the CP level. >>>> >>> >> I don't see why some ethernet address would require some special >>>> >>> >> offloading considerations, but maybe others have a better >>>> opinion on >>>> >>> >> this topic. >>>> >>> >> >>>> >>> >> >>>> >>> >> -- >>>> >>> >> David Marchand >>>> >>> >> >>>> >>>
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
