Re: [ovs-discuss] OVN Failed Flow Offload
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
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
>
Re: [ovs-discuss] OVN Failed Flow Offload
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 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 >
Re: [ovs-discuss] OVN Failed Flow Offload
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
Re: [ovs-discuss] OVN Failed Flow Offload
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 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 > 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 >> 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 >>> 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 >>> >>> >> >>> >> smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN Failed Flow Offload
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 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 > 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 >> 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 >> 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
Re: [ovs-discuss] OVN Failed Flow Offload
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 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 > 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 > 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
Re: [ovs-discuss] OVN Failed Flow Offload
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 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 > 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 >> wrote: >>> >>> On Mon, Feb 6, 2023 at 9:02 AM Lazuardi Nasution >>> 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 >>> > wrote: >>> >> >>> >> On Mon, Feb 6, 2023 at 5:46 PM Lazuardi Nasution >>> >> 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 >>> >> smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN Failed Flow Offload
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 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 > wrote: > >> On Mon, Feb 6, 2023 at 9:02 AM Lazuardi Nasution >> 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
Re: [ovs-discuss] OVN Failed Flow Offload
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 wrote: > On Mon, Feb 6, 2023 at 9:02 AM Lazuardi Nasution > 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
Re: [ovs-discuss] OVN Failed Flow Offload
On Mon, Feb 6, 2023 at 9:02 AM Lazuardi Nasution 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 > wrote: >> >> On Mon, Feb 6, 2023 at 5:46 PM Lazuardi Nasution >> 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 >> smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN Failed Flow Offload
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. Best regards, On Mon, Feb 6, 2023 at 11:54 PM David Marchand wrote: > On Mon, Feb 6, 2023 at 5:46 PM Lazuardi Nasution > 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
Re: [ovs-discuss] OVN Failed Flow Offload
On Mon, Feb 6, 2023 at 5:46 PM Lazuardi Nasution 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
Re: [ovs-discuss] OVN Failed Flow Offload
Hi Ajit, If you think that it should not be offloaded, please suggest the OVS development team for excluding reserved Ethernet addresses from offloading. As far as I know, LLDP Ethernet addresses and other reserved Ethernet addresses should be processed by software (control plane). Best regards. On Mon, Feb 6, 2023 at 11:34 PM Ajit Khaparde wrote: > On Mon, Feb 6, 2023 at 7:36 AM David Marchand > wrote: > > > > Hello, > > > > On Mon, Feb 6, 2023 at 4:16 PM Lazuardi Nasution via discuss > > wrote: > > > > > > Hi, > > > > > > I'm deploying OVN with OVS-DPDK. When I'm trying to offload flows by > using rte_flow, I find the following logs appear every second. How to get > rid those offload incompatible flows warning/error logs? How can I safely > select which offload incompatible flow should not be offloaded? > > > > I don't think there is a way to select offloaded flows in OVN. > > > > > > > > > > > 2023-02-06T15:04:03.588Z|00134|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > rte_flow creation failed: 13 (DMAC is invalid). > > > > 2023-02-06T15:04:03.588Z|00135|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > Failed flow: flow create 3 ingress priority 0 group 0 transfer pattern > eth src is e4:3d:1a:dc:48:80 dst is 01:80:c2:00:00:0e type is 0x88cc > has_vlan is 0 / end actions count / drop / end > > > > 2023-02-06T15:04:03.588Z|00136|dpdk(hw_offload105)|ERR|bnxt_validate_and_parse_flow_type(): > DMAC is invalid! > > > > This flow (for lldp frames) is rejected by the DPDK net/bnxt driver. > > Copying this driver MAINTAINERS, maybe they can give the reason why > > this driver won't accept such destination mac address. > Thanks for bringing this to our attention. > We will take a look at this and get back. > I don't have the answer on the top of my head right now. > > Thanks > Ajit > > > > > > > > -- > > David Marchand > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN Failed Flow Offload
On Mon, Feb 6, 2023 at 7:36 AM David Marchand wrote: > > Hello, > > On Mon, Feb 6, 2023 at 4:16 PM Lazuardi Nasution via discuss > wrote: > > > > Hi, > > > > I'm deploying OVN with OVS-DPDK. When I'm trying to offload flows by using > > rte_flow, I find the following logs appear every second. How to get rid > > those offload incompatible flows warning/error logs? How can I safely > > select which offload incompatible flow should not be offloaded? > > I don't think there is a way to select offloaded flows in OVN. > > > > > > 2023-02-06T15:04:03.588Z|00134|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > > rte_flow creation failed: 13 (DMAC is invalid). > > 2023-02-06T15:04:03.588Z|00135|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > > Failed flow: flow create 3 ingress priority 0 group 0 transfer pattern > > eth src is e4:3d:1a:dc:48:80 dst is 01:80:c2:00:00:0e type is 0x88cc > > has_vlan is 0 / end actions count / drop / end > > 2023-02-06T15:04:03.588Z|00136|dpdk(hw_offload105)|ERR|bnxt_validate_and_parse_flow_type(): > > DMAC is invalid! > > This flow (for lldp frames) is rejected by the DPDK net/bnxt driver. > Copying this driver MAINTAINERS, maybe they can give the reason why > this driver won't accept such destination mac address. Thanks for bringing this to our attention. We will take a look at this and get back. I don't have the answer on the top of my head right now. Thanks Ajit > > > -- > David Marchand > smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN Failed Flow Offload
HI David, Don't you think that offload of reserved Ethernet address should be disabled by default? Best regards. On Mon, Feb 6, 2023 at 10:36 PM David Marchand wrote: > Hello, > > On Mon, Feb 6, 2023 at 4:16 PM Lazuardi Nasution via discuss > wrote: > > > > Hi, > > > > I'm deploying OVN with OVS-DPDK. When I'm trying to offload flows by > using rte_flow, I find the following logs appear every second. How to get > rid those offload incompatible flows warning/error logs? How can I safely > select which offload incompatible flow should not be offloaded? > > I don't think there is a way to select offloaded flows in OVN. > > > > > > > 2023-02-06T15:04:03.588Z|00134|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > rte_flow creation failed: 13 (DMAC is invalid). > > > 2023-02-06T15:04:03.588Z|00135|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > Failed flow: flow create 3 ingress priority 0 group 0 transfer pattern > eth src is e4:3d:1a:dc:48:80 dst is 01:80:c2:00:00:0e type is 0x88cc > has_vlan is 0 / end actions count / drop / end > > > 2023-02-06T15:04:03.588Z|00136|dpdk(hw_offload105)|ERR|bnxt_validate_and_parse_flow_type(): > DMAC is invalid! > > This flow (for lldp frames) is rejected by the DPDK net/bnxt driver. > Copying this driver MAINTAINERS, maybe they can give the reason why > this driver won't accept such destination mac address. > > > -- > David Marchand > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN Failed Flow Offload
Hello, On Mon, Feb 6, 2023 at 4:16 PM Lazuardi Nasution via discuss wrote: > > Hi, > > I'm deploying OVN with OVS-DPDK. When I'm trying to offload flows by using > rte_flow, I find the following logs appear every second. How to get rid those > offload incompatible flows warning/error logs? How can I safely select which > offload incompatible flow should not be offloaded? I don't think there is a way to select offloaded flows in OVN. > > 2023-02-06T15:04:03.588Z|00134|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > rte_flow creation failed: 13 (DMAC is invalid). > 2023-02-06T15:04:03.588Z|00135|netdev_offload_dpdk(hw_offload105)|WARN|dpdkb201: > Failed flow: flow create 3 ingress priority 0 group 0 transfer pattern eth > src is e4:3d:1a:dc:48:80 dst is 01:80:c2:00:00:0e type is 0x88cc has_vlan is > 0 / end actions count / drop / end > 2023-02-06T15:04:03.588Z|00136|dpdk(hw_offload105)|ERR|bnxt_validate_and_parse_flow_type(): > DMAC is invalid! This flow (for lldp frames) is rejected by the DPDK net/bnxt driver. Copying this driver MAINTAINERS, maybe they can give the reason why this driver won't accept such destination mac address. -- David Marchand ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
