Hi Lazuardi, I tried to read the rest of the thread again. And I don't see a need to offload multicast packet handling to start with. I thought if HW offload is disabled we should not be seeing any offload request.
Anyways, you can try the attached patch and tell me if it helps -
diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index 8bdf2405f0..7514246bc5 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -227,7 +227,8 @@ bnxt_validate_and_parse_flow_type(struct bnxt *bp,
if (rte_is_broadcast_ether_addr(ð_mask->dst)) {
dst = ð_spec->dst;
- if (!rte_is_valid_assigned_ether_addr(dst)) {
+ if (!rte_is_valid_assigned_ether_addr(dst) ||
+ !rte_is_multicast_ether_addr(dst)) {
rte_flow_error_set(error,
EINVAL,
RTE_FLOW_ERROR_TYPE_ITEM,
Thanks
Ajit
On Wed, Feb 15, 2023 at 9: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
>>>>> >>> >>
accept_mcast_addr.patch
Description: Binary data
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
