Re: [ovs-dev] [PATCH v1 ovn 0/1] Forwarding group to load balance l2 traffic with liveness detection
Thank you for the review Numan. On 1/8/20, 11:14 PM, "Numan Siddique" wrote: Hi Manoj, Thanks for the patch. I didn't look into the complete patch. I have initial few comments. The patch fails to compile when --enable-Werror and --enable-sparse are enabled during configuration. I sent the v2 that has the fix for the compilation issue. Can you please include the description in Patch 0 in the actual patch commit message ? The commit message in the patch doesn't have much details. Done In your above description, does the logical switch (with logical ports lsp1 and lsp2) has a localnet port ? It does not matter if the switch has localnet port or not. You are only putting the logical switch ports in an openflow group so that traffic can be load balanced across them. I am confused how the packet goes out of the logical switch to the external network ? Does lsp1 and lsp2 bound to any VM/VIF ? From the test case you have written I see that lsp21 and lsp22 are part of forward group and they have VIF ports as well. So the packet destined to the VIP will be delivered to one of the VIF ? And the VIF/VM takes care of sending the traffic to external routers ? We can model an external router as an OVN chassis. For HA, you will need more than one external router and bind the lsp1 and lsp2 to these chassis (lsp1 <> chassis1, lsp2 <> chassis2). If we want to load balance across these external routers then just send the traffic to the VIP. Since I also wanted to include --liveness in the unit tests, I put the VIFs, bound to lsp1 and lsp2, on different hypervisors so that there is a tunnel interface from the source hypervisor to these two VIFs. For liveness, you need BFD running on the tunnel interface. Thanks, Manoj ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 ovn 1/3] Forwarding group to load balance l2 traffic with liveness detection
Bleep bloop. Greetings Manoj Sharma, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 149 characters long (recommended limit is 79)
#125 FILE: utilities/ovn-nbctl.8.xml:489:
[--liveness]fwd-group-add group
switch vip vmac ports
WARNING: Line is 85 characters long (recommended limit is 79)
#146 FILE: utilities/ovn-nbctl.8.xml:510:
[--if-exists] fwd-group-del
group
WARNING: Line lacks whitespace around operator
#172 FILE: utilities/ovn-nbctl.c:653:
fwd-group-add GROUP SWITCH VIP VMAC PORTS...\n\
WARNING: Line lacks whitespace around operator
#174 FILE: utilities/ovn-nbctl.c:655:
fwd-group-del GROUP delete a forwarding group\n\
WARNING: Line lacks whitespace around operator
#175 FILE: utilities/ovn-nbctl.c:656:
fwd-group-list [SWITCH] print forwarding groups\n\
ERROR: Improper whitespace around control block
#196 FILE: utilities/ovn-nbctl.c:4742:
NBREC_FORWARDING_GROUP_FOR_EACH(fwd_group, ctx->idl) {
ERROR: Improper whitespace around control block
#392 FILE: utilities/ovn-nbctl.c:4938:
NBREC_FORWARDING_GROUP_FOR_EACH(fwd_group, ctx->idl) {
Lines checked: 443, Warnings: 5, Errors: 2
Please check this out. If you feel there has been an error, please email
acon...@redhat.com
Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 ovn 3/3] Forwarding group to load balance l2 traffic with liveness detection
Unit tests for forwarding group Signed-off-by: Manoj Sharma --- tests/ovn-nbctl.at | 37 tests/ovn.at | 124 + 2 files changed, 161 insertions(+) diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at index 2679f1f..077c41e 100644 --- a/tests/ovn-nbctl.at +++ b/tests/ovn-nbctl.at @@ -1735,6 +1735,43 @@ $SW1P2 AT_CHECK([ovn-nbctl pg-del pg1], [0], [ignore]) AT_CHECK([ovn-nbctl list port_group], [0], []) ]) +dnl - + +OVN_NBCTL_TEST([ovn_nbctl_fwd_groups], [fwd groups], [ + +dnl Add fwd-group to a non-existent logical switch +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2], [1], [], + [ovn-nbctl: ls0: switch name not found +]) + +AT_CHECK([ovn-nbctl ls-add ls0]) + +dnl Add fwd-group with non-existent logical switch ports +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2], [1], [], + [ovn-nbctl: lsp1: logical switch port does not exist +]) + +AT_CHECK([ovn-nbctl lsp-add ls0 lsp1]) +AT_CHECK([ovn-nbctl lsp-add ls0 lsp2]) +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2]) +AT_CHECK([ovn-nbctl fwd-group-list ls0], [0], [dnl +FWD_GROUP LSVIP VMAC CHILD_PORTS +fwd_grp1ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2 +]) +AT_CHECK([ovn-nbctl --bare --columns=name list forwarding_group], [0], +[fwd_grp1 +]) + +dnl Add duplicate fwd-group +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2], [1], [], + [ovn-nbctl: fwd_grp1: a forwarding group by this name already exists +]) + +dnl Delete fwd-group +AT_CHECK([ovn-nbctl fwd-group-del fwd_grp1], [0], [ignore]) +AT_CHECK([ovn-nbctl list forwarding_group], [0], []) + +]) AT_SETUP([ovn-nbctl - daemon retry connection]) OVN_NBCTL_TEST_START daemon diff --git a/tests/ovn.at b/tests/ovn.at index 411b768..b8e8eba 100644 --- a/tests/ovn.at +++ b/tests/ovn.at @@ -17338,3 +17338,127 @@ OVS_WAIT_UNTIL([ OVN_CLEANUP([hv1]) AT_CLEANUP + +AT_SETUP([ovn -- forwarding group: 3 HVs, 1 LR, 2 LS]) +AT_KEYWORDS([forwarding-group]) +ovn_start + +# Logical network: +# One LR - R1 has a logical switch ls1 and ls2 connected to it. +# Logical switch ls1 has one port while ls2 has two logical switch ports as +# child ports. +ovn-nbctl lr-add R1 +ovn-nbctl ls-add ls1 +ovn-nbctl ls-add ls2 + +# Logical switch ls1 to R1 connectivity +ovn-nbctl lrp-add R1 R1-ls1 00:00:00:01:02:f1 192.168.1.1/24 +ovn-nbctl lsp-add ls1 ls1-R1 -- set Logical_Switch_Port ls1-R1 \ +type=router options:router-port=R1-ls1 -- lsp-set-addresses ls1-R1 router +ovn-nbctl lsp-add ls1 lsp11 \ +-- lsp-set-addresses lsp11 "00:00:00:01:02:01 192.168.1.2" + +# Logical switch ls2 to R1 connectivity +ovn-nbctl lrp-add R1 R1-ls2 00:00:00:01:02:f2 172.16.1.1/24 +ovn-nbctl lsp-add ls2 ls2-R1 -- set Logical_Switch_Port ls2-R1 \ +type=router options:router-port=R1-ls2 -- lsp-set-addresses ls2-R1 router +ovn-nbctl lsp-add ls2 lsp21 \ +-- lsp-set-addresses lsp21 "00:00:00:01:02:01 172.16.1.2" +ovn-nbctl lsp-add ls2 lsp22 \ +-- lsp-set-addresses lsp22 "00:00:00:01:02:02 172.16.1.3" + +# Create a network +net_add n1 + +# Create hypervisor hv1 connected to n1 +sim_add hv1 +as hv1 +ovs-vsctl add-br br-phys +ovn_attach n1 br-phys 192.168.0.1 +ovs-vsctl add-port br-int vif1 -- set Interface vif1 external-ids:iface-id=lsp11 options:tx_pcap=hv1/vif1-tx.pcap options:rxq_pcap=hv1/vif1-rx.pcap ofport-request=1 + +# Create hypervisor hv2 connected to n1 +sim_add hv2 +as hv2 +ovs-vsctl add-br br-phys +ovn_attach n1 br-phys 192.168.0.2 +ovs-vsctl add-port br-int vif2 -- set Interface vif2 external-ids:iface-id=lsp21 options:tx_pcap=hv2/vif2-tx.pcap options:rxq_pcap=hv2/vif2-rx.pcap ofport-request=1 + +# Create hypervisor hv3 connected to n1 +sim_add hv3 +as hv3 +ovs-vsctl add-br br-phys +ovn_attach n1 br-phys 192.168.0.3 +ovs-vsctl add-port br-int vif3 -- set Interface vif3 external-ids:iface-id=lsp22 options:tx_pcap=hv3/vif3-tx.pcap options:rxq_pcap=hv3/vif3-rx.pcap ofport-request=1 + +# Add a forwarding group on ls2 with lsp21 and lsp22 as child ports +# virtual IP - 172.16.1.11, virtual MAC - 00:11:de:ad:be:ef +ovn-nbctl fwd-group-add fwd_grp1 ls2 172.16.1.11 00:11:de:ad:be:ef lsp21 lsp22 + +# Allow some time for ovn-northd and ovn-controller to catch up. +sleep 1 + +# Check logical flow +AT_CHECK([ovn-sbctl dump-flows | grep ls_in_l2_lkup | grep fwd_group | wc -l], [0], [dnl +1 +]) + +# Check openflow rule with "group" on hypervisor +AT_CHECK([as hv1 ovs-ofctl dump-flows br-int | \ +grep "dl_dst=00:11:de:ad:be:ef actions=group" | wc -l], [0], [dnl +1 +]) + +# Verify openflow group members +for child_port in lsp21 lsp22; do +tunnel_key=`ovn-sbctl --bare --column tunnel_key find port_binding logical_port=$child_port` +AT_CHECK([as hv1 ovs-ofctl
[ovs-dev] [PATCH v2 ovn 1/3] Forwarding group to load balance l2 traffic with liveness detection
Add a forwarding group table and a reference to the logical switch it is
configured on. The forwarding group is configured with a virtual IP, virtual
MAC and a number of logical switch ports from a logical switch.
Signed-off-by: Manoj Sharma
---
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
utilities/ovn-nbctl.8.xml | 37 +++
utilities/ovn-nbctl.c | 253 ++
4 files changed, 341 insertions(+), 2 deletions(-)
diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 12999a4..99b6285 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
"version": "5.18.0",
-"cksum": "2806349485 24196",
+"cksum": "63300136 24879",
"tables": {
"NB_Global": {
"columns": {
@@ -59,7 +59,12 @@
"min": 0, "max": "unlimited"}},
"external_ids": {
"type": {"key": "string", "value": "string",
- "min": 0, "max": "unlimited"}}},
+ "min": 0, "max": "unlimited"}},
+ "forwarding_groups": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Forwarding_Group",
+ "refType": "strong"},
+ "min": 0, "max": "unlimited"}}},
"isRoot": true},
"Logical_Switch_Port": {
"columns": {
@@ -113,6 +118,15 @@
"min": 0, "max": "unlimited"}}},
"indexes": [["name"]],
"isRoot": false},
+"Forwarding_Group": {
+"columns": {
+"name": {"type": "string"},
+"vip": {"type": "string"},
+"vmac": {"type": "string"},
+"liveness": {"type": "boolean"},
+"child_port": {"type": {"key": "string",
+"min": 1, "max": "unlimited"}}},
+"isRoot": false},
"Address_Set": {
"columns": {
"name": {"type": "string"},
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 5ae52bb..decb4ae 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -197,6 +197,11 @@
Please see the table.
+
+ Groups a set of logical port endpoints for traffic going out of the
+ logical switch.
+
+
These columns provide names for the logical switch. From OVN's
@@ -1152,6 +1157,36 @@
+
+
+ Each row represents one forwarding group.
+
+
+
+ A name for the forwarding group. This name has no special meaning or
+ purpose other than to provide convenience for human interaction with
+ the ovn-nb database.
+
+
+
+ The virtual IP address assigned to the forwarding group. It will respond
+ with vmac when an ARP request is sent for vip.
+
+
+
+ The virtual MAC address assigned to the forwarding group.
+
+
+
+ If set to true, liveness is enabled for child ports
+ otherwise it is disabled.
+
+
+
+ List of child ports in the forwarding group.
+
+
+
Each row in this table represents a named set of addresses.
diff --git a/utilities/ovn-nbctl.8.xml b/utilities/ovn-nbctl.8.xml
index 88ebd13..2f3badd 100644
--- a/utilities/ovn-nbctl.8.xml
+++ b/utilities/ovn-nbctl.8.xml
@@ -483,6 +483,43 @@
+Forwarding Group Commands
+
+
+ [--liveness]fwd-group-add group
switch vip vmac ports
+
+
+ Creates a new forwarding group named group as the name
+ with the provided vip and vmac. vip
+ should be a virtual IP address and vmac should be a
+ virtual MAC address to access the forwarding group. ports
+ are the logical switch port names that are put in the forwarding
+ group. Example for ports is lsp1 lsp2 ...
+ Traffic destined to virtual IP of the forwarding group will be load
+ balanced to all the child ports.
+
+
+ When --liveness is specified then child ports are
+ expected to be bound to external devices like routers. BFD should
+ be configured between hypervisors and the external devices.
+ The child port selection will become dependent on BFD status with
+ its external device.
+
+
+
+ [--if-exists] fwd-group-del
group
+
+Deletes group. It is an error if group does
+not exist, unless --if-exists is specified.
+
+
+ fwd-group-list [switch]
+
+Lists all existing forwarding groups, If switch is specified
+then only the forwarding groups configured for switch will
+be listed.
+
+
Logical Router Commands
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index 46ba3a9..39f53da 100644
---
[ovs-dev] [PATCH v2 ovn 2/3] Forwarding group to load balance l2 traffic with liveness detection
Add forwarding group support for a logical switch. It will add a new OVN
action "fwd_group" with a virtual IP and virtual MAC. Any number of logical
switch ports of this switch can be added to this forwarding group.
If traffic has to be load balanced across these logical switch ports then
traffic should be sent to forwarding group's virtual IP.
If the logical switch ports correspond to tunnel interfaces and BFD
can be enabled on these tunnel interfaces, then liveness can be enabled
for the forwarding group so that if any of the tunnel is down then
the corresponding logical switch port will not be selected during
load balancing.
Signed-off-by: Manoj Sharma
---
controller/lflow.c| 20 +
controller/physical.c | 13 ++
controller/physical.h | 4 ++
include/ovn/actions.h | 19 +++-
lib/actions.c | 122 ++
northd/ovn-northd.c | 63 ++
utilities/ovn-trace.c | 3 ++
7 files changed, 243 insertions(+), 1 deletion(-)
diff --git a/controller/lflow.c b/controller/lflow.c
index a689320..49dfa06 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -103,6 +103,25 @@ lookup_port_cb(const void *aux_, const char *port_name,
unsigned int *portp)
return false;
}
+/* Given the OVN port name, get its openflow port */
+static bool
+tunnel_ofport_cb(const void *aux_, const char *port_name, ofp_port_t *ofport)
+{
+const struct lookup_port_aux *aux = aux_;
+
+const struct sbrec_port_binding *pb
+= lport_lookup_by_name(aux->sbrec_port_binding_by_name, port_name);
+if (!pb || (pb->datapath != aux->dp) || !pb->chassis) {
+return false;
+}
+
+if (!get_tunnel_ofport(pb->chassis->name, NULL, ofport)) {
+return false;
+}
+
+return true;
+}
+
static bool
is_chassis_resident_cb(const void *c_aux_, const char *port_name)
{
@@ -681,6 +700,7 @@ consider_logical_flow(
struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
struct ovnact_encode_params ep = {
.lookup_port = lookup_port_cb,
+.tunnel_ofport = tunnel_ofport_cb,
.aux = ,
.is_switch = is_switch(ldp),
.group_table = group_table,
diff --git a/controller/physical.c b/controller/physical.c
index 500d419..af1d10f 100644
--- a/controller/physical.c
+++ b/controller/physical.c
@@ -1794,3 +1794,16 @@ physical_run(struct ovsdb_idl_index
*sbrec_port_binding_by_name,
simap_destroy(_tunnel_to_ofport);
}
+
+bool
+get_tunnel_ofport(const char *chassis_name, char *encap_ip, ofp_port_t *ofport)
+{
+struct chassis_tunnel *tun = NULL;
+tun = chassis_tunnel_find(chassis_name, encap_ip);
+if (!tun) {
+return false;
+}
+
+*ofport = tun->ofport;
+return true;
+}
diff --git a/controller/physical.h b/controller/physical.h
index c93f6b1..c0e17cd 100644
--- a/controller/physical.h
+++ b/controller/physical.h
@@ -72,4 +72,8 @@ void physical_handle_mc_group_changes(
const struct simap *ct_zones,
const struct hmap *local_datapaths,
struct ovn_desired_flow_table *);
+bool get_tunnel_ofport(
+const char *chassis_name,
+char *encap_ip,
+ofp_port_t *ofport);
#endif /* controller/physical.h */
diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index 047a8d7..2d39239 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -89,7 +89,8 @@ struct ovn_extend_table;
OVNACT(CHECK_PKT_LARGER, ovnact_check_pkt_larger) \
OVNACT(TRIGGER_EVENT, ovnact_controller_event) \
OVNACT(BIND_VPORT,ovnact_bind_vport) \
-OVNACT(HANDLE_SVC_CHECK, ovnact_handle_svc_check)
+OVNACT(HANDLE_SVC_CHECK, ovnact_handle_svc_check) \
+OVNACT(FWD_GROUP, ovnact_fwd_group)
/* enum ovnact_type, with a member OVNACT_ for each action. */
enum OVS_PACKED_ENUM ovnact_type {
@@ -359,6 +360,15 @@ struct ovnact_handle_svc_check {
struct expr_field port; /* Logical port name. */
};
+/* OVNACT_FWD_GROUP. */
+struct ovnact_fwd_group {
+struct ovnact ovnact;
+bool liveness;
+char **child_ports; /* Logical ports */
+size_t n_child_ports;
+uint8_t ltable; /* Logical table ID of next table. */
+};
+
/* Internal use by the helpers below. */
void ovnact_init(struct ovnact *, enum ovnact_type, size_t len);
void *ovnact_put(struct ofpbuf *, enum ovnact_type, size_t len);
@@ -620,6 +630,13 @@ struct ovnact_encode_params {
* '*portp' and returns true; otherwise, returns false. */
bool (*lookup_port)(const void *aux, const char *port_name,
unsigned int *portp);
+
+/* Looks up tunnel port to a chassis by its port name. If found, stores
+ * its openflow port number in '*ofport' and returns true;
+ * otherwise, returns false. */
+bool (*tunnel_ofport)(const void *aux, const char *port_name,
+ ofp_port_t *ofport);
+
const void *aux;
[ovs-dev] [PATCH v2 ovn 0/3] Forwarding group to load balance l2 traffic with liveness detection
A forwarding group is an aggregation of logical switch ports of a
logical switch to load balance traffic across the ports. It also detects
the liveness if the logical switch ports are realized as OVN tunnel ports
on the physical topology.
In the below logical topology diagram, the logical switch has two ports
connected to chassis / external routers R1 and R2. The logical router needs
to send traffic to an external network that is connected through R1 and R2.
++
+--+ R1 |*
/ ++ ** **
+--++--+ / lsp1 * *
| Logical || Logical|/ * External *
| Router ++ switch X* Network *
| || |\ * *
+--++--+ \ lsp2 * *
^ \ ++ ** **
| +--+ R2 |*
| ++
fwd_group -> (lsp1, lsp2)
In the absence of forwarding group, the logical router will have unicast
route to point to either R1 or R2. In case of R1 or R2 going down, it will
require control plane's intervention to update the route to point to proper
nexthop.
With forwarding group, a virtual IP (VIP) and virtual MAC (VMAC) address
are configured on the forwarding group. The logical router points to the
forwarding group's VIP as the nexthop for hosts behind R1 and R2.
[root@fwd-group]# ovn-nbctl fwd-group-add fwd ls1 VIP_1 VMAC_1 lsp1 lsp2
[root@fwd-group]# ovn-nbctl fwd-group-list
UUIDFWD_GROUP VIPVMAC CHILD_PORTS
UUID_1fwd VIP_1 VMAC_1 lsp1 lsp2
[root@fwd-group]# ovn-nbctl lr-route-list lr1
IPv4 Routes
external_host_prefix/prefix_lenVIP_1 dst-ip
The logical switch will install an ARP responder rule to reply with VMAC
as the MAC address for ARP requests for VIP. It will also install a MAC
lookup rule for VMAC with action to load balance across the logical switch
ports of the forwarding group.
Datapath: "ls1" Pipeline: ingress
table=10(ls_in_arp_rsp ), priority=50 , match=(arp.tpa == VIP_1 &&
arp.op == 1), action=(eth.dst = eth.src; eth.src = VMAC_1; arp.op = 2;
/* ARP reply */ arp.tha = arp.sha; arp.sha = VMAC_1; arp.tpa = arp.spa;
arp.spa = VIP; outport = inport; flags.loopback = 1; output;)
table=13(ls_in_l2_lkup ), priority=50 , match=(eth.dst == VMAC_1),
action=(fwd_group("lsp1","lsp2");)
In the physical topology, OVN managed hypervisors are connected to R1 and
R2 through overlay tunnels. The logical flow's "fwd_group" action mentioned
above, gets translated to openflow group type "select" with one bucket for
each logical switch port.
cookie=0x0, duration=16.869s, table=29, n_packets=4, n_bytes=392, idle_age=0,
priority=111,metadata=0x9,dl_dst=VMAC_1 actions=group:1
group_id=1,type=select,selection_method=dp_hash,
bucket=actions=load:0x2->NXM_NX_REG15[0..15], resubmit(,32),
bucket=actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)
where 0x2 and 0x3 are port tunnel keys of lsp1 and lsp2.
The openflow group type "select" with selection method "dp_hash" load
balances traffic based on source and destination Ethernet address, VLAN ID,
Ethernet type, IPv4/v6 source and destination address and protocol, and for
TCP and SCTP only, the source and destination ports.
To detect path failure between OVN managed hypervisors and (R1, R2), BFD is
enabled on the tunnel interfaces. The openflow group is modified to include
watch_port for liveness detection of a port.
group_id=1,type=select,selection_method=dp_hash,
bucket=watch_port:31,actions=load:0x2->NXM_NX_REG15[0..15],resubmit(,32),
bucket=watch_port:32,actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)
Where 31 and 32 are ovs port numbers for the tunnel interfaces connecting
to R1 and R2.
If the BFD forwarding status is down for any of the tunnels, the
corresponding bucket will not be selected for packet forwarding.
Manoj Sharma (3):
Schema changes for adding forwarding_group table and new ovn-nbctl commands
Changes to add flow in the logical switch as well as in the ovn controller
Unit tests for forwarding group
controller/lflow.c| 20
controller/physical.c | 13 +++
controller/physical.h | 4 +
include/ovn/actions.h | 19 +++-
lib/actions.c | 122 ++
northd/ovn-northd.c | 63
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
tests/ovn-nbctl.at| 37 +++
tests/ovn.at | 124 +++
utilities/ovn-nbctl.8.xml | 37 +++
utilities/ovn-nbctl.c | 253
[ovs-dev] Is this d...@openvswitch.org still active?
I have tried to email this your d...@openvswitch.org account severally but I got no response, Please get back to me at your earliest convenience if you receive this email. Sincerely, Nelson Corey ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVN release-related dates
Hi, OVS has entered soft freeze, and OVN should follow suit since we want to make the first release of standalone OVN (2020.03.0) at the same time as OVS 2.13.0. We had a discussion during the IRC OVN meeting yesterday and the developers present were receptive to declaring soft freeze on January 20 and hard freeze on February 1. "Soft freeze" means that any new features that we wish to put in OVN 2020.03.0 should have a review posted before then. During the soft freeze period, we can merge these features into the master branch. On January 20, I'll post another message to this list about the soft freeze starting. Once hard freeze hits, we will create the branch for the release and begin testing. This means we will not be accepting any new features at this point. We can, of course, fix bugs that are found during testing. We will then release OVN 2020.03.0 in March, approximately the same time as OVS 2.13.0. If we can actually coordinate a simultaneous release, that would be nice, but I don't think it's a requirement. If you have any objections to the dates laid out in this e-mail, please speak up. AFAIK, this should give plenty of time for us to get remaining features merged and test before release. Thanks Mark Michelson ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Are you interested in this Investment Opportunity??
Dear Sir/Ma, I am a financial consultant willing to invest large sum of money in your credible business. Ready to fund Corporate, private and individual projects. The terms are very flexible and interesting. Kindly revert back if you have projects we can invest substantial amount of money on. Regards Derek Langston ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 2/2] Refactor physical module functions to take context argument - physical_ctx.
From: Numan Siddique
No functional changes are introduced in this patch.
Signed-off-by: Numan Siddique
---
controller/ovn-controller.c | 185 ++--
controller/physical.c | 126 +++-
controller/physical.h | 46 -
3 files changed, 144 insertions(+), 213 deletions(-)
diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
index 4942df6c4..390057ee2 100644
--- a/controller/ovn-controller.c
+++ b/controller/ovn-controller.c
@@ -1213,6 +1213,68 @@ struct ed_type_flow_output {
struct lflow_resource_ref lflow_resource_ref;
};
+static void init_physical_ctx(struct engine_node *node,
+ struct ed_type_runtime_data *rt_data,
+ struct ovn_desired_flow_table *flow_table,
+ struct physical_ctx *p_ctx)
+{
+struct ovsdb_idl_index *sbrec_port_binding_by_name =
+engine_ovsdb_node_get_index(
+engine_get_input("SB_port_binding", node),
+"name");
+
+struct sbrec_multicast_group_table *multicast_group_table =
+(struct sbrec_multicast_group_table *)EN_OVSDB_GET(
+engine_get_input("SB_multicast_group", node));
+
+struct sbrec_port_binding_table *port_binding_table =
+(struct sbrec_port_binding_table *)EN_OVSDB_GET(
+engine_get_input("SB_port_binding", node));
+
+struct sbrec_chassis_table *chassis_table =
+(struct sbrec_chassis_table *)EN_OVSDB_GET(
+engine_get_input("SB_chassis", node));
+
+struct ed_type_mff_ovn_geneve *ed_mff_ovn_geneve =
+engine_get_input_data("mff_ovn_geneve", node);
+
+struct ovsrec_open_vswitch_table *ovs_table =
+(struct ovsrec_open_vswitch_table *)EN_OVSDB_GET(
+engine_get_input("OVS_open_vswitch", node));
+struct ovsrec_bridge_table *bridge_table =
+(struct ovsrec_bridge_table *)EN_OVSDB_GET(
+engine_get_input("OVS_bridge", node));
+const struct ovsrec_bridge *br_int = get_br_int(bridge_table, ovs_table);
+const char *chassis_id = chassis_get_id();
+const struct sbrec_chassis *chassis = NULL;
+struct ovsdb_idl_index *sbrec_chassis_by_name =
+engine_ovsdb_node_get_index(
+engine_get_input("SB_chassis", node),
+"name");
+if (chassis_id) {
+chassis = chassis_lookup_by_name(sbrec_chassis_by_name, chassis_id);
+}
+
+ovs_assert(br_int && chassis);
+
+struct ed_type_ct_zones *ct_zones_data =
+engine_get_input_data("ct_zones", node);
+struct simap *ct_zones = _zones_data->current;
+
+p_ctx->sbrec_port_binding_by_name = sbrec_port_binding_by_name;
+p_ctx->port_binding_table = port_binding_table;
+p_ctx->mc_group_table = multicast_group_table;
+p_ctx->br_int = br_int;
+p_ctx->chassis_table = chassis_table;
+p_ctx->chassis = chassis;
+p_ctx->flow_table = flow_table;
+p_ctx->active_tunnels = _data->active_tunnels;
+p_ctx->local_datapaths = _data->local_datapaths;
+p_ctx->local_lports = _data->local_lports;
+p_ctx->ct_zones = ct_zones;
+p_ctx->mff_ovn_geneve = ed_mff_ovn_geneve->mff_ovn_geneve;
+}
+
static void init_lflow_ctx(struct engine_node *node,
struct ed_type_runtime_data *rt_data,
struct ed_type_flow_output *fo,
@@ -1317,17 +1379,6 @@ en_flow_output_run(struct engine_node *node, void *data)
{
struct ed_type_runtime_data *rt_data =
engine_get_input_data("runtime_data", node);
-struct hmap *local_datapaths = _data->local_datapaths;
-struct sset *local_lports = _data->local_lports;
-struct sset *active_tunnels = _data->active_tunnels;
-
-struct ed_type_ct_zones *ct_zones_data =
-engine_get_input_data("ct_zones", node);
-struct simap *ct_zones = _zones_data->current;
-
-struct ed_type_mff_ovn_geneve *ed_mff_ovn_geneve =
-engine_get_input_data("mff_ovn_geneve", node);
-enum mf_field_id mff_ovn_geneve = ed_mff_ovn_geneve->mff_ovn_geneve;
struct ovsrec_open_vswitch_table *ovs_table =
(struct ovsrec_open_vswitch_table *)EN_OVSDB_GET(
@@ -1367,37 +1418,15 @@ en_flow_output_run(struct engine_node *node, void *data)
lflow_resource_clear(lfrr);
}
-struct ovsdb_idl_index *sbrec_port_binding_by_name =
-engine_ovsdb_node_get_index(
-engine_get_input("SB_port_binding", node),
-"name");
-
*conj_id_ofs = 1;
struct lflow_ctx l_ctx;
init_lflow_ctx(node, rt_data, fo, _ctx);
lflow_run(_ctx);
-struct sbrec_multicast_group_table *multicast_group_table =
-(struct sbrec_multicast_group_table *)EN_OVSDB_GET(
-engine_get_input("SB_multicast_group", node));
-
-struct sbrec_port_binding_table *port_binding_table =
-(struct sbrec_port_binding_table *)EN_OVSDB_GET(
-
[ovs-dev] [PATCH ovn 1/2] Refactor lflow functions to take one context argument - lflow_ctx.
From: Numan Siddique
Presently most of the lflow_*() functions called from ovn-controller.c
takes lots of arguments. This patch adds 'struct lflow_ctx' to simplify
the code a bit. This also reduces some code in ovn-controller.c and
improves readability to some degree.
No functional changes are introduced in this patch.
Signed-off-by: Numan Siddique
---
controller/lflow.c | 255 ++--
controller/lflow.h | 83
controller/ovn-controller.c | 240 -
3 files changed, 186 insertions(+), 392 deletions(-)
diff --git a/controller/lflow.c b/controller/lflow.c
index a6893201e..311f8e2be 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -61,25 +61,12 @@ struct condition_aux {
const struct sset *active_tunnels;
};
-static bool consider_logical_flow(
-struct ovsdb_idl_index *sbrec_multicast_group_by_name_datapath,
-struct ovsdb_idl_index *sbrec_port_binding_by_name,
-const struct sbrec_logical_flow *,
-const struct hmap *local_datapaths,
-const struct sbrec_chassis *,
-struct hmap *dhcp_opts,
-struct hmap *dhcpv6_opts,
-struct hmap *nd_ra_opts,
-struct controller_event_options *controller_event_opts,
-const struct shash *addr_sets,
-const struct shash *port_groups,
-const struct sset *active_tunnels,
-const struct sset *local_lport_ids,
-struct ovn_desired_flow_table *,
-struct ovn_extend_table *group_table,
-struct ovn_extend_table *meter_table,
-struct lflow_resource_ref *lfrr,
-uint32_t *conj_id_ofs);
+static bool
+consider_logical_flow(struct lflow_ctx *l_ctx,
+ const struct sbrec_logical_flow *lflow,
+ struct hmap *dhcp_opts, struct hmap *dhcpv6_opts,
+ struct hmap *nd_ra_opts,
+ struct controller_event_options *controller_event_opts);
static bool
lookup_port_cb(const void *aux_, const char *port_name, unsigned int *portp)
@@ -257,30 +244,15 @@ lflow_resource_destroy_lflow(struct lflow_resource_ref
*lfrr,
/* Adds the logical flows from the Logical_Flow table to flow tables. */
static void
-add_logical_flows(
-struct ovsdb_idl_index *sbrec_multicast_group_by_name_datapath,
-struct ovsdb_idl_index *sbrec_port_binding_by_name,
-const struct sbrec_dhcp_options_table *dhcp_options_table,
-const struct sbrec_dhcpv6_options_table *dhcpv6_options_table,
-const struct sbrec_logical_flow_table *logical_flow_table,
-const struct hmap *local_datapaths,
-const struct sbrec_chassis *chassis,
-const struct shash *addr_sets,
-const struct shash *port_groups,
-const struct sset *active_tunnels,
-const struct sset *local_lport_ids,
-struct ovn_desired_flow_table *flow_table,
-struct ovn_extend_table *group_table,
-struct ovn_extend_table *meter_table,
-struct lflow_resource_ref *lfrr,
-uint32_t *conj_id_ofs)
+add_logical_flows(struct lflow_ctx *l_ctx)
{
const struct sbrec_logical_flow *lflow;
struct hmap dhcp_opts = HMAP_INITIALIZER(_opts);
struct hmap dhcpv6_opts = HMAP_INITIALIZER(_opts);
const struct sbrec_dhcp_options *dhcp_opt_row;
-SBREC_DHCP_OPTIONS_TABLE_FOR_EACH (dhcp_opt_row, dhcp_options_table) {
+SBREC_DHCP_OPTIONS_TABLE_FOR_EACH (dhcp_opt_row,
+ l_ctx->dhcp_options_table) {
dhcp_opt_add(_opts, dhcp_opt_row->name, dhcp_opt_row->code,
dhcp_opt_row->type);
}
@@ -288,7 +260,7 @@ add_logical_flows(
const struct sbrec_dhcpv6_options *dhcpv6_opt_row;
SBREC_DHCPV6_OPTIONS_TABLE_FOR_EACH (dhcpv6_opt_row,
- dhcpv6_options_table) {
+ l_ctx->dhcpv6_options_table) {
dhcp_opt_add(_opts, dhcpv6_opt_row->name, dhcpv6_opt_row->code,
dhcpv6_opt_row->type);
}
@@ -299,16 +271,9 @@ add_logical_flows(
struct controller_event_options controller_event_opts;
controller_event_opts_init(_event_opts);
-SBREC_LOGICAL_FLOW_TABLE_FOR_EACH (lflow, logical_flow_table) {
-if (!consider_logical_flow(sbrec_multicast_group_by_name_datapath,
- sbrec_port_binding_by_name,
- lflow, local_datapaths,
- chassis, _opts, _opts,
- _ra_opts, _event_opts,
- addr_sets, port_groups,
- active_tunnels, local_lport_ids,
- flow_table, group_table, meter_table,
- lfrr, conj_id_ofs)) {
+SBREC_LOGICAL_FLOW_TABLE_FOR_EACH (lflow, l_ctx->logical_flow_table) {
+if (!consider_logical_flow(l_ctx, lflow, _opts, _opts,
+ _ra_opts, _event_opts)) {
static struct
[ovs-dev] Ventas fuera de su horario laboral
Miércoles 12 de Febrero | Horario de 10:00 a 14:00 hrs. | (hora del centro de México) - ¿Cómo aumentar tus ventas con Whatsapp Business? - ¿De qué hablaremos? Aprende a vender por la aplicación más usada del mundo utilizando herramientas digitales que aumentarán tu conversión actual de leads. Es el momento de darle un giro a tu negocio o empresa, crea contenido, diseños y videos profesionales para enamorar a tus prospectos. ¡Haz que tus ejecutivos de venta VENDAN por WhatsApp fuera de su horario laboral! ¿Qué aprenderás?: - WhatsApp cómo poderosa herramienta de ventas. - Errores comunes al utilizar WhatsApp cómo herramienta de marketing. - Atención al cliente como estrategia de fidelización. - Robot en Whatsapp Business Solicita información respondiendo a este correo con la palabra WhatsApp junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Dirigido a: Gerente y ejecutivos de ventas. Emprendedores, comerciantes y todo aquel que quiera conocer herramientas tecnológicas para impulsar sus ventas. Números de Atención: (045) 55 15 54 66 30 - (045) 55 85567293 - (045) 5530167085 En caso de que haya recibido este correo sin haberlo solicitado o si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas@ innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly
Hi Yun, On Fri, Jan 10, 2020 at 3:10 AM taoyunxi...@cmss.chinamobile.com < taoyunxi...@cmss.chinamobile.com> wrote: > > Hi Han, >Thanks for your reply. I agree with your following comment 1. For the comment 2, I think Ben' s patch will make "UUID" and "name" be similar, I don't know the reason for summit this patch, I have comment for that patch in another email. > Ben's patch "Allow OVSDB clients to specify the UUID for inserted rows" was initially intended for DDlog's use case to reduce memory footprint in DDlog. However, I think it is very useful for many other OVSDB clients, such as networking-ovn. With this feature, clients doesn't need to store a mapping between its own objects and the rows in OVSDB, either by storing the its own ID in external-ids, or by saving the mapping in its own DB. Instead, clients can generate the object uuid and tell OVSDB to use the same uuid as the row uuid. I feel it is also the feature you are looking for to solve the efficiency of QoS operations. I agree that you will need some work in networking-ovn to benefit from this feature. >Enventually, If we use Ben's patch to record mappings between OVN and Neutron,we may also need to finish two jobs: > 1. A patch to make QoS could be search by UUID, which not supported now, has finished in my patch 2. For read/update/delete operations, OVSDB already supports directly using uuid to identify a row, and all the ovs/ovn-xxctl tools supports this (see man page of any ctl tool, e.g. man ovn-nbctl, in section "Database Commands"). So even without any change, users are able to operating any records using uuid. However, I agree that it is more user-friendly if we add the support of operations on uuid to the QoS related commands. And also, specifying uuid when creating a row is not yet supported by the ctl tools (I have mentioned it in the code review, and I think it should be an easy task to add it). > 2. Alter the methods which has used "name" to record the mappings . Do you mean in OVN or in Neutron networking-ovn? In general I don't think we need to alter any existing methods, because they will just continue to work. I agree that we will need some work in networking-ovn to benefit from this feature, as an optimization, such as for QoS operations. And eventually we may convert other operations in networking-ovn to benefit from this feature, if needed. Before this feature can be used by networking-ovn, probably the first thing to do is to update the python ovsdbapp to support specifying uuid when creating a record. > > What do you think? :) > > Thanks, > Yun > > > I agree with you that it is more efficient to delete with an ID instead of searching based on fields. I think we need to consider below two factors: > > 1. If the new "name" column is supposed to uniquely identify a row, it is better to add the "index" constraint in the schema for this new column, to avoid duplicated names. > > 2. Ben recently worked on the new feature of OVSDB to make it allows client to specify row uuid when creating a row [0]. If this patch is merged, we don't need a "name" column to uniquely identify a row any more. I'd> prefer to utilize this new feature and to avoid adding new "name" columns for individual tables. Do you think this is helpful? > > [0] https://patchwork.ozlabs.org/patch/1220644/ > > > From: Han Zhou > Date: 2020-01-10 12:03 > To: taoyunxi...@cmss.chinamobile.com > CC: ovs-dev > Subject: Re: Re: [ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly > Sorry for the late reply. Please see my response below. > > On Wed, Jan 8, 2020 at 5:16 PM taoyunxi...@cmss.chinamobile.com < taoyunxi...@cmss.chinamobile.com> wrote: > > > > Hi Han, > > If you have time, Could you review this patch or give a response. > > > > > > Thanks , > > Yun > > > > > > > > From: taoyunxi...@cmss.chinamobile.com > > Date: 2019-12-24 19:55 > > To: Han Zhou > > CC: ovs-dev > > Subject: Re: Re: [ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly > > Hi Han, > > Thanks for your review! > > > > 1. As for point 1 and point 4, I think it is not bad to use external_ids to record association between Neutron and OVN, even we can record LS info also. But it is not directly and clearly. > > Actually, I find almost resource tables have "name" column, included ACL table, which summited by this patch[0]. The purpose of adding "name" for ACL, is also to make ACL rule could be easily find and check in OVN. > > Ok, the name column of ACL table was added for the logging purpose, but I agree with you it can be used the way you intended to. > > > > > 2. As for point 2, I am agreed, but do not know how to do now. > > There are several ways. > Option1: Keep the old command and add a new command for deleting by name. > Option2: Add an option to the old command such as "--by-name" to delete by name. > Option3:
Re: [ovs-dev] 答复: 答复: 答复: [PATCH] socket-util: Introduce emulation and wrapper for recvmmsg().
> OK. I applied both patches to master. Thank you! Hi, Ben. These patches broke OSX build: https://travis-ci.org/openvswitch/ovs/jobs/634863662 lib/socket-util.c:1294:31: error: use of undeclared identifier 'MSG_WAITFORONE' bool waitforone = flags & MSG_WAITFORONE; ^ lib/socket-util.c:1295:15: error: use of undeclared identifier 'MSG_WAITFORONE' flags &= ~MSG_WAITFORONE; ^ Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovs-dev v3] dpif-netdev: Allow to set max capacity of flow on netdev.
On 10.01.2020 03:16, Tonghao Zhang wrote: > On Fri, Jan 10, 2020 at 2:04 AM Ben Pfaff wrote: >> >> On Thu, Jan 09, 2020 at 04:14:10PM +0100, Ilya Maximets wrote: >>> On 09.01.2020 08:36, xiangxia.m@gmail.com wrote: From: Tonghao Zhang For installing more than MAX_FLOWS (65536) flows to netdev datapath. Add the ovs-appctl subcommand "dpif-netdev/pmd-set-max-flow" which can change the flow number which netdev datapath support. Signed-off-by: Tonghao Zhang >>> >>> Hi. >>> >>> I'm wondering why we need the flow limit on the datapath level at all? >>> >>> MAX_FLOWS constant was there from the introduction of dpif-netdev, >>> however, later new flow-limit mechanism was implemented that >>> controls number of datapath flows in a dynamic way on ofproto level. >>> >>> So, maybe we can just remove the limit and fully rely on ofproto >>> to decide what flow limit we need? There are no limitations for >>> flow table size in dpif-netdev beside the artificial one. >>> 'other_config:flow-limit' seems suitable to control this. >>> >>> Ben, what do you think? >> >> Hmm, that's a good point. >> >> Tonghao, do you have a good reason to want to limit flows at this level? > Hi Ben, as I explained, we don't use the ofproto layer, and use the > ovs-appctl to install flow and > offload them to hardware. so the "other_config:flow-limit" and > "should_install_flow" function is called > when upcall install the rules, and can't limit it in dpcls layer as I > know. I am not sure installing rule via ovs-appctl > is welcome. As far as I understand, revalidators will start flow eviction if flow-limit is reached while dumping datapath flows. So, you should start seeing flow deletion events if you'll reach ~200K flows installed in dpif-netdev. Anyway, why you need a flow limit on datapath level if you're managing them in so tricky way? Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS-DPDK public meeting
Next meeting Jan 22nd 1700 UTC (Ian will run meeting - may be cancelled if no agenda) January 8th minutes Attendees: David, Flavio, Ilya, Johann, Malvika, Aaron, Simon, Ian, Kevin. - OVS 2.13 Release -- Feature Freeze is 17th January http://docs.openvswitch.org/en/latest/internals/release-process/#release-scheduling -- Planned Release Feb ~15th - Features/bugs -- Balance-tcp bond mode optimization https://mail.openvswitch.org/pipermail/ovs-dev/2020-January/366586.html -- Full HWOL Support --- A few patches don't work as expected, but major arch work is done --- Should be in shape over next week -- TSO --- Flavio will send new version (sent) --- Ciara has tested --- Issue with TSO & i40e - resolved with DPDK master fix -- QoS RFC 4115 egress policer --- Requires experimental DPDK API in DPDK 19.11 --- API seems stable, so probably DPDK can promote to non-experimental --- Build warning may be worked around with allow_experimental 19.11.1 -- Ian will inquire if the above issues can be resolved in an early DPDK 19.11.1 On 25/07/2017 14:25, Kevin Traynor wrote: > Hi All, > > The OVS-DPDK public meetings have moved to Wednesday's at the same time. > Everyone is welcome, it's a chance to share status/plans etc. > > It's scheduled for every 2 weeks starting 26th July. Meeting time is > currently @ 4pm UTC. > > You can connect through Bluejeans or through dial in: > > https://bluejeans.com/139318596 > > US: +1.408.740.7256 > UK: +44.203.608.5256 > Germany: +49.32.221.091256 > Ireland: +353.1.697.1256 > Other numbers at https://www.bluejeans.com/numbers > Meeting ID: 139318596 > > thanks, > Kevin. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] Fix the travis CI compilation error seen for osx job
On Fri, Jan 10, 2020 at 6:44 PM Lorenzo Bianconi
wrote:
>
> On Fri, Jan 10, 2020 at 1:25 PM wrote:
> >
> > From: Numan Siddique
> >
> > After the commit [1], travis CI job for osx [2] is failing with the below
> > error:
> >
> > *
> > In file included from lib/actions.c:25:
> > ./lib/ovn-l7.h:246:9: error: 'ND_OPT_ROUTE_INFO' macro redefined
> > [-Werror,-Wmacro-redefined]
> > ^
> > /usr/include/netinet/icmp6.h:329:9: note: previous definition is here
> > *
> >
>
> Acked-by: Lorenzo Bianconi
Thanks Lorenzo. I applied this patch to master.
Numan
>
> > This patch renames the macro ND_OPT_ROUTE_INFO to ND_OPT_ROUTE_INFO_TYPE as
> > this macro
> > is used to set the Route Information Option Type.
> >
> > [1] - 9f7f466af("Add support for Route Info Option in RA - RFC 4191")
> > [2] -
> > https://travis-ci.org/ovn-org/ovn/jobs/634833728?utm_medium=notification_source=github_status
> >
> > Fixes- 9f7f466af("Add support for Route Info Option in RA - RFC 4191")
> > CC: Lorenzo Bianconi
> > Signed-off-by: Numan Siddique
> > ---
> > controller/pinctrl.c | 2 +-
> > lib/ovn-l7.h | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> > index c4752c673..452ca8a1c 100644
> > --- a/controller/pinctrl.c
> > +++ b/controller/pinctrl.c
> > @@ -2486,7 +2486,7 @@ packet_put_ra_route_info_opt(struct dp_packet *b,
> > ovs_be32 lifetime,
> > for (t1 = strtok_r(t0, "-", ), index = 0; t1;
> > t1 = strtok_r(NULL, "-", ), index++) {
> >
> > -nd_rinfo.type = ND_OPT_ROUTE_INFO;
> > +nd_rinfo.type = ND_OPT_ROUTE_INFO_TYPE;
> > nd_rinfo.route_lifetime = lifetime;
> >
> > switch (index) {
> > diff --git a/lib/ovn-l7.h b/lib/ovn-l7.h
> > index ae6dbfdfb..375b77014 100644
> > --- a/lib/ovn-l7.h
> > +++ b/lib/ovn-l7.h
> > @@ -243,10 +243,10 @@ struct ovs_nd_dnssl {
> > BUILD_ASSERT_DECL(ND_DNSSL_OPT_LEN == sizeof(struct ovs_nd_dnssl));
> >
> > /* Route Information option RFC 4191 */
> > -#define ND_OPT_ROUTE_INFO 24
> > +#define ND_OPT_ROUTE_INFO_TYPE 24
> > #define ND_ROUTE_INFO_OPT_LEN8
> > struct ovs_nd_route_info {
> > -u_int8_t type; /* ND_OPT_ROUTE_INFO */
> > +u_int8_t type; /* ND_OPT_ROUTE_INFO_TYPE */
> > u_int8_t len; /* 1, 2 or 3 */
> > u_int8_t prefix_len;
> > u_int8_t flags;
> > --
> > 2.24.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
Re: [ovs-dev] [PATCH v3 0/3] Add support for TSO with DPDK
> -Original Message- > From: Flavio Leitner > Sent: Thursday 9 January 2020 14:45 > To: d...@openvswitch.org > Cc: Stokes, Ian ; Loftus, Ciara > ; Ilya Maximets ; > yangy...@inspur.com; Flavio Leitner > Subject: [PATCH v3 0/3] Add support for TSO with DPDK > > Abbreviated as TSO, TCP Segmentation Offload is a feature which enables > the network stack to delegate the TCP segmentation to the NIC reducing > the per packet CPU overhead. > > A guest using vhost-user interface with TSO enabled can send TCP packets > much bigger than the MTU, which saves CPU cycles normally used to break > the packets down to MTU size and to calculate checksums. > > It also saves CPU cycles used to parse multiple packets/headers during > the packet processing inside virtual switch. > > If the destination of the packet is another guest in the same host, then > the same big packet can be sent through a vhost-user interface skipping > the segmentation completely. However, if the destination is not local, > the NIC hardware is instructed to do the TCP segmentation and checksum > calculation. > > The first 2 patches are not really part of TSO support, but they are > required to make sure everything works. > > There are good improvements sending to or receiving from veth pairs or > tap devices as well. See the iperf3 results below: > > [*] veth with ethtool tx off. > > VM sending to: Default Enabled >Local BR 859 Mbits/sec 9.23 Gbits/sec >Net NS (veth) 965 Mbits/sec[*] 9.74 Gbits/sec >VM (same host)2.54 Gbits/sec 22.4 Gbits/sec >Ext Host 10.3 Gbits/sec 35.0 Gbits/sec I performed some similar tests. I recorded the following improvements in throughput: VM -> VM (same host): +5.4x VM -> Ext Host: +3.8x I tested VM -> Ext Host for both MT27800 (ConnectX-5) and a XL710 (Fortville) NICs. The result above was measured for the XL710. Two things to note when testing with an i40e NIC: 1. The following patch is required for DPDK, which fixes an issue on the TSO path: http://git.dpdk.org/next/dpdk-next-net/commit/?id=b2a4dc260139409c539fb8e7f1b9d0a5182cfd2b 2. For optimal performance, ensure the IRQs of the queue being used by the iperf server are pinned to their own core, as opposed to the same core as the server process, which appears to be the default behavior. I intend on submitting a follow up patch which documents the above. Tested-by: Ciara Loftus Thanks, Ciara >Ext Host (vxlan) 8.77 Gbits/sec (not supported) > > Using VLAN: >Local BR 877 Mbits/sec 9.49 Gbits/sec >VM (same host)2.35 Gbits/sec 23.3 Gbits/sec >Ext Host 5.84 Gbits/sec 34.6 Gbits/sec > > Using IPv6: >Net NS (veth) 937 Mbits/sec[*] 9.32 Gbits/sec >VM (same host)2.53 Gbits/sec 21.1 Gbits/sec >Ext Host 8.66 Gbits/sec 37.7 Gbits/sec > > Conntrack: >No packet changes: 1.41 Gbits/sec33.1 Gbits/sec > > VM receiving from: >Local BR 221 Mbits/sec 220 Mbits/sec >Net NS (veth) 221 Mbits/sec[*] 5.91 Gbits/sec >VM (same host)4.79 Gbits/sec 22.2 Gbits/sec >Ext Host 10.6 Gbits/sec 10.7 Gbits/sec >Ext Host (vxlan) 5.82 Gbits/sec (not supported) > > Using VLAN: >Local BR 223 Mbits/sec 219 Mbits/sec >VM (same host)4.21 Gbits/sec 24.1 Gbits/sec >Ext Host 10.3 Gbits/sec 10.2 Gbits/sec > > Using IPv6: >Net NS (veth) 217 Mbits/sec[*] 9.32 Gbits/sec >VM (same host)4.26 Gbits/sec 23.3 Gbits/sec >Ext Host 9.99 Gbits/sec 10.1 Gbits/sec > > Used iperf3 -u to test UDP traffic limited at default 1Mbits/sec > and noticed no change with the exception for tunneled packets (not > supported). > > Travis, AppVeyor, and Cirrus-ci passed. > > Flavio Leitner (3): > dp-packet: preserve headroom when cloning a pkt batch > vhost: Disable multi-segmented buffers > netdev-dpdk: Add TCP Segmentation Offload support > > Documentation/automake.mk | 1 + > Documentation/topics/dpdk/index.rst | 1 + > Documentation/topics/dpdk/tso.rst | 96 + > NEWS| 1 + > lib/automake.mk | 2 + > lib/conntrack.c | 29 ++- > lib/dp-packet.h | 158 +- > lib/ipf.c | 32 +-- > lib/netdev-dpdk.c | 318 > lib/netdev-linux-private.h | 4 + > lib/netdev-linux.c | 296 +++--- > lib/netdev-provider.h | 10 + > lib/netdev.c| 66 +- > lib/tso.c | 54 + > lib/tso.h | 23 ++ > vswitchd/bridge.c | 2 + > vswitchd/vswitch.xml| 12 ++ > 17 files changed, 1013 insertions(+), 92
Re: [ovs-dev] [PATCH ovn] Fix the travis CI compilation error seen for osx job
On Fri, Jan 10, 2020 at 1:25 PM wrote:
>
> From: Numan Siddique
>
> After the commit [1], travis CI job for osx [2] is failing with the below
> error:
>
> *
> In file included from lib/actions.c:25:
> ./lib/ovn-l7.h:246:9: error: 'ND_OPT_ROUTE_INFO' macro redefined
> [-Werror,-Wmacro-redefined]
> ^
> /usr/include/netinet/icmp6.h:329:9: note: previous definition is here
> *
>
Acked-by: Lorenzo Bianconi
> This patch renames the macro ND_OPT_ROUTE_INFO to ND_OPT_ROUTE_INFO_TYPE as
> this macro
> is used to set the Route Information Option Type.
>
> [1] - 9f7f466af("Add support for Route Info Option in RA - RFC 4191")
> [2] -
> https://travis-ci.org/ovn-org/ovn/jobs/634833728?utm_medium=notification_source=github_status
>
> Fixes- 9f7f466af("Add support for Route Info Option in RA - RFC 4191")
> CC: Lorenzo Bianconi
> Signed-off-by: Numan Siddique
> ---
> controller/pinctrl.c | 2 +-
> lib/ovn-l7.h | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> index c4752c673..452ca8a1c 100644
> --- a/controller/pinctrl.c
> +++ b/controller/pinctrl.c
> @@ -2486,7 +2486,7 @@ packet_put_ra_route_info_opt(struct dp_packet *b,
> ovs_be32 lifetime,
> for (t1 = strtok_r(t0, "-", ), index = 0; t1;
> t1 = strtok_r(NULL, "-", ), index++) {
>
> -nd_rinfo.type = ND_OPT_ROUTE_INFO;
> +nd_rinfo.type = ND_OPT_ROUTE_INFO_TYPE;
> nd_rinfo.route_lifetime = lifetime;
>
> switch (index) {
> diff --git a/lib/ovn-l7.h b/lib/ovn-l7.h
> index ae6dbfdfb..375b77014 100644
> --- a/lib/ovn-l7.h
> +++ b/lib/ovn-l7.h
> @@ -243,10 +243,10 @@ struct ovs_nd_dnssl {
> BUILD_ASSERT_DECL(ND_DNSSL_OPT_LEN == sizeof(struct ovs_nd_dnssl));
>
> /* Route Information option RFC 4191 */
> -#define ND_OPT_ROUTE_INFO 24
> +#define ND_OPT_ROUTE_INFO_TYPE 24
> #define ND_ROUTE_INFO_OPT_LEN8
> struct ovs_nd_route_info {
> -u_int8_t type; /* ND_OPT_ROUTE_INFO */
> +u_int8_t type; /* ND_OPT_ROUTE_INFO_TYPE */
> u_int8_t len; /* 1, 2 or 3 */
> u_int8_t prefix_len;
> u_int8_t flags;
> --
> 2.24.1
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] tc: handle packet mark of zero
On Fri, Jan 10, 2020 at 06:59:00AM -0500, 0-day Robot wrote: > Bleep bloop. Greetings Simon Horman, I am a robot and I have tried out your > patch. > Thanks for your contribution. > > I encountered some error that I wasn't expecting. See the details below. > > > checkpatch: > WARNING: Unexpected sign-offs from developers who are not authors or > co-authors or committers: Simon Horman > Lines checked: 38, Warnings: 1, Errors: 0 > > > Please check this out. If you feel there has been an error, please email > acon...@redhat.com I will add Co-Authored-by: Simon Horman but if someone offers a positive review then I'll do so when applying. In any case I'll wait before reposting to see if there is any further feedback. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Aucun numéro mobile enregistré.
Cher(e) Client(e), votre demande de changement de numero ne peut pas être établie veulliez confirme votre information le mise a jour indique que votre numero telephone et incorrect malgré le courrier que on a envoyer sur votre adresse actuelle. Merci de bien vouloir vérifier votre numero téléphone . Accéder à mes comptes --Merci de vоtre cоnfiance,ΒNP PARIΒAS Merci de ne pas répоndre à ce cоurrier électronique. ATTENTION ! Il vous est désormais nécessaire de saisir un code reçu par SMS pour conclure cette operation: Nous vous invitons à vérifier votre numéro de mobile sur https://mabanque.bnpparibas ou à contacter votre conseiller. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] Fix the travis CI compilation error seen for osx job
From: Numan Siddique
After the commit [1], travis CI job for osx [2] is failing with the below
error:
*
In file included from lib/actions.c:25:
./lib/ovn-l7.h:246:9: error: 'ND_OPT_ROUTE_INFO' macro redefined
[-Werror,-Wmacro-redefined]
^
/usr/include/netinet/icmp6.h:329:9: note: previous definition is here
*
This patch renames the macro ND_OPT_ROUTE_INFO to ND_OPT_ROUTE_INFO_TYPE as
this macro
is used to set the Route Information Option Type.
[1] - 9f7f466af("Add support for Route Info Option in RA - RFC 4191")
[2] -
https://travis-ci.org/ovn-org/ovn/jobs/634833728?utm_medium=notification_source=github_status
Fixes- 9f7f466af("Add support for Route Info Option in RA - RFC 4191")
CC: Lorenzo Bianconi
Signed-off-by: Numan Siddique
---
controller/pinctrl.c | 2 +-
lib/ovn-l7.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index c4752c673..452ca8a1c 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -2486,7 +2486,7 @@ packet_put_ra_route_info_opt(struct dp_packet *b,
ovs_be32 lifetime,
for (t1 = strtok_r(t0, "-", ), index = 0; t1;
t1 = strtok_r(NULL, "-", ), index++) {
-nd_rinfo.type = ND_OPT_ROUTE_INFO;
+nd_rinfo.type = ND_OPT_ROUTE_INFO_TYPE;
nd_rinfo.route_lifetime = lifetime;
switch (index) {
diff --git a/lib/ovn-l7.h b/lib/ovn-l7.h
index ae6dbfdfb..375b77014 100644
--- a/lib/ovn-l7.h
+++ b/lib/ovn-l7.h
@@ -243,10 +243,10 @@ struct ovs_nd_dnssl {
BUILD_ASSERT_DECL(ND_DNSSL_OPT_LEN == sizeof(struct ovs_nd_dnssl));
/* Route Information option RFC 4191 */
-#define ND_OPT_ROUTE_INFO 24
+#define ND_OPT_ROUTE_INFO_TYPE 24
#define ND_ROUTE_INFO_OPT_LEN8
struct ovs_nd_route_info {
-u_int8_t type; /* ND_OPT_ROUTE_INFO */
+u_int8_t type; /* ND_OPT_ROUTE_INFO_TYPE */
u_int8_t len; /* 1, 2 or 3 */
u_int8_t prefix_len;
u_int8_t flags;
--
2.24.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] tc: handle packet mark of zero
Bleep bloop. Greetings Simon Horman, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. checkpatch: WARNING: Unexpected sign-offs from developers who are not authors or co-authors or committers: Simon Horman Lines checked: 38, Warnings: 1, Errors: 0 Please check this out. If you feel there has been an error, please email acon...@redhat.com Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly
Hi Han, Thanks for your reply. I agree with your following comment 1. For the comment 2, I think Ben' s patch will make "UUID" and "name" be similar, I don't know the reason for summit this patch, I have comment for that patch in another email. Enventually, If we use Ben's patch to record mappings between OVN and Neutron,we may also need to finish two jobs: 1. A patch to make QoS could be search by UUID, which not supported now, has finished in my patch 2. 2. Alter the methods which has used "name" to record the mappings . What do you think? :) Thanks, Yun > I agree with you that it is more efficient to delete with an ID instead of searching based on fields. I think we need to consider below two factors: > 1. If the new "name" column is supposed to uniquely identify a row, it is better to add the "index" constraint in the schema for this new column, to avoid duplicated names. > 2. Ben recently worked on the new feature of OVSDB to make it allows client to specify row uuid when creating a row [0]. If this patch is merged, we don't need a "name" column to uniquely identify a row any more. I'd > prefer to utilize this new feature and to avoid adding new "name" columns for individual tables. Do you think this is helpful? > [0] https://patchwork.ozlabs.org/patch/1220644/ From: Han Zhou Date: 2020-01-10 12:03 To: taoyunxi...@cmss.chinamobile.com CC: ovs-dev Subject: Re: Re: [ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly Sorry for the late reply. Please see my response below. On Wed, Jan 8, 2020 at 5:16 PM taoyunxi...@cmss.chinamobile.com wrote: > > Hi Han, > If you have time, Could you review this patch or give a response. > > > Thanks , > Yun > > > > From: taoyunxi...@cmss.chinamobile.com > Date: 2019-12-24 19:55 > To: Han Zhou > CC: ovs-dev > Subject: Re: Re: [ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly > Hi Han, > Thanks for your review! > > 1. As for point 1 and point 4, I think it is not bad to use > external_ids to record association between Neutron and OVN, even we can > record LS info also. But it is not directly and clearly. > Actually, I find almost resource tables have "name" column, > included ACL table, which summited by this patch[0]. The purpose of adding > "name" for ACL, is also to make ACL rule could be easily find and check in > OVN. Ok, the name column of ACL table was added for the logging purpose, but I agree with you it can be used the way you intended to. > > 2. As for point 2, I am agreed, but do not know how to do now. There are several ways. Option1: Keep the old command and add a new command for deleting by name. Option2: Add an option to the old command such as "--by-name" to delete by name. Option3: Keep the SWITCH arg when deleting by name, but only for the given switch. If the next argument can be found as a QoS name in the switch, it is treated as delete by name, otherwise, it is handled as before. > > 3. As for point 3, I think we can record LS info, it is not bad. > > > As for why I want to change "qos-del" comand, I want to explain more > detailed. Hope to get your advice. > > 1. QoS rule resource of Neutron is not mapping any resource of OVN, and > it just contains rate, burst, dircetion and so on. > > 2. In Neutron, when we bind QoS rule to port or network, it will triger > OVN to record in QoS table. > > 3. When we update QoS rule in Neutron , it will DIRECTLY update its > record of Neutron DB(will not wait OVN to update, because no mapping > resource), gradually, it will update port or network which binded this QoS > rule. But the QoS rule has already become the lasted one in Neutron DB, and > networking-ovn can not get the old QoS rule of Neutron. So we can not > update it exactly. > > 4. For the above situaiton, we can only delete old rules that have the > same direction as the new rules, or , we will expand the scope of deletion. > This patch [1] is the logic process for networking-ovn to execute QoS > rule. The update process is not exactly and suitable, I think the Core OVN > may need some changes. > I agree with you that it is more efficient to delete with an ID instead of searching based on fields. I think we need to consider below two factors: 1. If the new "name" column is supposed to uniquely identify a row, it is better to add the "index" constraint in the schema for this new column, to avoid duplicated names. 2. Ben recently worked on the new feature of OVSDB to make it allows client to specify row uuid when creating a row [0]. If this patch is merged, we don't need a "name" column to uniquely identify a row any more. I'd prefer to utilize this new feature and to avoid adding new "name" columns for individual tables. Do you think this is helpful?
[ovs-dev] [PATCH] tc: handle packet mark of zero
From: John Hurley
Openstack may set an skb mark of 0 in tunnel rules. This is considered to
be an unused/unset value. However, it prevents the rule from being
offloaded.
Check if the key value of the skb mark is 0 when it is in use (mask is
set to all ones). If it is then ignore the field and continue with TC offload.
Signed-off-by: John Hurley
[simon; check for exact-match rather than any match]
Signed-off-by: Simon Horman
---
lib/netdev-offload-tc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 7453078d535f..daff8a379e97 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -1619,6 +1619,11 @@ netdev_tc_flow_put(struct netdev *netdev, struct match
*match,
mask->ct_label = OVS_U128_ZERO;
}
+/* ignore exact match on skb_mark of 0. */
+if (mask->pkt_mark == UINT32_MAX && !key->pkt_mark) {
+mask->pkt_mark = 0;
+}
+
err = test_key_and_mask(match);
if (err) {
return err;
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-trace: Improve NAT tracing.
On Tue, Jan 7, 2020 at 8:25 PM Ben Pfaff wrote: > > On Tue, Jan 07, 2020 at 09:15:26AM +0100, Dumitru Ceara wrote: > > On Mon, Jan 6, 2020 at 11:11 PM Ben Pfaff wrote: > > > > > > On Fri, Jan 03, 2020 at 05:27:31PM +0100, Dumitru Ceara wrote: > > > > When ofproto/trace detects a recirc action it resumes execution at the > > > > specified next table. However, if the ct action performs SNAT/DNAT, > > > > e.g., ct(commit,nat(src=1.1.1.1:4000),table=42), the src/dst IPs and > > > > ports in the oftrace_recirc_node->flow field are not updated. This leads > > > > to misleading outputs from ofproto/trace as real packets would actually > > > > first get NATed and might match different flows when recirculated. > > > > > > > > Assume the first IP/port from the NAT src/dst action will be used by > > > > conntrack for the translation and update the oftrace_recirc_node->flow > > > > accordingly. This is not entirely correct as conntrack might choose a > > > > different IP/port but the result is more realistic than before. > > > > > > > > This fix covers new connections. However, for reply traffic that > > > > executes > > > > actions of the form ct(nat, table=42) we still don't update the flow as > > > > we don't have any information about conntrack state when tracing. > > > > > > > > Signed-off-by: Dumitru Ceara > > > > > > This is a great idea. > > > > > > I have an idea for further improvement. Currently this patch is quiet: > > > it doesn't say what's going on. It would be better if it said that it > > > was replacing the source and/or destination addresses, and by what and > > > why. I think that would be easiest done in ofproto_trace() itself near > > > the existing code that does it already for ct_state. I think we could > > > just save the ofn pointer in the recirc node and move the replacement > > > code to ofproto_trace(). > > > > > > > Thanks for the review! Sounds better indeed. I'll respin the patch > > with your enhancement. Hi Ben, I sent v2 including your suggestions: https://patchwork.ozlabs.org/patch/1220907/ > > > > As follow up work I was thinking it would be nice to be able to cover > > the other types of nat recirculation too, e.g., ct(nat, table=42), and > > allow the user to specify the outcome of the nat operation in a > > similar way as we do for conntrack with --ct-next. However, I'm not > > sure what the best way is to do that.. I'm open to suggestions. > > > > Could we enhance ofproto/trace such that the user can specify a > > conntrack database in a predefined format? For example, the output of > > "conntrack -L -o xml". Or would that become confusing? > > I have two ideas. > > First, OVS is already able to read and dump the actual connection > tracking database in use (see e.g. the dpctl/dump-conntrack command in > ovs-vswitchd(8)). ofproto/trace could consult this. It would want to > dump out the entry that was found (or not found) while doing it. This is nice, thanks for pointing it out. So I guess when troubleshooting packet forwarding we could insert conntrack entries to guide ofproto/trace. > > Second, I guess we could have an option whose argument is a set of > actions to execute, which could update the source and destination, etc. > That's very general purpose! > I also like this second option because it decouples tracing from the underlying datapath conntrack implementation. I'll give it more thought and follow up when I have something working. Regards, Dumitru ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] ofproto-dpif-trace: Improve NAT tracing.
When ofproto/trace detects a recirc action it resumes execution at the
specified next table. However, if the ct action performs SNAT/DNAT,
e.g., ct(commit,nat(src=1.1.1.1:4000),table=42), the src/dst IPs and
ports in the oftrace_recirc_node->flow field are not updated. This leads
to misleading outputs from ofproto/trace as real packets would actually
first get NATed and might match different flows when recirculated.
Assume the first IP/port from the NAT src/dst action will be used by
conntrack for the translation and update the oftrace_recirc_node->flow
accordingly. This is not entirely correct as conntrack might choose a
different IP/port but the result is more realistic than before.
This fix covers new connections. However, for reply traffic that executes
actions of the form ct(nat, table=42) we still don't update the flow as
we don't have any information about conntrack state when tracing.
Also move the oftrace_recirc_node processing out of ofproto_trace()
and to its own function, ofproto_trace_recirc_node() for better
readability/
Signed-off-by: Dumitru Ceara
---
v2:
- Address Ben's comments:
- Move trace node flow code replacement to ofproto_trace_*().
- Add outputs describing the NAT actions.
- Move recirc node processing to its own function for better
readability (ofproto_trace_recirc_node).
---
ofproto/ofproto-dpif-trace.c | 116 +--
ofproto/ofproto-dpif-trace.h | 2 +
ofproto/ofproto-dpif-xlate.c | 6 ++-
tests/ofproto-dpif.at| 36 ++
4 files changed, 133 insertions(+), 27 deletions(-)
diff --git a/ofproto/ofproto-dpif-trace.c b/ofproto/ofproto-dpif-trace.c
index 8ae8a22..5f1a05c 100644
--- a/ofproto/ofproto-dpif-trace.c
+++ b/ofproto/ofproto-dpif-trace.c
@@ -86,6 +86,7 @@ oftrace_node_destroy(struct oftrace_node *node)
bool
oftrace_add_recirc_node(struct ovs_list *recirc_queue,
enum oftrace_recirc_type type, const struct flow *flow,
+const struct ofpact_nat *ofn,
const struct dp_packet *packet, uint32_t recirc_id,
const uint16_t zone)
{
@@ -101,6 +102,7 @@ oftrace_add_recirc_node(struct ovs_list *recirc_queue,
node->flow = *flow;
node->flow.recirc_id = recirc_id;
node->flow.ct_zone = zone;
+node->nat_act = ofn;
node->packet = packet ? dp_packet_clone(packet) : NULL;
return true;
@@ -179,6 +181,25 @@ oftrace_node_print_details(struct ds *output,
}
}
+static void
+oftrace_print_ip_flow(const struct flow *flow, int af, struct ds *output)
+{
+if (af == AF_INET) {
+ds_put_format(output, "nw_src="IP_FMT",tp_src=%"PRIu16","
+ "nw_dst="IP_FMT",tp_dst=%"PRIu16,
+ IP_ARGS(flow->nw_src), ntohs(flow->tp_src),
+ IP_ARGS(flow->nw_dst), ntohs(flow->tp_dst));
+} else if (af == AF_INET6) {
+ds_put_cstr(output, "ipv6_src=");
+ipv6_format_addr_bracket(>ipv6_src, output, true);
+ds_put_format(output, ",tp_src=%"PRIu16, ntohs(flow->tp_src));
+ds_put_cstr(output, ",ipv6_dst=");
+ipv6_format_addr_bracket(>ipv6_dst, output, true);
+ds_put_format(output, ",tp_dst=%"PRIu16, ntohs(flow->tp_dst));
+}
+ds_put_char(output, '\n');
+}
+
/* Parses the 'argc' elements of 'argv', ignoring argv[0]. The following
* forms are supported:
*
@@ -638,6 +659,75 @@ execute_actions_except_outputs(struct dpif *dpif,
}
static void
+ofproto_trace_recirc_node(struct oftrace_recirc_node *node,
+ struct ovs_list *next_ct_states,
+ struct ds *output)
+{
+ds_put_cstr(output, "\n\n");
+ds_put_char_multiple(output, '=', 79);
+ds_put_format(output, "\nrecirc(%#"PRIx32")", node->recirc_id);
+
+if (next_ct_states && node->type == OFT_RECIRC_CONNTRACK) {
+uint32_t ct_state;
+if (ovs_list_is_empty(next_ct_states)) {
+ct_state = CS_TRACKED | CS_NEW;
+ds_put_cstr(output, " - resume conntrack with default "
+"ct_state=trk|new (use --ct-next to customize)");
+} else {
+ct_state = oftrace_pop_ct_state(next_ct_states);
+struct ds s = DS_EMPTY_INITIALIZER;
+format_flags(, ct_state_to_string, ct_state, '|');
+ds_put_format(output, " - resume conntrack with ct_state=%s",
+ ds_cstr());
+ds_destroy();
+}
+node->flow.ct_state = ct_state;
+}
+ds_put_char(output, '\n');
+
+/* If there's any snat/dnat information assume we always translate to
+ * the first IP/port to make sure we don't match on incorrect flows later
+ * on.
+ */
+if (node->nat_act) {
+const struct ofpact_nat *ofn = node->nat_act;
+
+ds_put_cstr(output, "Replacing src/dst IP/ports to simulate NAT:\n");
+ds_put_cstr(output, " Initial flow: ");
+
Re: [ovs-dev] [PATCH v2] ovsdb-server: Allow OVSDB clients to specify the UUID for inserted rows.
Hi Ben,
It will be appreciated，if you give more explanation for the resaon
to summit this patch. In my opinion, it makes the "UUID" column be almost the
same with "name" column, if we need "name" column in the future?
At 2020-01-10 11:39:22, "Han Zhou" wrote:
>On Thu, Jan 9, 2020 at 12:48 PM Ben Pfaff wrote:
>>
>> Requested-by: Leonid Ryzhyk
>> Signed-off-by: Ben Pfaff
>> ---
>> v1->v2: Improve test as suggested by Flavio Fernandes.
>>
>> Documentation/ref/ovsdb-server.7.rst | 9 +
>> NEWS | 1 +
>> ovsdb/execution.c| 26 ++
>> ovsdb/transaction.c | 22 +-
>> ovsdb/transaction.h | 5 -
>> tests/ovsdb-execution.at | 24
>> tests/uuidfilt.py| 18 --
>> 7 files changed, 97 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/ref/ovsdb-server.7.rst
>b/Documentation/ref/ovsdb-server.7.rst
>> index bc533611cb4a..967761bdfb84 100644
>> --- a/Documentation/ref/ovsdb-server.7.rst
>> +++ b/Documentation/ref/ovsdb-server.7.rst
>> @@ -546,6 +546,15 @@ condition can be either a 3-element JSON array as
>described in the RFC or a
>> boolean value. In case of an empty array an implicit true boolean value
>will be
>> considered.
>>
>> +5.2.1 Insert
>> +
>> +
>> +As an extension, Open vSwitch 2.13 and later allow an optional ``uuid``
>member
>> +to specify the UUID for the new row. The specified UUID must be unique
>within
>> +the table when it is inserted and not the UUID of a row previously
>deleted
>> +within the transaction. If the UUID violates these rules, then the
>operation
>> +fails with a ``duplicate uuid`` error.
>> +
>> 5.2.6 Wait, 5.2.7 Commit, 5.2.9 Comment
>> ---
>>
>> diff --git a/NEWS b/NEWS
>> index 965facaf852d..d8f82cd18af0 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -34,6 +34,7 @@ Post-v2.12.0
>> interval is increased to 60 seconds for the connection to the
>> replication server. This value is configurable with the unixctl
>> command - ovsdb-server/set-active-ovsdb-server-probe-interval.
>> + * ovsdb-server: New OVSDB extension to allow clients to specify row
>UUIDs.
>>
>> v2.12.0 - 03 Sep 2019
>> -
>> diff --git a/ovsdb/execution.c b/ovsdb/execution.c
>> index f2cf3d72d45f..e45f3d6796a7 100644
>> --- a/ovsdb/execution.c
>> +++ b/ovsdb/execution.c
>> @@ -1,4 +1,4 @@
>> -/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2017 Nicira, Inc.
>> +/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2017, 2019 Nicira, Inc.
>> *
>> * Licensed under the Apache License, Version 2.0 (the "License");
>> * you may not use this file except in compliance with the License.
>> @@ -329,11 +329,12 @@ ovsdb_execute_insert(struct ovsdb_execution *x,
>struct ovsdb_parser *parser,
>> {
>> struct ovsdb_table *table;
>> struct ovsdb_row *row = NULL;
>> -const struct json *uuid_name, *row_json;
>> +const struct json *uuid_json, *uuid_name, *row_json;
>> struct ovsdb_error *error;
>> struct uuid row_uuid;
>>
>> table = parse_table(x, parser, "table");
>> +uuid_json = ovsdb_parser_member(parser, "uuid", OP_STRING |
>OP_OPTIONAL);
>> uuid_name = ovsdb_parser_member(parser, "uuid-name", OP_ID |
>OP_OPTIONAL);
>> row_json = ovsdb_parser_member(parser, "row", OP_OBJECT);
>> error = ovsdb_parser_get_error(parser);
>> @@ -341,6 +342,19 @@ ovsdb_execute_insert(struct ovsdb_execution *x,
>struct ovsdb_parser *parser,
>> return error;
>> }
>>
>> +if (uuid_json) {
>> +if (!uuid_from_string(_uuid, json_string(uuid_json))) {
>> +return ovsdb_syntax_error(uuid_json, NULL, "bad uuid");
>> +}
>> +
>> +if (!ovsdb_txn_may_create_row(table, _uuid)) {
>> +return ovsdb_syntax_error(uuid_json, "duplicate uuid",
>> + "This UUID would duplicate a UUID "
>> + "already present within the table
>or "
>> + "deleted within the same
>transaction.");
>> +}
>> +}
>> +
>> if (uuid_name) {
>> struct ovsdb_symbol *symbol;
>>
>> @@ -350,9 +364,13 @@ ovsdb_execute_insert(struct ovsdb_execution *x,
>struct ovsdb_parser *parser,
>>"This \"uuid-name\" appeared on an
>"
>>"earlier \"insert\" operation.");
>> }
>> -row_uuid = symbol->uuid;
>> +if (uuid_json) {
>> +symbol->uuid = row_uuid;
>> +} else {
>> +row_uuid = symbol->uuid;
>> +}
>> symbol->created = true;
>> -} else {
>> +} else if (!uuid_json) {
>> uuid_generate(_uuid);
>> }
>>
>> diff --git a/ovsdb/transaction.c b/ovsdb/transaction.c
>> index
