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 protoc
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, ipv4_
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, H
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 co
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 --
da
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 insertions
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 +
datapath-windows/ovsext/o
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 da
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 pl
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 t
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 OVS_US
Compile as C by default
In order to avoid the header files (.h) from being compiled as C++ code.
Signed-off-by: Samuel Ghinet
---
datapath-windows/ovsext/ovsext.vcxproj | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/datapath-windows/ovsext/ovsext.vcxproj
b/datapath-wi
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 destructi
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, H
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
---
datapath-windows/ovsext/Core/Atomic.h | 32
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 co
Add Error.h
Constants to be used in km-um / winetlink communication.
Signed-off-by: Samuel Ghinet
---
datapath-windows/ovsext/Core/Error.h | 189 +
datapath-windows/ovsext/ovsext.vcxproj | 1 +
datapath-windows/ovsext/ovsext.vcxproj.filters | 3 +
3
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
---
datapath-windows/ovsext/Core/List.h| 36 ++
datapath-windows/ovsext/ovsext.vcxproj |
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 pl
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 da
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_ pre
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.
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 offe
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 ne
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 i
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
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
>
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, Augu
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 k
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 t
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_ pre
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, H
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 co
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
---
datapath-windows/ovsext/Core/Atomic.h | 32
Add Error.h
Constants to be used in km-um / winetlink communication.
Signed-off-by: Samuel Ghinet
---
datapath-windows/ovsext/Core/Error.h | 189 +
datapath-windows/ovsext/ovsext.vcxproj | 1 +
datapath-windows/ovsext/ovsext.vcxproj.filters | 3 +
3
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
---
datapath-windows/ovsext/Core/List.h| 36 ++
datapath-windows/ovsext/ovsext.vcxproj |
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 da
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 pl
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 OVS_US
Compile as C by default
In order to avoid the header files (.h) from being compiled as C++ code.
Signed-off-by: Samuel Ghinet
---
datapath-windows/ovsext/ovsext.vcxproj | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/datapath-windows/ovsext/ovsext.vcxproj
b/datapath-wi
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 destructi
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 offe
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 ne
> On Aug 5, 2014, at 6:19 PM, Jesse Gross wrote:
>
>> On Tue, Aug 5, 2014 at 4:38 PM, Jarno Rajahalme
>> wrote:
>> diff --git a/datapath/linux/compat/include/linux/openvswitch.h
>> b/datapath/linux/compat/include/linux/openvswitch.h
>> index 271a14e..64761b4 100644
>> --- a/datapath/linux/com
Add functionality for dp ports, hv nics, hv ports
In order to be able to make the mapping between datapath ports and hyper-v
ports.
Hyper-v switch ports and hyper-v nics belong to the switch, while the dp ports
are implemented as fixed
sized arrays and belong in the datapath.
Functions to hande
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
> 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 "datapath" on linux uses
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, may
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 th
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 postin
Acked-by: Justin Pettit
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 (aux_=aux_@entry=0xff
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 wrote:
> On Mon, Aug 04, 2014 at 05:40:24PM -0700, Justin Pettit wrote:
>> On
Thanks, applied to branch-2.3.
On Wed, Aug 06, 2014 at 09:54:28AM -0700, Justin Pettit wrote:
> Acked-by: Justin Pettit
>
>
> 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:
> >
> >
On Wed, Aug 6, 2014 at 9:53 AM, Ben Pfaff 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 [PATCH] to
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 types,
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
---
There's something interesting about the warning
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 mailto:jpet...@nicira.com>>
Date: Wednesday, A
On Aug 6, 2014, at 2:48 AM, Samuel Ghinet
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 have a requirement that t
One suggestion below, otherwise looks right to me,
Acked-by: Jarno Rajahalme
On Aug 5, 2014, at 3:25 PM, Pravin B Shelar wrote:
> In case hash collision on mask cache, OVS does extra flow lookup.
> Following patch avoid it.
>
> Suggested-by: Jarno Rajahalme
> Signed-off-by: Pravin B Shelar
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
Pushed to master,
Jarno
On Aug 6, 2014, at 10:35 AM, Daniele Di Proietto wrote:
> There's no reason for the local varia
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
Date: Wednesday, August 6, 2014 at 10:52 AM
T
Thanks,
Daniele
On 8/6/14, 11:07 AM, "Jarno Rajahalme" 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
>
>Pushed to master,
>
> Jarno
>
>On Aug 6, 2014, at 1
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
the
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
clou
On Aug 6, 2014, at 11:07 AM, Saurabh Shah
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 with Saurabh on thi
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
atomic_add64(BasePointer->ChildObject
>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: Samuel
>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
namin
On Aug 6, 2014, at 12:36 PM, Alin Serdean
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: Move
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 t
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 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 e
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 05/
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 Has
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 identi
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 we
> 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 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 wrote:
>> Currently tun_info is used for
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, Aug
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
wrote:
>> Since our issue tracker is in a different repo from the code, I think you
>> need
>> to reference issues in the f
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
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, we'll leverage existing code as
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 wrote:
>
>> On Aug 5, 2014, at 6:19 PM, Jesse Gross wrote:
>>
>>> On Tue, Aug 5, 2014 at 4:38 PM, Jarno Rajahalme
>>> wrote:
>>> diff --git a/datapath/linux/compat/include/linux/openvswitch.h
>>> b/datapath/linux/compat/include/linux/openvswitch.
+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
---
data
A future commit will add more L4 state fields that will be part of the
L3 section.
Signed-off-by: Justin Pettit
---
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
+++ b/lib/flow.h
@@ -
Looks good in general. Some minor comments inline.
Acked-by: Andy Zhou
On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar 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 tun_info
> can be overwritten by tunn
On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar 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 request. I messed u
On Wed, Jul 30, 2014 at 8:51 AM, Daniele Di Proietto
wrote:
> DPDK rings must have a power-of-two size.
>
> Signed-off-by: Daniele Di Proietto
> ---
> lib/netdev-dpdk.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index b4
On Wed, Aug 6, 2014 at 3:30 PM, Andy Zhou wrote:
> On Tue, Aug 5, 2014 at 4:46 PM, Pravin B Shelar 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 param
1 - 100 of 118 matches
Mail list logo
