Diploma?
http://tiny.cc/gfyyw1gulr
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
If VLAN acceleration is used when the kernel receives a packet
then the outer-most VLAN tag will not be present in the packet
when it is received by netdev-linux. Rather, it will be present
in auxdata.
This patch uses recvmsg() instead of recv() to read auxdata for
each packet and if the vlan_tid
On Wed, Dec 11, 2013 at 10:42:02AM +0900, Simon Horman wrote:
> On Tue, Dec 10, 2013 at 05:40:00PM -0800, Ben Pfaff wrote:
> > On Wed, Dec 11, 2013 at 10:34:14AM +0900, Simon Horman wrote:
> > > On Tue, Dec 10, 2013 at 05:07:14PM -0800, Ben Pfaff wrote:
> > > > On Wed, Dec 11, 2013 at 10:01:12AM +0
On Tue, Dec 10, 2013 at 05:40:00PM -0800, Ben Pfaff wrote:
> On Wed, Dec 11, 2013 at 10:34:14AM +0900, Simon Horman wrote:
> > On Tue, Dec 10, 2013 at 05:07:14PM -0800, Ben Pfaff wrote:
> > > On Wed, Dec 11, 2013 at 10:01:12AM +0900, Simon Horman wrote:
> > > > Remove count_1bits_8() from util.c.
>
On Wed, Dec 11, 2013 at 10:34:14AM +0900, Simon Horman wrote:
> On Tue, Dec 10, 2013 at 05:07:14PM -0800, Ben Pfaff wrote:
> > On Wed, Dec 11, 2013 at 10:01:12AM +0900, Simon Horman wrote:
> > > Remove count_1bits_8() from util.c.
> > > It appears to be unused since
> > > c3cc4d2dd2658238 ("util: B
On Tue, Dec 10, 2013 at 05:07:14PM -0800, Ben Pfaff wrote:
> On Wed, Dec 11, 2013 at 10:01:12AM +0900, Simon Horman wrote:
> > Remove count_1bits_8() from util.c.
> > It appears to be unused since
> > c3cc4d2dd2658238 ("util: Better count_1bits().")
> >
> > Cc: Jarno Rajahalme
> > Signed-off-by:
Allow datapath to recognize and extract MPLS labels into flow keys
and execute actions which push, pop, and set labels on packets.
Based heavily on work by Leo Alterman, Ravi K, Isaku Yamahata and Joe Stringer.
Cc: Ravi K
Cc: Leo Alterman
Cc: Isaku Yamahata
Cc: Joe Stringer
Signed-off-by: Sim
This patch modifies the push_mpls behaviour to allow
pushing of an MPLS LSE either before any VLAN tag that may be present.
Pushing the MPLS LSE before any VLAN tag that is present is the
behaviour specified in OpenFlow 1.3.
Pushing the MPLS LSE after the any VLAN tag that is present is the
behav
From: Joe Stringer
OpenFlow 1.1 and 1.2, and 1.3 differ in their handling of MPLS actions in the
presence of VLAN tags. To allow correct behaviour to be committed in
each situation, this patch adds a second round of VLAN tag action
handling to commit_odp_actions(), which occurs after MPLS actions
Break out deacceleration portion of vlan_push into vlan_put
so that it may be re-used by mpls_push.
For both vlan_push and mpls_push if there is an accelerated VLAN tag
present then it should be deaccelerated, adding it to the data of
the skb, before the new tag is added.
Signed-off-by: Simon Hor
Hi,
This series implements MPLS actions and matches based on work by
Ravi K, Leo Alterman, Yamahata-san and Joe Stringer.
This series provides three changes
* Patches 1 - 3
Provide user-space support for the VLAN/MPLS tag insertion order
up to and including OpenFlow 1.2, and the different o
In the presence of VLAN tags there are two possibilities for pushing
an MPLS LSE described in different versions of OpenFlow: before or after
the VLAN tags.
* Pushing after any VLAN tags that are present is the behaviour described in
OpenFlow1.1 and 1.2 and the behaviour that Open vSwitch curren
* The ethertype of the packet is always set to
the ethertype of the push_mpls action
* Drop references to unicast and multicast MPLS ethertypes,
in RFC5332 0x8847 and 0x8848 do not always have
those meanings.
Signed-off-by: Simon Horman
---
v2.52
* First post
---
utilities/ovs-ofctl.8.in
On Wed, Dec 11, 2013 at 10:01:12AM +0900, Simon Horman wrote:
> Remove count_1bits_8() from util.c.
> It appears to be unused since
> c3cc4d2dd2658238 ("util: Better count_1bits().")
>
> Cc: Jarno Rajahalme
> Signed-off-by: Simon Horman
It's used from inline functions defined in util.h.
___
Remove count_1bits_8() from util.c.
It appears to be unused since
c3cc4d2dd2658238 ("util: Better count_1bits().")
Cc: Jarno Rajahalme
Signed-off-by: Simon Horman
---
lib/util.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/lib/util.c b/lib/util.c
index 13d41a7..f08
Thanks! I'm fine with looking at a more portable version of this.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Dec 10, 2013 at 5:49 AM, Helmut Schaa
wrote:
> Functions marked with OVS_CONSTRUCTOR are called unconditionally
> before main.
>
> Signed-off-by: Helmut Schaa
> ---
>
> This works with gcc (tested), should work with clang (untested)
> but does not work with MSVS.
>
> Could anyone using MS
From: Thomas Graf
Date: Tue, 10 Dec 2013 21:47:48 +0100
> We were not sure whether the runtime check, function pointer and
> hardware dependencies are something other subsystems that are less
> x86_64 centric would want to live with.
The things you are listing as implicit overhead can be elimina
On Tue, Dec 10, 2013 at 1:27 PM, Tom Herbert wrote:
> On Tue, Dec 10, 2013 at 11:36 AM, David Miller wrote:
>> From: Jesse Gross
>> Date: Tue, 10 Dec 2013 11:28:08 -0800
>>
>>> I think this is definitely a good optimization to do given that so
>>> much of the work that OVS does is hashing. Howev
On Tue, Dec 10, 2013 at 12:47 PM, Thomas Graf wrote:
> On 12/10/2013 08:36 PM, David Miller wrote:
>>
>> From: Jesse Gross
>> Date: Tue, 10 Dec 2013 11:28:08 -0800
>>
>>> I think this is definitely a good optimization to do given that so
>>> much of the work that OVS does is hashing. However, isn
On Tue, Dec 10, 2013 at 11:36 AM, David Miller wrote:
> From: Jesse Gross
> Date: Tue, 10 Dec 2013 11:28:08 -0800
>
>> I think this is definitely a good optimization to do given that so
>> much of the work that OVS does is hashing. However, isn't there a
>> library where there would be a more app
On Tue, Dec 10, 2013 at 3:02 AM, Daniel Borkmann wrote:
> As we're only doing a kfree() anyway in the RCU callback, we can
> simply use kfree_rcu, which does the same job, and remove the
> function rcu_free_sw_flow_mask_cb() and rcu_free_acts_callback().
>
> Signed-off-by: Daniel Borkmann
Applie
Err, for those without gmail context; I am referring to the bfd
forwarding changes here:
http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=a1aeea86475db086ce95679962fb6d03d0a645f3
On 10 December 2013 12:56, Joe Stringer wrote:
> The merged version of the above patchset d
The merged version of the above patchset doesn't quite address the
testsuite failure, for reasons described in that thread. Below is an
incremental to fix this issue. I'm happy to fold in and repost, but I
might as well wait until I get further feedback on the rest of this
set.
diff --git a/lib/bf
Yes, if you're happy with that then it sounds good to me.
On 10 December 2013 12:51, Ethan Jackson wrote:
>> I believe that in this case, the sensible place to update
>> bfd->forwarding is in bfd_run(), however this is not currently
>> happening. I suggest ensuring that bfd_forwarding__() happens
> I believe that in this case, the sensible place to update
> bfd->forwarding is in bfd_run(), however this is not currently
> happening. I suggest ensuring that bfd_forwarding__() happens in every
> bfd_run(), not only when the detect_timer expires.
You need bfd_forwarding__ to be called because
On 12/10/2013 08:36 PM, David Miller wrote:
From: Jesse Gross
Date: Tue, 10 Dec 2013 11:28:08 -0800
I think this is definitely a good optimization to do given that so
much of the work that OVS does is hashing. However, isn't there a
library where there would be a more appropriate place to put
This one gets curlier the more I look at it. I think that the
behaviour of this patch is fine against master, but it does not tackle
the original, subtle interaction with my global connectivity_seq
patches. I'll try to address the issue in context of those changes
below.
Currently, there are sever
From: Jesse Gross
Date: Tue, 10 Dec 2013 11:28:08 -0800
> I think this is definitely a good optimization to do given that so
> much of the work that OVS does is hashing. However, isn't there a
> library where there would be a more appropriate place to put this?
I also honestly don't see why we w
On Tue, Dec 10, 2013 at 1:52 AM, Francesco Fusco wrote:
> Currently OVS uses jhash2() for calculating flow hashes in its
> internal flow_hash() function. The performance of the flow_hash()
> function is critical, as the input data can be hundreds of bytes
> long.
>
> One possible direction to achi
There is a minor test failure with this latest version and my patches,
but I am happy that this due to problems with the testsuite and not
this patch. I'll send an update for my relevant patch.
On 9 December 2013 17:36, Alex Wang wrote:
> The only thing is I didn't follow is:
>
> """
> Do we real
Functions marked with OVS_CONSTRUCTOR are called unconditionally
before main.
Signed-off-by: Helmut Schaa
---
This works with gcc (tested), should work with clang (untested)
but does not work with MSVS.
Could anyone using MSVC try if the solution described at
http://stackoverflow.com/questions/
Signed-off-by: Helmut Schaa
---
configure.ac | 1 -
lib/automake.mk | 22 --
m4/openvswitch.m4 | 34 --
3 files changed, 57 deletions(-)
diff --git a/configure.ac b/configure.ac
index 167cc71..96880af 100644
--- a/configure.ac
+++ b/co
Use a global array that gets initialized by constructor functions
per coverage definition.
Signed-off-by: Helmut Schaa
---
The realloc is not the nicest thing to do but looks reasonable as initial
approach. Using a list would cause more intrusive changes to the coverage
implementation.
lib/cov
This allows to get rid of some special segment handling to allow
distributed registering of vlog modules.
Instead use a global list and vlog module constructor functions to
build up the list. That means vlog modules reside within the
compilation unit they are defined in and can be iterated upon
by
As Ben pointed out the special segment handling used in vlog and coverage
makes the transition to shared libs a bit more difficult.
This series tries to get rid of the special segments that are created for the
vlog
and coverage implementations. When trying to use libopenvswitch as shared lib
thi
> From: Francesco Fusco
...
> One possible direction to achieve higher performance consists
> of replacing jhash2() with an architecture specific hash
> function pretty much like the Intel folks have proposed in
> DPDK. DPDK provides a very fast hash function that leverages
> the 32bit crc32l instr
Currently OVS uses jhash2() for calculating flow hashes in its
internal flow_hash() function. The performance of the flow_hash()
function is critical, as the input data can be hundreds of bytes
long.
One possible direction to achieve higher performance consists
of replacing jhash2() with an arch
On Mon, Dec 9, 2013 at 8:19 PM, Ben Pfaff wrote:
> On Mon, Dec 09, 2013 at 10:32:06AM +0100, Helmut Schaa wrote:
>> Currently openvswitch builds all libraries static only. However,
>> libopenvswitch is linked into nearly all openvswitch executables
>> making it hardly possible to run openvswitch o
39 matches
Mail list logo
