This patch series adds OpenvSwitch datapath support for Windows platform. The
kernel switch extension has support for bridged back forwarding & tunneling
over VXLAN.
The patch series is based on top of c450371 ("datapath: Initialize OVS_CB in
ovs_vport_receive()")
V3:
Posting the series for sake
Signed-off-by: Saurabh Shah
---
lib/dpif-netdev.c | 17 +
lib/odp-util.c| 24
lib/odp-util.h|2 ++
3 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index fce2650..01ebcec 100644
--- a/li
sorry for the confusion, please ignore my patch~
On Sun, Jul 27, 2014 at 6:29 PM, Justin Pettit wrote:
> Your patch had two fixes, so he should probably grab yours.
>
> --Justin
>
>
> > On Jul 27, 2014, at 5:37 PM, Ben Pfaff wrote:
> >
> > Yeah, but I'm happy if Alex wants to push it since I d
The message was not delivered due to the following reason(s):
Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely
Your patch had two fixes, so he should probably grab yours.
--Justin
> On Jul 27, 2014, at 5:37 PM, Ben Pfaff wrote:
>
> Yeah, but I'm happy if Alex wants to push it since I didn't get around to
> it yet.
>> On Jul 27, 2014 5:32 PM, "Joe Stringer" wrote:
>>
>> http://openvswitch.org/piperma
Yeah, but I'm happy if Alex wants to push it since I didn't get around to
it yet.
On Jul 27, 2014 5:32 PM, "Joe Stringer" wrote:
> http://openvswitch.org/pipermail/dev/2014-July/043119.html
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvsw
http://openvswitch.org/pipermail/dev/2014-July/043119.html
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Signed-off-by: Alex Wang
---
ofproto/ofproto-dpif-upcall.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index f00c17f..654fbd3 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
--
Greetings from gulf region
Thanks for the e-mail. I am very interested on funding lucrative business
partnership with you acting as the manager and sole controller of the
investment while i remain a silent investor for a period of ten yrs ,
though I am only looking at investment opportunities
> On Jul 27, 2014, at 1:58 PM, Ben Pfaff wrote:
>
>> On Sun, Jul 27, 2014 at 10:45:40AM -0700, Jarno Rajahalme wrote:
>> Add non-standard atomic types atomic_uint64_t and atomic_int64_t. Use
>> of these types is more natural in OVS code than the standard
>> equivalents.
>>
>> Signed-off-by: Ja
On Sun, Jul 27, 2014 at 10:45:40AM -0700, Jarno Rajahalme wrote:
> Add non-standard atomic types atomic_uint64_t and atomic_int64_t. Use
> of these types is more natural in OVS code than the standard
> equivalents.
>
> Signed-off-by: Jarno Rajahalme
Commit e09d61c41b4fe (ovs-atomic: Remove atom
Exact match flow lookup is always done under ovs lock. So use
ovsl_dereference() API for rcu access.
Signed-off-by: Pravin B Shelar
---
datapath/flow_table.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/datapath/flow_table.c b/datapath/flow_table.c
index
Use 'volatile' to enforce a new memory access on each lockless atomic
store and read. Without this a loop consisting of an atomic_read with
memory_order_relaxed would be simply optimized away. Also, using
volatile is cheaper than adding a full compiler barrier (also) in that
case.
Without this c
The definition of memory_order_relaxed included a compiler barrier,
while it is not necessary, and indeed the following text on
atomic_thread_fence and atomic_signal_fence contradicted that.
memory_model_consume is also more thoroughly described.
Signed-off-by: Jarno Rajahalme
---
lib/ovs-atomi
Compiler implementations may provide sub-optimal support for
a memory_order passed in as a run-time value
(ref. https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html).
Document that OVS atomics require the memory order to be passed in as
a compile-time constant, and modify lib/cmap.c t
Some supported XenServer build environments lack compiler support for
atomic operations. This patch provides native support for x86_64 on
GCC, which covers the 64-bit builds of XenServer.
Since this implementation is faster than the existing support prior to
GCC 4.7, especially for cmap inserts,
This adds tests using all of the defined memory orders, as well as
simple two-thread test cases for the acquire-release and
consume-release patterns.
These new tests helped uncover a bug in the ovs-atomic-gcc4+
implementation, which was fixed in a preceding patch.
Signed-off-by: Jarno Rajahalme
Add non-standard atomic types atomic_uint64_t and atomic_int64_t. Use
of these types is more natural in OVS code than the standard
equivalents.
Signed-off-by: Jarno Rajahalme
---
lib/ovs-atomic.h |4
1 file changed, 4 insertions(+)
diff --git a/lib/ovs-atomic.h b/lib/ovs-atomic.h
inde
Our supported XenServer build environments lack proper atomic support,
which makes recent OVS techiques (ovs-rcu, cmap) painfully slow. This
series enhances OVS atomic support to address this issue.
Corresponding 32-bit support is still to be done.
Jarno Rajahalme (6):
lib/ovs-atomic: Add atomi
This patch introduces the use of the macro IS_ERR_OR_NULL in place of
tests for NULL and IS_ERR.
The following Coccinelle semantic patch was used for making the change:
@@
expression e;
@@
- e == NULL || IS_ERR(e)
+ IS_ERR_OR_NULL(e)
|| ...
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawal
20 matches
Mail list logo
