-Original Message-
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Wednesday, August 06, 2014 4:52 AM
To: Lichunhe
Cc: dev@openvswitch.org; Qianhuibin (Huibin QIAN, Euler); Wuyunfei
Subject: Re: [PATCH v2] ovs-lib.in:Add process name checking when start ovs
service
On Mon, Aug 04, 2014 at
Looks good in general. It would be nice if we can rename key_extract
to flow_key_extract for consistency with other APIs.
Acked-by: Andy Zhou az...@nicira.com
On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar pshe...@nicira.com wrote:
OVS flow extract is called on packet receive or packet
Dear Colleagues,
*Call for papers*
International Conference on Economics, Energy, Environment and Agricultural
Sciences
* (ICBEEEAS)*
*(20 -21 Sep, 2014 – Kuala Lumpur, Malaysia)*
*Pearl International Hotel**, Kuala Lumpur, Malaysia*
http://www.pakrdw.com/?ic=detailsid=7
The aim of
Hello Nithin,
I'd like to highlight two points here:
1. the datapath on linux doesn't have all files Ovs-prefixed. I don't think
there's a specific requirement for
datapath-windows for that.
2. the datapath on linux uses a lot of functionality of the linux kernel
(such as, the netlink
Thanks for reviewing it. I am working on address the comments. And I add some
new comments inline.
Bests,
Wenyu
Important
-
This needs a rebase because openvswitch.h has moved.
There are sparse warnings and errors. I'll append a patch to fix these.
In datapath/flow_netlink.c,
Move and rename files:
1. Remove Ovs prefixes. There is no reason to have them.
2. Create directories and Visual Studio filters to represent them:
* Core:anything that is generic, that might be used anywhere in code,
etc.
* Hyper-v:functionality for Hyper-V Switch, Hyper-V Nics,
WinlProtocol: km-um attribute and commands constants
openvswitch.h was does not seem to have been originally designed to consider
the Windows platform as well:
a) coding style differs from linux kernel to windows kernel, and we cannot
combine the two in the windows kernel
code.
b) the structs
We don't need wrappers for Interlocked ops.
Atomic.h contain simple wrappers for windows kernel API interlocked functions.
There is no reason to use the wrappers instead of the Kernel API functions
directly.
---
datapath-windows/ovsext/Core/Atomic.h | 32 --
Add Error.h
Constants to be used in km-um / winetlink communication.
---
datapath-windows/ovsext/Core/Error.h | 189 +
datapath-windows/ovsext/ovsext.vcxproj | 1 +
datapath-windows/ovsext/ovsext.vcxproj.filters | 3 +
3 files changed, 193
Add List.h
Macros to be used for operating over a list.
Other possible macros functions to operate on lists should be added here.
---
datapath-windows/ovsext/Core/List.h| 36 ++
datapath-windows/ovsext/ovsext.vcxproj | 1 +
Replace Types.h
The coding style on windows kernel is to use uppercase for all types. This also
applies to builtin types.
We shouldn't use int64_t, uint64_t, etc. Instead, we should use windows style
builtin types: INT64, UINT64, etc.
Also, the new Types.h adds macros for splitting uniting
Add Spooky Hash: a fast hashing algorithm for 64-bit Little Endian machines
Descriptions of the original author:
http://burtleburtle.net/bob/c/lookup3.c (2006) is about 2 cycles/byte, works
well on 32-bit platforms, and can produce a 32 or 64 bit hash. SpookyHash
(2011) is specific to 64-bit
Hello again,
I would also suggest, in order to improve clarity.
For instance, say if there is a function we need to add, that searches the list
of Hyper-V Nics in a list.
And this list is supposed to be previously locked / synchronized by the caller.
The windows kernel style, as we had seen in
Add macros in Debug.h
Checks that:
a) make the code shorter for functions that return BOOLEAN or OVS_ERROR, by
hiding the
repetitive work.
b) on debug mode, do ASSERT, while on release mode can do an, e.g. return X;
instead, for the failure case.
c) by using OVS_CHECK, we can choose via
Compile as C by default
In order to avoid the header files (.h) from being compiled as C++ code.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
datapath-windows/ovsext/ovsext.vcxproj | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Add RefCount.h
The struct that needs to benefit of reference counting should have an
OVS_REF_COUNT field as the
first field in that struct.
What it does:
* It helps shortening the time a spin lock / rw lock is held (the spin lock
rw lock block the cpu).
* It allows deferred object destruction
Move and rename files:
1. Remove Ovs prefixes. There is no reason to have them.
2. Create directories and Visual Studio filters to represent them:
* Core:anything that is generic, that might be used anywhere in code,
etc.
* Hyper-v:functionality for Hyper-V Switch, Hyper-V Nics,
We don't need wrappers for Interlocked ops.
Atomic.h contain simple wrappers for windows kernel API interlocked functions.
There is no reason to use the wrappers instead of the Kernel API functions
directly.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
WinlProtocol: km-um attribute and commands constants
openvswitch.h was does not seem to have been originally designed to consider
the Windows platform as well:
a) coding style differs from linux kernel to windows kernel, and we cannot
combine the two in the windows kernel
code.
b) the structs
Add Error.h
Constants to be used in km-um / winetlink communication.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
datapath-windows/ovsext/Core/Error.h | 189 +
datapath-windows/ovsext/ovsext.vcxproj | 1 +
Add List.h
Macros to be used for operating over a list.
Other possible macros functions to operate on lists should be added here.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
datapath-windows/ovsext/Core/List.h| 36 ++
Add Spooky Hash: a fast hashing algorithm for 64-bit Little Endian machines
Descriptions of the original author:
http://burtleburtle.net/bob/c/lookup3.c (2006) is about 2 cycles/byte, works
well on 32-bit platforms, and can produce a 32 or 64 bit hash. SpookyHash
(2011) is specific to 64-bit
Replace Types.h
The coding style on windows kernel is to use uppercase for all types. This also
applies to builtin types.
We shouldn't use int64_t, uint64_t, etc. Instead, we should use windows style
builtin types: INT64, UINT64, etc.
Also, the new Types.h adds macros for splitting uniting
Update the file CodingStyle: add more Windows-style rules.
Also, other rules will make code more clear.
Windows Kernel style rules:
o) Type names (structs, enums), constants, symbols, macros.
o) Braces
o) Code annotations
o) Function suffix: Unsafe
o) Switch Cases
Code clarity rules:
o) OVS_
Sorry for the many replies.
I had forgotten to add the sign-off-s.
Please let me know if there is any other problem :)
Sam
From: Samuel Ghinet
Sent: Wednesday, August 06, 2014 4:32 PM
To: dev@openvswitch.org
Subject: RE: [PATCH] datapath-windows: Replace Types.h
Add FixedSizedArray
This fixed sized array implementation is meant to be used for datapath ports,
hyper-v switch ports and
hyper-v switch nics. It is a fixed array of MAXUINT16 pointers to fixed sized
array items.
The OVS_FXDARRAY_ITEM supports reference counting.
The fixed sized array will
On Wed, Aug 06, 2014 at 09:55:14AM +, Wenyu Zhang wrote:
Ben Pfaf writes:
In dpif_ipfix_add_tunnel_port(), the check for dip == NULL should be
removed. xmalloc() never returns NULL.
You means that xmalloc() never fails? If it may fail, how shall I check it?
xmalloc() never fails.
Add Core.h
Functionalities macros that are expected to be needed / used anywhere.
Such as: macros for memory allocations.
These would replace the memory allocations functions defined in Utils.c:
* There is no need to allocate memory with priority if priority = normal
(default)
* There is no
On Wed, Aug 06, 2014 at 01:58:00AM +, Alin Serdean wrote:
Sure Ben, hope the following is more accurate.
Win8 Debug solution configuration currently builds in fact under Win8.1
Debug
This patch updates the configuration to properly build under Win8 Debug
Reported in:
On Wed, Aug 06, 2014 at 05:48:03AM +, Lichunhe wrote:
-Original Message-
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Wednesday, August 06, 2014 4:52 AM
To: Lichunhe
Cc: dev@openvswitch.org; Qianhuibin (Huibin QIAN, Euler); Wuyunfei
Subject: Re: [PATCH v2] ovs-lib.in:Add
On Wed, Aug 06, 2014 at 11:00:28AM +, Samuel Ghinet wrote:
Move and rename files:
1. Remove Ovs prefixes. There is no reason to have them.
2. Create directories and Visual Studio filters to represent them:
* Core:anything that is generic, that might be used anywhere in
code,
Hi Sam,
Since the switch extension driver is an NDIS filter driver it would be
preferable to use NDIS memory allocation functions rather direct executive
system calls.
On another thing: since this driver is basically two combined drivers
(Extension and WFP) it would be nice if we could pass
Thanks Ben for the suggestion!
I'm quite new to sending patches via mailing lists, so I am bit left handed :)
I think I will send replies for this, renaming [PATCH] to e.g. [PATCH 01 / 15]
Thanks!
Sam
From: Ben Pfaff [b...@nicira.com]
Sent: Wednesday,
Hello Eitan,
Just found this (it is an answer on a thread, not true doc, but may be helpful):
I would actually suggest avoiding the NdisAllocateMemory* APIs for general
pool allocations, and going straight to the ExAllocate APIs. There's nothing
interesting going on in the NDIS APIs, and the
Sam,
I think Microsoft official recommendation is to NDIS wrapper calls (for
certification).
I came across the following when I read same the thread you pointed out:
I remember an invigorated discussion here some time ago regarding the
necessity to use NDIS APIs inside NDIS drivers in order
Update the file CodingStyle: add more Windows-style rules.
Also, other rules will make code more clear.
Windows Kernel style rules:
o) Type names (structs, enums), constants, symbols, macros.
o) Braces
o) Code annotations
o) Function suffix: Unsafe
o) Switch Cases
Code clarity rules:
o) OVS_
Move and rename files:
1. Remove Ovs prefixes. There is no reason to have them.
2. Create directories and Visual Studio filters to represent them:
* Core:anything that is generic, that might be used anywhere in code,
etc.
* Hyper-v:functionality for Hyper-V Switch, Hyper-V Nics,
WinlProtocol: km-um attribute and commands constants
openvswitch.h was does not seem to have been originally designed to consider
the Windows platform as well:
a) coding style differs from linux kernel to windows kernel, and we cannot
combine the two in the windows kernel
code.
b) the structs
We don't need wrappers for Interlocked ops.
Atomic.h contain simple wrappers for windows kernel API interlocked functions.
There is no reason to use the wrappers instead of the Kernel API functions
directly.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
Add Error.h
Constants to be used in km-um / winetlink communication.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
datapath-windows/ovsext/Core/Error.h | 189 +
datapath-windows/ovsext/ovsext.vcxproj | 1 +
Add List.h
Macros to be used for operating over a list.
Other possible macros functions to operate on lists should be added here.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
datapath-windows/ovsext/Core/List.h| 36 ++
Replace Types.h
The coding style on windows kernel is to use uppercase for all types. This also
applies to builtin types.
We shouldn't use int64_t, uint64_t, etc. Instead, we should use windows style
builtin types: INT64, UINT64, etc.
Also, the new Types.h adds macros for splitting uniting
Add Spooky Hash: a fast hashing algorithm for 64-bit Little Endian machines
Descriptions of the original author:
http://burtleburtle.net/bob/c/lookup3.c (2006) is about 2 cycles/byte, works
well on 32-bit platforms, and can produce a 32 or 64 bit hash. SpookyHash
(2011) is specific to 64-bit
Add macros in Debug.h
Checks that:
a) make the code shorter for functions that return BOOLEAN or OVS_ERROR, by
hiding the
repetitive work.
b) on debug mode, do ASSERT, while on release mode can do an, e.g. return X;
instead, for the failure case.
c) by using OVS_CHECK, we can choose via
Compile as C by default
In order to avoid the header files (.h) from being compiled as C++ code.
Signed-off-by: Samuel Ghinet sghi...@cloudbasesolutions.com
---
datapath-windows/ovsext/ovsext.vcxproj | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Add RefCount.h
The struct that needs to benefit of reference counting should have an
OVS_REF_COUNT field as the
first field in that struct.
What it does:
* It helps shortening the time a spin lock / rw lock is held (the spin lock
rw lock block the cpu).
* It allows deferred object destruction
Add FixedSizedArray
This fixed sized array implementation is meant to be used for datapath ports,
hyper-v switch ports and
hyper-v switch nics. It is a fixed array of MAXUINT16 pointers to fixed sized
array items.
The OVS_FXDARRAY_ITEM supports reference counting.
The fixed sized array will
Add Core.h
Functionalities macros that are expected to be needed / used anywhere.
Such as: macros for memory allocations.
These would replace the memory allocations functions defined in Utils.c:
* There is no need to allocate memory with priority if priority = normal
(default)
* There is no
On Aug 5, 2014, at 6:19 PM, Jesse Gross je...@nicira.com wrote:
On Tue, Aug 5, 2014 at 4:38 PM, Jarno Rajahalme jrajaha...@nicira.com
wrote:
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 271a14e..64761b4 100644
Hi Sam,
I was wondering if you could add an explanation for how (or if) each patch is
related to the open issues or enhancements that we filed in Github.
I think we need to see a motivation which is aligned with the priority we
assigned to the open issues we filed. Otherwise, it would be hard
On Aug 6, 2014, at 2:48 AM, Samuel Ghinet sghi...@cloudbasesolutions.com
wrote:
Hello Nithin,
I'd like to highlight two points here:
1. the datapath on linux doesn't have all files Ovs-prefixed. I don't think
there's a specific requirement for
datapath-windows for that.
2. the
Otherwise creating the first dpif-netdev bridge fails because there are
no handlers:
Program terminated with signal 8, Arithmetic exception.
#0 0x080971e9 in dp_execute_cb (aux_=aux_@entry=0xffcfaa54,
packet=packet@entry=0xffcfac54, md=md@entry=0xffcfac84,
a=a@entry=0x8f58930,
Thanks, Samuel, for posting those patches. As Eitan mentioned, it's helpful to
reference the issue number for tracking purposes. It looks like Github is
pretty smart about updating the issue tracker, too, when a commit goes in.
Since our issue tracker is in a different repo from the code, I
On Wed, Aug 06, 2014 at 03:58:38PM +, Samuel Ghinet wrote:
Thanks Ben for the suggestion!
I'm quite new to sending patches via mailing lists, so I am bit left handed :)
I think I will send replies for this, renaming [PATCH] to
e.g. [PATCH 01 / 15]
Thanks a lot. I see the new postings,
Acked-by: Justin Pettit jpet...@nicira.com
On August 6, 2014 at 9:47:22 AM, Ben Pfaff (b...@nicira.com) wrote:
Otherwise creating the first dpif-netdev bridge fails because there are
no handlers:
Program terminated with signal 8, Arithmetic exception.
#0 0x080971e9 in dp_execute_cb
I crossported this to branch-2.3.
branch-2.3 has an unrelated bug that makes it unusable, though. I posted a fix:
http://openvswitch.org/pipermail/dev/2014-August/043634.html
On Mon, Aug 4, 2014 at 8:23 PM, Ben Pfaff b...@nicira.com wrote:
On Mon, Aug 04, 2014 at 05:40:24PM -0700, Justin
Thanks, applied to branch-2.3.
On Wed, Aug 06, 2014 at 09:54:28AM -0700, Justin Pettit wrote:
Acked-by: Justin Pettit jpet...@nicira.com
On August 6, 2014 at 9:47:22 AM, Ben Pfaff (b...@nicira.com) wrote:
Otherwise creating the first dpif-netdev bridge fails because there are
no
On Wed, Aug 6, 2014 at 9:53 AM, Ben Pfaff b...@nicira.com wrote:
On Wed, Aug 06, 2014 at 03:58:38PM +, Samuel Ghinet wrote:
Thanks Ben for the suggestion!
I'm quite new to sending patches via mailing lists, so I am bit left handed
:)
I think I will send replies for this, renaming
Add files for mapping arg types: from userspace to kernel and vice versa.
The approach of mapping attribute types from userspace to kernel has the
following advantages:
* each arg type can uniquely identify the windows netlink attribute data. Its
value does not depend on
parent attribute
Hello Eitan,
Two pair of eyes are better than one!
Anyway, reading a bit further of what you read:
The only NDIS APIs rule is meant to cover areas that are more central to
networking, like DMA, interrupts, DPCs, and IRPs. For that sort of thing,
miniport drivers must either go through NDIS,
There's no reason for the local variable 'old_count' to be atomic. In fact, if
it is atomic it triggers a GCC4.9 warning (Wunused-value)
The global variables 'a' and 'paux' could be static, according to sparse.
Signed-off-by: Daniele Di Proietto ddiproie...@vmware.com
---
There's something
Some of the changes say we may use this in future. Unless there is an
immediate patch that is using that functionality, it shouldn't be posted for
review. OVS should not be used to park dead code in my opinion.
Thanks!
Saurabh
From: Justin Pettit jpet...@nicira.commailto:jpet...@nicira.com
On Aug 6, 2014, at 2:48 AM, Samuel Ghinet sghi...@cloudbasesolutions.com
wrote:
Hello Nithin,
I'd like to highlight two points here:
1. the datapath on linux doesn't have all files Ovs-prefixed. I don't think
there's a specific requirement for datapath-windows for that.
Sure, we don't
One suggestion below, otherwise looks right to me,
Acked-by: Jarno Rajahalme jrajaha...@nicira.com
On Aug 5, 2014, at 3:25 PM, Pravin B Shelar pshe...@nicira.com wrote:
In case hash collision on mask cache, OVS does extra flow lookup.
Following patch avoid it.
Suggested-by: Jarno Rajahalme
Daniele,
Thanks for spotting these. GCC error message may be cryptic, but using an
atomic variable as the return value is an error regardless.
Acked-by: Jarno Rajahalme jrajaha...@nicira.com
Pushed to master,
Jarno
On Aug 6, 2014, at 10:35 AM, Daniele Di Proietto ddiproie...@vmware.com
My 2 cents, I am not in favor of redoing the directory structure in the
anticipation of it becoming more complex. When/If it becomes complex, we
can do the re-structuring. I don¹t see any need to do it right now.
Thanks!
Saurabh
From: Nithin Raju nit...@vmware.com
Date: Wednesday, August 6,
Thanks,
Daniele
On 8/6/14, 11:07 AM, Jarno Rajahalme jrajaha...@nicira.com wrote:
Daniele,
Thanks for spotting these. GCC error message may be cryptic, but using an
atomic variable as the return value is an error regardless.
Acked-by: Jarno Rajahalme jrajaha...@nicira.com
Pushed to master,
Hello all,
Here is a summary of our initial design. Not all areas are covered so we would
be glad to discuss anything listed here and any other code/features we could
leverage.
Thanks!
Eitan
A. Objectives:
[1] Create a NetLink (NL) driver interface for Windows which interoperates with
hi Sam,
Thanks for posting the patch series. We'll review them.
I am a little confused the netlink patch. From the IRC meeting on 8/5, my
understanding is that we'd come up with a proposal for how to go about making
these changes: VMware would come up with something on the kernel side, and
On Aug 6, 2014, at 11:07 AM, Saurabh Shah ssaur...@vmware.com
wrote:
My 2 cents, I am not in favor of redoing the directory structure in the
anticipation of it becoming more complex. When/If it becomes complex, we
can do the re-structuring. I don¹t see any need to do it right now.
I agree
Hi Samuel,
Move and rename files:
These are two separate changes. Renaming the files to drop ŒOvs¹ is fine.
But, I am not in favor of redoing the directory structure (as expressed in
the another thread). If you can separate these out, we could apply the
renaming patch while we discuss the need
Hi Samuel,
I like the wrapper because it keeps the code looking tidy. With the long
names casting the code line typically ends up way to long unwieldy.
InterlockedAdd64((LONGLONG volatile *)
BasePointer-ChildObject-SomeStatVariable, (LONGLONG) val);
Vs
Add List.h
Macros to be used for operating over a list.
Other possible macros functions to operate on lists should be added
here.
Can you also put these macros to use with some existing code? I am a
little wary of making/using new utilities till we have a working
user/kernel communication.
Add functionality for dp ports, hv nics, hv ports
This is a little ahead of its time. Adding functional changes when we
can¹t even test it with the upstream code is not the way to go. This
should be resurrected once the Netlink-integration is complete and we have
a OVS working on HyperV.
In
Hi,
+1 to drop the OVS prefix.
One another thing that comes to mind would be to have filenames in lowercase,
but maybe that is just me.
Alin.
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Saurabh Shah
Trimis: Wednesday, August 6, 2014 9:52 PM
Către:
Hi,
+1 to drop the OVS prefix.
One another thing that comes to mind would be to have filenames in
lowercase, but maybe that is just me.
But then we need to go away from camel casing and start using underscores.
I am totally up for using Linux/OVS style naming conventions. :) Common
naming
On Aug 6, 2014, at 12:36 PM, Alin Serdean aserd...@cloudbasesolutions.com
wrote:
One another thing that comes to mind would be to have filenames in lowercase,
but maybe that is just me.
Alin,
Windows seems to encourage CamelCasing. Hence we named the files as such.
-- Nithin
Hi Sam,
Just some pointers from me:
- format the text up to 79 characters.
- Do not use space after ( or before ) , people using vi would have a
harder time
- o) _ prefix for private functions, I don't quite understand. Do you mean
static?
Alin.
-Mesaj original-
De la: dev
I fully understand Nithin, maybe it is just me :).
-Mesaj original-
De la: Nithin Raju [mailto:nit...@vmware.com]
Trimis: Wednesday, August 6, 2014 10:46 PM
Către: Alin Serdean
Cc: Saurabh Shah; Samuel Ghinet; dev@openvswitch.org
Subiect: Re: [ovs-dev] [PATCH 02/15] datapath-windows:
Eitan,
Thanks so much for writing this up. This should clarify the questions that the
folks had during the IRC meeting.
Alin,
Pls. feel free to send out a writeup if you have anything to discuss regarding
the changes in dpif-linux.c. If not, if you can cleanup dpif-linux.c, and
submit it with
This patch does not apply for me. Would you please rebase and repost?
On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar pshe...@nicira.com wrote:
Currently tun_info is used for passing tunnel information
on ingress and egress path, this cause confusion. Following
patch removes its use on
Hi Sam,
This looks like a lot of duplicate code from openvswitch.h/odp-netlink.h.
Let us wait for https://github.com/openvswitch/ovs-issues/issues/21 issue to be
fixed first, and after work on top of it.
Alin.
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele
We should wait on this topic until we have the Netlink interface in both
userspace and kernel.
Alin.
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Samuel Ghinet
Trimis: Wednesday, August 6, 2014 7:11 PM
Către: dev@openvswitch.org
Subiect: [ovs-dev] [PATCH
Hi Sam,
Let us discuss this topic on our next meeting.
Ty!
Alin.
-Mesaj original-
De la: dev [mailto:dev-boun...@openvswitch.org] În numele Samuel Ghinet
Trimis: Wednesday, August 6, 2014 7:12 PM
Către: dev@openvswitch.org
Subiect: [ovs-dev] [PATCH 08/15] datapath-windows: Add Spooky
Not to kick off a naming/code convention war, but it would be so much better to
have just one convention for a project. The code can freely call platform
specific routines that don't adhere to the convention (for e.g. Windows
library calls), and that is fine. In fact, it makes it easy to
Hi Sam,
Let us wait for until we have the Netlink interface in place until we want to
start adding other features.
The macros you want to put in place sound useful but they need use cases in the
code also :),
so you might consider respin the patches after we pass the compilation issue
that
Since our issue tracker is in a different repo from the code, I think you need
to reference issues in the following way:
ovs/ovs-issues#42
This is good to know. I wasn't aware about this. Thanks Justin!
-- Saurabh
___
dev mailing
On Wed, Aug 6, 2014 at 1:07 PM, Andy Zhou az...@nicira.com wrote:
This patch does not apply for me. Would you please rebase and repost?
It applies fine to me. It does depends on earlier patches, have you
applied those?
On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar pshe...@nicira.com wrote:
Thank you a lot for writing the document in such a short period.
I will have it in mind when I will write the patches for dpif. If I have
further questions can I get back to you Eitan?
Regards,
Alin.
-Mesaj original-
De la: Nithin Raju [mailto:nit...@vmware.com]
Trimis: Wednesday,
BTW, CONTRIBUTING file mentions a Reported-at: that we could use to provide
specific links to the issue addressed.
-- Nithin
On Aug 6, 2014, at 2:01 PM, Saurabh Shah ssaur...@vmware.com
wrote:
Since our issue tracker is in a different repo from the code, I think you
need
to reference
Yes, it would be helpful to use that form. So far I've transformed
the issue references in the patches I've committed into that form. If
some other form is better for github then let's write up the
appropriate format as a patch to CONTRIBUTING.
Thanks,
Ben.
On Wed, Aug 06, 2014 at 09:14:23PM
On Aug 6, 2014, at 2:12 PM, Alin Serdean aserd...@cloudbasesolutions.com
wrote:
I will have it in mind when I will write the patches for dpif. If I have
further questions can I get back to you Eitan?
Absolutely, we'll start working on the patches based on this design, and while
we do so,
Sure Alin, we would be glad to add details or to clarify any issue.
Thanks,
Eitan
-Original Message-
From: Alin Serdean [mailto:aserd...@cloudbasesolutions.com]
Sent: Wednesday, August 06, 2014 2:12 PM
To: Nithin Raju; Eitan Eliahu
Cc: dev@openvswitch.org; Rajiv Krishnamurthy; Ben Pfaff;
On Wed, Aug 6, 2014 at 9:23 AM, Jarno Rajahalme jrajaha...@nicira.com wrote:
On Aug 5, 2014, at 6:19 PM, Jesse Gross je...@nicira.com wrote:
On Tue, Aug 5, 2014 at 4:38 PM, Jarno Rajahalme jrajaha...@nicira.com
wrote:
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
+1 from my point of view.
-Mesaj original-
De la: Saurabh Shah [mailto:ssaur...@vmware.com]
Trimis: Wednesday, August 6, 2014 11:24 PM
Către: Alin Serdean; Nithin Raju
Cc: Samuel Ghinet; dev@openvswitch.org
Subiect: RE: [ovs-dev] [PATCH 02/15] datapath-windows: Move and Rename files
Not
On Tue, Aug 05, 2014 at 09:44:40PM -0700, Ethan Jackson wrote:
Based on my (long ago) reading of the LACP spec, only supporting a
single aggregator is a valid configuration. Furthermore, it's what
It is, no questions about that.
makes the most sense given the structure of the OVS bonding
Commit fea393b1 (datapath: Describe policy for extending flow key,
implement needed changes.) changed the key 'OVS_KEY_ATTR_8021Q' to
'OVS_KEY_ATTR_VLAN' and the size of the attribute structure. A couple
of comments were missed, so this commit updates them.
Signed-off-by: Justin Pettit
A future commit will add more L4 state fields that will be part of the
L3 section.
Signed-off-by: Justin Pettit jpet...@nicira.com
---
lib/flow.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/lib/flow.h b/lib/flow.h
index 3b8d24d..250a10e 100644
--- a/lib/flow.h
Looks good in general. Some minor comments inline.
Acked-by: Andy Zhou az...@nicira.com
On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar pshe...@nicira.com wrote:
Recirc action needs to extract flow key from packet, it uses tun_info
from OVS_CB for setting tunnel meta data in flow key. But
On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar pshe...@nicira.com wrote:
Currently tun_info is used for passing tunnel information
on ingress and egress path, this cause confusion. Following
patch removes its use on ingress path make it egress only parameter.
Sorry for the patch rebasing
1 - 100 of 118 matches
Mail list logo
