One maintainer or debian developer can do a new build of ovs with the
fix available in 2.3.1 please?
* Version 2.3.0+git20140819-2 of openvswitch is marked for
autoremoval from testing on 2015-01-15.
* It is affected by RC bug #771863 https://bugs.debian.org/771863.
Without this fix
On Wed, Dec 17, 2014 at 06:19:09PM +0530, Aman Kumar wrote:
Hi Flavio,
Thank you for giving us your valuable time
It's working fine and now multicast packets are going out only if there is
a receiver out to the node
ok, thanks for testing the patch.
But in our case (OpenStack) there is
Thanks,
Today again i tested the patch with some more scenarios and i found that
OVS is doing it's enough work and now it's our (openstack) responsibility
to set our requirement by doing modifications on Br-tun.
Please try to upstream the patch set for the next release of OVS so that it
will be
Hi John,
The path using DPDK through the netdev can use the exact match cache in
dpif-netdev.c to enable very fast switching. You could think of this as an
equivalent to the fast path in OVDK. Have a look at the rates that Madhu Challa
presented at the OVS Fall Conference on Slide 3
Hi Kevin,
The performance number looks great!
- For DPDK OVS, the number only shows NIC - OVS - NIC as vhost-user is
not supported yet, do you know what's the schedule for vhost-user
support?
- On slide #8, it's interesting to see TCP_STREAM degrade quite a lot
in offload case.
Thanks,
Jun
On
Yes, I agree we need to encode (bridge, ofp_port). recirc_id (the
upper 16 bit part) is globally unique, so bridge can be recovered by
maintaining recirc_id -bridge mapping in the user space.
I agree odp_port could be used as well. For the problem at hand, using
recirc_id seems to be simpler.
Would it be simpler to do 16%SCNx64 ?
On Wed, Dec 17, 2014 at 10:34 AM, Joe Stringer joestrin...@nicira.com wrote:
Commit 534a19b (dpctl: Add support for using UFID to add/del flows.)
introduced string parsing functions for UFIDs, but provided a broken
implementation where the upper 64 bits
On Wed, Dec 17, 2014 at 10:50 PM, Justin Pettit jpet...@nicira.com wrote:
Hi, Pravin. I think commit a36de77 (openvswitch: Userspace tunneling.)
introduces a problem when new actions are added in the kernel. This part
makes the kernel's idea of actions defined after _TUNNEL_POP different
On Tue, Dec 16, 2014 at 3:10 PM, Jarno Rajahalme jrajaha...@nicira.com wrote:
LGTM,
With some comments below:
Acked-by: Jarno Rajahalme jrajaha...@nicira.com
Jarno
On Dec 15, 2014, at 12:37 PM, Pravin B Shelar pshe...@nicira.com wrote:
vSwitchd does not generate correct MPLS actions
You mean %16SCNx64? That's much tidier:-)
Full diff against master is:
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 1dc63ef..b1940c7 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -2017,12 +2017,12 @@ odp_ufid_from_string(const char *s_, ovs_u128 *ufid)
return -EINVAL;
On Dec 18, 2014, at 10:15 AM, Pravin Shelar pshe...@nicira.com wrote:
On Wed, Dec 17, 2014 at 10:50 PM, Justin Pettit jpet...@nicira.com wrote:
Hi, Pravin. I think commit a36de77 (openvswitch: Userspace tunneling.)
introduces a problem when new actions are added in the kernel. This part
The current implementation is not standards compliant and inferior to
BFD in every way. This patch marks it as deprecated so it may be
removed in the future.
Signed-off-by: Ethan Jackson et...@nicira.com
---
lib/cfm.c| 7 +++
vswitchd/vswitch.xml | 4
2 files changed, 11
The last time we did something like this that I remember, we specified a date
that it would not happen before. That might be nice to do, so people can know
the future is not the next release.
--Justin
On Dec 18, 2014, at 1:10 PM, Ethan Jackson et...@nicira.com wrote:
The current
On Thu, Dec 18, 2014 at 11:26 AM, Justin Pettit jpet...@nicira.com wrote:
On Dec 18, 2014, at 10:15 AM, Pravin Shelar pshe...@nicira.com wrote:
On Wed, Dec 17, 2014 at 10:50 PM, Justin Pettit jpet...@nicira.com wrote:
Hi, Pravin. I think commit a36de77 (openvswitch: Userspace tunneling.)
This is better, how about:
if (!ovs_scan(s, %16SCNx64%16SCNx64, ufid-u64.hi, ufid-u64.lo) ...
On Thu, Dec 18, 2014 at 10:40 AM, Joe Stringer joestrin...@nicira.com wrote:
You mean %16SCNx64? That's much tidier:-)
Full diff against master is:
diff --git a/lib/odp-util.c b/lib/odp-util.c
:-)
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Commit 534a19b (dpctl: Add support for using UFID to add/del flows.)
introduced string parsing functions for UFIDs, but provided a broken
implementation where the upper 64 bits would be ignored, then the lower
64 bits would be read into both the lower and upper UFID positions. Fix
the
It seems we can do away with udpif-enable_ufid field. udpif has
access to the backer, so it can know
about the datapath capability.
The debug interface just need to control another global 'enable'
variable. ufid can only be use if both conditions
are true. This will also remove the possibility
Looks good.
Acked-by: Andy Zhou az...@nicira.com
Is it worth while to add a unit test for this?
On Wed, Dec 17, 2014 at 10:34 AM, Joe Stringer joestrin...@nicira.com wrote:
This allows users to fetch a flow by giving a particular UFID.
Usage: 'ovs-dpctl get-flow ufid:ufid'
Signed-off-by:
Thanks for fixing them.
Acked-by: Andy Zhou az...@nicira.com
On Thu, Dec 18, 2014 at 3:36 PM, Joe Stringer joestrin...@nicira.com wrote:
Commit 534a19b (dpctl: Add support for using UFID to add/del flows.)
introduced string parsing functions for UFIDs, but provided a broken
implementation
Almost; theoretically not all udpifs will have the same backer, each
of which may or may not support UFID. So, it's still useful to track
this per-udpif. (One example is right now if you add a userspace
datapath and a kernel datapath, the userspace will support UFID but
the kernel will not.)
The
On 18 December 2014 at 16:17, Andy Zhou az...@nicira.com wrote:
Looks good.
Acked-by: Andy Zhou az...@nicira.com
Thanks,
Is it worth while to add a unit test for this?
Can do, this would also depend on the following patch:
http://openvswitch.org/pipermail/dev/2014-December/049739.html
On Tue, Dec 2, 2014 at 11:12 PM, Alex Wang al...@nicira.com wrote:
This commit changes the per dpif-netdev datapath flow-table/
classifier to per pmd-thread. As direct benefit, datapath
and flow statistics no longer need to be protected by mutex
or be declared as per-thread variable, since
Thinking about this a little more, I could make the debug interface
set a single static 'enable_ufid' variable, then have a helper
function like so:
+static bool
+udpif_use_ufid(struct udpif *udpif)
+{
+return enable_ufid ofproto_dpif_get_enable_ufid(udpif-backer);
+}
I don't feel strongly
I want the sFlow module to know when a sampled packet was a cache miss in
the datapath. That way we can include this information with the sFlow
sample feed that is sent out, and applications can analyze the data to see
what mix of traffic is suffering cache misses.Any ideas on how to add
I don't strongly object the current version either (with the fix
above), but this version seems simpler.
Is it worth while to make it inline?
Acked-by: Andy Zhou az...@nicira.com
On Thu, Dec 18, 2014 at 5:11 PM, Joe Stringer joestrin...@nicira.com wrote:
Thinking about this a little more, I
On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote:
One maintainer or debian developer can do a new build of ovs with the fix
available in 2.3.1 please?
* Version 2.3.0+git20140819-2 of openvswitch is marked for
autoremoval from testing on 2015-01-15.
* It is
Consider that patch acked as well. It is trivially correct.
On Thu, Dec 18, 2014 at 5:06 PM, Joe Stringer joestrin...@nicira.com wrote:
On 18 December 2014 at 16:17, Andy Zhou az...@nicira.com wrote:
Looks good.
Acked-by: Andy Zhou az...@nicira.com
Thanks,
Is it worth while to add a unit
On 15 December 2014 at 10:21, Gurucharan Shetty shet...@nicira.com wrote:
On Sat, Dec 13, 2014 at 2:03 AM, Stig Sandbeck Mathisen s...@debian.org
wrote:
I would like to clarify that 2.3.1 does get rid of the check on
$RUNLEVEL which was the original bug description.
That's great, thanks. :)
openvswitch_2.3.0+git20140819-3_i386.changes uploaded successfully to localhost
along with the files:
openvswitch_2.3.0+git20140819-3.dsc
openvswitch_2.3.0+git20140819-3.debian.tar.xz
openvswitch-common_2.3.0+git20140819-3_i386.deb
openvswitch-switch_2.3.0+git20140819-3_i386.deb
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 19 Dec 2014 10:54:08 +0900
Source: openvswitch
Binary: openvswitch-common openvswitch-switch openvswitch-ipsec openvswitch-pki
openvswitch-dbg python-openvswitch openvswitch-test openvswitch-vtep
Architecture:
Your message dated Fri, 19 Dec 2014 03:49:22 +
with message-id e1y1oz8-0008ut...@franck.debian.org
and subject line Bug#771863: fixed in openvswitch 2.3.0+git20140819-3
has caused the Debian Bug report #771863,
regarding openvswitch-switch: Open vSwitch configuration through
On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote:
On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote:
One maintainer or debian developer can do a new build of ovs with the fix
available in 2.3.1 please?
* Version 2.3.0+git20140819-2 of openvswitch is
i agree on all points.
YAMAMOTO Takashi
Yes, I agree we need to encode (bridge, ofp_port). recirc_id (the
upper 16 bit part) is globally unique, so bridge can be recovered by
maintaining recirc_id -bridge mapping in the user space.
I agree odp_port could be used as well. For the problem
Hey Yamamoto,
Upon further offline discussion, we'd like to take the following approach
to fix the bug,
- Keep a map between 'recirc_id' and corresponding 'ofproto_dpif',
- When handling misses of 'recirc'ed pkts, we find the 'recirc_ofproto' via
lookup the map with 'recirc_id', and start the
Hey Yamamoto,
Upon further offline discussion, we'd like to take the following approach
to fix the bug,
- Keep a map between 'recirc_id' and corresponding 'ofproto_dpif',
- When handling misses of 'recirc'ed pkts, we find the 'recirc_ofproto' via
lookup the map with 'recirc_id', and
After commit 0c7812e5e (recirculation: Do not drop packet when
there is no match from internal table.), if flow keys are modified
before the recirculation action (e.g. set vlan ID), the miss
handling of recirc'ed packets may not reach the intended
'ofproto_dpif' which has rules looking up the
37 matches
Mail list logo
