hi Ben,
This is very reasonable. This will enable meaningful collaboration
without duplicating effort. There are some indications of design choices
that have seem different between the two implementations. Discussing
about those things would be useful for the product.
For Eg:.
> * Cloudbase ha
> > [5] Offload encapsulation is important for GENEVE as well. I would
> expect NDIS support for it. We might a need special intermediate support
> though.
>
> Agreed. I limited the list to VXLAN and GRE because that's what we had
> ATM, but suppot GENEVE offloading support has definitely to be in
per Ben's suggestion.
This fix is specific to Windows, since '/' is a valid character
in a file or directory name in Linux.
Signed-off-by: Nithin Raju
---
lib/lockfile.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/lockfile.c b/lib/lockfile.c
index 1ef6251..15a7e4
Alin,
Saurabh shared the wireshark trace you sent him. I agree that the packets have
protocol 0x01 - ICMP. So, ping packets are directly being sent over the wire
without encap.
To start with, let's clear out the following variables:
1. Is there a patch port at all between br-int and br-pif? I re
10.00 AM Pacific - Sounds good to me.
hi Alessandro,
We'll be meeting tomorrow. In the light of that, we had the following items on
mind that we could discuss. Pls. feel free to edit the list:
1. Helping Alin to run some tests successfully (with the V2 patch that Saurabh
posted last week).
hi Folks,
Alessandro might be writing up a more detailed transcript of the IRC meeting we
had on Tuesday. I just wanted to cover things at a high level:
Attendees:
>From VMware : Justin Pettit, Ben Pfaff, Guru Shetty, Saurabh, Ankur, Nithin
>and Eitan
>From Cloudbase: Alin Serdean and SamuelG, A
hi Alin,
In the light of issues filed on github that are a side effect of
mis-configuration, I wanted to point out that we have documented the steps to
get a basic working setup in INSTALL.Windows. There is documentation to setup a
VXLAN network, and a VLAN network. I posted the same on one of t
On Aug 1, 2014, at 12:17 AM, Eitan Eliahu
wrote:
> BSOD while setting AllowManagementOS on $false #13
> https://urldefense.proofpoint.com/v1/url?u=https://github.com/openvswitch/ovs/issues/13&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=ubrOpIWavCMqX4l4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=nJEdnLEDoAO
On Jul 31, 2014, at 5:22 PM, Eitan Eliahu
wrote:
> 3. If clearing the context from will be removed from
> OvsCompleteNBLForwardingCtx then we need to call OvsClearTunCtx() on all
> error paths of this function. Apply it only to this path does not buy
> anything here.
Currently, it does so.
ntext->internalVport == NULL) {
> +OvsClearTunTxCtx(ovsFwdCtx);
> +OvsCompleteNBLForwardingCtx(ovsFwdCtx,
> +L"OVS-Dropped since internal port is absent");
> +return NDIS_STATUS_FAILURE;
> +}
> ovsFwdCtx->srcVportNo =
> ((
hi,
This is a followup to the discussion on 7/29 between the VMware and the
Cloudbase teams working on OVS for Hyper-V, regarding Netlink based interface
implementation between kernel and userspace.
It was agreed that VMware folks would look at the kernel code posted on 7/29 by
Cloudbase team, and
hi Alessandro,
We have the following items to discuss for tomorrow's meeting:
1. Netlink implementation. (A note has been sent out about this)
2. Discuss issues that Cloudbase found during their testing.
3. Followup from previous week.
Like last week, pls. feel free to add more items.
thanks,
Ni
Since commit 837eefc7 (Do not seemingly #include Linux-specific
headers on other platforms), openvswitch.h is being auto-generated
as include/odp-netlink.h.
On Windows, the auto-generated files are explicitly built. In this
change, we update the list of auto-generated files to also refer
to inclu
This "issue" is not limited to missed packets only. This is applicable when
there is a flow in the kernel as well.
When a VIF requests IPsec offload, and such a packet needs to be tunneled, we
might need to complete the IPsec offload requested before we encap the packet
to form an outer packet.
We no-longer need to build individual targets on Windows. This information
was lost when we committed the hyper-v changes to the repo.
Resurrecting that information in this change.
Also, added the testing instructions on how to setup a VLAN based network.
Signed-off-by: Nithin Raju
On Aug 5, 2014, at 7:24 AM, Samuel Ghinet
wrote:
> Hello Nithin,
>
> Even with having this IPSec problem:
> a) The other NBL info items are still standing.
> b) There is no IPSec worry for the cases where we do not do tunneling (I
> believe).
Yes and No. In general, we don't need to complete
On Aug 5, 2014, at 10:36 AM, Ben Pfaff
wrote:
> On Tue, Aug 05, 2014 at 08:58:08AM -0700, Gurucharan Shetty wrote:
>> On Tue, Aug 5, 2014 at 8:30 AM, Nithin Raju wrote:
>>> We no-longer need to build individual targets on Windows. This information
>>> was lost wh
-windows/{extensions.sln => ovsext.sln} (100%)
>
> diff --git a/datapath-windows/extensions.sln b/datapath-windows/ovsext.sln
> similarity index 100%
> rename from datapath-windows/extensions.sln
> rename to datapath-windows/ovsext.sln
Acked-by: Nithin Raju
__
On Aug 5, 2014, at 1:47 PM, Ben Pfaff
wrote:
> diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
I didn't realize that we have a datapath-windows/automake.mk. I missed this. My
bad.
-- Nithin
___
dev mailing list
dev@openvswi
Sam,
One thing to note is that there's thought that has gone into organizing the
files by functionality, and the names of the files indicate so. For someone
familiar with how a OVS datapath works, it should not take a lot of time to
figure out which file implements a particular functionality. I
o%3D%0A&m=N3EnO8zQgjzNalr%2FXQYRKqXm2MX%2BV4DSCCKbhVSAqGw%3D%0A&s=c412f105afd7a199178382e05d15138cee8df314113f9b485dcda14072fd41e3
>
> Signed-off-by: Alin Gabriel Serdean
> ---
> datapath-windows/ovsext.sln | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
Acked-by: Nithin Raju
We eventually want to get rid of support
Jarno
>>
>> (*) include directory and Linux compat code are exceptions, but
>> usually that does not matter. include/openflow is about the only
>> significant directory there, and it is rather stable :-)
>>
>>> On Aug 5, 2014, at 3:43 PM, Nithin Raju
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
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
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
_
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
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
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
approach, this patch looks good to me.
Acked-by: Nithin Raju
thanks,
Nithin
On Aug 6, 2014, at 4:30 PM, Ankur Sharma
wrote:
> odp-netlink.h: Autogenerate a version of odp-netlink for windows kernel.
>
> Autogenerated odp-netlink.h will not compile with windows kernel, as
>
rdean; dev@openvswitch.org; Rajiv Krishnamurthy; Ben Pfaff;
> Kaushik Guha; Ben Pfaff; Justin Pettit; Nithin Raju; Ankur Sharma; Samuel
> Ghinet; Linda Sun; Keith Amidon
> Subiect: RE: Design notes for provisioning Netlink interface from the OVS
> Windows driver (Switch extension)
hi folks,
Here are the items to discuss. Pls. feel free to fill in more items.
1. Netlink implementation discussion - design discussions, status.
2. Discussion about the persistent ports patch that Cloudbase is tasked with.
3. Discussion about P0 issues.
4. Discussion of other issues.
5. Samuel's
On Aug 11, 2014, at 10:04 AM, Ben Pfaff
wrote:
> On Mon, Aug 11, 2014 at 04:19:41PM +0000, Nithin Raju wrote:
>> 5. Samuel's reviews:
>> * I'll let Sam and Alin fill this in.
>
> I hope that code reviews will be mainly on the mailing list. That's
On Aug 11, 2014, at 4:01 PM, Ankur Sharma
wrote:
> Hi Ben,
>
> Thanks a lot for your reply.
>
> The reason we did not generate header file in build directory is because as
> of now the windows datapath build is not coupled with user-space build.
> The userspace build system is 'make' and com
pif-windows.c):
- Was able to perform VTEP <-> VTEP ping with the configuration posted in the
issue.
- Was able to perform VIF <-> VIF ping when the setup was configured correctly.
Signed-off-by: Nithin Raju
Reported-by: Alin Serdean
Reported-at: https://github.com/openvsw
Samuel,
Were you able to test cases where the multiple NBL case originated from a VM,
and was subject to tunneling?
I'll look at your patch.
thanks,
Nithin
On Aug 13, 2014, at 7:25 AM, Samuel Ghinet
wrote:
> Create a NBL for each NB when required
>
> ovs/ovs-issues#15
>
> All NET_BUFFERs o
On Aug 13, 2014, at 7:05 AM, Samuel Ghinet
wrote:
> [QUOTE]The driver does not care about multiple threads concurrently executing
> dump as any DeviceIOContol will be self-contained. Also, the user mode
> implementation guarantees that there are no simultaneous dumps for a given
> socket.[/
Sam,
OvsDpInterface.h is basically the OVS datapath's interface. It is being
generated in a separate directory - sort of public for the datapath - to be
sure. I'm inclined to leave the Ovs keyword alone for this 'OVS interface'
file. Is that reasonable?
thanks,
Nithin
On Aug 13, 2014, at 8:11
comments
and have discussions on the ML itself.
Just wanted to communicate this.
thanks,
Nithin
On Aug 11, 2014, at 9:19 AM, Nithin Raju
mailto:nit...@vmware.com>>
wrote:
hi folks,
Here are the items to discuss. Pls. feel free to fill in more items.
1. Netlink implementation disc
On Aug 13, 2014, at 8:24 AM, Alin Serdean
wrote:
> I will take a look over the patch after the meeting.
Sounds good.
thanks,
Nithin
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Aug 13, 2014, at 8:29 AM, Samuel Ghinet
wrote:
> However, I would remove "Ovs" from OvsPub.h and OvsNetlink.h.
> Would that be ok to you?
Totally fine!
OvsPub.h is the legacy interface and will be nuked as soon as the netlink based
interface is ready. OvsNetlink.h will be moved back within
Sure. I'll take a look. There may be some complications with the existing code
if we process an NBL with multiple NBs through tunneling. Maybe your changes
fixes some of it.
-- Nithin
On Aug 13, 2014, at 9:00 AM, Samuel Ghinet
wrote:
> Hello Nithin,
>
> I did only a very basic test for thi
On Aug 13, 2014, at 1:07 PM, Alin Serdean
wrote:
> Very sporadic times.
>
> Will continue my testing and review tomorrow.
>
> Just wanted to let you know :).
Thanks Alin for the review and validation.
I also left a VIF <-> VIF VXLAN based ping overnight. Still going strong.
-- Nithin
.
Thanks!
-- Nithin
From: Ankur Sharma
Sent: Wednesday, August 13, 2014 4:31 PM
To: Saurabh Shah; Samuel Ghinet; Nithin Raju
Cc: dev@openvswitch.org
Subject: RE: [ovs-dev] datapath-windows: Renaming files proposal
Correct, i think userspace interaction headers should have Ovs prefix.
Regards,
A
On Aug 13, 2014, at 5:21 PM, Samuel Ghinet
mailto:sghi...@cloudbasesolutions.com>>
wrote:
OvsEth.h -> Ethernet.h [TELL ME IF YOU PREFER "Eth.h"]
I like Eth.h, just my opinion though.
The following will be left intact:
OvsDpInterface.h
Because it is a userspace interaction file and it is a gen
On Aug 13, 2014, at 5:32 PM, Samuel Ghinet
mailto:sghi...@cloudbasesolutions.com>>
wrote:
I meant,
tell me whether you prefer Eth.h or Ethernet.h
I have a slight preference for Ethernet.h, but it's no big deal to me.
hi Sam,
Since you are making the change, I'll go with your preference. Etherne
being checked in.
Signed-off-by: Nithin Raju
---
lib/netlink-socket.c | 68 +++--
1 files changed, 54 insertions(+), 14 deletions(-)
diff --git a/lib/netlink-socket.c b/lib/netlink-socket.c
index 3dbfe59..e7449c2 100644
--- a/lib/netlink-socket.c
+++
27;ll turn it to 1.
Since OvsDatapath.[ch] containes code copied from OvsIoctl.[ch], acking
the original author as well.
Signed-off-by: Nithin Raju
Co-authored-by: Guolin Yang
---
datapath-windows/ovsext/OvsActions.c |1 -
datapath-windows/ovsext/OvsDatapath.c |
OvsDpInterfaceExt.h.
Also, we define three ioctls in OvsDpInterfaceExt.h:
read: provides an output buffer (mimics a recv)
write:provides an input buffer (mimics a send)
transact: provides an input and optionally an output buffer.
(mimics a send followed by recv)
Signed-off-by: Nithin Raju
recv, send, and send-recv in userspace netlink. This interface
is subject to change as iron out the details of the user-kernel
interface for operations around packet receive, events, dump, etc.
We also turn on OVS_USE_NL_INTERFACE to 1 in the ovsext project.
Signed-off-by: Nithin Raju
---
datapath
hi,
I just wanted to send out the meeting minutes for any future reference:
Attendees: Alin Serdean, Samuel Ghinet, Ankur Sharma, Saurabh Shah, Ben Pfaff,
Nithin Raju.
1. Netlink implementation discussion - design discussions, status
Signed-off-by: Nithin Raju
---
datapath-windows/ovsext/OvsActions.c |2 +-
datapath-windows/ovsext/OvsSwitch.h |1 +
datapath-windows/ovsext/OvsUser.c|3 ++-
datapath-windows/ovsext/OvsVport.c | 10 +-
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a
> I saw that Ben already applied this patch yesterday. However, I just have one
> comment below.
Np. I'll take care of review comments in a followup patch.
>> +/*
>> + * Tx:
>> + * The destination port is a tunnel port. Encapsulation must be
>> + * performed only
On Aug 14, 2014, at 4:41 PM, Ankur Sharma
wrote:
> Changes are fine (if we want to keep both devices till netlink integration
> is done).
> Lets wait for alin/sam's comments as well.
Thanks. I am keeping the 2 devices, since that is what we communicated in the
design document. I'll check wit
Alin,
Thanks for making this change. It is great that we can build via command line
now.
Some comments I had are:
1. Somewhere at the top we should mention that the 'forwarding extension' is a
'kernel driver'. For someone now familiar with Windows, it might make it more
obvious as to which is t
On Aug 14, 2014, at 5:01 PM, Saurabh Shah
wrote:
>> +#define OVS_DEVICE_NAME_USER TEXT(".\\OpenVSwitchDevice")
>> +
>
> Should be "OpenvSwitchDevice".
Sure. I'll change this.
>> +#ifdef _WIN32
>> +#include "OvsDpInterfaceExt.h"
>> +#endif
>
> Since we define & control the dp interface,
On Aug 14, 2014, at 5:56 PM, Nithin Raju
wrote:
>> Since we define & control the dp interface, why not just include
>> OvsDpInterfaceExt.h directly? (Just like what we used to do earlier by
>> including OvsPub.h.)
>
> If we include OvsDpInterfaceExt.h, we'll
On Aug 14, 2014, at 4:46 PM, Saurabh Shah
wrote:
> $ grep PORT_NO datapath-windows/include/OvsPub.h
> #define OVS_DEFAULT_PORT_NO 0x
I named it the way you had suggested initially, then changed it to
OVS_VPORTNO_DEFAULT, since other constants in the file were named like
OVS__DEFAULT_
On Aug 14, 2014, at 4:53 PM, Ankur Sharma
wrote:
> a. I think we should add the cmd handler installation in following format:
>
> /* Netlink control family: this is a Windows specific family. */
> NETLINK_CMD nlControlFamilyCmdOps[] = {
>{OVS_CTRL_CMD_WIN_GET_PID, OvsGetPidCmdHandler, OVS_TR
On Aug 14, 2014, at 5:08 PM, Saurabh Shah
wrote:
> Naming the file OvsIoctl.[ch] seems much clearer to me. I don't know why
> these files are being renamed. Also, if these are not going to be shared with
> the userspace, you should drop the Ovs prefix from the file name.
hi Saurabh,
The legac
OvsDpInterfaceExt.h.
Also, we define three ioctls in OvsDpInterfaceExt.h:
read: provides an output buffer (mimics a recv)
write:provides an input buffer (mimics a send)
transact: provides an input and optionally an output buffer.
(mimics a send followed by recv)
Signed-off-by: Nithin Raju
being checked in.
Signed-off-by: Nithin Raju
---
lib/netlink-socket.c | 94 +++---
1 files changed, 74 insertions(+), 20 deletions(-)
diff --git a/lib/netlink-socket.c b/lib/netlink-socket.c
index 3dbfe59..45bbd9b 100644
--- a/lib/netlink-socket.c
+++
rn it to 1.
Since Datapath.[ch] containes code copied from OvsIoctl.[ch], acking
the original author as well.
Signed-off-by: Nithin Raju
Co-authored-by: Guolin Yang
---
datapath-windows/ovsext/Datapath.c | 407
datapath-windows/ovsext/{OvsIoctl.h => Da
recv, send, and send-recv in userspace netlink. This interface
is subject to change as iron out the details of the user-kernel
interface for operations around packet receive, events, dump, etc.
We also turn on OVS_USE_NL_INTERFACE to 1 in the ovsext project.
Signed-off-by: Nithin Raju
---
datapath
On Aug 14, 2014, at 7:03 PM, Saurabh Shah
wrote:
> Can your rename OVS_VPORTNO_DEFAULT to something else? Having two defaults
> with similar name, but different value is confusing.
My bad, I didn't realize that you had pointed me to OVS_DEFAULT_PORT_NO
earlier. New patch will be up on a bit.
Signed-off-by: Nithin Raju
---
datapath-windows/ovsext/OvsActions.c |2 +-
datapath-windows/ovsext/OvsUser.c|3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/datapath-windows/ovsext/OvsActions.c
b/datapath-windows/ovsext/OvsActions.c
index 635becc..321f53a
On Aug 15, 2014, at 1:24 PM, Ben Pfaff
wrote:
> I'm fine with this. I'd like someone else to review the actual
> Windows-specific bits.
Thanks Ben. Ankur and Saurabh have reviewed the Windows bits and are fine with
it. I am waiting for Alin and Samuel's review.
thanks,
Nithin
___
Samuel,
Thanks for writing this up. I don't agree with some of them, but do like some
of the suggestions. I am actually encouraged that the CodingStyle for
datapath-windows is evolving.
> - For types, use all upper case for all letters with words separated by '_'.
> If
> - camel casing is pre
On Aug 13, 2014, at 8:16 AM, Alin Serdean
wrote:
> The following changes are just a start to begin a discussion.
>
> Bypass all epoll functionality.
>
> IOCP work the other way around than epoll: you get if the operation finished
> for a HANDLE in contrast of getting the number of file descrip
On Aug 13, 2014, at 7:25 AM, Samuel Ghinet
wrote:
> Create a NBL for each NB when required
>
> ovs/ovs-issues#15
>
> All NET_BUFFERs of a NET_BUFFER_LIST must go through
> the pipeline: extract, find flow, execute. Previously,
> only the first NET_BUFFER of a NET_BUFFER_LIST was going
> throug
On Aug 6, 2014, at 9:14 AM, Samuel Ghinet
wrote:
> How it works:
> Say we have a list of OVS_FLOWs, where OVS_FLOW uses OVS_REF_COUNT.
>
> * The OVS_REF_COUNT must be initialized to 0 at object creation.
> * Assign a destruction function to the func ptr "Destroy" of OVS_REF_COUNT.
> * When you
hi Sam,
I don't understand this change completely. Can you pls. give some background?
If someone else can ack it, that is fine with me.
> - Condition="'$(Configuration)|$(Platform)'=='Win8.1
> Debug|x64'">..\..\datapath\linux\compat\include\linux;$(IntDir);%(AdditionalIncludeDirectories);.
On Aug 6, 2014, at 9:11 AM, Samuel Ghinet
wrote:
> 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, et
Sam,
There are lot of assumptions here about how code should be structured and
written. eg. there's an implicit assumption that 'Cleanup' should be defined.
Let's table this for sometime till we get the current code starts working with
netlink.
If you can point me to some code what is using the
Samuel,
Is this a pre-cursor for implementing the persistent ports feature that the
cloudbase repo had implemented. We really liked that feature to be able to set
the port name from userspace.
Can the persistent port patch be implemented on the of the VPORT array data
structure we have today in
Sam,
I don't have a strong opinion here. I am fine if you want to change the utility
functions in OvsUtil.c to allocate and free the memory. These are different
implementations to do the same thing, and not significantly different. If you
want to go ahead and make this change, pls. make it in Ov
; I will try to take a look over the patches if I get a chance.
>>
>> Thank you for looking up our patches.
>>
>> Thanks,
>> Alin.
>>
>> -Mesaj original-
>> De la: Nithin Raju [mailto:nit...@vmware.com]
>> Trimis: Friday, August 15, 201
On Aug 18, 2014, at 7:19 AM, Nithin Raju
wrote:
> +ovs-dev
>
> hi Sam/Alin,
> I want to propose that I can go ahead get my patches committed, since we am
> working on more patches that are dependent on this. Any review comments that
> I get from you folks, I'll
On Aug 18, 2014, at 5:17 PM, Alin Serdean
wrote:
> Good place to start in my opinion but I will leave the final review to Sam
> because he is working on the Netlink integration part aswell.
Alin,
Thanks for taking a look late into the night :) So, I'll take this as an ACK
from you.
It is fin
On Aug 18, 2014, at 5:14 PM, Alin Serdean
wrote:
> I'm fine with this patch with the idea in mind that OvsDpInterfaceExt.h can
> be added to odp-netlink.h. Not sure about the name though :).
Alin,
As the name indicates, the idea is to add "extensions" to the DP interface. We
could add the co
On Aug 18, 2014, at 5:35 PM, Alin Serdean
wrote:
> I worked mostly on the userspace last week and Sam worked on multiple NB to
> NBL.
>
> I will redo my patches with the build and userspace somewhere tomorrow and
> will repost Sam's patch (we spent some time in the weekend testing it).
Sound
On Aug 18, 2014, at 5:35 PM, Alin Serdean
wrote:
> I think you can work with Sam together this week to get the Netlink part in
> the kernel up and running.
Alin,
Just one question here. From my understanding, VMware folks are working on the
kernel patch to add netlink support, and Alin (and p
On Aug 18, 2014, at 5:08 PM, Alin Serdean
wrote:
> Hi Nithin,
>
> Just a few thoughts:
> Since get PID is a special case would it not be better to treat it as a
> DeviceIoControl;dwIoControlCode like OVS_IOCTL_TRANSACT (i.e.
> OVS_IOCTL_GET_PID)?
>
> We can drop the extra headers and the wh
> Is there any objection if we directly include OvsDpInterfaceExt.h in
> userspace (with the right #ifdefs, of course)? I don't understand why we
> would want to auto-generate a file just to include the kernel header file.
> This is what the auto-generated file is supposed to look like -
>
> /*
>
being checked in.
Signed-off-by: Nithin Raju
---
lib/netlink-socket.c | 93 +++---
1 files changed, 73 insertions(+), 20 deletions(-)
diff --git a/lib/netlink-socket.c b/lib/netlink-socket.c
index 3dbfe59..91a4809 100644
--- a/lib/netlink-socket.c
+++
being checked in.
Signed-off-by: Nithin Raju
Acked-by: Alin Serdean
Acked-by: Ankur Sharma
Acked-by: Saurabh Shah
Reported-at: https://github.com/openvswitch/ovs-issues/issues/18
---
lib/netlink-socket.c | 93 +++---
1 files changed, 73 insertions(+
recv, send, and send-recv in userspace netlink. This interface
is subject to change as iron out the details of the user-kernel
interface for operations around packet receive, events, dump, etc.
We also turn on OVS_USE_NL_INTERFACE to 1 in the ovsext project.
Signed-off-by: Nithin Raju
Acked-by: Alin
rn it to 1.
Since Datapath.[ch] containes code copied from OvsIoctl.[ch], acking
the original author as well.
Signed-off-by: Nithin Raju
Co-authored-by: Guolin Yang
Acked-by: Alin Serdean
Acked-by: Ankur Sharma
Acked-by: Saurabh Shah
---
datapath-windows/ovsext/Datapath.c |
OvsDpInterfaceExt.h:
read: provides an output buffer (mimics a recv)
write:provides an input buffer (mimics a send)
transact: provides an input and optionally an output buffer.
(mimics a send followed by recv)
Signed-off-by: Nithin Raju
Co-Authored-by: Ben Pfaff
Acked-by: Alin Serdean
Acked-by
rn it to 1.
Since Datapath.[ch] containes code copied from OvsIoctl.[ch], acking
the original author as well.
Signed-off-by: Nithin Raju
Co-authored-by: Guolin Yang
Acked-by: Alin Serdean
Acked-by: Ankur Sharma
Acked-by: Saurabh Shah
---
datapath-windows/ovsext/Datapath.c |
OvsDpInterfaceExt.h:
read: provides an output buffer (mimics a recv)
write:provides an input buffer (mimics a send)
transact: provides an input and optionally an output buffer.
(mimics a send followed by recv)
Signed-off-by: Nithin Raju
Co-Authored-by: Ben Pfaff
Acked-by: Alin Serdean
Acked-by
it back to userspace.
dpif-linux.c was ported to Windows (similar to Alin's change in
the cloudbase repo) and was able to exercise the code changes
in netlink-socket.c to read the PID. dpif-linux.c changes are
not being checked in.
Signed-off-by: Nithin Raju
Acked-by: Alin Serdean
Acked-by:
recv, send, and send-recv in userspace netlink. This interface
is subject to change as iron out the details of the user-kernel
interface for operations around packet receive, events, dump, etc.
We also turn on OVS_USE_NL_INTERFACE to 1 in the ovsext project.
Signed-off-by: Nithin Raju
Acked-by: Alin
hi Samuel,
Thanks for resending.
I'm CCing Ben if he as more points.
At a high level, IP helper uses the host Hyper-V's ARP and IP routing stack
functionality. At a high level it consists of the following parts:
1. Data structures the maintain the L2 and L3 cache.
2. Functionality to Query the
hi,
Just sending out the meeting minutes for future reference.
Attendees: Alin Serdean, Samuel Ghinet, Ankur Sharma, Saurabh Shah, Nithin Raju
1. Review http://openvswitch.org/pipermail/dev/2014-August/044315.html
--
- VMware
Ankur,
Thanks for working on this. I had the following overall comments. I have
annotated the patch with specific comments as appropriate.
I didn't realize initially that the Netlink.c, Netlink.h that you are
introducing have major modifications compared to the userspace netlink.c and
netlink.h
hi Ankur,
Thanks for working on this. Looks good overall, but for the minor comments I
had.
On Aug 20, 2014, at 9:46 AM, Ankur Sharma wrote:
> In this patch we incorporate the usage of netlink message
> and the parsing APIs that were added in previous commit.
>
> Change-Id: If627ba5a10d78b9366
hi Ankur,
Looks good, but for a few minor comments.
On Aug 20, 2014, at 9:46 AM, Ankur Sharma wrote:
> In this patch we remove reference to OvsNetlink.h.
> Since we do not refer to lib/netlink-protocol.h anymore,
> hence removed the WIN_DP based check.
>
> Change-Id: I281a0c6478e3de2e9b04c988be
hi Alin/Sam,
Like I said earlier, this is a critical fix, and thanks for working on this.
I started looking at OvsPacketIO.c, and you are right in using the
OvsPartialCopyToMultipleNBLs() API. However, is it required to update many of
the functions to process an NB instead of an NBL? From my und
call into
the kernel, but that in itself may not buy anything more than this
approach.
This patch is a precursor to make progress of the other commands.
The next hurdle is to support nl_lookup_genl_mcgroup().
Signed-off-by: Nithin Raju
---
lib/netlink-socket.c | 68
1 - 100 of 936 matches
Mail list logo
