Any progress about this case? By the way, is it possible to filter reserved broadcast addresses from being seen by such VF? I'm thinking about something like the following rule, but I know that rule will never work.
ethtool -N ens4f0np0 flow-type ether dst 01:80:c2:00:00:00 m ff:ff:ff:ff:ff:00 vf 1 queue -1 Best regards. On Thu, Feb 16, 2023 at 12:26 PM Lazuardi Nasution <mrxlazuar...@gmail.com> wrote: > 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
