[ovs-dev] [RFC recirc fix] recirculation: Map recirc_id to ofproto_dpif.

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 'reci

Re: [ovs-dev] [RFC recirc-fix] recirculation: Do not change handling of packets after recirculation.

> 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',

Re: [ovs-dev] [RFC recirc-fix] recirculation: Do not change handling of packets after recirculation.

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 h

Re: [ovs-dev] [RFC recirc-fix] recirculation: Do not change handling of packets after recirculation.

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 prob

[ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly

On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote: > On 18 December 2014 at 01:00, Fabio Fantoni 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 > >>

[ovs-dev] Bug#771863: marked as done (openvswitch-switch: Open vSwitch configuration through /etc/network/interfaces does not work)

Your message dated Fri, 19 Dec 2014 03:49:22 + with message-id 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 /etc/network/interfaces does not work to be marked as

[ovs-dev] openvswitch_2.3.0+git20140819-3_i386.changes ACCEPTED into unstable

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: sourc

[ovs-dev] Processing of openvswitch_2.3.0+git20140819-3_i386.changes

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 openvswit

[ovs-dev] Bug#771863: Bug#771863: Bug#771863: Service does not start or parse interfaces correctly, updating severity

On 15 December 2014 at 10:21, Gurucharan Shetty wrote: > On Sat, Dec 13, 2014 at 2:03 AM, Stig Sandbeck Mathisen > 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. :) >> >> I probably shou

Re: [ovs-dev] [PATCH 3/3] dpctl: Add 'get-flow' command.

Consider that patch acked as well. It is trivially correct. On Thu, Dec 18, 2014 at 5:06 PM, Joe Stringer wrote: > On 18 December 2014 at 16:17, Andy Zhou wrote: >> Looks good. >> Acked-by: Andy Zhou > > Thanks, > >> Is it worth while to add a unit test for this? > > Can do, this would also dep

[ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly

On 18 December 2014 at 01:00, Fabio Fantoni 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 affected by RC b

Re: [ovs-dev] [PATCH 2/3] dpif: Shift ufid support checking up to dpif_backer.

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 On Thu, Dec 18, 2014 at 5:11 PM, Joe Stringer wrote: > Thinking about this a little more, I could make the debug interface > set a

[ovs-dev] How to know if sampled packet was cache miss?

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 this

Re: [ovs-dev] [PATCH 2/3] dpif: Shift ufid support checking up to dpif_backer.

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 strongl

Re: [ovs-dev] [per-pmd ftb/cls 3/3] dpif-netdev: Add per-pmd flow-table/classifier.

On Tue, Dec 2, 2014 at 11:12 PM, Alex Wang 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 they are only >

Re: [ovs-dev] [PATCH 3/3] dpctl: Add 'get-flow' command.

On 18 December 2014 at 16:17, Andy Zhou wrote: > Looks good. > Acked-by: Andy Zhou 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

Re: [ovs-dev] [PATCH 2/3] dpif: Shift ufid support checking up to dpif_backer.

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 r

Re: [ovs-dev] [PATCHv2] odp-util: Fix UFID string parsing.

Thanks for fixing them. Acked-by: Andy Zhou On Thu, Dec 18, 2014 at 3:36 PM, Joe Stringer 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 would be ignore

Re: [ovs-dev] [PATCH 3/3] dpctl: Add 'get-flow' command.

Looks good. Acked-by: Andy Zhou Is it worth while to add a unit test for this? On Wed, Dec 17, 2014 at 10:34 AM, Joe Stringer wrote: > This allows users to fetch a flow by giving a particular UFID. > > Usage: 'ovs-dpctl get-flow ufid:' > > Signed-off-by: Joe Stringer > --- > lib/dpctl.c

Re: [ovs-dev] [PATCH 2/3] dpif: Shift ufid support checking up to dpif_backer.

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

[ovs-dev] [PATCHv2] odp-util: Fix UFID string parsing.

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 implementatio

[ovs-dev] I am happy!

:-) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/3] odp-util: Fix UFID string parsing.

This is better, how about: if (!ovs_scan(s, "%16"SCNx64"%16"SCNx64, &ufid->u64.hi, &ufid->u64.lo) ... On Thu, Dec 18, 2014 at 10:40 AM, Joe Stringer wrote: > You mean "%16"SCNx64? That's much tidier:-) > > Full diff against master is: > > diff --git a/lib/odp-util.c b/lib/odp-util.c > index

Re: [ovs-dev] Kernel/Userspace Action Mismatch

On Thu, Dec 18, 2014 at 11:26 AM, Justin Pettit wrote: > >> On Dec 18, 2014, at 10:15 AM, Pravin Shelar wrote: >> >> On Wed, Dec 17, 2014 at 10:50 PM, Justin Pettit wrote: >>> Hi, Pravin. I think commit a36de77 (openvswitch: Userspace tunneling.) >>> introduces a problem when new actions are a

Re: [ovs-dev] [PATCH] cfm: Mark CFM as deprecated.

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 wrote: > > The current implementation is no

[ovs-dev] [PATCH] cfm: Mark CFM as deprecated.

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 --- lib/cfm.c| 7 +++ vswitchd/vswitch.xml | 4 2 files changed, 11 insertions(+) diff

Re: [ovs-dev] Kernel/Userspace Action Mismatch

> On Dec 18, 2014, at 10:15 AM, Pravin Shelar wrote: > > On Wed, Dec 17, 2014 at 10:50 PM, Justin Pettit 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

Re: [ovs-dev] [PATCH 1/3] odp-util: Fix UFID string parsing.

You mean "%16"SCNx64? 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;

Re: [ovs-dev] [PATCH] ofproto: Fix MPLS multiple Push pop action.

On Tue, Dec 16, 2014 at 3:10 PM, Jarno Rajahalme wrote: > LGTM, > > With some comments below: > > Acked-by: Jarno Rajahalme > > Jarno > > On Dec 15, 2014, at 12:37 PM, Pravin B Shelar wrote: > >> vSwitchd does not generate correct MPLS actions for multiple >> MPLS push or pop action. >> Datapa

Re: [ovs-dev] Kernel/Userspace Action Mismatch

On Wed, Dec 17, 2014 at 10:50 PM, Justin Pettit 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 from > userspace:

Re: [ovs-dev] [PATCH 1/3] odp-util: Fix UFID string parsing.

Would it be simpler to do "16%"SCNx64 ? On Wed, Dec 17, 2014 at 10:34 AM, Joe Stringer 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 would be ignored, th

Re: [ovs-dev] [RFC recirc-fix] recirculation: Do not change handling of packets after recirculation.

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.

Re: [ovs-dev] OVS DPDK support technical direction

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 Th

Re: [ovs-dev] OVS DPDK support technical direction

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 http://ope

Re: [ovs-dev] Support for MCAST_Snooping

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 he

Re: [ovs-dev] Support for MCAST_Snooping

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) the

[ovs-dev] Bug#771863: Service does not start or parse interfaces correctly

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 . Without this fi