It seems this is a scam anyway:
http://www.europeandomaincentre.com/pages/news-room/domain-management-news/hey!-got-an-email-from-china-domain-name-registration-center-asian-domain-registration-service-in-china-the-department-of-registration-service-in-china-etc
On 04/05/16 15:46, Ben Pfaff wrot
Hi,
I have a related question: is it a possible alternative with the current
codebase to use KNI for configuring the MTU?
I never actually tried KNI, does it have a performance penalty to just
have it?
The reason I'm asking these questions because OVS normally doesn't
configure the MTU, but it
On 08/01/16 16:31, Aaron Conole wrote:
Panu Matilainen writes:
On 01/04/2016 11:46 PM, Aaron Conole wrote:
Existing DPDK integration is provided by use of command line options which
must be split out and passed to librte in a special manner. However, this
forces any configuration to be passe
On 17/12/15 16:23, Fischetti, Antonio wrote:
Hi Zoltan, thanks for your questions.
Please find below my answers inline.
-Original Message-
From: Zoltan Kiss [mailto:zoltan.k...@linaro.org]
Sent: Thursday, December 17, 2015 2:33 PM
To: Fischetti, Antonio; dev@openvswitch.org
Subject
On 17/12/15 10:41, Fischetti, Antonio wrote:
Hi All,
Here's an optimization idea for the datapath classifier table.
I'd like to get some feedback.
I used the DPDK ACL tables. They can perform a wildcarded matching and each
lookup requires less CPU cycles than the Classifier.
Anyway there's a n
Hi,
On 15/12/15 14:50, Traynor, Kevin wrote:
Seems good, assuming that the thread affinity at the time dpdk_init()
>was called reflects what cores are allowed for non-PMD threads. And what
>if the user wants to change that later?
Hi - not sure what you mean by "allowed for non-PMD threads". Is
On 14/12/15 17:35, Traynor, Kevin wrote:
How about letting the control threads just float on the non-isolcpu'd cores.
We could then potentially remove the -c argument which would simplify
setup as the user would only need to think about one mask - pmd-cpu-mask
(which of course we could also def
Hi,
On 14/12/15 16:02, Aaron Conole wrote:
Just some more activity on this topic, after spending time going through
the code a bit.
Zoltan Kiss writes:
On 08/12/15 17:31, Gray, Mark D wrote:
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, December 8, 2015
about the DPDK -c and -n parameters.
Signed-off-by: Kevin Traynor
Reported-by: Zoltan Kiss
---
INSTALL.DPDK.md | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md index
96b686c..ee016da
100644
--- a/INSTALL.DPDK.md
+++ b
On 04/12/15 16:15, Gray, Mark D wrote:
5. Start vswitchd:
>
>- DPDK configuration arguments can be passed to vswitchd via `--dpdk`
>- argument. This needs to be first argument passed to vswitchd process.
>- dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter
>- for dpdk
On 03/12/15 04:23, Aaron Conole wrote:
Existing DPDK integration is provided by use of command line options which
must be split out and passed to librte in a special manner. However, this
forces any configuration to be passed by way of a special DPDK flag, and
interferes with ovs+dpdk packaging
I plan to, obviously as part of an ODP series. But I don't have a time
set for that.
Regards,
Zoltan
On 02/12/15 16:33, Ben Pfaff wrote:
On Wed, Dec 02, 2015 at 03:40:33PM +0000, Zoltan Kiss wrote:
On 01/12/15 18:04, Ben Pfaff wrote:
On Tue, Dec 01, 2015 at 04:09:07PM +0200,
On 01/12/15 18:04, Ben Pfaff wrote:
On Tue, Dec 01, 2015 at 04:09:07PM +0200, Panu Matilainen wrote:
On 11/26/2015 07:56 PM, Traynor, Kevin wrote:
Just wanted to post some summary notes on the recent OVS with DPDK Meetup we
had after the OVS conference. Thanks to everyone for the often lively
On 24/11/15 17:06, Ben Pfaff wrote:
On Tue, Nov 24, 2015 at 10:51:28AM +, Zoltan Kiss wrote:
I've also have a question unanswered, but only for two weeks:
http://openvswitch.org/pipermail/dev/2015-November/062039.html
Probably you are the best person to answer it, I should have
I've also have a question unanswered, but only for two weeks:
http://openvswitch.org/pipermail/dev/2015-November/062039.html
Probably you are the best person to answer it, I should have added you Cc.
Regards,
Zoltan
On 24/11/15 04:53, Ben Pfaff wrote:
Some of these date back to September:
Hi,
This documentation talks a great deal about porting strategies, and it
mentions that "Only an ofproto provider can take full advantage of
hardware with built-in support for wildcards"
I wonder if it's still true, as dpif providers can use megaflows now,
which are essentially wildcarding. G
On 18/09/15 13:46, Joe Stringer wrote:
Do you mind rebasing this patch? I'm getting errors when I try to
apply it (error below).
Ok, I've resent it based on latest master
Also, I believe that the control characters are used by some
developers to separate sections of the files, so please leave
enable before touching the latch and blocking on pause_barrier.
Signed-off-by: Zoltan Kiss
---
v2:
- ofproto_dpif_backer_enabled() to check recv_set_enable
- do not touch the latch
v3:
- rebase to latest master
- don't touch control chars
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofpr
prefetching if it a simple change like the this.
Thanks,
Daniele
On 17/09/2015 21:29, "Zoltan Kiss" wrote:
It's better to have it in the cache as soon as possible. On my test setup
it
meant a 0.7 Mpps increase.
Signed-off-by: Zoltan Kiss
diff --git a/lib/dpif-netdev.c b/lib/d
It's better to have it in the cache as soon as possible. On my test setup it
meant a 0.7 Mpps increase.
Signed-off-by: Zoltan Kiss
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 72e5653..3312cc0 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3229,11 +3
enable before touching the latch and blocking on pause_barrier.
It removes a stale control character in ofproto/ofproto.c as well.
Signed-off-by: Zoltan Kiss
---
v2:
- ofproto_dpif_backer_enabled() to check recv_set_enable
- do not touch the latch
-
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofp
On 16/09/15 22:54, Joe Stringer wrote:
On 16 September 2015 at 13:32, Zoltan Kiss wrote:
e4e74c3a "dpif-netdev: Purge all ukeys when reconfigure pmd." introduced a new
dp_purge_cb function, which calls udpif_pause_revalidators() and that tries to
block on pause_barrier.
But
fg=ovs_cfg@entry=0x961db0)
at vswitchd/bridge.c:700
#12 0x00418439 in bridge_run () at vswitchd/bridge.c:2984
#13 0x0040d025 in main (argc=11, argv=0x7fffe9a8) at
vswitchd/ovs-vswitchd.c:120
I'm not sure that checking for this initialization is the right thing here, bu
t much, while with the non-vector PMD it can
max out the link.
Any more suggestions?
Regards,
Zoltan
On 21/08/15 19:05, Zoltan Kiss wrote:
Hi,
I've set up a simple packet forwarding perf test on a dual-port 10G
82599ES: one port receives 64 byte UDP packets, the other sends it out,
one cor
Hi,
On 24/08/15 12:43, Traynor, Kevin wrote:
-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Zoltan Kiss
Sent: Friday, August 21, 2015 7:05 PM
To: d...@dpdk.org; dev@openvswitch.org
Cc: Richardson, Bruce; Ananyev, Konstantin
Subject: [ovs-dev] OVS-DPDK
Hi,
I've set up a simple packet forwarding perf test on a dual-port 10G
82599ES: one port receives 64 byte UDP packets, the other sends it out,
one core used. I've used latest OVS with DPDK 2.1, and the first result
was only 13.2 Mpps, which was a bit far from the 13.9 I've seen last
year wit
I
couldn't establish an error scenario yet, I think it's quite dangerous
to leave the packet to inherit the previous packet's ofpbuf.
Or am I missing some place where this piece is reinitialized?
Regards,
Zoltan Kiss
___
dev mailing list
dev@o
Hi Olivier,
On 25/03/15 17:04, Olivier MATZ wrote:
Hi Zoltan,
On 03/24/2015 06:42 PM, Zoltan Kiss wrote:
Hi,
I've noticed in lib/netdev-dpdk.c that __rte_pktmbuf_init() stores the
packet metadata right after "struct rte_mbuf", and before the buffer
data:
/* start of
; Points to the other buffer if this one
is (in)direct. Otherwise NULL. */
What do you think?
Regards,
Zoltan Kiss
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
ng.txt
That would avoid problems with transient states like the reported one.
fbl
On Mon, Jul 14, 2014 at 3:11 PM, Ben Pfaff wrote:
On Tue, Jul 08, 2014 at 05:35:57PM +0100, Zoltan Kiss wrote:
This patch modifies the LACP selection logic by prefering a slaves with up and
running partners whe
On 08/08/14 02:38, Flavio Leitner wrote:
On Thu, Aug 07, 2014 at 04:19:17PM +0100, Zoltan Kiss wrote:
On 05/08/14 22:16, Flavio Leitner wrote:
On Mon, Aug 04, 2014 at 12:08:48PM -0700, Andy Zhou wrote:
Zoltan,
Sorry it took a while to get back to you. I am just coming up to
speed on OVS
On 05/08/14 22:16, Flavio Leitner wrote:
On Mon, Aug 04, 2014 at 12:08:48PM -0700, Andy Zhou wrote:
Zoltan,
Sorry it took a while to get back to you. I am just coming up to
speed on OVS LACP implementation, so my understanding may not be
correct. Please feel free to point them out If I am wro
g
such problems quite hard, therefore I think it is still valid to improve things
in OVS side.
Btw. the Linux kernel bonding drivers' LACP implementation allows more
aggregators, and therefore it could handle this situation properly.
Signed-off-by: Zoltan Kiss
---
v2:
- fixing bitmask in lacp_p
g
such problems quite hard, therefore I think it is still valid to improve things
in OVS side.
Btw. the Linux kernel bonding drivers' LACP implementation allows more
aggregators, and therefore it could handle this situation properly.
Signed-off-by: Zoltan Kiss
---
diff --git a/lib/lacp.c b/lib/
Hi,
Recently we have seen a pool-wide storage fence in a XenServer 6.2 SP1
enviroment. OVS 1.4.6+ were in use, up until the commit e58f54a4aa1 on
that branch.
In a 20 minutes period all 4 hosts in the pool lost network connectivity
and HA restarted them automatically. First ovsdb-server logged
On 29/04/14 17:36, Thomas Graf wrote:
On Tue, Apr 29, 2014 at 05:17:07PM +0100, Zoltan Kiss wrote:
On 23/04/14 22:56, Thomas Graf wrote:
On 04/23/2014 10:12 PM, Ethan Jackson wrote:
The problem has actually gotten worse since we've gotten rid of the
dispatcher thread. Now each threa
the upcall itself
will be minimized. However, I remember someone (Alex?) stating that the
unfairness was primarily caused by the classification.
Thomas
Ethan
On Wed, Apr 23, 2014 at 1:05 PM, Zoltan Kiss
wrote:
Hi,
I would like to ask, what's the status of enabling Netlink MMAP in the
us
Hi,
I would like to ask, what's the status of enabling Netlink MMAP in the
userspace? I'm interested to see this progressing, but digging the mail
archive I've found it run into scalability issues:
http://openvswitch.org/pipermail/dev/2013-December/034546.html
And also it can't handle frags
'long long' and do a boundary check
before returning the converted value.
This patch also move the function to the .c file as it's not-trivial now, and
deletes the other str_to_u* functions as they are not used.
Signed-off-by: Zoltan Kiss
---
v2:
- remove OVS_UNLIKELY and unnecessary
On 22/04/14 22:39, Ben Pfaff wrote:
On Tue, Apr 22, 2014 at 06:27:18PM +0100, Zoltan Kiss wrote:
This function returns true when 's' is negative or greater than UINT_MAX. Also,
the representation of 'int' and 'unsigned int' is implementation dependent, so
convert
On 22/04/14 20:18, Ben Hutchings wrote:
From: Zoltan Kiss
commit 36d5fe6a000790f56039afe26834265db0a3ad4c upstream.
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well,
On 22/04/14 16:38, Ben Hutchings wrote:
On Mon, 2014-04-21 at 12:26 +0100, Luis Henriques wrote:
Hi David,
On Thu, Mar 27, 2014 at 03:29:56PM -0400, David Miller wrote:
From: Zoltan Kiss
Date: Wed, 26 Mar 2014 22:37:45 +
skb_zerocopy can copy elements of the frags array between skbs
'long long' and do a boundary check
before returning the converted value.
Signed-off-by: Zoltan Kiss
---
diff --git a/lib/util.h b/lib/util.h
index aff17a5..9b677c5 100644
--- a/lib/util.h
+++ b/lib/util.h
@@ -294,7 +294,16 @@ bool str_to_llong(const char *, int base, long long *);
stati
On 18/04/14 02:42, Jarno Rajahalme wrote:
On Apr 17, 2014, at 11:26 AM, Zoltan Kiss wrote:
On 16/04/14 18:00, Justin Pettit wrote:
On April 16, 2014 at 9:00:15 AM, Zoltan Kiss (zoltan.k...@citrix.com) wrote:
My actual problem is that an important rule gets deleted:
cookie=0x0, duration
On 16/04/14 18:00, Justin Pettit wrote:
On April 16, 2014 at 9:00:15 AM, Zoltan Kiss (zoltan.k...@citrix.com) wrote:
My actual problem is that an important rule gets deleted:
cookie=0x0, duration=1581.083s, table=0, n_packets=52804,
n_bytes=88968151, idle_age=0, priority=0,in_port=ANY actions
if-exists del-port vif3.0
There is no sign the controller did anything about deleting those rules,
but somehow it still happened. Does anyone knows
Unfortunately it is hard to reproduce the problem, it is only
intermittent in one of our testcases.
Regards,
Zoli
On 16/04/14 00:59, Zoltan Kiss
it happens deferred somewhere else, but can someone point me there?
Regards,
Zoltan Kiss
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify the callers accordingly. skb_tx_error() is also added to
the callers so they will signal the failed delivery towards the creator of the
skb."
Signed-off-by: Zoltan Kiss
---
v2:
- adding stubs o
them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify the callers accordingly. skb_tx_error() is also added to
the callers so they will signal the failed delivery towards the creator of the
skb."
Signed-off-by: Zoltan Kiss
---
v2:
- adding stubs o
On 09/04/14 22:52, Jesse Gross wrote:
On Wed, Apr 9, 2014 at 9:20 AM, Zoltan Kiss wrote:
This is the ported version of commit 36d5fe6a with the same name from net-next.
Apart from the small datapath.c changes it adjust the compat layer files as
well. This is the original commit message
I don't know if Kyle posted this already, but I needed it anyway, so I
sent in my version.
Zoli
On 09/04/14 17:20, Zoltan Kiss wrote:
This is the ported version of commit 36d5fe6a with the same name from net-next.
Apart from the small datapath.c changes it adjust the compat layer fil
them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify the callers accordingly. skb_tx_error() is also added to
the callers so they will signal the failed delivery towards the creator of the
skb."
Signed-off-by: Zoltan Kiss
---
diff --git a/datapath/d
On 01/04/14 20:26, Jesse Gross wrote:
On Tue, Apr 1, 2014 at 11:41 AM, Kyle Mestery wrote:
On Tue, Apr 1, 2014 at 1:27 PM, Zoltan Kiss wrote:
Hi,
I have a recent patch on net-next which affects OVS as well:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id
Hi,
It seems some parts of the changes from my original patch are missing.
On 01/04/14 14:32, Kyle Mestery wrote:
diff --git a/datapath/linux/compat/skbuff-openvswitch.c
b/datapath/linux/compat/skbuff-openvswitch.c
index ddd7bc8..bcba930 100644
--- a/datapath/linux/compat/skbuff-openvswitch.c
Hi,
I have a recent patch on net-next which affects OVS as well:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=36d5fe6a000790f56039afe26834265db0a3ad4c
I guess the changes for datapatch.c will turn up automagically sometime
during a merge, is that correct?
But there
On 26/03/14 20:12, David Miller wrote:
From: David Miller
Date: Wed, 26 Mar 2014 15:59:58 -0400 (EDT)
From: Zoltan Kiss
Date: Fri, 21 Mar 2014 10:31:34 +
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle error
owards the creator of the
skb.
Signed-off-by: Zoltan Kiss
---
v2: orphan the frags right before touching the frags
v3:
- orphan 'from' instead of 'to'
- call skb_tx_error() in the callers if something went wrong
v4: correctly use error path in queue_userspace_packet
v5: remov
On 20/03/14 22:22, Thomas Graf wrote:
On 03/20/2014 05:02 PM, Zoltan Kiss wrote:
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -464,7 +464,9 @@ static int queue_userspace_packet(struct datapath
*dp, struct sk_buff *skb,
}
nla->nla_len = nla_attr_size(skb-&
owards the creator of the
skb.
Signed-off-by: Zoltan Kiss
---
v2: orphan the frags right before touching the frags
v3:
- orphan 'from' instead of 'to'
- call skb_tx_error() in the callers if something went wrong
v4: correctly use error path in queue_userspace_packet
diff --
owards the creator of the
skb.
Signed-off-by: Zoltan Kiss
---
v2: orphan the frags right before touching the frags
v3:
- orphan 'from' instead of 'to'
- call skb_tx_error() in the callers if something went wrong
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
On 20/03/14 12:33, Thomas Graf wrote:
On 03/20/2014 01:16 PM, Thomas Graf wrote:
On 03/19/2014 10:07 PM, Zoltan Kiss wrote:
skb_zerocopy can copy elements of the frags array between skbs, but it
doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care
of th
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well.
Signed-off-by: Zoltan Kiss
---
v2: orphan the frags right before touching the frags
diff --git a/include/linux/skbuff.h
On 19/03/14 20:47, Thomas Graf wrote:
On 03/19/2014 09:38 PM, Zoltan Kiss wrote:
skb_zerocopy can copy elements of the frags array between skbs, but it
doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care
of that
as well.
Signed-off-by: Zoltan Kiss
---
On 19/03/14 20:24, David Miller wrote:
From: Zoltan Kiss
Date: Tue, 18 Mar 2014 21:17:35 +
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well.
Signed-off-by: Z
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well.
Signed-off-by: Zoltan Kiss
---
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 03db95a..35c4e85 10
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well.
Signed-off-by: Zoltan Kiss
---
net/openvswitch/datapath.c |6 ++
1 file changed, 6 insertions(+)
diff --git
On 11/03/14 19:41, Zoltan Kiss wrote:
On 07/03/14 17:59, Thomas Graf wrote:
On 03/07/2014 06:28 PM, Pravin Shelar wrote:
Problem is mapping SKBTX_DEV_ZEROCOPY pages to userspace. skb_zerocopy
is not doing that.
Unless I missing something, Current netlink code can not handle
skb-frags with
On 07/03/14 17:59, Thomas Graf wrote:
On 03/07/2014 06:28 PM, Pravin Shelar wrote:
Problem is mapping SKBTX_DEV_ZEROCOPY pages to userspace. skb_zerocopy
is not doing that.
Unless I missing something, Current netlink code can not handle
skb-frags with zero copy. So we have to copy skb anyways a
On 07/03/14 04:46, Pravin Shelar wrote:
On Thu, Mar 6, 2014 at 9:09 AM, Zoltan Kiss wrote:
Do you have any feedback on this? I'm also adding KVM list as they might be
interested in this.
Zoli
On 28/02/14 19:16, Zoltan Kiss wrote:
The kernel datapath now switched to zerocopy Ne
Do you have any feedback on this? I'm also adding KVM list as they might
be interested in this.
Zoli
On 28/02/14 19:16, Zoltan Kiss wrote:
The kernel datapath now switched to zerocopy Netlink messages, but that also
means that the pages on frags array are sent straight to userspace. If
I also had problems with these locks on current net-next, I believe the
issue is that "datapath: Fix deadlock during stats update." is not
merged from official OVS repo to kernel.
Zoli
On 13/02/14 17:13, Jiri Pirko wrote:
Hi.
On current net-next I'm getting following message once I add a dp:
The kernel datapath now switched to zerocopy Netlink messages, but that also
means that the pages on frags array are sent straight to userspace. If those
pages came outside the kernel, we have to swap them out with local copies.
Signed-off-by: Zoltan Kiss
---
net/openvswitch/datapath.c |6
50570: openvswitch: Per cpu flow stats.
Signed-off-by: Zoltan Kiss
---
v2: use _bh instead of _irqsave/restore
net/openvswitch/flow.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 16f4b46..9110cf4 100644
--- a/net/openvs
On 27/02/14 22:04, Zoltan Kiss wrote:
The megaflow feature introduced per-CPU stats, and the new code did some
refactoring as well [1]. However the new functions doesn't disable bottom halves
when locking the stat, and as they can be called from userspace context, they
can be interrupt
50570: openvswitch: Per cpu flow stats.
Signed-off-by: Zoltan Kiss
---
net/openvswitch/flow.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 16f4b46..07a4672 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/f
Hi,
Currently I'm working on a patchset which reintroduces grant mapping
into netback. We used it before Linux Xen bits were upstreamed, but we
had to change to grant copy as the original solution were fundamentally
not upstreamable. But the advantage would be huge, as we could replace
copy g
It works for me, thanks!
Acked-by: Zoltan Kiss
On 14/01/14 16:27, Thomas Graf wrote:
While the zerocopy method is correctly omitted if user space
does not support unaligned Netlink messages. The attribute is
still not padded correctly as skb_zerocopy() will not ensure
padding and the
On 14/01/14 09:46, Thomas Graf wrote:
On 01/14/2014 02:30 AM, Jesse Gross wrote:
And it works. I guess the last one causing the problem. Might be an
important factor, I'm using 32 bit Dom0.
I think you're probably right. Thomas - can you take a look?
We shouldn't be doing any zerocopy in this
On 13/01/14 18:04, Zoltan Kiss wrote:
On 08/01/14 15:10, Jesse Gross wrote:
On Wed, Jan 8, 2014 at 9:49 AM, Zoltan Kiss
wrote:
Hi,
I've tried the latest net-next on a Xenserver install with 1.9.3
userspace,
and it seems this patch series broke it (at least after reverting that
local
On 08/01/14 15:10, Jesse Gross wrote:
On Wed, Jan 8, 2014 at 9:49 AM, Zoltan Kiss wrote:
Hi,
I've tried the latest net-next on a Xenserver install with 1.9.3 userspace,
and it seems this patch series broke it (at least after reverting that
locally it works now). I haven't went t
Hi,
I've tried the latest net-next on a Xenserver install with 1.9.3
userspace, and it seems this patch series broke it (at least after
reverting that locally it works now). I haven't went too far yet
checking what's the problem, but it seems the xenbrX device doesn't
really receive too much
On 21/05/13 18:58, Gurucharan Shetty wrote:
Thank you. I pushed this to master, 1.11, 1.10 and 1.9 branches.
Can you please push it into 1.4 branch as well? That's the branch
shipped in stock XenServer 6.1.
Regards,
Zoltan Kiss
___
dev ma
Hi,
Can you explain a little bit what was the effect of this bug for you?
What kind of problems you have seen?
Regards,
Zoli
On 20/05/13 15:56, Gurucharan Shetty wrote:
For xenservers with version less than 6.1, interface reconfiguration
happened through interface-reconfigure scripts in thi
3 at 05:40:57PM +0100, Zoltan Kiss wrote:
Now I've tried with the latest 1.4 code, but it still produces these
message intermittently. Here are some examples:
May 3 16:32:27 localhost ovs-vswitchd:
00093|ofproto_dpif|WARN|unexpected flow from datapath
in_port(1),eth(src=00:21:1b:f3:63:45,dst
: Ethan Jackson
Backported-by: Zoltan Kiss
Signed-off-by: Zoltan Kiss
---
ovsdb/log.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/ovsdb/log.c b/ovsdb/log.c
index f0926c0..6decf1f 100644
--- a/ovsdb/log.c
+++ b/ovsdb/log.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2
Could you provide a log excerpt that includes some of these messages?
On Tue, Apr 30, 2013 at 10:08:20AM +0100, Zoltan Kiss wrote:
Hi,
The latest commit we included in XS 6.1 is cc8ccb5 (26 Jun 2012
14:43:54: lib: Do not assume sig_atomic_t is int)
Regards,
Zoli
On 25/04/13 19:25, Ben Pfaff wr
Hi,
Just a reminder, in case this patch fell off the radar: please review it
sometime.
Regards,
Zoli
On 25/04/13 22:40, Justin Pettit wrote:
On Apr 25, 2013, at 11:23 AM, Ben Pfaff wrote:
I'd really like to get multiple reviews on this. Justin, are you
willing to spend some time looking
What commit is the original XS 6.1
OVS based on?
On Wed, Apr 24, 2013 at 09:48:32PM +0100, Zoltan Kiss wrote:
Hi,
Thanks, I've made my comments on that thread. Another related
question came to my mind: I've seen from time to time some
"ofproto_dpif|WARN|unexpected flow from dat
Hi,
Thanks, I've made my comments on that thread. Another related question
came to my mind: I've seen from time to time some
"ofproto_dpif|WARN|unexpected flow from datapath" messages, not just
with these patches but with the original XS 6.1 ovs. I couldn't see a
pattern in the type of flows.
I've reviewed and tested this. In the patch description there are one
small mistakes:
-execute_controller_action(), by passing true instead of false as its
+execute_controller_action(), by passing false instead of true as its
But more importantly, todo in handle_miss_upcalls are freed twice, an
t the captures never show such ARP packets. Is it possible that these
fields get corrupted when they were installed to the datapath? This
src-target hw address combination are found often by facet_unexpected,
and never appears in the captures.
Regards,
Zoli
On 22/04/13 19:13, Zoltan Kiss wrote:
Hi
Hi,
On 16/04/13 23:53, Zoltan Kiss wrote:
On 15/04/13 18:15, Ben Pfaff wrote:
On Mon, Apr 15, 2013 at 03:59:52PM +0100, Zoltan Kiss wrote:
When the packet is sent to the controller due to an userspace rule
(and not
a kernel-space flow), execute_controller_action is invoked with
clone=true,
so
On 15/04/13 18:15, Ben Pfaff wrote:
On Mon, Apr 15, 2013 at 03:59:52PM +0100, Zoltan Kiss wrote:
When the packet is sent to the controller due to an userspace rule (and not
a kernel-space flow), execute_controller_action is invoked with clone=true,
so handle_flow_miss retains ownership of the
ports to trigger misses in kernel:
mz -B [mgmt IP] -d 100m eth0 -t udp sp=3000,dp=1024-65535,iplen=1400
- track memory consumption over time
Signed-off-by: Zoltan Kiss
---
ofproto/ofproto-dpif.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b
;actions, subfacet->actions_len));
execute->actions_len = subfacet->actions_len;
execute->packet = packet;
+} else {
+ofpbuf_delete(packet);
}
}
Regards,
Zoltan Kiss
___
dev mailing
159b7e53f7e9a890aa130a35801083
There isn't any XS 6.1 public hotfix released for this.
Regards,
Zoltan Kiss
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Zoli
On 09/01/13 20:40, Ben Pfaff wrote:
On Mon, Jan 07, 2013 at 10:39:56PM +, Zoltan Kiss wrote:
On 07/01/13 19:33, Ben Pfaff wrote:
On Sat, Jan 05, 2013 at 09:42:16PM +, Zoltan Kiss wrote:
The hash entry tag connects to facet(s), not slaves.
struct bond_entry {
struct bond_s
Thanks, can you merge it to 1.4 branch please? We plan to release this
in an XS 6.1 hotfix sometime.
Zoli
On 07/01/13 23:16, Ben Pfaff wrote:
On Mon, Jan 07, 2013 at 10:47:51PM +, Zoltan Kiss wrote:
The old algorithm tries to converge to 0, despite it would mean a very
unbalanced
s closer to equal
traffic load.
Signed-off-by: Zoltan Kiss
---
lib/bond.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/bond.c b/lib/bond.c
index 2c59f9d..28f107a 100644
--- a/lib/bond.c
+++ b/lib/bond.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
On 07/01/13 19:33, Ben Pfaff wrote:
On Sat, Jan 05, 2013 at 09:42:16PM +, Zoltan Kiss wrote:
The hash entry tag connects to facet(s), not slaves.
Signed-off-by: Zoltan Kiss
---
lib/bond.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/bond.c b/lib/bond.c
index
1 - 100 of 121 matches
Mail list logo
