[ovs-dev] Add an new action to insert ip options
Hi, I want to add a new action into OVS which will insert an option field (e.g: timestamp option) into ip header. Because it is a experiment and for simplicity, this action only needs to be performed on userspace. Can you give me some advice on how to do this? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC OVN] DHCP Relay Agent support for overlay subnets
> On 10-Nov-2023, at 10:52 PM, Numan Siddique wrote: > > On Fri, Nov 3, 2023 at 1:36 PM naveen.yerramneni > wrote: >> >>This patch contains changes to enable DHCP Relay Agent support for >> overlay subnets. >> >>NOTE: >>- >> - This patch has required changes to enable basic DHCP Relay >> functionality for overlay subnets. Sending this for review to get the >> initial feedback about the approach taken. >> >>POST RFC REVIEW >> >> 1. Address review comments/suggestions >> 2. Address TODOs >> 3. Add unit tests >> 4. Complete testing >> >>USE CASE: >>-- >> - Enable IP address assignment for overlay subnets from the centralized >> DHCP server present in the underlay network. >> >>PREREQUISITES >>-- >> - Logical Router Port IP should be assigned (statically) from the same >> overlay subnet which is managed by DHCP server. >> - LRP IP is used for GIADRR field when relaying the DHCP packets and >> also same IP needs to be configured as default gateway for the overlay >> subnet. >> - Overlay subnets managed by external DHCP server are expected to be >> directly reachable from the underlay network. >> >>EXPECTED PACKET FLOW: >>-- >>Following is the expected packet flow inorder to support DHCP rleay >> functionality in OVN. >> 1. DHCP client originates DHCP discovery (broadcast). >> 2. DHCP relay (running on the OVN) receives the broadcast and forwards >> the packet to the DHCP server by converting it to unicast. While forwarding >> the packet, it updates the GIADDR in DHCP header to its >> interface IP on which DHCP packet is received. >> 3. DHCP server uses GIADDR field to decide the IP address pool from >> which IP has to be assigned and DHCP offer is sent to the same IP (GIADDR). >> 4. DHCP relay agent forwards the offer to the client, it resets the >> GIADDR field when forwarding the offer to the client. >> 5. DHCP client sends DHCP request (broadcast) packet. >> 6. DHCP relay (running on the OVN) receives the broadcast and forwards >> the packet to the DHCP server by converting it to unicast. While forwarding >> the packet, it updates the GIADDR in DHCP header to its >> interface IP on which DHCP packet is received. >> 7. DHCP Server sends the ACK packet. >> 8. DHCP relay agent forwards the ACK packet to the client, it resets >> the GIADDR field when forwarding the ACK to the client. >> 9. All the future renew/release packets are directly exchanged between >> DHCP client and DHCP server. >> >>OVN DHCP RELAY PACKET FLOW: >> >>To add DHCP Relay support on OVN, we need to replicate all the behavior >> described above using distributed logical switch and logical router. >>At, highlevel packet flow is distributed among Logical Switch and Logical >> Router on source node (where VM is deployed) and redirect chassis(RC) node. >> 1. Request packet gets processed on the source node where VM is >> deployed and relays the packet to DHCP server. >> 2. Response packet is first processed on RC node (which first recieves >> the packet from underlay network). RC node forwards the packet to the right >> node by filling in the dest MAC and IP. >> >>OVN Packet flow with DHCP relay is explained below. >> 1. DHCP client (VM) sends the DHCP discover packet (broadcast). >> 2. Logical switch converts the packet to L2 unicast by setting the >> destination MAC to LRP's MAC >> 3. Logical Router receives the packet and redirects it to the OVN >> controller. >> 4. OVN controller updates the required information(GIADDR) in the DHCP >> payload after doing the required checks. If any check fails, packet is >> dropped. >> 5. Logical Router converts the packet to L3 unicast and forwards it to >> the server. This packets gets routed like any other packet (via RC node). >> 6. Server replies with DHCP offer. >> 7. RC node processes the DHCP offer and forwards it to the OVN >> controller. >> 8. OVN controller does sanity checks and updates the destination MAC >> (available in DHCP header), destination IP (available in DHCP header), >> resets GIADDR and reinjects the packet to datapath. >> If any check fails, packet is dropped. >> 9. Logical router updates the source IP and port and forwards the >> packet to logical switch. >> 10. Logical switch delivers the packet to the DHCP client. >> 11. Similar steps are performed for Request and Ack packets. >> 12. All the future renew/release packets are directly exchanged between >> DHCP client and DHCP server >> >>NEW OVN ACTIONS >>--- >> >> 1. dhcp_relay_req(, ) >> - This action executes on the source node on which the DHCP request >> originated. >> - This action relays the DHCP requ
[ovs-dev] [PATCH v2 2/2] mcast-snooping: Flush flood and report ports when deleting interfaces.
When a configuration change triggers an interface destruction/creation
(like for example, setting ofport_request), a port object may still be
referenced as a fport or a rport in the mdb.
Before the fix, when flooding multicast traffic:
bridge("br0")
-
0. priority 32768
NORMAL
-> forwarding to mcast group port
>> mcast flood port is unknown, dropping
-> mcast flood port is input port, dropping
-> forwarding to mcast flood port
Before the fix, when flooding igmp report traffic:
bridge("br0")
-
0. priority 32768
NORMAL
>> mcast port is unknown, dropping the report
-> forwarding report to mcast flagged port
-> mcast port is input port, dropping the Report
-> forwarding report to mcast flagged port
Add relevant cleanup and update unit tests.
Fixes: 4fbbf8624868 ("mcast-snooping: Flush ports mdb when VLAN configuration
changed.")
Signed-off-by: David Marchand
---
Changes since v1:
- updated the test on report flooding,
---
lib/mcast-snooping.c| 15 +++
tests/mcast-snooping.at | 38 ++
2 files changed, 53 insertions(+)
diff --git a/lib/mcast-snooping.c b/lib/mcast-snooping.c
index 029ca28558..34755447f8 100644
--- a/lib/mcast-snooping.c
+++ b/lib/mcast-snooping.c
@@ -948,6 +948,7 @@ mcast_snooping_flush_bundle(struct mcast_snooping *ms, void
*port)
{
struct mcast_group *g;
struct mcast_mrouter_bundle *m;
+struct mcast_port_bundle *p;
if (!mcast_snooping_enabled(ms)) {
return;
@@ -971,5 +972,19 @@ mcast_snooping_flush_bundle(struct mcast_snooping *ms,
void *port)
}
}
+LIST_FOR_EACH_SAFE (p, node, &ms->fport_list) {
+if (p->port == port) {
+mcast_snooping_flush_port(p);
+ms->need_revalidate = true;
+}
+}
+
+LIST_FOR_EACH_SAFE (p, node, &ms->rport_list) {
+if (p->port == port) {
+mcast_snooping_flush_port(p);
+ms->need_revalidate = true;
+}
+}
+
ovs_rwlock_unlock(&ms->rwlock);
}
diff --git a/tests/mcast-snooping.at b/tests/mcast-snooping.at
index b5474cf392..1ce31168e8 100644
--- a/tests/mcast-snooping.at
+++ b/tests/mcast-snooping.at
@@ -207,6 +207,24 @@ Megaflow:
recirc_id=0,eth,udp,in_port=3,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e
Datapath actions: 1,2
])
+AT_CHECK([ovs-vsctl set interface p2 ofport_request=4])
+
+AT_CHECK([ovs-appctl ofproto/trace
"in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:01:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
[0], [dnl
+Flow:
udp,in_port=3,vlan_tci=0x,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
+
+bridge("br0")
+-
+ 0. priority 32768
+NORMAL
+ -> forwarding to mcast group port
+ -> mcast flood port is input port, dropping
+ -> forwarding to mcast flood port
+
+Final flow: unchanged
+Megaflow:
recirc_id=0,eth,udp,in_port=3,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_dst=224.1.1.1,nw_frag=no
+Datapath actions: 1,2
+])
+
OVS_VSWITCHD_STOP
AT_CLEANUP
@@ -381,6 +399,26 @@ This flow is handled by the userspace slow path because it:
- Uses action(s) not supported by datapath.
])
+AT_CHECK([ovs-vsctl set interface p3 ofport_request=4])
+
+AT_CHECK([ovs-appctl ofproto/trace "in_port(1)"
'01005E010101000C29A027A10800451C00014002CBAEAC10221EE001010112140CE9E0010101'],
[0], [dnl
+Flow:
ip,in_port=1,vlan_tci=0x,dl_src=00:0c:29:a0:27:a1,dl_dst=01:00:5e:01:01:01,nw_src=172.16.34.30,nw_dst=224.1.1.1,nw_proto=2,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=18,tp_dst=20
+
+bridge("br0")
+-
+ 0. priority 32768
+NORMAL
+ -> forwarding report to mcast flagged port
+ -> mcast port is input port, dropping the Report
+ -> forwarding report to mcast flagged port
+
+Final flow: unchanged
+Megaflow:
recirc_id=0,eth,ip,in_port=1,dl_src=00:0c:29:a0:27:a1,dl_dst=01:00:5e:01:01:01,nw_proto=2,nw_frag=no
+Datapath actions: 2,3
+This flow is handled by the userspace slow path because it:
+ - Uses action(s) not supported by datapath.
+])
+
OVS_VSWITCHD_STOP
AT_CLEANUP
--
2.41.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 1/2] mcast-snooping: Test per port explicit flooding.
Various options affect how the mcast snooping module work.
When multicast snooping is enabled and a reporter is known, it is still
possible to flood associated packets to some other port via the
mcast-snooping-flood option.
If flooding unregistered traffic is disabled, it is still possible to
flood multicast traffic too with the mcast-snooping-flood option.
IGMP reports may have to be flooded to some ports explicitly with the
mcast-snooping-flood-reports option.
Test those parameters.
Signed-off-by: David Marchand
---
Changes since v1:
- fixed dest mac address,
- added tests for mcast-snooping-disable-flood-unregistered=true and
mcast-snooping-flood-reports,
---
tests/mcast-snooping.at | 280
1 file changed, 280 insertions(+)
diff --git a/tests/mcast-snooping.at b/tests/mcast-snooping.at
index d5b7c4774c..b5474cf392 100644
--- a/tests/mcast-snooping.at
+++ b/tests/mcast-snooping.at
@@ -105,6 +105,286 @@ AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
OVS_VSWITCHD_STOP
AT_CLEANUP
+
+AT_SETUP([mcast - check multicast per port flooding])
+OVS_VSWITCHD_START([])
+
+AT_CHECK([
+ovs-vsctl set bridge br0 \
+datapath_type=dummy \
+mcast_snooping_enable=true \
+other-config:mcast-snooping-disable-flood-unregistered=false
+], [0])
+
+AT_CHECK([ovs-ofctl add-flow br0 action=normal])
+
+AT_CHECK([
+ovs-vsctl add-port br0 p1 \
+-- set Interface p1 type=dummy other-config:hwaddr=aa:55:aa:55:00:01
ofport_request=1 \
+-- add-port br0 p2 \
+-- set Interface p2 type=dummy other-config:hwaddr=aa:55:aa:55:00:02
ofport_request=2 \
+-- add-port br0 p3 \
+-- set Interface p3 type=dummy other-config:hwaddr=aa:55:aa:55:00:03
ofport_request=3 \
+], [0])
+
+ovs-appctl time/stop
+
+AT_CHECK([ovs-appctl ofproto/trace
"in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:01:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
[0], [stdout])
+AT_CHECK([grep -v 'Datapath actions:' stdout], [0], [dnl
+Flow:
udp,in_port=3,vlan_tci=0x,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
+
+bridge("br0")
+-
+ 0. priority 32768
+NORMAL
+ -> unregistered multicast, flooding
+
+Final flow: unchanged
+Megaflow:
recirc_id=0,eth,udp,in_port=3,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_dst=224.1.1.1,nw_frag=no
+])
+AT_CHECK([sed -ne 's/^Datapath actions: \(.*\)$/\1/p' stdout | tr "," "\n" |
sort -n], [0], [dnl
+1
+2
+100
+])
+
+# send report packets
+AT_CHECK([
+ovs-appctl netdev-dummy/receive p1 \
+
'01005E010101000C29A027A10800451C00014002CBAEAC10221EE001010112140CE9E0010101'
+], [0])
+AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
+ port VLAN GROUPAge
+1 0 224.1.1.1 0
+])
+
+AT_CHECK([ovs-appctl ofproto/trace
"in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:01:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
[0], [dnl
+Flow:
udp,in_port=3,vlan_tci=0x,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
+
+bridge("br0")
+-
+ 0. priority 32768
+NORMAL
+ -> forwarding to mcast group port
+
+Final flow: unchanged
+Megaflow:
recirc_id=0,eth,udp,in_port=3,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_dst=224.1.1.1,nw_frag=no
+Datapath actions: 1
+])
+
+AT_CHECK([ovs-vsctl set port p2 other_config:mcast-snooping-flood=true])
+
+AT_CHECK([ovs-appctl ofproto/trace
"in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:01:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
[0], [dnl
+Flow:
udp,in_port=3,vlan_tci=0x,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
+
+bridge("br0")
+-
+ 0. priority 32768
+NORMAL
+ -> forwarding to mcast group port
+ -> forwarding to mcast flood port
+
+Final flow: unchanged
+Megaflow:
recirc_id=0,eth,udp,in_port=3,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_dst=224.1.1.1,nw_frag=no
+Datapath actions: 1,2
+])
+
+AT_CHECK([ovs-vsctl set port p3 other_config:mcast-snooping-flood=true])
+
+AT_CHECK([ovs-appctl ofproto/trace
"in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:01:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
[0], [dnl
+Flow:
udp,in_port=3,vlan_tci=0x,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:01:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
+
+bridge("br0")
+-
+ 0. priority 32768
+NORMAL
+ -> forwarding to mcast group port
+ -> forwarding to mcast flood port
+ -> mca
Re: [ovs-dev] [RFC OVN] DHCP Relay Agent support for overlay subnets
On Fri, Nov 3, 2023 at 1:36 PM naveen.yerramneni wrote: > > This patch contains changes to enable DHCP Relay Agent support for > overlay subnets. > > NOTE: > - > - This patch has required changes to enable basic DHCP Relay > functionality for overlay subnets. Sending this for review to get the initial > feedback about the approach taken. > > POST RFC REVIEW > > 1. Address review comments/suggestions > 2. Address TODOs > 3. Add unit tests > 4. Complete testing > > USE CASE: > -- > - Enable IP address assignment for overlay subnets from the centralized > DHCP server present in the underlay network. > > PREREQUISITES > -- > - Logical Router Port IP should be assigned (statically) from the same > overlay subnet which is managed by DHCP server. > - LRP IP is used for GIADRR field when relaying the DHCP packets and > also same IP needs to be configured as default gateway for the overlay subnet. > - Overlay subnets managed by external DHCP server are expected to be > directly reachable from the underlay network. > > EXPECTED PACKET FLOW: > -- > Following is the expected packet flow inorder to support DHCP rleay > functionality in OVN. > 1. DHCP client originates DHCP discovery (broadcast). > 2. DHCP relay (running on the OVN) receives the broadcast and forwards > the packet to the DHCP server by converting it to unicast. While forwarding > the packet, it updates the GIADDR in DHCP header to its > interface IP on which DHCP packet is received. > 3. DHCP server uses GIADDR field to decide the IP address pool from > which IP has to be assigned and DHCP offer is sent to the same IP (GIADDR). > 4. DHCP relay agent forwards the offer to the client, it resets the > GIADDR field when forwarding the offer to the client. > 5. DHCP client sends DHCP request (broadcast) packet. > 6. DHCP relay (running on the OVN) receives the broadcast and forwards > the packet to the DHCP server by converting it to unicast. While forwarding > the packet, it updates the GIADDR in DHCP header to its > interface IP on which DHCP packet is received. > 7. DHCP Server sends the ACK packet. > 8. DHCP relay agent forwards the ACK packet to the client, it resets > the GIADDR field when forwarding the ACK to the client. > 9. All the future renew/release packets are directly exchanged between > DHCP client and DHCP server. > > OVN DHCP RELAY PACKET FLOW: > > To add DHCP Relay support on OVN, we need to replicate all the behavior > described above using distributed logical switch and logical router. > At, highlevel packet flow is distributed among Logical Switch and Logical > Router on source node (where VM is deployed) and redirect chassis(RC) node. > 1. Request packet gets processed on the source node where VM is > deployed and relays the packet to DHCP server. > 2. Response packet is first processed on RC node (which first recieves > the packet from underlay network). RC node forwards the packet to the right > node by filling in the dest MAC and IP. > > OVN Packet flow with DHCP relay is explained below. > 1. DHCP client (VM) sends the DHCP discover packet (broadcast). > 2. Logical switch converts the packet to L2 unicast by setting the > destination MAC to LRP's MAC > 3. Logical Router receives the packet and redirects it to the OVN > controller. > 4. OVN controller updates the required information(GIADDR) in the DHCP > payload after doing the required checks. If any check fails, packet is > dropped. > 5. Logical Router converts the packet to L3 unicast and forwards it to > the server. This packets gets routed like any other packet (via RC node). > 6. Server replies with DHCP offer. > 7. RC node processes the DHCP offer and forwards it to the OVN > controller. > 8. OVN controller does sanity checks and updates the destination MAC > (available in DHCP header), destination IP (available in DHCP header), resets > GIADDR and reinjects the packet to datapath. > If any check fails, packet is dropped. > 9. Logical router updates the source IP and port and forwards the > packet to logical switch. > 10. Logical switch delivers the packet to the DHCP client. > 11. Similar steps are performed for Request and Ack packets. > 12. All the future renew/release packets are directly exchanged between > DHCP client and DHCP server > > NEW OVN ACTIONS > --- > > 1. dhcp_relay_req(, ) > - This action executes on the source node on which the DHCP request > originated. > - This action relays the DHCP request coming from client to the > server. Relay-ip is used to update GIADDR in the DHCP header. > 2. dhcp_relay_re
Re: [ovs-dev] [PATCH ovn v2] .gitignore: ignore /compile_commands.json
On 10/31/23 18:33, Ihar Hrachyshka wrote: > This is the standard clang JSON Compilation Database file name, as > documented in: > > https://clang.llvm.org/docs/JSONCompilationDatabase.html#build-system-integration > > FYI the file is used by Language Server Protocol implementations and > other AST tools. > > Signed-off-by: Ihar Hrachyshka > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 7ca9b3859..775bf0f09 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -42,6 +42,7 @@ > /build-arch-stamp > /build-indep-stamp > /compile > +/compile_commands.json > /config.guess > /config.h > /config.h.in Hi Ihar, As discussed offline, this probably fits better into a local gitignore file as I'm guessing you'd need to do this for multiple (all?) repos you contribute to. I'm going to nack the patch for now. Thanks, Dumitru ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2] controller: fixed potential segfault when changing tunnel_key and deleting ls
On 11/3/23 10:38, Ales Musil wrote:
> On Mon, Oct 30, 2023 at 9:46 AM Xavier Simonart wrote:
>
>> When a tunnel_key for a datapath was changed, the local_datapaths hmap was
>> not properly updated
>> as the old/initial entry was not removed.
>> - If the datapath was not deleted at the same time, a new entry (for the
>> same dp) was created
>> in the local_datapaths as the previous entry was not found (wrong hash).
>> - If the datapath was deleted at the same time, the former entry also
>> remained (as, again, the hash
>> was wrong). So, we kept a deleted (dp) entry in the hmap, and might
>> crash when we used it later.
>>
>> When tunnel_key is updated for an existing datapath, we now clean the
>> local_datapaths,
>> removing bad entries (i.e entries for which the hash is not the
>> tunnel_key).
>>
>> This issue was identified by flaky failures of test "ovn-ic -- route
>> deletion upon TS deletion".
>>
>> Backtrace:
>> 0 0x00504a9a in hmap_first_with_hash (hmap=0x20f4d90,
>> hmap@entry=0x5d5634,
>> hmap=0x20f4d90, hmap@entry=0x5d5634, hash=1956414673) at
>> ./include/openvswitch/hmap.h:360
>> 1 smap_find__ (smap=smap@entry=0x20f4d90, key=key@entry=0x5d5634
>> "snat-ct-zone", key_len=key_len@entry=12, hash=1956414673) at
>> lib/smap.c:421
>> 2 0x00505073 in smap_get_node (key=0x5d5634 "snat-ct-zone",
>> smap=0x20f4d90) at lib/smap.c:217
>> 3 smap_get_def (def=0x0, key=0x5d5634 "snat-ct-zone", smap=0x20f4d90) at
>> lib/smap.c:208
>> 4 smap_get (smap=0x20f4d90, key=key@entry=0x5d5634 "snat-ct-zone") at
>> lib/smap.c:200
>> 5 0x00419898 in get_common_nat_zone (ldp=0x20a8c40,
>> ldp=0x20a8c40) at controller/lflow.c:831
>> 6 add_matches_to_flow_table (lflow=lflow@entry=0x21ddf90,
>> ldp=ldp@entry=0x20a8c40,
>> matches=matches@entry=0x211bb50, ptable=ptable@entry=10 '\n',
>> output_ptable=output_ptable@entry=37 '%', ovnacts=ovnacts@entry
>> =0x7ffd19b99de0,
>> ingress=true, l_ctx_in=0x7ffd19b9a300, l_ctx_out=0x7ffd19b9a2c0) at
>> controller/lflow.c:892
>> 7 0x0041a29b in consider_logical_flow__
>> (lflow=lflow@entry=0x21ddf90,
>> dp=0x20eb720, l_ctx_in=l_ctx_in@entry=0x7ffd19b9a300,
>> l_ctx_out=l_ctx_out@entry=0x7ffd19b9a2c0) at controller/lflow.c:1207
>> 8 0x0041a587 in consider_logical_flow (lflow=lflow@entry=0x21ddf90,
>> is_recompute=is_recompute@entry=false,
>> l_ctx_in=l_ctx_in@entry=0x7ffd19b9a300,
>> l_ctx_out=l_ctx_out@entry=0x7ffd19b9a2c0) at controller/lflow.c:1276
>> 9 0x0041e30f in lflow_handle_changed_flows
>> (l_ctx_in=l_ctx_in@entry=0x7ffd19b9a300,
>> l_ctx_out=l_ctx_out@entry=0x7ffd19b9a2c0)
>> at controller/lflow.c:271
>> 10 0x00439fc7 in lflow_output_sb_logical_flow_handler
>> (node=0x7ffd19ba5b70, data=) at
>> controller/ovn-controller.c:4045
>> 11 0x004682fe in engine_compute (recompute_allowed=> out>, node=) at lib/inc-proc-eng.c:441
>> 12 engine_run_node (recompute_allowed=true, node=0x7ffd19ba5b70) at
>> lib/inc-proc-eng.c:503
>> 13 engine_run (recompute_allowed=recompute_allowed@entry=true) at
>> lib/inc-proc-eng.c:528
>> 14 0x0040ade2 in main (argc=, argv=)
>> at controller/ovn-controller.c:5709
>>
>> Signed-off-by: Xavier Simonart
>>
>> ---
>> v2: Fixed potential memory leak.
>> ---
Thanks, Xavier and Ales! A few comments inline.
>> controller/local_data.c | 14 +
>> controller/local_data.h | 4
>> controller/ovn-controller.c | 22 +++
>> tests/ovn.at| 42 +
>> 4 files changed, 82 insertions(+)
>>
>> diff --git a/controller/local_data.c b/controller/local_data.c
>> index 3a7d3afeb..8f0890a14 100644
>> --- a/controller/local_data.c
>> +++ b/controller/local_data.c
>> @@ -56,6 +56,20 @@ static bool datapath_is_transit_switch(const struct
>> sbrec_datapath_binding *);
>>
>> static uint64_t local_datapath_usage;
>>
>> +/* To be used when hmap_node.hash might be wrong e.g. tunnel_key got
>> updated */
>> +struct local_datapath *
>> +get_local_datapath_no_hash(const struct hmap *local_datapaths,
>> +uint32_t tunnel_key)
>> +{
>> +struct local_datapath *ld;
>> +HMAP_FOR_EACH (ld, hmap_node, local_datapaths) {
>> +if (ld->datapath->tunnel_key == tunnel_key) {
>> +return ld;
>> +}
>> +}
>> +return NULL;
>> +}
>> +
>> struct local_datapath *
>> get_local_datapath(const struct hmap *local_datapaths, uint32_t
>> tunnel_key)
>> {
>> diff --git a/controller/local_data.h b/controller/local_data.h
>> index f6d8f725f..a1bf0790b 100644
>> --- a/controller/local_data.h
>> +++ b/controller/local_data.h
>> @@ -69,6 +69,10 @@ struct local_datapath *local_datapath_alloc(
>> const struct sbrec_datapath_binding *);
>> struct local_datapath *get_local_datapath(const struct hmap *,
>>uint32_t tunnel_key);
>> +struct local_datapath
>> +*get_local_datapath_no_hash(const struct hmap *local_datapa
Re: [ovs-dev] [PATCH ovn] northd: forward arp request to lrp snat on.
On 10/24/23 09:39, Daniel Ding wrote:
> If the router has a snat rule and it's external ip isn't lrp address,
> when the arp request from other router for this external ip, will
> be drop, because of this external ip use same mac address as lrp, so
> can not forward to MC_FLOOD.
>
> Fixes: 32f5ebb06226 ("ovn-northd: Limit ARP/ND broadcast domain whenever
> possible.")
> Reported-at: https://github.com/ovn-org/ovn/issues/209
>
> Signed-off-by: Daniel Ding
> ---
Hi Daniel,
Thanks for the patch! I think it makes sense to do what you're
suggesting. The patch itself, however, is malformed.
Could you please use git format-patch and git send-email?
https://github.com/ovn-org/ovn/blob/3bf67405faed9fc5c2d07024b0775e0d363651a6/Documentation/internals/contributing/submitting-patches.rst?plain=1#L90
I fixed the patch formatting so I can apply it locally for review; it
was mostly lines being truncated to shorten their lengths.
> northd/northd.c | 18 +-
> tests/ovn-northd.at | 12
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index e9cb906e2..99fb30f46 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -8974,6 +8974,9 @@ build_lswitch_rport_arp_req_flows(struct ovn_port *op,
> }
> }
>
> +struct sset snat_ips_v4 = SSET_INITIALIZER(&snat_ips_v4);
> +struct sset snat_ips_v6 = SSET_INITIALIZER(&snat_ips_v6);
> +
> for (size_t i = 0; i < op->od->nbr->n_nat; i++) {
> struct ovn_nat *nat_entry = &op->od->nat_entries[i];
> const struct nbrec_nat *nat = nat_entry->nb;
> @@ -8983,7 +8986,17 @@ build_lswitch_rport_arp_req_flows(struct ovn_port
> *op,
> }
>
> if (!strcmp(nat->type, "snat")) {
> -continue;
> +if (nat_entry_is_v6(nat_entry)) {
> +if (sset_contains(&snat_ips_v6, nat->external_ip)) {
> +continue;
> +}
> +sset_add(&snat_ips_v6, nat->external_ip);
> +} else {
> +if (sset_contains(&snat_ips_v4, nat->external_ip)) {
> +continue;
> +}
> +sset_add(&snat_ips_v4, nat->external_ip);
> +}
> }
Can't we just remove the whole if? And not skip all snats?
Regards,
Dumitru
>
> /* Check if the ovn port has a network configured on which we could
> @@ -9025,6 +9038,9 @@ build_lswitch_rport_arp_req_flows(struct ovn_port *op,
> if (sw_od->n_router_ports != sw_od->nbs->n_ports) {
> build_lswitch_rport_arp_req_self_orig_flow(op, 75, sw_od, lflows);
> }
> +
> +sset_destroy(&snat_ips_v4);
> +sset_destroy(&snat_ips_v6);
> }
>
> static void
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index 5c9da811f..953e0d829 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -5084,6 +5084,7 @@ AT_CHECK([grep "ls_in_l2_lkup" ls1_lflows | sed
> 's/table=../table=??/' | sort],
>table=??(ls_in_l2_lkup ), priority=70 , match=(eth.mcast),
> action=(outport = "_MC_flood"; output;)
>table=??(ls_in_l2_lkup ), priority=75 , match=(eth.src ==
> {00:00:00:00:01:01} && (arp.op == 1 || rarp.op == 3 || nd_ns)),
> action=(outport = "_MC_flood_l2"; output;)
>table=??(ls_in_l2_lkup ), priority=80 , match=(flags[[1]] == 0 &&
> arp.op == 1 && arp.tpa == 10.0.0.100), action=(clone {outport = "ls1-ro1";
> output; }; outport = "_MC_flood_l2"; output;)
> + table=??(ls_in_l2_lkup ), priority=80 , match=(flags[[1]] == 0 &&
> arp.op == 1 && arp.tpa == 10.0.0.200), action=(clone {outport = "ls1-ro1";
> output; }; outport = "_MC_flood_l2"; output;)
>table=??(ls_in_l2_lkup ), priority=80 , match=(flags[[1]] == 0 &&
> arp.op == 1 && arp.tpa == 192.168.1.1), action=(clone {outport = "ls1-ro1";
> output; }; outport = "_MC_flood_l2"; output;)
>table=??(ls_in_l2_lkup ), priority=80 , match=(flags[[1]] == 0 &&
> nd_ns && nd.target == fe80::200:ff:fe00:101), action=(clone {outport =
> "ls1-ro1"; output; }; outport = "_MC_flood_l2"; output;)
> ])
> @@ -5098,6 +5099,7 @@ AT_CHECK([grep "ls_in_l2_lkup" ls2_lflows | sed
> 's/table=../table=??/' | sort],
>table=??(ls_in_l2_lkup ), priority=75 , match=(eth.src ==
> {00:00:00:00:02:01} && (arp.op == 1 || rarp.op == 3 || nd_ns)),
> action=(outport = "_MC_flood_l2"; output;)
>table=??(ls_in_l2_lkup ), priority=80 , match=(flags[[1]] == 0 &&
> arp.op == 1 && arp.tpa == 192.168.2.1), action=(clone {outport = "ls2-ro2";
> output; }; outport = "_MC_flood_l2"; output;)
>table=??(ls_in_l2_lkup ), priority=80 , match=(flags[[1]] == 0 &&
> arp.op == 1 && arp.tpa == 20.0.0.100), action=(clone {outport = "ls2-ro2";
> output; }; outport = "_MC_flood_l2"; output;)
> + table=??(ls_in_l2_lkup ), priority=80 , match=(flags[[1]] == 0 &&
> arp.op == 1 && arp.tpa == 20.0.0.200), action=(clone {outport = "ls2-ro2";
> output; }; out
Re: [ovs-dev] [PATCH 1/2] checkpatch.py: Load personal words list.
Roi Dayan writes:
> On 08/11/2023 21:04, Aaron Conole wrote:
>> Roi Dayan via dev writes:
>>
>>> On 02/11/2023 16:11, Eelco Chaudron wrote:
On 2 Nov 2023, at 14:20, Roi Dayan via dev wrote:
> Add personal words list as spellcheck.txt and load it
> into enchant spell checker. This file is generated from
> codespell dictionary.txt and contains words users use
> but enchant spell checker failed on like
> refcount, pthread, enqueuing, etc.
>
> Signed-off-by: Roi Dayan
Thanks for the patch, but it doesn’t look right to add the full list
of words to the OVS repository.
Maybe we can update the extra_keywords list with the most common
missing ones, and add a command line option to include a
user-defined file for people who want this?
What do you think?
>>>
>>> I think it is needed. It's a dictionary of most commonly used words
>>> and the enchant spell check does not seem to be enough.
>>> Some examples enchant fails as I remember are:
>>> lacp, dereferenced, valgrind, priv, syscall,..
>>
>> Well, we do add some of those - BUT I see that codespell probably has a
>> more complete dictionary.
>>
>> The original implementation using enchant was due to there not being a
>> clear winner at the time. Enchant is a spell checking frontend intended
>> for lots of tools, so seemed like a good idea (for example, used by
>> libreoffice, AbiWord, and others).
>>
>> It may be that codepspell is more appropriate since it is targeted at
>> development spell checking. OTOH, codespell will miss lots of
>> misspellings where enchant will have a larger lexicon. I have no real
>> opinion on which framework makes sense - but we shouldn't include a
>> dictionary. After all, even linux checkpatch.pl will find the codespell
>> dictionary and just use that as it exists.
>>
>> However, I will point out that there *is* a difference between the two.
>> Here's a simple example:
>>
>> 02:01:19 aconole@RHTPC1VM0NT {(594d145410...)} ~/git/ovs$ echo vailgrind |
>> codespell -
>> 02:01:24 aconole@RHTPC1VM0NT {(594d145410...)} ~/git/ovs$
>>
>> vs.
>>
>> 02:00:18 aconole@RHTPC1VM0NT {(594d145410...)} ~/git/ovs$
>> ./utilities/checkpatch.py -S test.patch
>> == Checking "test.patch" ==
>> WARNING: Possible misspelled word: "vaigrind"
>> Did you mean: ['grinder', 'valgrind']
>>
>> So I guess we can probably do something better - and maybe that
>> something is to find the codespell dictionary cut it up and merge the
>> values with the current session (instead of add(), ie: 2/2 in this
>> series).
>>
>> But I don't think we need to copy the entire codespell dict.
>>
>
> In linux checkpatch find codespell dictonary.txt, loads it into memory and
> cut on '>' to get the word needed and looks like internal perl code does
> the spell check.
>
> I can do the same here to find codespell dictionary.txt and cut on '>'
> and I get the same dictionary I tried to add here but I need to create
> a temporary file to load it with enchant.DictWithPWL()
>
> As doing a loop of calls to spell_check_dict.add_to_session() seems
> to take a lot longer for the library by far as shown.
>
> Will that be ok?
>
> This is the example diff. I can send as an update patch if its ok.
> Looking for the codespell dictionary as it can be different folder between
> fedora and ubuntu for example.
> Then loading it and creating temporary file to load into enchant which
> is being removed when file is closed.
I think it's a good idea to use the codespell dict, but it turns out we
don't actually need the temp file. I've tested with the add_to_session
patch, and here is my timing output:
09:19:43 aconole@RHTPC1VM0NT {(594d145410...)} ~/git/ovs$ time
./utilities/checkpatch.py -S -1 test.patch
== Checking 594d145410c5 ("readthedocs: Use dirhtml builder.") ==
WARNING: Possible misspelled word: "readthedocs"
Did you mean: ['headteachers']
WARNING: Possible misspelled word: "dirhtml"
Did you mean: ['dirtily']
Subject: readthedocs: Use dirhtml builder.
WARNING: Possible misspelled word: "ReadTheDocs"
Did you mean: ['Headteachers']
Lines checked: 44, Warnings: 3, Errors: 0
real0m0.369s
user0m0.344s
sys 0m0.024s
The difference being that I don't use a tempfile - just your delta above
as:
if codespell_file != '':
with open(codespell_file) as f:
for line in f.readlines():
words = line.strip().split('>')[1].strip(', ').split(',')
for word in words:
spell_check_dict.add_to_session(word)
Of course, looks like we would want to add other things like readthedocs,
dirhtml, etc. Or possibly skip checking words that are proper nouns
(like ReadTheDocs would be). Codespell ignores words it doesn't have a
correction / suggestion for, while enchant will assume something it
doesn't know is misspelled. This makes it so we will flag more often.
WDYT?
> --- a/utilities/che
Re: [ovs-dev] [PATCH 2/2] checkpatch: Fix personal word list storage.
Roi Dayan writes:
> On 08/11/2023 20:50, Aaron Conole wrote:
>> Eelco Chaudron writes:
>>
>>> On 2 Nov 2023, at 14:20, Roi Dayan via dev wrote:
>>>
From: Gaetan Rivet
The enchant dictionary synchronizes additions to the source file.
Keep the two word source separate by adding the extra words only
to the current session.
Signed-off-by: Gaetan Rivet
Acked-by: Roi Dayan
---
utilities/checkpatch.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index 9276640760d4..b484a37db2e8 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -95,7 +95,7 @@ def open_spell_check_dict():
'dictionary.txt')
spell_check_dict = enchant.DictWithPWL('en_US', word_dic)
for kw in extra_keywords:
-spell_check_dict.add(kw)
+spell_check_dict.add_to_session(kw)
>>>
>>> I guess this should be the first patch (or maybe a fixes patch in general).
>>
>> +1 - I would be fine with merging this on its own.
>>
>
> ok. is it possible to take only this one from the series or I need
> to send it again on its own?
Yes - I will take this patch on Monday.
return True
except:
--
2.40.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/2] mcast-snooping: Test per port explicit flooding.
David Marchand writes:
> On Thu, Nov 9, 2023 at 4:33 PM Paolo Valerio wrote:
>>
>> David Marchand writes:
>>
>> > When multicast snooping is enabled and a reporter is known, it is still
>> > possible to flood associated packets to some other port via the
>> > mcast-snooping-flood option.
>> >
>> > Test this combination.
>> >
>> > Signed-off-by: David Marchand
>> > ---
>> > tests/mcast-snooping.at | 88 +
>> > 1 file changed, 88 insertions(+)
>> >
>> > diff --git a/tests/mcast-snooping.at b/tests/mcast-snooping.at
>> > index d5b7c4774c..21c806ef63 100644
>> > --- a/tests/mcast-snooping.at
>> > +++ b/tests/mcast-snooping.at
>> > @@ -105,6 +105,94 @@ AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
>> > OVS_VSWITCHD_STOP
>> > AT_CLEANUP
>> >
>> > +
>> > +AT_SETUP([mcast - check flooding on ports])
>> > +OVS_VSWITCHD_START([])
>> > +
>> > +AT_CHECK([
>> > +ovs-vsctl set bridge br0 \
>> > +datapath_type=dummy \
>> > +mcast_snooping_enable=true \
>> > +other-config:mcast-snooping-disable-flood-unregistered=false
>> > +], [0])
>> > +
>>
>> in the case flood unregistered is disabled packets are supposed to
>> be sent to flood ports. While at it, it might also be worth testing that
>> like in the quick example at the end I used to test it.
>> WDYT?
>
> It sounds reasonable yes.
>
> I was also considering testing reports flooding.
> WDYT?
>
if you mean testing mcast-snooping-flood-reports, that would be nice.
This way that flag as well will have some coverage.
>
>>
>> > +AT_CHECK([ovs-ofctl add-flow br0 action=normal])
>> > +
>> > +AT_CHECK([
>> > +ovs-vsctl add-port br0 p1 \
>> > +-- set Interface p1 type=dummy other-config:hwaddr=aa:55:aa:55:00:01
>> > ofport_request=1 \
>> > +-- add-port br0 p2 \
>> > +-- set Interface p2 type=dummy other-config:hwaddr=aa:55:aa:55:00:02
>> > ofport_request=2 \
>> > +-- add-port br0 p3 \
>> > +-- set Interface p3 type=dummy other-config:hwaddr=aa:55:aa:55:00:03
>> > ofport_request=3 \
>> > +], [0])
>> > +
>> > +ovs-appctl time/stop
>> > +
>> > +# send report packets
>> > +AT_CHECK([
>> > +ovs-appctl netdev-dummy/receive p1 \
>> > +
>> > '01005E010101000C29A027A10800451C00014002CBAEAC10221EE001010112140CE9E0010101'
>> > +], [0])
>> > +
>> > +AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
>> > + port VLAN GROUPAge
>> > +1 0 224.1.1.1 0
>> > +])
>> > +
>> > +AT_CHECK([ovs-appctl ofproto/trace
>> > "in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:5e:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
>> > [0], [dnl
>> > +Flow:
>> > udp,in_port=3,vlan_tci=0x,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:5e:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
>> > +
>>
>> I think the mac for 224.1.1.1 maps to 01:00:5e:01:01:01.
>
> Argh.. indeed, wrong copy/paste.
> Thanks for the review!
>
thank you for working on this!
>>
>> > +bridge("br0")
>> > +-
>> > + 0. priority 32768
>> > +NORMAL
>> > + -> forwarding to mcast group port
>
>
> --
> David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/2] mcast-snooping: Test per port explicit flooding.
On Thu, Nov 9, 2023 at 4:33 PM Paolo Valerio wrote:
>
> David Marchand writes:
>
> > When multicast snooping is enabled and a reporter is known, it is still
> > possible to flood associated packets to some other port via the
> > mcast-snooping-flood option.
> >
> > Test this combination.
> >
> > Signed-off-by: David Marchand
> > ---
> > tests/mcast-snooping.at | 88 +
> > 1 file changed, 88 insertions(+)
> >
> > diff --git a/tests/mcast-snooping.at b/tests/mcast-snooping.at
> > index d5b7c4774c..21c806ef63 100644
> > --- a/tests/mcast-snooping.at
> > +++ b/tests/mcast-snooping.at
> > @@ -105,6 +105,94 @@ AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
> > OVS_VSWITCHD_STOP
> > AT_CLEANUP
> >
> > +
> > +AT_SETUP([mcast - check flooding on ports])
> > +OVS_VSWITCHD_START([])
> > +
> > +AT_CHECK([
> > +ovs-vsctl set bridge br0 \
> > +datapath_type=dummy \
> > +mcast_snooping_enable=true \
> > +other-config:mcast-snooping-disable-flood-unregistered=false
> > +], [0])
> > +
>
> in the case flood unregistered is disabled packets are supposed to
> be sent to flood ports. While at it, it might also be worth testing that
> like in the quick example at the end I used to test it.
> WDYT?
It sounds reasonable yes.
I was also considering testing reports flooding.
WDYT?
>
> > +AT_CHECK([ovs-ofctl add-flow br0 action=normal])
> > +
> > +AT_CHECK([
> > +ovs-vsctl add-port br0 p1 \
> > +-- set Interface p1 type=dummy other-config:hwaddr=aa:55:aa:55:00:01
> > ofport_request=1 \
> > +-- add-port br0 p2 \
> > +-- set Interface p2 type=dummy other-config:hwaddr=aa:55:aa:55:00:02
> > ofport_request=2 \
> > +-- add-port br0 p3 \
> > +-- set Interface p3 type=dummy other-config:hwaddr=aa:55:aa:55:00:03
> > ofport_request=3 \
> > +], [0])
> > +
> > +ovs-appctl time/stop
> > +
> > +# send report packets
> > +AT_CHECK([
> > +ovs-appctl netdev-dummy/receive p1 \
> > +
> > '01005E010101000C29A027A10800451C00014002CBAEAC10221EE001010112140CE9E0010101'
> > +], [0])
> > +
> > +AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
> > + port VLAN GROUPAge
> > +1 0 224.1.1.1 0
> > +])
> > +
> > +AT_CHECK([ovs-appctl ofproto/trace
> > "in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:5e:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
> > [0], [dnl
> > +Flow:
> > udp,in_port=3,vlan_tci=0x,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:5e:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
> > +
>
> I think the mac for 224.1.1.1 maps to 01:00:5e:01:01:01.
Argh.. indeed, wrong copy/paste.
Thanks for the review!
>
> > +bridge("br0")
> > +-
> > + 0. priority 32768
> > +NORMAL
> > + -> forwarding to mcast group port
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
