[ovs-dev] MPLS Label Stacking - Issue with single POP

Hi, I have a problem similar to this http://openvswitch.org/pipermail/dev/2014-April/038779.html I am using OVSSwitch V2.3 with OpenFlow 1.3 for multiple MPLS labels. I need to pop one MPLS label while retaining the other labels. But whenever I use POP_MPLS=0x8847, I get error sudo ovs-ofctl -

Re: [ovs-dev] Permission to post

You don't need permission. Post away. :-) --Justin > On Dec 4, 2014, at 5:02 PM, Maiti, Eeran > wrote: > > Hello, > > I am a masters candidate at University of Göttingen, Germany. > I am working on SDN, and I am willing to obtain help from this great > community. > Please grant me permiss

[ovs-dev] Permission to post

Hello, I am a masters candidate at University of Göttingen, Germany. I am working on SDN, and I am willing to obtain help from this great community. Please grant me permission to post. Thanks & Regards, Eeran Maiti Graduate Student Faculty of Mathematics and Computer Science

Re: [ovs-dev] [PATCH] util: Fix include for htonl().

Thanks, pushed to master and branch-2.3. On 4 December 2014 at 16:38, Jarno Rajahalme wrote: > LGTM, > > Jarno > > Acked-by: Jarno Rajahalme > > On Dec 4, 2014, at 4:26 PM, Joe Stringer wrote: > >> Commit 526a7c85d11dc "util: Add be32_prefix_mask()." added an include for >> byte-order.h into

Re: [ovs-dev] [PATCH] util: Fix include for htonl().

LGTM, Jarno Acked-by: Jarno Rajahalme On Dec 4, 2014, at 4:26 PM, Joe Stringer wrote: > Commit 526a7c85d11dc "util: Add be32_prefix_mask()." added an include for > byte-order.h into util.h, which could cause link failures if users of > libopenvswitch defined their own version of htonll(). C

[ovs-dev] [PATCH] util: Fix include for htonl().

Commit 526a7c85d11dc "util: Add be32_prefix_mask()." added an include for byte-order.h into util.h, which could cause link failures if users of libopenvswitch defined their own version of htonll(). Change the include, as only htonl() is needed and arpa/inet.h provides this. Signed-off-by: Joe Stri

Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

On 2014/12/5 7:23, Jesse Gross wrote: On Wed, Dec 3, 2014 at 11:48 PM, Du Fan wrote: 于 2014年12月04日 06:51, Jesse Gross 写道: My proposal would be something like this: * For L2, reduce the VM MTU to the lowest common denominator on the segment. * For L3, use path MTU discovery or fragment i

Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

