Thanks Alex,
I've pushed applied this patch to master and branch-2.3.
On 2 July 2014 16:02, Alex Wang wrote:
> Thanks for the fix,
>
> Acked-by: Alex Wang
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Jul 01, 2014 at 04:58:06PM -0700, Jesse Gross wrote:
> On Sun, Jun 29, 2014 at 9:20 PM, Simon Horman wrote:
> > This patch loosens the restrictions surrounding push and pop MPLS actions
> > such that they will be allowed after a pop VLAN action if the inner
> > ethernet type is acceptable
Thanks for the fix,
Acked-by: Alex Wang
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Jul 1, 2014 at 5:10 PM, Ben Pfaff wrote:
> On Tue, Jul 01, 2014 at 05:00:45PM -0700, Jesse Gross wrote:
>> On Tue, Jul 1, 2014 at 3:49 PM, Ben Pfaff wrote:
>> > I found when reconfiguring my kernel that if I turned on NET_IPGRE, GRE
>> > tunnels no longer worked. (I might not understand
There are many possible ways that a flow can be invalid so we've
added logging for most of them. This adds logs for the remaining
possible cases so there isn't any ambiguity while debugging.
CC: Federico Iezzi
Signed-off-by: Jesse Gross
---
datapath/datapath.c | 12 +---
datapath/fl
On Tue, Jul 1, 2014 at 3:49 PM, Ben Pfaff wrote:
> I found when reconfiguring my kernel that if I turned on NET_IPGRE, GRE
> tunnels no longer worked. (I might not understand this issue.)
>
> Signed-off-by: Ben Pfaff
> ---
> INSTALL |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-
On Sun, Jun 29, 2014 at 9:20 PM, Simon Horman wrote:
> This patch loosens the restrictions surrounding push and pop MPLS actions
> such that they will be allowed after a pop VLAN action if the inner
> ethernet type is acceptable for pop and push MPLS actions. This implies
> that there is only one
The should_revalidate() optimisation introduced with commit 698ffe3623
(revalidator: Only revalidate high-throughput flows.) was a little
aggressive, occasionally deleting flows even when OVS is quite capable
of performing full revalidation.
This commit modifies the logic to:
* Firstly, check if w
I found when reconfiguring my kernel that if I turned on NET_IPGRE, GRE
tunnels no longer worked. (I might not understand this issue.)
Signed-off-by: Ben Pfaff
---
INSTALL |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/INSTALL b/INSTALL
index bfd053b..8b2097f 100644
Since the sys_id is different from the existing ones, when partner of A came
back, partner of A shouldn't be really added to lacp (which isn't possible) or
shouldn't be considered to be the "lead".
Thanks,
Anoob.
From: Zoltan Kiss
Sent: 01 July 2014 20:5
Thx very much, applied to master, branch-2.3 with suggested changes.
On Tue, Jul 1, 2014 at 12:22 PM, Pravin Shelar wrote:
> On Tue, Jul 1, 2014 at 10:46 AM, Alex Wang wrote:
> > Due to the race condition in userspace, there is chance that two
> > overlapping megaflows could be installed in da
This patch modifies the LACP selection logic by prefering a slaves with up and
running partners when looking for a lead.
That fixes the following scenario:
- bond has 2 ports, A and B, their other ends are in separate chassis with
MC-LAG sync
- the partner of port A is restarted
- port B is still
On Tue, Jul 1, 2014 at 12:26 PM, Pravin Shelar wrote:
> On Tue, Jul 1, 2014 at 12:22 PM, Jesse Gross wrote:
>> On Tue, Jul 1, 2014 at 11:33 AM, Pritesh Kothari (pritkoth)
>> wrote:
>>>
>>> On Jul 1, 2014, at 11:18 AM, Pravin Shelar wrote:
>>>
why not just check for HAVE_U64_STATS_FETCH_BEG
On Tue, Jul 1, 2014 at 12:22 PM, Jesse Gross wrote:
> On Tue, Jul 1, 2014 at 11:33 AM, Pritesh Kothari (pritkoth)
> wrote:
>>
>> On Jul 1, 2014, at 11:18 AM, Pravin Shelar wrote:
>>
>>> why not just check for HAVE_U64_STATS_FETCH_BEGIN_IRQ?
>>
>> because of this which was added in 3.13, i guess:
On Tue, Jul 1, 2014 at 11:33 AM, Pritesh Kothari (pritkoth)
wrote:
>
> On Jul 1, 2014, at 11:18 AM, Pravin Shelar wrote:
>
>> why not just check for HAVE_U64_STATS_FETCH_BEGIN_IRQ?
>
> because of this which was added in 3.13, i guess:
>
> -#if LINUX_VERSION_CODE < KERNEL_VERSION(3,13,0)
> -
> -#i
On Tue, Jul 1, 2014 at 10:46 AM, Alex Wang wrote:
> Due to the race condition in userspace, there is chance that two
> overlapping megaflows could be installed in datapath. And this
> causes userspace unable to delete the less inclusive megaflow flow
> even after it timeout, since the flow_del lo
On Jul 1, 2014, at 11:18 AM, Pravin Shelar wrote:
> why not just check for HAVE_U64_STATS_FETCH_BEGIN_IRQ?
because of this which was added in 3.13, i guess:
-#if LINUX_VERSION_CODE < KERNEL_VERSION(3,13,0)
-
-#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
-# define u64_stats_init(syncp) seqco
On Mon, Jun 30, 2014 at 6:01 PM, Jesse Gross wrote:
> The upstream u64_stats API has been changed to remove the _bh()
> versions and switch all consumers to use IRQ safe variants instead.
> This was done to be safe for netpoll generated packets, which can
> occur in hard IRQ context. From a safety
On Tue, Jul 1, 2014 at 11:06 AM, Ben Pfaff wrote:
> On Tue, Jul 1, 2014 at 10:58 AM, Gurucharan Shetty wrote:
>> On Mon, Jun 30, 2014 at 10:20 AM, Ben Pfaff wrote:
>>> On Mon, Jun 30, 2014 at 10:13:54AM -0700, Gurucharan Shetty wrote:
On Thu, Jun 26, 2014 at 1:26 PM, Ben Pfaff wrote:
On Tue, Jul 1, 2014 at 10:58 AM, Gurucharan Shetty wrote:
> On Mon, Jun 30, 2014 at 10:20 AM, Ben Pfaff wrote:
>> On Mon, Jun 30, 2014 at 10:13:54AM -0700, Gurucharan Shetty wrote:
>>> On Thu, Jun 26, 2014 at 1:26 PM, Ben Pfaff wrote:
>>> > On Tue, Jun 24, 2014 at 11:52:54AM -0700, Gurucharan Sh
Acked-by: Pritesh Kothari
On Jun 30, 2014, at 6:01 PM, Jesse Gross wrote:
> The upstream u64_stats API has been changed to remove the _bh()
> versions and switch all consumers to use IRQ safe variants instead.
> This was done to be safe for netpoll generated packets, which can
> occur in hard I
On Mon, Jun 30, 2014 at 10:20 AM, Ben Pfaff wrote:
> On Mon, Jun 30, 2014 at 10:13:54AM -0700, Gurucharan Shetty wrote:
>> On Thu, Jun 26, 2014 at 1:26 PM, Ben Pfaff wrote:
>> > On Tue, Jun 24, 2014 at 11:52:54AM -0700, Gurucharan Shetty wrote:
>> >> On Windows ECONNRESET is WSAECONNRESET.
>> >>
Thx Pravin, addressed all your comments,
On Tue, Jul 1, 2014 at 9:57 AM, Pravin Shelar wrote:
> On Mon, Jun 30, 2014 at 3:01 PM, Alex Wang wrote:
> > Due to the race condition in userspace, there is chance that two
> > overlapping megaflows could be installed in datapath. And this
> > causes
Due to the race condition in userspace, there is chance that two
overlapping megaflows could be installed in datapath. And this
causes userspace unable to delete the less inclusive megaflow flow
even after it timeout, since the flow_del logic will stop at the
first match of masked flow.
This comm
On Mon, Jun 30, 2014 at 3:01 PM, Alex Wang wrote:
> Due to the race condition in userspace, there is chance that two
> overlapping megaflows could be installed in datapath. And this
> causes userspace unable to delete the less inclusive megaflow flow
> even after it timeout, since the flow_del lo
On Tue, Jul 1, 2014 at 4:26 AM, Lori Jakab wrote:
> On 6/27/14, 4:25 PM, Lori Jakab wrote:
>>
>> On 6/25/14, 6:58 PM, Lori Jakab wrote:
>>>
>>> On 6/25/14, 5:19 AM, Jesse Gross wrote:
On Wed, Jun 18, 2014 at 9:45 PM, Jesse Gross wrote:
>
> On Tue, Jun 17, 2014 at 12:21 PM, Lori
On Mon, Jun 30, 2014 at 9:27 PM, Flavio Leitner wrote:
> On Mon, Jun 30, 2014 at 05:50:20PM -0700, Gurucharan Shetty wrote:
>> For RHEL, Fedora and Xenserver, run unit tests while
>> building rpms. This may catch some cross-platform bugs.
>>
>> The commit also allows the users to optionally skip
We hit the same bug with a Linux-3.12 kernel and openvswitch in SLES-12
and I built a reproducer without openvswitch with just two network
interfaces, one VLAN and one DNAT+SNAT rule.
Also some more analysis of what goes wrong
http://www.spinics.net/lists/netdev/msg287640.html
=> this is actuall
On 6/27/14, 4:25 PM, Lori Jakab wrote:
On 6/25/14, 6:58 PM, Lori Jakab wrote:
On 6/25/14, 5:19 AM, Jesse Gross wrote:
On Wed, Jun 18, 2014 at 9:45 PM, Jesse Gross wrote:
On Tue, Jun 17, 2014 at 12:21 PM, Lori Jakab
wrote:
Hi Jesse,
On 5/23/14, 2:07 AM, Jesse Gross wrote:
On Tue, May 20, 2
We may consider unit tests for IPFIX in a later patch.
I have made some investiagtion about unit tests, but found that the normal
traffic(non-tunnel) for IPFIX can be simulated via dummy device, but there is
no way to simulate tunnel traffic due to that tunnel packets is not supported
on dummy
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
31 matches
Mail list logo
