[ovs-dev] DHL Shipment Delay
d...@openvswitch.org Notification for your shipment "Clearance delay" check the attach for more detail Erik Sugg Credit & Receivable Coordinator T +18004338466 | EXT3477 DHL Service ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 ovn 0/3] Introduce localnet egress QoS support
I've pushed this to master.
On 9/24/19 12:39 PM, Lorenzo Bianconi wrote:
OVN applies logical switch QoS settings to egress interfaces. It
currently works by analyzing each br-int interface to see what the remote-ip
is on it, and then adding qdiscs to the tunnel-egress-iface associated
with this br-int interface.
This doesn't work as well when working with VLAN networks. In VLAN
networks, the interface on br-int associated with the localnet port on
the logical switch will be a patch port. It's connected to another
bridge, making it difficult to determine which interface (or interfaces) is
the egress interface on that connected bridge.
This series aims to mend this. On the bridge that is patched to br-int,
interfaces can have the boolean external-ids:ovn-egress-iface set to
true if this is an egress interface. This way, QoS can be applied to
these interfaces the same as is applied to tunnel interfaces.
Moreover rework qos code in order to add the capability to select automatically
the queue_id used to identify the device queue
Finally add the set_queue action to logical flows in Egress Port Security - L2
stage
for localnet QoS capable ports in order to set the physical_interface qdisc id
Changes since v1:
- split build_lswitch_port_sec in build_lswitch_input_port_sec and
build_lswitch_output_port_sec
- removed unnecessary log messages
Changes since RFC:
- introduce build_lswitch_port_sec as a container for {in/out}_port_sec logical
flow configuration
- move ovn-egress-iface lookup in consider_localnet_port in order to avoid an
unnecessary port_binding lookup
Lorenzo Bianconi (3):
Add egress QoS mapping for non-tunnel interfaces
northd: add the possibility to define localnet as qos capable port
northd: interoduce logical flow for localnet egress shaping
controller/binding.c| 51 ++-
controller/binding.h| 4 +
controller/ovn-controller.c | 3 +-
controller/patch.c | 76 +-
controller/patch.h | 4 +
northd/ovn-northd.8.xml | 7 +-
northd/ovn-northd.c | 276 ++--
7 files changed, 276 insertions(+), 145 deletions(-)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] MAINTAINERS: Add William Tu.
William was elected by the Open vSwitch committers today. Welcome to the team, William! Signed-off-by: Ben Pfaff --- MAINTAINERS.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS.rst b/MAINTAINERS.rst index 72e1c693f0d3..8fcc9ad10108 100644 --- a/MAINTAINERS.rst +++ b/MAINTAINERS.rst @@ -75,6 +75,8 @@ This is the current list of active Open vSwitch committers: - ho...@ovn.org * - Thomas Graf - tg...@noironetworks.com + * - William Tu + - u9012...@gmail.com * - YAMAMOTO Takashi - yamam...@midokura.com -- 2.21.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/1] ovsdb-client: fix memory leak to prevent valgrind reporting memory leaks while running test suite
On Mon, Sep 30, 2019 at 09:20:39AM +0200, Damijan Skvarc wrote:
> memory leaks are reported in several tests and are expressed in a following
> way:
Thank you for the patch.
This patch introduces a use-after-free error:
> } else if (txn_id && json_equal(txn_id, reply->id)) {
> +jsonrpc_msg_destroy(reply);
> check_transaction_reply(reply);
Thanks,
Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/1] ovsdb-client: fix memory leak in do_needs_conversion() and do_convert()
On Mon, Sep 30, 2019 at 10:21:00AM +0200, Damijan Skvarc wrote: > Memory leak itself is not so important, however the problem is that > it is caused by forgetting to close rpc channel which might in > a long term lead to the leak of system resources. > > Memory leak is reported by Valgrin running test suite and is expressed as: Thanks for the fix. I don't understand why this is necessary. These functions are called from main(), which closes the rpc connection just afterward: command->handler(rpc, database, argc - optind, argv + optind); free(database); jsonrpc_close(rpc); Can you take a closer look? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH branch-2.6 v2] conntrack: Fix ICMPv4 error data L4 length check.
On Sun, Sep 29, 2019 at 04:11:27PM +0530, Vishal Deep Ajmera via dev wrote:
> From: Darrell Ball
>
> The ICMPv4 error data L4 length check was found to be too strict for TCP,
> expecting a minimum of 20 rather than 8 bytes. This worked by
> hapenstance for other inner protocols. The approach is to explicitly
> handle the ICMPv4 error data L4 length check and to do this for all
> supported inner protocols in the same way. Making the code common
> between protocols also allows the existing ICMPv4 related UDP tests to
> cover TCP and ICMP inner protocol cases.
> Note that ICMPv6 does not have an 8 byte limit for error L4 data.
>
> Fixes: a489b16854b5 ("conntrack: New userspace connection tracker.")
> CC: Daniele Di Proietto
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-August/361949.html
> Reported-by: Vishal Deep Ajmera
> Signed-off-by: Vishal Deep Ajmera
> Co-authored-by: Vishal Deep Ajmera
> Signed-off-by: Darrell Ball
Thanks, applied to branch-2.6.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] upcall: Configure datapath max-unkeep-op through ovs-vsctl.
On Mon, Sep 30, 2019 at 07:15:39PM +0800, we...@ucloud.cn wrote: > From: wenxu > > This patch adds a new configuration option, "max-unkeep_op" to the > Open_vSwitch "other-config" column. This sets maximum allowed ravalidator > do the UNKEEP operations with limit in each dump. > In the hw-offload mode. The huge number of UNKEEP operationes will > make revalidator block long time. Thanks for working to make OVS perform better. It's best if OVS can perform well without requiring users to tune it by hand. This commit does not try to do that; instead, users have to notice that there is a performance problem, find this particular setting, and then experiment to find the best value. That's a lot of work. Can you try to make this self-tuning, so that users don't have to go through all of that? Second, when OVS does require manual tuning for best performance, we should try to document the settings' purpose and rationale and how to determine their values. The name for this setting is not informative (I do not understand it myself) and the documentation does not explain what it is for, how one should recognize that tuning it is necessary, or how to choose a useful value. Will you please take another look to see if you can improve the patch along those two axes? Thanks again for working to make OVS faster. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] userspace-tunnelling.rst: Fix a typo in the userspace tunnel guide
On Sun, Sep 29, 2019 at 10:07:27AM +0800, Timo_Liu wrote: > This commit fixes potential unintended mistake in userspace-tunneling guide: > for the example in userspace-tunneling guide, there is no bridge named > "br-eth1", but only a bridge name "br-phy" which has a port named "eth1" > > Signed-off-by: Liu Chang Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/2] ovsdb-cluster: Use ovs-vsctl instead of ovn-nbctl and ovn-sbctl.
On Fri, Sep 27, 2019 at 02:07:49PM -0700, Han Zhou wrote: > On Fri, Sep 27, 2019 at 12:50 PM Ben Pfaff wrote: > > > > This removes a dependency on OVN from the tests. > Thanks Ben. For the series: > Acked-by: Han Zhou Thanks for the review. I applied this series to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] datapath: Fix conntrack cache with timeout
Thanks for the patch, Yi-Hung, and the review, Darrell. I pushed this to
master.
--Justin
> On Sep 29, 2019, at 10:09 AM, Darrell Ball wrote:
>
> Thanks for the patch
>
> Looks good and matches the upstream version, including the rcu deference
> fixup.
> Thanks for remembering to add the requested test incremental, post fix.
>
> Darrell
>
> On Fri, Sep 27, 2019 at 2:14 PM Yi-Hung Wei wrote:
>
>> This patch is from the following upstream net-next commit along with
>> an updated system traffic test to avoid regression.
>>
>> Upstream commit:
>>commit 7177895154e6a35179d332f4a584d396c50d0612
>>Author: Yi-Hung Wei
>>Date: Thu Aug 22 13:17:50 2019 -0700
>>
>>openvswitch: Fix conntrack cache with timeout
>>
>>This patch addresses a conntrack cache issue with timeout policy.
>>Currently, we do not check if the timeout extension is set
>> properly in the
>>cached conntrack entry. Thus, after packet recirculate from
>> conntrack
>>action, the timeout policy is not applied properly. This patch
>> fixes the
>>aforementioned issue.
>>
>>Fixes: 06bd2bdf19d2 ("openvswitch: Add timeout support to ct
>> action")
>>Reported-by: kbuild test robot
>>Signed-off-by: Yi-Hung Wei
>>Acked-by: Pravin B Shelar
>>Signed-off-by: David S. Miller
>>
>> Signed-off-by: Yi-Hung Wei
>> ---
>> datapath/conntrack.c| 13 +
>> tests/system-traffic.at | 18 ++
>> 2 files changed, 31 insertions(+)
>>
>> diff --git a/datapath/conntrack.c b/datapath/conntrack.c
>> index 35a183aeb33a..c6d523758ff1 100644
>> --- a/datapath/conntrack.c
>> +++ b/datapath/conntrack.c
>> @@ -88,6 +88,7 @@ struct ovs_conntrack_info {
>>struct md_mark mark;
>>struct md_labels labels;
>>char timeout[CTNL_TIMEOUT_NAME_MAX];
>> + struct nf_ct_timeout *nf_ct_timeout;
>> #ifdef CONFIG_NF_NAT_NEEDED
>>struct nf_nat_range2 range; /* Only present for SRC NAT and DST
>> NAT. */
>> #endif
>> @@ -750,6 +751,14 @@ static bool skb_nfct_cached(struct net *net,
>>if (help && rcu_access_pointer(help->helper) !=
>> info->helper)
>>return false;
>>}
>> + if (info->nf_ct_timeout) {
>> + struct nf_conn_timeout *timeout_ext;
>> +
>> + timeout_ext = nf_ct_timeout_find(ct);
>> + if (!timeout_ext || info->nf_ct_timeout !=
>> + rcu_dereference(timeout_ext->timeout))
>> + return false;
>> + }
>>/* Force conntrack entry direction to the current packet? */
>>if (info->force && CTINFO2DIR(ctinfo) != IP_CT_DIR_ORIGINAL) {
>>/* Delete the conntrack entry if confirmed, else just
>> release
>> @@ -1709,6 +1718,10 @@ int ovs_ct_copy_action(struct net *net, const
>> struct nlattr *attr,
>> ct_info.timeout))
>>pr_info_ratelimited("Failed to associated timeout "
>>"policy `%s'\n",
>> ct_info.timeout);
>> + else
>> + ct_info.nf_ct_timeout = rcu_dereference(
>> + nf_ct_timeout_find(ct_info.ct)->timeout);
>> +
>>}
>>
>>if (helper) {
>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
>> index bfc6bb5b47c7..3d4e365764b5 100644
>> --- a/tests/system-traffic.at
>> +++ b/tests/system-traffic.at
>> @@ -3242,6 +3242,24 @@ sleep 4
>> AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0],
>> [dnl
>> ])
>>
>> +dnl Re-send ICMP and UDP traffic to test conntrack cache
>> +NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.2 |
>> FORMAT_PING], [0], [dnl
>> +3 packets transmitted, 3 received, 0% packet loss, time 0ms
>> +])
>> +AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 "in_port=1
>> packet=5054000a505400090800451c0011a4cd0a0101010a010102000100020008
>> actions=resubmit(,0)"])
>> +
>> +AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | sort],
>> [0], [dnl
>>
>> +icmp,orig=(src=10.1.1.1,dst=10.1.1.2,id=,type=8,code=0),reply=(src=10.1.1.2,dst=10.1.1.1,id=,type=0,code=0),zone=5
>>
>> +udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=10.1.1.2,dst=10.1.1.1,sport=,dport=),zone=5
>> +])
>> +
>> +dnl Wait until the timeout expire.
>> +dnl We intend to wait a bit longer, because conntrack does not recycle
>> the entry right after it is expired.
>> +sleep 4
>> +
>> +AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0],
>> [dnl
>> +])
>> +
>> OVS_TRAFFIC_VSWITCHD_STOP
>> AT_CLEANUP
>>
>> --
>> 2.7.4
>>
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
> ___
> dev mailing list
> d...@openvswitch.org
>
Re: [ovs-dev] [PATCHv2] netdev-afxdp: Detect numa node id.
Hi, William.
Thanks for the patch.
Few general comments on the topic:
1. This function is not afxdp specific. Maybe it's worth to move
it to more generic netdev-linux?
2. netdev-linux caches most of things like mtu and ifindex.
Maybe we could cache numa_id too and not read it all the time
from the filesystem?
3. More comments inline.
Best regards, Ilya Maximets.
On 27.09.2019 20:26, William Tu wrote:
The patch detects the numa node id from the name of the netdev,
by reading the '/sys/class/net//device/numa_node'.
If not available, ex: virtual device, or any error happens,
return numa id 0.
Signed-off-by: William Tu
---
v2:
Address feedback from Eelco
fix memory leak of xaspintf
log using INFO instead of WARN
---
lib/netdev-afxdp.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index 6e01803272aa..6ff1473461a6 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -552,11 +552,42 @@ out:
int
netdev_afxdp_get_numa_id(const struct netdev *netdev)
{
-/* FIXME: Get netdev's PCIe device ID, then find
- * its NUMA node id.
- */
-VLOG_INFO("FIXME: Device %s always use numa id 0.",
- netdev_get_name(netdev));
+const char *numa_node_path;
+long int node_id;
+char buffer[4];
+FILE *stream;
+int n;
+
+numa_node_path = xasprintf("/sys/class/net/%s/device/numa_node",
+ netdev_get_name(netdev));
Do we need some escaping here like we have for vhost:
strchr(name, '/') || strchr(name, '\\')
For security reasons?
+stream = fopen(numa_node_path, "r");
+if (!stream) {
+/* Virtual device does not have this info. */
+VLOG_INFO_RL(, "Open %s failed: %s, use numa_id 0",
+ numa_node_path, ovs_strerror(errno));
How about:
VLOG_INFO_RL(, "%s: Can't open '%s': %s, using numa_id 0",
netdev_get_name(netdev), numa_node_path,
ovs_strerror(errno));
In general, I'd like if we could print only 'fopen' related error here
and report about 'numa_id 0' in the end of function in the last message.
+free(numa_node_path);
+return 0;
+}
+
+n = fread(buffer, 1, sizeof buffer, stream);
Why fread? It looks much easier to use fscanf instead.
And you'll not need to parse the resulted string in this case.
+if (!n) {
+goto error;
+}
+
+node_id = strtol(buffer, NULL, 10);
Anyway, please, use str_to_int() from lib/util.h instead.
+if (node_id < 0 || node_id > 2) {
This check looks strange. Even on Intel platforms, systems with
more than 2 NUMA nodes are widely available.
You may use ovs_numa_numa_id_is_valid() instead.
+goto error;
+}
+
+fclose(stream);
+free(numa_node_path);
+return (int)node_id;
+
+error:
+VLOG_WARN_RL(, "Error detecting numa node of %s, use numa_id 0",
+ numa_node_path);
VLOG_WARN_RL(, "%s: Can't detect NUMA node, using numa_id 0",
netdev_get_name(netdev));
+free(numa_node_path);
+fclose(stream);
return 0;
}
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Pricelist Bonesca
___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] Partially revert "Exclude inport and outport symbol tables from conjunction."
From: Numan Siddique This partially revers the commit - 298701dbc99645700be41680a43d049cb061847a as the commit [1] disables the conjunction. We still need the changes to the tests/ovn.at file. CC: Han Zhou Signed-off-by: Numan Siddique --- lib/expr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/expr.c b/lib/expr.c index 64ea0aafa..9b9b6bcca 100644 --- a/lib/expr.c +++ b/lib/expr.c @@ -1517,7 +1517,7 @@ expr_symtab_add_string(struct shash *symtab, const char *name, const struct mf_field *field = mf_from_id(id); struct expr_symbol *symbol; -symbol = add_symbol(symtab, name, 0, prereqs, EXPR_L_NOMINAL, true, +symbol = add_symbol(symtab, name, 0, prereqs, EXPR_L_NOMINAL, false, field->writable); symbol->field = field; return symbol; -- 2.21.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH branch-2.10] dpdk: Use DPDK 17.11.6 release.
On 9/26/2019 11:00 AM, Stokes, Ian wrote: On 9/26/2019 10:55 AM, Ilya Maximets wrote: On 26.09.2019 12:46, Kevin Traynor wrote: On 26/09/2019 09:44, Stokes, Ian wrote: On 9/25/2019 10:50 PM, Ben Pfaff wrote: It looks like these DPDK version update patches have been overlooked. Ilya, Ian, do you want to look at them? Hi Ben, sure I can look at them, I had worked with Lukasz to validate this so was waiting for an ACK from someone outside Intel. Below looks ok to me. @Kevin/Ilya, any objections to me applying these to branch 2.10 and 2.9? No objection. 17.11.7 is about to be released, so if for some reason you were going to do any sort of re-validation etc, it would be better to wait a few days and pick up 17.11.7, but if it's just pushing then it seems fine to do. One comment below. Hi Ian and Kevin, I didn't test this, but it seems OK in general for me as far as you've tested it. However, I tend to agree that if we could wait a bit and validate with 17.11.7 this might be better. If we're not going to test with 17.11.7 in a near future, than we could apply this now. Yes, we're planning to validate 17.11.7 in the near future anyhow but had completed validation on this so though it would be worth flagging it can be used until we get around to 17.11.7. Regards Ian On Mon, Sep 02, 2019 at 09:34:53AM +0200, Lukasz Pawlik wrote: Modify travis linux build script to use the latest DPDK stable release 17.11.6. Update docs for latest DPDK stable releases. Signed-off-by: Lukasz Pawlik --- .travis/linux-build.sh | 2 +- Documentation/faq/releases.rst | 4 ++-- Documentation/intro/install/dpdk.rst | 8 Documentation/topics/dpdk/vhost-user.rst | 6 +++--- NEWS | 2 ++ 5 files changed, 12 insertions(+), 10 deletions(-) diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh index 1fe5bbf..ede62a5 100755 --- a/.travis/linux-build.sh +++ b/.travis/linux-build.sh @@ -83,7 +83,7 @@ fi if [ "$DPDK" ]; then if [ -z "$DPDK_VER" ]; then - DPDK_VER="17.11.4" + DPDK_VER="17.11.6" fi install_dpdk $DPDK_VER if [ "$CC" = "clang" ]; then diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst index 216eb30..8fe16d9 100644 --- a/Documentation/faq/releases.rst +++ b/Documentation/faq/releases.rst @@ -167,8 +167,8 @@ Q: What DPDK version does each Open vSwitch release work with? 2.6.x 16.07.2 2.7.x 16.11.8 2.8.x 17.05.2 - 2.9.x 17.11.4 - 2.10.x 17.11.4 + 2.9.x 17.11.6 + 2.10.x 17.11.6 === Q: Are all the DPDK releases that OVS versions work with maintained? diff --git a/Documentation/intro/install/dpdk.rst b/Documentation/intro/install/dpdk.rst index 13546bb..5f39263 100644 --- a/Documentation/intro/install/dpdk.rst +++ b/Documentation/intro/install/dpdk.rst @@ -42,7 +42,7 @@ Build requirements In addition to the requirements described in :doc:`general`, building Open vSwitch with DPDK will require the following: -- DPDK 17.11.4 +- DPDK 17.11.6 - A `DPDK supported NIC`_ @@ -71,9 +71,9 @@ Install DPDK #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``:: $ cd /usr/src/ - $ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz - $ tar xf dpdk-17.11.4.tar.xz - $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.4 + $ wget http://fast.dpdk.org/rel/dpdk-17.11.6.tar.xz + $ tar xf dpdk-17.11.6.tar.xz + $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.6 $ cd $DPDK_DIR #. (Optional) Configure DPDK as a shared library diff --git a/Documentation/topics/dpdk/vhost-user.rst b/Documentation/topics/dpdk/vhost-user.rst index 6334590..c5fe9ee 100644 --- a/Documentation/topics/dpdk/vhost-user.rst +++ b/Documentation/topics/dpdk/vhost-user.rst @@ -320,9 +320,9 @@ To begin, instantiate a guest as described in :ref:`dpdk-vhost-user` or DPDK sources to VM and build DPDK:: $ cd /root/dpdk/ - $ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz - $ tar xf dpdk-17.11.4.tar.xz - $ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.4 + $ wget http://fast.dpdk.org/rel/dpdk-17.11.6.tar.xz + $ tar xf dpdk-17.11.6.tar.xz + $ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.6 $ export DPDK_TARGET=x86_64-native-linuxapp-gcc $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET $ cd $DPDK_DIR diff --git a/NEWS b/NEWS index 064550b..92c3f81 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,8 @@ v2.10.3 - xx xxx v2.10.2 - 30 Mar 2019 - Bug fixes + - DPDK + * OVS validated with DPDK 17.11.6 which is recommended to be used. I guess it's still valid to add this to the 2.10.2 NEWS (even though it has now been released) as testing would have been done in the context of 2.10.2 at some point. Similar comment for 2.9 branch.
Re: [ovs-dev] [PATCH] upcall: Configure datapath max-unkeep-op through ovs-vsctl.
Bleep bloop. Greetings wenxu, 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: ERROR: Author wenxu needs to sign off. WARNING: Line is 80 characters long (recommended limit is 79) #135 FILE: vswitchd/vswitch.xml:228: The maximum unkeep operations that for each dump in revalidator thread Lines checked: 148, Warnings: 1, Errors: 1 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] upcall: Configure datapath max-unkeep-op through ovs-vsctl.
From: wenxu
This patch adds a new configuration option, "max-unkeep_op" to the
Open_vSwitch "other-config" column. This sets maximum allowed ravalidator
do the UNKEEP operations with limit in each dump.
In the hw-offload mode. The huge number of UNKEEP operationes will
make revalidator block long time.
---
ofproto/ofproto-dpif-upcall.c | 10 +++---
ofproto/ofproto-provider.h| 3 +++
ofproto/ofproto.c | 9 +
ofproto/ofproto.h | 2 ++
vswitchd/bridge.c | 3 +++
vswitchd/vswitch.xml | 11 +++
6 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 657aa7f..9423a50 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -2607,6 +2607,7 @@ revalidate(struct revalidator *revalidator)
long long int now;
size_t n_dp_flows;
bool kill_them_all;
+unsigned int counter = 0;
n_dumped = dpif_flow_dump_next(dump_thread, flows, ARRAY_SIZE(flows));
if (!n_dumped) {
@@ -2695,9 +2696,12 @@ revalidate(struct revalidator *revalidator)
}
if (result != UKEY_KEEP) {
-/* Takes ownership of 'recircs'. */
-reval_op_init([n_ops++], result, udpif, ukey, ,
- _actions);
+ if (!ofproto_max_unkeep_op ||
+++counter <= ofproto_max_unkeep_op) {
+/* Takes ownership of 'recircs'. */
+reval_op_init([n_ops++], result, udpif, ukey, ,
+ _actions);
+}
}
ovs_mutex_unlock(>mutex);
}
diff --git a/ofproto/ofproto-provider.h b/ofproto/ofproto-provider.h
index c980e6b..bce194a 100644
--- a/ofproto/ofproto-provider.h
+++ b/ofproto/ofproto-provider.h
@@ -532,6 +532,9 @@ extern unsigned ofproto_max_revalidator;
* duration exceeds half of max-revalidator config variable. */
extern unsigned ofproto_min_revalidate_pps;
+/* Maximum unkeep op in revalidator.*/
+extern unsigned ofproto_max_unkeep_op;
+
/* Number of upcall handler and revalidator threads. Only affects the
* ofproto-dpif implementation. */
extern size_t n_handlers, n_revalidators;
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index b4249b0..6a4cf2e 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -308,6 +308,7 @@ unsigned ofproto_flow_limit = OFPROTO_FLOW_LIMIT_DEFAULT;
unsigned ofproto_max_idle = OFPROTO_MAX_IDLE_DEFAULT;
unsigned ofproto_max_revalidator = OFPROTO_MAX_REVALIDATOR_DEFAULT;
unsigned ofproto_min_revalidate_pps = OFPROTO_MIN_REVALIDATE_PPS_DEFAULT;
+unsigned ofproto_max_unkeep_op = OFPROTO_MAX_UNKEEP_OP_DEFAULT;
size_t n_handlers, n_revalidators;
@@ -721,6 +722,14 @@ ofproto_set_min_revalidate_pps(unsigned min_revalidate_pps)
ofproto_min_revalidate_pps = min_revalidate_pps ? min_revalidate_pps : 1;
}
+/* Sets the maximum allowed unkeep operation inrevalidator. */
+void
+ofproto_set_max_unkeep_op(unsigned max_unkeep_op)
+{
+ofproto_max_unkeep_op = max_unkeep_op;
+}
+
+
/* If forward_bpdu is true, the NORMAL action will forward frames with
* reserved (e.g. STP) destination Ethernet addresses. if forward_bpdu is
false,
* the NORMAL action will drop these frames. */
diff --git a/ofproto/ofproto.h b/ofproto/ofproto.h
index 033c4cf..e1946ff 100644
--- a/ofproto/ofproto.h
+++ b/ofproto/ofproto.h
@@ -311,6 +311,7 @@ int ofproto_port_dump_done(struct ofproto_port_dump *);
#define OFPROTO_MAX_IDLE_DEFAULT 1 /* ms */
#define OFPROTO_MAX_REVALIDATOR_DEFAULT 500 /* ms */
#define OFPROTO_MIN_REVALIDATE_PPS_DEFAULT 5
+#define OFPROTO_MAX_UNKEEP_OP_DEFAULT 0
const char *ofproto_port_open_type(const struct ofproto *,
const char *port_type);
@@ -340,6 +341,7 @@ void ofproto_set_flow_limit(unsigned limit);
void ofproto_set_max_idle(unsigned max_idle);
void ofproto_set_max_revalidator(unsigned max_revalidator);
void ofproto_set_min_revalidate_pps(unsigned min_revalidate_pps);
+void ofproto_set_max_unkeep_op(unsigned max_unkeep_op);
void ofproto_set_forward_bpdu(struct ofproto *, bool forward_bpdu);
void ofproto_set_mac_table_config(struct ofproto *, unsigned idle_time,
size_t max_entries);
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 9095ebf..5248926 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -804,6 +804,9 @@ bridge_reconfigure(const struct ovsrec_open_vswitch
*ovs_cfg)
ofproto_set_min_revalidate_pps(
smap_get_int(_cfg->other_config, "min-revalidate-pps",
OFPROTO_MIN_REVALIDATE_PPS_DEFAULT));
+ofproto_set_max_unkeep_op(smap_get_int(_cfg->other_config,
+ "max-ukeep-op",
+ OFPROTO_MAX_UNKEEP_OP_DEFAULT));
Re: [ovs-dev] [PATCHv2] netdev-afxdp: Detect numa node id.
On 27 Sep 2019, at 19:26, William Tu wrote:
The patch detects the numa node id from the name of the netdev,
by reading the '/sys/class/net//device/numa_node'.
If not available, ex: virtual device, or any error happens,
return numa id 0.
Signed-off-by: William Tu
Will you update the “Limitations/Known Issues” section as part of
the libnuma and numa_alloc_onnode() patch?
---
v2:
Address feedback from Eelco
fix memory leak of xaspintf
log using INFO instead of WARN
---
lib/netdev-afxdp.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index 6e01803272aa..6ff1473461a6 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -552,11 +552,42 @@ out:
int
netdev_afxdp_get_numa_id(const struct netdev *netdev)
{
-/* FIXME: Get netdev's PCIe device ID, then find
- * its NUMA node id.
- */
-VLOG_INFO("FIXME: Device %s always use numa id 0.",
- netdev_get_name(netdev));
+const char *numa_node_path;
+long int node_id;
+char buffer[4];
+FILE *stream;
+int n;
+
+numa_node_path = xasprintf("/sys/class/net/%s/device/numa_node",
+ netdev_get_name(netdev));
+stream = fopen(numa_node_path, "r");
+if (!stream) {
+/* Virtual device does not have this info. */
+VLOG_INFO_RL(, "Open %s failed: %s, use numa_id 0",
+ numa_node_path, ovs_strerror(errno));
+free(numa_node_path);
+return 0;
+}
+
+n = fread(buffer, 1, sizeof buffer, stream);
+if (!n) {
+goto error;
+}
+
+node_id = strtol(buffer, NULL, 10);
+if (node_id < 0 || node_id > 2) {
+goto error;
+}
Any reason why you limit this to 2? Guess it depends on the kernel’s
CONFIG_NODES_SHIFT value. You might be able to use the libnuma API
numa_max_possible_node().
+
+fclose(stream);
+free(numa_node_path);
+return (int)node_id;
Guess you need a space after (int) node_id.
+
+error:
+VLOG_WARN_RL(, "Error detecting numa node of %s, use numa_id
0",
+ numa_node_path);
+free(numa_node_path);
+fclose(stream);
return 0;
}
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] group dp_hash method works incorrectly when using snat
Hi,
You have pointed out an interesting issue in the netdev datapath implementation
(not sure in how far the same applies also to the kernel datapath).
Conceptually, the dp_hash of a packet should be based on the current packet's
flow. It should not change if the headers remain unchanged.
For performance reasons, the actual implementation of the dp_hash action in
odp_execute.c bases the dp_hash value on the current RSS hash of the packet, if
it has one, and only computes it from the actual packet content if not.
However, the RSS hash of the packet is updated with every recirculation in
order to improve the EMC lookup success rate. So even if initially the RSS hash
was a suitable base for dp_hash (that itself is uncertain, as the
implemantation of the RSS hash is dependent on the NIC HW and might not satisfy
the algorithm specified as part of the dp_hash action), its volatility at
recirculation destroys the required property of the dp_hash.
What we could do is something like the following (not even compiler-tested):
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 563ad1da8..1937bb1e6 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -820,16 +820,22 @@ odp_execute_actions(void *dp, struct dp_packet_batch
*batch, bool steal,
uint32_t hash;
DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
-/* RSS hash can be used here instead of 5tuple for
- * performance reasons. */
-if (dp_packet_rss_valid(packet)) {
-hash = dp_packet_get_rss_hash(packet);
-hash = hash_int(hash, hash_act->hash_basis);
-} else {
-flow_extract(packet, );
-hash = flow_hash_5tuple(, hash_act->hash_basis);
+if (packet->md.dp_hash == 0) {
+if (packet->md.recirc_id == 0 &&
+dp_packet_rss_valid(packet)) {
+/* RSS hash is used here instead of 5tuple for
+ * performance reasons. */
+hash = dp_packet_get_rss_hash(packet);
+hash = hash_int(hash, hash_act->hash_basis);
+} else {
+flow_extract(packet, );
+hash = flow_hash_5tuple(,
hash_act->hash_basis);
+}
+if (unlikely(hash == 0)) {
+hash = 1;
+}
+packet->md.dp_hash = hash;
}
-packet->md.dp_hash = hash;
}
break;
}
@@ -842,6 +848,9 @@ odp_execute_actions(void *dp, struct dp_packet_batch
*batch, bool steal,
hash = flow_hash_symmetric_l3l4(,
hash_act->hash_basis,
false);
+if (unlikely(hash == 0)) {
+hash = 1;
+}
packet->md.dp_hash = hash;
}
break;
diff --git a/lib/packets.c b/lib/packets.c
index ab0b1a36d..a03a3ab61 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -391,6 +391,8 @@ push_mpls(struct dp_packet *packet, ovs_be16 ethtype,
ovs_be32 lse)
header = dp_packet_resize_l2_5(packet, MPLS_HLEN);
memmove(header, header + MPLS_HLEN, len);
memcpy(header + len, , sizeof lse);
+/* Invalidate dp_hash */
+packet->md.dp_hash = 0;
}
/* If 'packet' is an MPLS packet, removes its outermost MPLS label stack entry.
@@ -411,6 +413,8 @@ pop_mpls(struct dp_packet *packet, ovs_be16 ethtype)
/* Shift the l2 header forward. */
memmove((char*)dp_packet_data(packet) + MPLS_HLEN,
dp_packet_data(packet), len);
dp_packet_resize_l2_5(packet, -MPLS_HLEN);
+/* Invalidate dp_hash */
+packet->md.dp_hash = 0;
}
}
@@ -444,6 +448,8 @@ push_nsh(struct dp_packet *packet, const struct nsh_hdr
*nsh_hdr_src)
packet->packet_type = htonl(PT_NSH);
dp_packet_reset_offsets(packet);
packet->l3_ofs = 0;
+/* Invalidate dp_hash */
+packet->md.dp_hash = 0;
}
bool
@@ -474,6 +480,8 @@ pop_nsh(struct dp_packet *packet)
length = nsh_hdr_len(nsh);
dp_packet_reset_packet(packet, length);
+/* Invalidate dp_hash */
+packet->md.dp_hash = 0;
packet->packet_type = htonl(next_pt);
/* Packet must be recirculated for further processing. */
}
diff --git a/lib/packets.h b/lib/packets.h
index a4bee3819..8691fa0c2 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -98,8 +98,7 @@ PADDED_MEMBERS_CACHELINE_MARKER(CACHE_LINE_SIZE, cacheline0,
uint32_t recirc_id; /* Recirculation id carried with the
recirculating
[ovs-dev] (no subject)
Heeft u een persoonlijke lening, een zakelijke lening of projectfinanciering / investeringslening nodig. Wij bieden deze en nog veel meer financieringsdiensten tegen een vaste rentevoet van 3% per jaar. Neem voor meer informatie contact met ons op via e-mail: sigmafinance...@gmail.com stuur e-mail alleen naar: sigmafinance...@gmail.com Do you need a personal loan, a business loan or project financing/investment loan. We offer these and many more financing services at a fixed interest rate of 3% per year. For more information, kindly contact us via Email: sigmafinance...@gmail.com send email only to : sigmafinance...@gmail.com The information contained in this message may be confidential and protected from disclosure under applicable law. These materials are intended only for the use of the intended recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and then delete it from your computer. All e-mail sent to this address will be received by the Littleton Regional Healthcare e-mail system and is subject to archiving and review by someone other than the intended recipient such as technical support and/or management personnel." ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Painting, Renovation and Epoxy Flooring
http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/674f9b33e3a5e778f1e2cff565f205ef92242237 About Us http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/89a8d8d16e51bcfe00d75d1fcb892ac5d88ba95b Services http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/2413522413732719aa4c2660996b1fb91e4a256f Promotion http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/29c5334b4fa1a8f4e443fe6857de83d9ee424e3c Our Portfolio http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/855105cdc6c4be4a1dd9c969c860c3ff60c001b4 Contact Us http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/9c160ab08b9ef3e6bef7e440046c0dd770cf35b5 Email http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/22935e12baf54dbda85ddb008a833d84f4cf39c6 Сall Us http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/9c160ab08b9ef3e6bef7e440046c0dd770cf35b5 Wall Art & Design Epoxy Flooring Internal & External Paitning Waterproofing GET IN TOUCH! (HP) +65 84822650 (Tel) +65 62812408 (Fax) +65 62812562 Email: vince.starli...@gmail.com http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/7378ce9527d80878bf74944fafc34adc5e95969f You are receiving this email because you have visited our site or asked us about the regular newsletter. Unsubscribe http://vps.starlightwaterproofing.com.sg/newsletter/index.php/campaigns/he459b3ev909d/track-url/kp0883gn9y360/df3c2830af29b2cebdd290b60866ef5baff68aef and reply with "Remove" in the subject. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/1] ovsdb-client: fix memory leak in do_needs_conversion() and do_convert()
Memory leak itself is not so important, however the problem is that
it is caused by forgetting to close rpc channel which might in
a long term lead to the leak of system resources.
Memory leak is reported by Valgrin running test suite and is expressed as:
==29472== 784 (600 direct, 184 indirect) bytes in 1 blocks are definitely lost
in loss record 23 of 23
==29472==at 0x4C2FB55: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29472==by 0x449D32: xcalloc (util.c:121)
==29472==by 0x432147: jsonrpc_open (jsonrpc.c:87)
==29472==by 0x40ABBE: open_jsonrpc (ovsdb-client.c:528)
==29472==by 0x40ABBE: open_rpc (ovsdb-client.c:143)
==29472==by 0x40AE50: do_needs_conversion (ovsdb-client.c:1670)
==29472==by 0x405F76: main (ovsdb-client.c:282)
==29464== 784 (600 direct, 184 indirect) bytes in 1 blocks are definitely lost
in loss record 23 of 23
==29464==at 0x4C2FB55: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29464==by 0x449D32: xcalloc (util.c:121)
==29464==by 0x432147: jsonrpc_open (jsonrpc.c:87)
==29464==by 0x40ABBE: open_jsonrpc (ovsdb-client.c:528)
==29464==by 0x40ABBE: open_rpc (ovsdb-client.c:143)
==29464==by 0x40AF5A: do_convert (ovsdb-client.c:1644)
==29464==by 0x405F76: main (ovsdb-client.c:282)
Signed-off-by: Damijan Skvarc
---
ovsdb/ovsdb-client.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ovsdb/ovsdb-client.c b/ovsdb/ovsdb-client.c
index e3ef372..e78e9d9 100644
--- a/ovsdb/ovsdb-client.c
+++ b/ovsdb/ovsdb-client.c
@@ -1657,6 +1657,7 @@ do_convert(struct jsonrpc *rpc, const char *database_
OVS_UNUSED,
check_txn(jsonrpc_transact_block(rpc, request, ), );
jsonrpc_msg_destroy(reply);
ovsdb_schema_destroy(new_schema);
+jsonrpc_close(rpc);
}
static void
@@ -1677,6 +1678,7 @@ do_needs_conversion(struct jsonrpc *rpc, const char
*database_ OVS_UNUSED,
puts(ovsdb_schema_equal(schema1, schema2) ? "no" : "yes");
ovsdb_schema_destroy(schema1);
ovsdb_schema_destroy(schema2);
+jsonrpc_close(rpc);
}
struct dump_table_aux {
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/1] ovsdb-client: fix memory leak in is_database_clustered() function.
Memory leak is reported while running test suite. It is evidenced with the following report: ==18447== 1,868 (48 direct, 1,820 indirect) bytes in 1 blocks are definitely lost in loss record 45 of 45 ==18447==at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18447==by 0x449C02: xcalloc (util.c:121) ==18447==by 0x432949: jsonrpc_msg_from_json (jsonrpc.c:697) ==18447==by 0x432A8F: jsonrpc_parse_received_message (jsonrpc.c:472) ==18447==by 0x432A8F: jsonrpc_recv.part.7 (jsonrpc.c:338) ==18447==by 0x432D0B: jsonrpc_recv (jsonrpc.c:297) ==18447==by 0x432D0B: jsonrpc_recv_block (jsonrpc.c:402) ==18447==by 0x4330BB: jsonrpc_transact_block (jsonrpc.c:436) ==18447==by 0x40A7C1: is_database_clustered (ovsdb-client.c:1624) ==18447==by 0x40AE3F: do_needs_conversion (ovsdb-client.c:1670) ==18447==by 0x405F76: main (ovsdb-client.c:282) Signed-off-by: Damijan Skvarc --- ovsdb/ovsdb-client.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ovsdb/ovsdb-client.c b/ovsdb/ovsdb-client.c index bc12d42..e3ef372 100644 --- a/ovsdb/ovsdb-client.c +++ b/ovsdb/ovsdb-client.c @@ -1627,7 +1627,9 @@ is_database_clustered(struct jsonrpc *rpc, const char *database) const struct json *row = parse_database_info_reply( reply, jsonrpc_get_name(rpc), database, NULL); -return !strcmp(parse_string_column(row, "model"), "clustered"); +bool clustered = !strcmp(parse_string_column(row, "model"), "clustered"); +jsonrpc_msg_destroy(reply); +return clustered; } static void -- 2.7.4 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] bad performance delete tc flower rule in revalidator threads
Hi all, I test upstrem openvswitch with upstream net-next branch. It support rtnl-independent rule add and delete. I did three test. 1. add rule only There is good performance for add rules concurrent in the handler threads. 2. delete rule only There is bad performance for del rules. But I test the delete rules concurrent using tc is quite good. I think the problem maybe that the delete actions work in the revalidator thread which make the performance bad? If there are 3k rules delete at the same time there will be the following log timeval(revalidator62)|WARN|Unreasonably long 1189ms poll interval (6ms user, 34ms system) 2019-09-30T07:23:57.741Z|00052|timeval(revalidator62)|WARN|faults: 1 minor, 0 major 2019-09-30T07:23:57.741Z|00053|timeval(revalidator62)|WARN|context switches: 1110 voluntary, 1 involuntary 3. add and delete rules concurrently There is also bad performance for this case. First the revalidator will block long time, and later the handler will also block long time. It means the revalidator block also make the handler block? But I test this case through tc rule get good performance. For the second and last case, I add a ofproto_max_unkeep_op parameter to limit the delete/modify operation make thing go well. I also set the max-revalidator to 1. BR wenxu ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/1] ovsdb-client: fix memory leak to prevent valgrind reporting memory leaks while running test suite
memory leaks are reported in several tests and are expressed in a following way:
==29840== 208 (48 direct, 160 indirect) bytes in 1 blocks are definitely lost
in loss record 43 of 44
==29840==at 0x4C2FB55: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29840==by 0x449D12: xcalloc (util.c:121)
==29840==by 0x432949: jsonrpc_msg_from_json (jsonrpc.c:697)
==29840==by 0x432A8F: jsonrpc_parse_received_message (jsonrpc.c:472)
==29840==by 0x432A8F: jsonrpc_recv.part.7 (jsonrpc.c:338)
==29840==by 0x4338F7: jsonrpc_recv (jsonrpc.c:1139)
==29840==by 0x4338F7: jsonrpc_session_recv (jsonrpc.c:1112)
==29840==by 0x40719B: do_wait (ovsdb-client.c:2463)
==29840==by 0x405F76: main (ovsdb-client.c:282)
Signed-off-by: Damijan Skvarc
---
ovsdb/ovsdb-client.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ovsdb/ovsdb-client.c b/ovsdb/ovsdb-client.c
index bfc90e6..bc12d42 100644
--- a/ovsdb/ovsdb-client.c
+++ b/ovsdb/ovsdb-client.c
@@ -2464,11 +2464,13 @@ do_wait(struct jsonrpc *rpc_unused OVS_UNUSED,
if (reply && reply->id) {
if (sdca_id && json_equal(sdca_id, reply->id)) {
if (reply->type == JSONRPC_ERROR) {
+jsonrpc_msg_destroy(reply);
ovs_fatal(0, "%s: set_db_change_aware failed (%s)",
jsonrpc_session_get_name(js),
json_to_string(reply->error, 0));
}
} else if (txn_id && json_equal(txn_id, reply->id)) {
+jsonrpc_msg_destroy(reply);
check_transaction_reply(reply);
exit(0);
}
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