On Wed, Dec 3, 2014 at 11:48 PM, Du Fan wrote: > 于 2014年12月04日 06:51, Jesse Gross 写道: >> >> My proposal would be something like this: >> * For L2, reduce the VM MTU to the lowest common denominator on the >> segment. >> * For L3, use path MTU discovery or fragment inner packet (i.e. >> normal

Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

On Thu, Dec 4, 2014 at 1:26 AM, Thomas Graf wrote: > On 12/03/14 at 05:51pm, Jesse Gross wrote: >> I think it depends on where you put the PMTU check. If routing is >> happening in OVS where it is decomposed in several discrete actions >> like set MAC and decrement TTL then perhaps there is anothe

Re: [ovs-dev] OFtest--time for a new run?

No problem. 6 of the tests fail because we failed to revalidate the flows fast enough. e.g the pktact priority tests add flow in_port=1, match M actions=output:2 with priority 250 sends a packet and verifies its egress port is 2 add flow in_port=1, match M actions=output:3 with priority 1250 send

Re: [ovs-dev] [PATCH] cccl: Respect silent flags.

On 4 December 2014 at 12:52, Gurucharan Shetty wrote: > On Thu, Dec 4, 2014 at 11:42 AM, Joe Stringer wrote: >> Automake sets $V to tell the compiler whether to print verbose messages >> as it compiles or not. Add support for this variable in cccl, allowing >> more quiet build output on windows i

Re: [ovs-dev] [PATCH 2/2] tests: Fix race in async config test.

Thanks for the review, I made that change and pushed this series to master. On 4 December 2014 at 11:23, Alex Wang wrote: > Since we stop the time, should we add a warp before calling > ovs-appctl netdev-dummy/receive ? > > Otherwise, looks good to me, > Acked-by: Alex Wang > > > On Wed, Dec 3,

[ovs-dev] [PATCH] ofp-actions: Only set defined bits when encoding "load" actions.

Commit 7eb4b1f1d70345f ("ofp-actions: Support OF1.5 (draft) masked Set-Field, merge with reg_load.") introduced a bug in that a set_field action that set an entire field would be translated incorrectly to reg_load, if the field being set only occupied a portion of the bytes that it contains. For e

Re: [ovs-dev] [PATCH] cccl: Respect silent flags.

On Thu, Dec 4, 2014 at 11:42 AM, Joe Stringer wrote: > Automake sets $V to tell the compiler whether to print verbose messages > as it compiles or not. Add support for this variable in cccl, allowing > more quiet build output on windows if the build is configured with > --silent or the developer r

[ovs-dev] [PATCH v2] ofproto: add support of OFPR_GROUP as packet-in reason for OF1.4+

When the Packet-In message is triggered by a group action, OFPR_GROUP is passed internally as the reason. The wire_reason() function converts the reason to OFPR_ACTION if the wire protocol is earlier than OF1.4. The wire_reason() function also converts other unsupported reasons (i.e., OFPR_ACTION_

[ovs-dev] [PATCH] cccl: Respect silent flags.

Automake sets $V to tell the compiler whether to print verbose messages as it compiles or not. Add support for this variable in cccl, allowing more quiet build output on windows if the build is configured with --silent or the developer runs make V=0. Signed-off-by: Joe Stringer --- build-aux/ccc

Re: [ovs-dev] [PATCH 2/2] tests: Fix race in async config test.

Since we stop the time, should we add a warp before calling ovs-appctl netdev-dummy/receive ? Otherwise, looks good to me, Acked-by: Alex Wang On Wed, Dec 3, 2014 at 11:07 AM, Joe Stringer wrote: > Occasionally, the testsuite would send the OFPT_SET_ASYNC before > ovs-vswitchd got a chance to

Re: [ovs-dev] [PATCH 1/2] tests: Make ofproto-dpif tests more resilient.

looks good to me, Acked-by: Alex Wang On Wed, Dec 3, 2014 at 11:07 AM, Joe Stringer wrote: > We have previously used a combination of time/warp and revalidator/wait > to try to synchronize the datapath flow statistics and status up to the > ofproto layer, so that tests may confirm their expect

[ovs-dev] [PATCH] tunnel: Recreate tunnel port only when the netdev status change.

On current master, the 'struct tnl_port' in tunnel module will be recreated whenever the global connectivity sequence number changes (e.g. when adding unrelated flow). This is unnecessary and could cause drop of tunnel packet if a lookup happens between the removal and recreate. This commit fixes

Re: [ovs-dev] [PATCH] ovs-ofctl: Implementation of eviction on the basis of Importance

Hi Ben/Team, Could you please review the patch "[PATCH] ovs-ofctl: Implementation of eviction on the basis of Importance" and provide review comments if any. Thanks and Regards, Saloni Jain Tata Consultancy Services Mailto: saloni.j...@tcs.com Website: http://www.tcs.com

Re: [ovs-dev] Support for MCAST_Snooping

On Thu, Dec 04, 2014 at 03:25:08PM +0530, Aman Kumar wrote: > Thanks a lot guys it worked.[?] Glad to hear that! fbl > > On Wed, Dec 3, 2014 at 6:09 PM, Flavio Leitner wrote: > > > On Wed, Dec 03, 2014 at 03:16:34PM +0530, Aman Kumar wrote: > > > > It supports only IGMPv1 and IGMPv2, so m

Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

On Wed, Dec 03, 2014 at 10:56:02AM -0800, Rick Jones wrote: > Trying to "fake-out" an ICMP message to paper-over "devices" in the "middle" > of same Layer2 network having different MTUs from the ends goes back to at > least the days when people started joining FDDI networks to Ethernet > networks w

Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU

On 12/03/14 at 05:51pm, Jesse Gross wrote: > I think it depends on where you put the PMTU check. If routing is > happening in OVS where it is decomposed in several discrete actions > like set MAC and decrement TTL then perhaps there is another explicit > action to check the MTU. If it is happening