--
Hallo Charity Gewinner,
Herzlichen Glückwunsch, wir möchten Sie darüber informieren, dass Sie in der
aktuellen BILL & MELINDA GATES Business Magnate Charity Spende die Summe
von €850.000,00, gewonnen haben, Ihre E-Mail-Adresse wurde unter den 10
glücklichen Gewinnern ausgewählt . ..
On Fri, Nov 02, 2018 at 08:31:06AM -0700, Gregory Rose wrote:
> On 11/2/2018 4:45 AM, Jaime Caamaño Ruiz wrote:
> >Upstream commit:
> > commit 46ebe2834ba5b541f28ee72e556a3fed42c47570
> > Author: Jaime Caamaño Ruiz
> > Date: Wed Oct 31 18:52:03 2018 +0100
> >
> > openvswitch:
Thanks for the patches, I applied this to master.
On Fri, Nov 02, 2018 at 01:17:25PM -0700, Yifeng Sun wrote:
> Looks good to me, thanks.
>
> Reviewed-by: Yifeng Sun
>
> On Thu, Nov 1, 2018 at 8:07 AM Ben Pfaff wrote:
>
> > On my machine it takes almost a second for enchant to read its
I guess I had in mind that OVS_RESOLV_CONF would point to an alternate
file to be used instead of /etc/resolve.conf.
On Fri, Nov 02, 2018 at 02:51:19PM -0700, Yifeng Sun wrote:
> Hi Ben,
>
> Based on the discussion, I am going to create a dns_resolve_timeout__
> specifically for
> sandboxing and
On Fri, Nov 02, 2018 at 03:25:29PM -0700, Zak Whittington wrote:
> Commit 7ed73428a changed the behavior of flow-restore-wait to
> also prevent the switch from connecting to controllers in the
> controller table, but failed to update the man page documentation
> generated by vswitchd/vswitch.xml
On Fri, Nov 02, 2018 at 01:57:08PM -0700, Gregory Rose wrote:
> On 11/2/2018 1:46 PM, Ben Pfaff wrote:
> >On Fri, Nov 02, 2018 at 08:31:06AM -0700, Gregory Rose wrote:
> >>On 11/2/2018 4:45 AM, Jaime Caamaño Ruiz wrote:
> >>>Upstream commit:
> >>> commit
¡Cierre de Inscripciones!
Las relaciones laborales pueden y deben ser más prácticas en sus etapas, para
esto es que existen los departamentos de recursos humanos y otro tipo de
organismos que se encargan de mediar entre ambas partes cuando por algún motivo
la relación laboral llega a su
Commit 7ed73428a changed the behavior of flow-restore-wait to
also prevent the switch from connecting to controllers in the
controller table, but failed to update the man page documentation
generated by vswitchd/vswitch.xml to reflect this.
This commit adds that documentation.
Signed-off-by: Zak
RAFT requires odd number of nodes. With 2 out of 4 down, there never be a
majority vote.
Best Regards,
Paul Greenberg
From: ovs-dev-boun...@openvswitch.org on behalf of Paul Greenberg
Sent: Friday, November 2, 2018 5:09 PM
To: Ben Pfaff
Cc: ovs dev
Subject:
Hi Ben,
Based on the discussion, I am going to create a dns_resolve_timeout__
specifically for
sandboxing and testing. In runtime, dns resolving will check the
environment variable,
say OVS_RESOLV_CONF, to decide whether or not to use the timeout version of
actual
dns resolution. Does this sound
Looks good to me, thanks.
Reviewed-by: Yifeng Sun
On Thu, Nov 1, 2018 at 8:07 AM Ben Pfaff wrote:
> On my machine it takes almost a second for enchant to read its dictionary.
> This time is wasted when spell checking is not enabled. This commit makes
> checkpatch read the dictionary only
A few weeks ago, I sent a detailed document[1] with a tasklist of what
would need to be done to separate OVN from OVS. To summarize, the work
was divided into four phases:
1) Physical separation.
2) Compile time compatibilty.
3) Runtime compatibility.
4) Separation of OVN and OVS packages.
Hi Ben,
Let me clarify. Based on my observation, once a server loses touch with the
rest of the cluster you have to rejoin it. At the same time it is not readily
apparent that you have to do the clean up (removal) yourself. For example, you
had a cluster of 3 nodes, then after some time one
On Fri, Nov 02, 2018 at 05:34:56PM +, Stokes, Ian wrote:
> Hi Ben,
>
> The following changes since commit ff7067e076bc0219aba7ab180e8442644d0c1054:
>
> python-c-ext: Fix memory leak in Parser_finish (2018-10-31 10:35:45 -0700)
>
> are available in the git repository at:
>
>
On Fri, Nov 02, 2018 at 04:05:13PM -0400, Mark Michelson wrote:
> On 11/01/2018 02:15 PM, Yifeng Sun wrote:
> >Hi Mark,
> >
> >Thanks a lot for the information, that is very helpful.
> >
> > From your comments, I understand that we should keep the current
> >DNS resolving behavior as is. The thing
Looks good to me, thanks.
Reviewed-by: Yifeng Sun
On Thu, Nov 1, 2018 at 8:06 AM Ben Pfaff wrote:
> Somehow some such patches snuck through. checkpatch caught them (and the
> committer missed that) but this makes it even more explicit.
>
> Signed-off-by: Ben Pfaff
> ---
>
On 11/01/2018 02:15 PM, Yifeng Sun wrote:
Hi Mark,
Thanks a lot for the information, that is very helpful.
From your comments, I understand that we should keep the current
DNS resolving behavior as is. The thing we need to improve is to
stop resolving if there is no /etc/resolv.conf
On Fri, Nov 02, 2018 at 05:33:39PM +, Stokes, Ian wrote:
> Hi Ben,
>
> The following changes since commit af26093ab197c309dc0cfa83c5a2db34706f6021:
>
> connmgr: Improve interface for setting controllers. (2018-10-31 16:04:36
> -0700)
>
> are available in the git repository at:
>
>
On Fri, Nov 02, 2018 at 03:13:35PM -0400, Mark Michelson wrote:
> With this in mind, we'd like to propose an amended plan.
[...]
> In order to facilitate this, OVS will need to be outfitted with ways for OVN
> to probe for the existence of features at runtime. The most obvious use of
> this
On Thu, Nov 01, 2018 at 03:05:31PM -0700, Yifeng Sun wrote:
> Currently, if unroll_xlate is passed to ovs-ofctl as one of actions,
> let say 'ovs-ofctl add-flow br0 in_port=1,actions=unroll_xlate',
> ovs-ofctl will crash. This patch fixes it by returning an error
> message.
>
> Reported-at:
On 11/2/2018 1:46 PM, Ben Pfaff wrote:
On Fri, Nov 02, 2018 at 08:31:06AM -0700, Gregory Rose wrote:
On 11/2/2018 4:45 AM, Jaime Caamaño Ruiz wrote:
Upstream commit:
commit 46ebe2834ba5b541f28ee72e556a3fed42c47570
Author: Jaime Caamaño Ruiz
Date: Wed Oct 31 18:52:03 2018
On Fri, Nov 02, 2018 at 08:34:16AM +0800, xurong00037997 wrote:
> Signed-off-by: Xu Rong
Thanks for finding the bug and fixing it! I applied this to master and
branch-2.10.
___
dev mailing list
d...@openvswitch.org
On Fri, Nov 02, 2018 at 11:24:30AM +0300, Ilya Maximets wrote:
> On 01.11.2018 21:29, Ben Pfaff wrote:
> > On Thu, Nov 01, 2018 at 04:58:40PM +0300, Ilya Maximets wrote:
> >> revalidator_purge() iterates and modifies umap->cmap. This should
> >> not happen in quiescent state, because cmap
No problem. I fixed that up and applied this to master.
On Thu, Nov 01, 2018 at 04:11:57PM -0700, Yifeng Sun wrote:
> Sorry, there is a typo in the message,
> the leaked free string => the leaked error string
> Ben, do you mind fixing it? Thanks.
>
> Best,
> Yifeng
>
> On Thu, Nov 1, 2018 at
On Thu, Nov 01, 2018 at 11:51:21AM -0700, Yifeng Sun wrote:
> Left shift int (1 here) can result in a negative value. This is an undefined
> behavior according to ISO C99 (6.5.7).
>
> The error message reported by oss-fuzz is:
> runtime error: left shift of 1 by 31 places cannot be represented
I'm not sure what you mean. Do you mean that the commands for removing
a server from a cluster aren't documented well enough? Or something
else?
On Thu, Nov 01, 2018 at 07:03:07PM +, Paul Greenberg wrote:
> I would also add that when a server leaves a cluster, it must be removed
> using
Thanks, applied.
On Thu, Nov 01, 2018 at 11:25:10AM -0700, Yifeng Sun wrote:
> Looks good to me, thanks.
> Reviewed-by: Yifeng Sun
>
> On Mon, Oct 29, 2018 at 4:37 PM Ben Pfaff wrote:
>
> > This wasn't clear from the documentation.
> >
> > Reported-by; Paul Greenberg
> > Signed-off-by: Ben
revalidator_purge() iterates and modifies umap->cmap. This should
not happen in quiescent state, because cmap implementation based
on rcu protected variables. Let's narrow the quiescent period
to avoid possible wrong memory accesses.
CC: Joe Stringer
Fixes: 9fce0584a643 ("revalidator: Use 'cmap'
Hi Ben,
The following changes since commit ff7067e076bc0219aba7ab180e8442644d0c1054:
python-c-ext: Fix memory leak in Parser_finish (2018-10-31 10:35:45 -0700)
are available in the git repository at:
https://github.com/istokes/ovs dpdk_merge_2_6
for you to fetch changes up to
On 02.11.2018 19:45, Stokes, Ian wrote:
>> On 02/11/2018 10:35, Ilya Maximets wrote:
>>> On 02.11.2018 12:06, Tiago Lam wrote:
From: Mark Kavanagh
dp_packets are created using xmalloc(); in the case of OvS-DPDK, it's
possible the the resultant mbuf portion of the dp_packet
Hi Ben,
The following changes since commit 5272e0c71efe377317de562ce9aa1f025130be38:
python-c-ext: Fix memory leak in Parser_finish (2018-10-31 10:35:39 -0700)
are available in the git repository at:
https://github.com/istokes/ovs dpdk_merge_2_7
for you to fetch changes up to
Hi Ben,
The following changes since commit b9d89442eabbb71267c60469eb69450583de31a3:
ovn-northd: Fix memory leak in free_chassis_queueid(). (2018-10-31 10:55:19
-0700)
are available in the git repository at:
https://github.com/istokes/ovs dpdk_merge_2_8
for you to fetch changes up to
Hi Ben,
The following changes since commit 9d469b1c2d2d473ca733f661e8c9004489bf6c0e:
ovn: Fix IPv6 DAD failure for container ports (2018-10-31 13:59:24 -0700)
are available in the git repository at:
https://github.com/istokes/ovs dpdk_merge_2_9
for you to fetch changes up to
Hi Ben,
The following changes since commit af26093ab197c309dc0cfa83c5a2db34706f6021:
connmgr: Improve interface for setting controllers. (2018-10-31 16:04:36
-0700)
are available in the git repository at:
https://github.com/istokes/ovs dpdk_merge
for you to fetch changes up to
Hi Ben,
The following changes since commit 855949977a0b494e556d87e795712db676d2e66c:
ovn-northd: Fix memory leak in free_chassis_queueid(). (2018-10-31 10:55:05
-0700)
are available in the git repository at:
https://github.com/istokes/ovs dpdk_merge_2_10
for you to fetch changes up to
On 02/11/2018 10:35, Ilya Maximets wrote:
> On 02.11.2018 12:06, Tiago Lam wrote:
>> From: Mark Kavanagh
>>
>> dp_packets are created using xmalloc(); in the case of OvS-DPDK, it's
>> possible the the resultant mbuf portion of the dp_packet contains
>> random data. For some mbuf fields,
In some cases the code didn't set these columns.
Found by inspection.
Signed-off-by: Ben Pfaff
---
ovn/northd/ovn-northd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index e42ceea99264..665b0d820a05 100644
---
> On 02/11/2018 10:35, Ilya Maximets wrote:
> > On 02.11.2018 12:06, Tiago Lam wrote:
> >> From: Mark Kavanagh
> >>
> >> dp_packets are created using xmalloc(); in the case of OvS-DPDK, it's
> >> possible the the resultant mbuf portion of the dp_packet contains
> >> random data. For some mbuf
When CONFIG_CC_OPTIMIZE_FOR_DEBUGGING is enabled, the compiler
fails to optimize out a dead code path, which leads to a link failure:
net/openvswitch/conntrack.o: In function `ovs_ct_set_labels':
conntrack.c:(.text+0x2e60): undefined reference to `nf_connlabels_replace'
In this configuration, we
On 11/2/2018 4:45 AM, Jaime Caamaño Ruiz wrote:
Upstream commit:
commit 46ebe2834ba5b541f28ee72e556a3fed42c47570
Author: Jaime Caamaño Ruiz
Date: Wed Oct 31 18:52:03 2018 +0100
openvswitch: Fix push/pop ethernet validation
When there are both pop and push ethernet
On 02.11.2018 1:31, Ian Stokes wrote:
> This commit fixes netdev_dpdk_get_features() by initializing a bitmap
> that represents current features to zero and accounting for non defined
> link speed values in the OpenFlow spec.
>
> The current approach for retrieving netdev dpdk features uses a
>
Upstream commit:
commit 46ebe2834ba5b541f28ee72e556a3fed42c47570
Author: Jaime Caamaño Ruiz
Date: Wed Oct 31 18:52:03 2018 +0100
openvswitch: Fix push/pop ethernet validation
When there are both pop and push ethernet header actions among the
actions to be applied to a
> On 02.11.2018 13:45, Ian Stokes wrote:
> > Report the link speed of the device in netdev_dpdk_get_status()
> > function.
> >
> > Link speed is already reported as part of the netdev_get_features()
> > function. However only link speeds defined in the OpenFlow specs are
> > supported so speeds
On 02.11.2018 12:54, Ian Stokes wrote:
> Report the link speed of the device in netdev_dpdk_get_status()
> function.
>
> Link speed is already reported as part of the netdev_get_features()
> function. However only link speeds defined in the OpenFlow specs are
> supported so speeds such as 25 Gbps
On 02.11.2018 12:06, Tiago Lam wrote:
> From: Mark Kavanagh
>
> dp_packets are created using xmalloc(); in the case of OvS-DPDK, it's
> possible the the resultant mbuf portion of the dp_packet contains
> random data. For some mbuf fields, specifically those related to
> multi-segment mbufs
From: Numan Siddique
When 'make check' is called by the mock rpm build (which disables networking),
the test "ovn-nbctl: LBs - daemon" fails when it runs the command
"ovn-nbctl lb-add lb0 30.0.0.1a 192.168.10.10:80,192.168.10.20:80". ovn-nbctl
extracts the vip by calling the socket util function
> On 02.11.2018 14:01, Stokes, Ian wrote:
> >> Ilya Maximets (3):
> >> dpif-netdev: Fix cmap node use after free on flow disassociation.
> >> netdev-dpdk: Print port name in offload API messages.
> >> netdev-dpdk: Dump flow patterns only if debug enabled.
> >>
> >
> > I take it the intention
On 02.11.2018 13:45, Ian Stokes wrote:
> Report the link speed of the device in netdev_dpdk_get_status()
> function.
>
> Link speed is already reported as part of the netdev_get_features()
> function. However only link speeds defined in the OpenFlow specs are
> supported so speeds such as 25 Gbps
On 02.11.2018 14:01, Stokes, Ian wrote:
>> Ilya Maximets (3):
>> dpif-netdev: Fix cmap node use after free on flow disassociation.
>> netdev-dpdk: Print port name in offload API messages.
>> netdev-dpdk: Dump flow patterns only if debug enabled.
>>
>
> I take it the intention is to backport
> Ilya Maximets (3):
> dpif-netdev: Fix cmap node use after free on flow disassociation.
> netdev-dpdk: Print port name in offload API messages.
> netdev-dpdk: Dump flow patterns only if debug enabled.
>
I take it the intention is to backport this series to 2.10 also Ilya? Patches 2
and 3
> On 31.10.2018 20:01, Ophir Munk wrote:
> > Hi,
> > It is a good idea to remove the macro from the h file.
> > Please find more comments inline
> >
> >> -Original Message-
> >> From: Lam, Tiago [mailto:tiago@intel.com]
> >> Sent: Wednesday, October 31, 2018 2:41 PM
> >> To: Stokes,
> On 01.11.2018 3:30, Flavio Leitner wrote:
> > On Wed, Oct 31, 2018 at 06:44:09PM +0300, Ilya Maximets wrote:
> >> Flow offloading thread uses concurrent hash maps which are based on
> >> rcu protected variables. It must use them while in active state.
> >> Working in a quiescent state could
> On 02.11.2018 12:54, Ian Stokes wrote:
> > +/* Not all link speeds are defined in the OpenFlow specs e.g. 25
> Gbps.
> > + * In that case the speed will not be reported as part of the usual
> > + * call to get_features(). Get the link speed of the device and add
> it
> > + *
Report the link speed of the device in netdev_dpdk_get_status()
function.
Link speed is already reported as part of the netdev_get_features()
function. However only link speeds defined in the OpenFlow specs are
supported so speeds such as 25 Gbps etc. are not shown. The link
speed for the device
On 02.11.2018 12:23, Stokes, Ian wrote:
>> On 02.11.2018 1:31, Ian Stokes wrote:
>>> Report the link speed of the device in netdev_dpdk_get_status()
>>> function.
>>>
>>> Link speed is already reported as part of the netdev_get_features()
>>> function. However only link speeds defined in the
Report the link speed of the device in netdev_dpdk_get_status()
function.
Link speed is already reported as part of the netdev_get_features()
function. However only link speeds defined in the OpenFlow specs are
supported so speeds such as 25 Gbps etc. are not shown. The link
speed for the device
> On 02.11.2018 1:31, Ian Stokes wrote:
> > Report the link speed of the device in netdev_dpdk_get_status()
> > function.
> >
> > Link speed is already reported as part of the netdev_get_features()
> > function. However only link speeds defined in the OpenFlow specs are
> > supported so speeds
On 01/11/2018 19:30, Stokes, Ian wrote:
>> Hi Tiago, Ian,
>>
>> On Tue, Oct 16, 2018 at 02:28:56PM +, Stokes, Ian wrote:
From: Mark Kavanagh
dp_packets are created using xmalloc(); in the case of OvS-DPDK,
it's possible the the resultant mbuf portion of the dp_packet
When enabled with DPDK OvS deals with two types of packets, the ones
coming from the mempool and the ones locally created by OvS - which are
copied to mempool mbufs before output. In the latter, the space is
allocated from the system, while in the former the mbufs are allocated
from a mempool,
From: Mark Kavanagh
dp_packets are created using xmalloc(); in the case of OvS-DPDK, it's
possible the the resultant mbuf portion of the dp_packet contains
random data. For some mbuf fields, specifically those related to
multi-segment mbufs and/or offload features, random values may cause
From: Mark Kavanagh
There are numerous factors that must be considered when calculating
the size of an mbuf:
- the data portion of the mbuf must be sized in accordance With Rx
buffer alignment (typically 1024B). So, for example, in order to
successfully receive and capture a 1500B packet,
This series is a split from the multi-seg mbuf series, "v11 - Support
multi-segment mbufs"; Hence why it starts at v12.
v12: - Rebase on master af26093 ("connmgr: Improve interface for setting
controllers.");
- Address Ian's comments:
- Updated memory model calculations in
On 01.11.2018 21:30, Ben Pfaff wrote:
> On Thu, Nov 01, 2018 at 04:58:41PM +0300, Ilya Maximets wrote:
>> Datapath implementation of 'flow_flush()' could use cmaps.
>> dpif-netdev actively uses them to store flow tables and the polling
>> threads. Flushing flows while in a quiescent state may lead
On 02.11.2018 1:31, Ian Stokes wrote:
> Report the link speed of the device in netdev_dpdk_get_status()
> function.
>
> Link speed is already reported as part of the netdev_get_features()
> function. However only link speeds defined in the OpenFlow specs are
> supported so speeds such as 25 Gbps
On 01.11.2018 21:29, Ben Pfaff wrote:
> On Thu, Nov 01, 2018 at 04:58:40PM +0300, Ilya Maximets wrote:
>> revalidator_purge() iterates and modifies umap->cmap. This should
>> not happen in quiescent state, because cmap implementation based
>> on rcu protected variables. Let's move the thread to
65 matches
Mail list logo
