Re: [ovs-dev] [PATCH] datapath-windows: Update OvsIPv4TunnelKey flags in geneve decap.

[Nithin Raju]

> On Oct 17, 2017, at 5:31 PM, Anand Kumar <kumaran...@vmware.com> wrote:
> 
> Set the geneve flags OVS_TNL_F_GENEVE_OPT and OVS_TNL_F_CRT_OPT
> in OvsDecapGeneve, so that windows behavior is similiar to linux
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_datapath_linux_compat_geneve.c-23L242=DwICAg=uilaK90D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=cM6BjMekLlE1U4o08yWj5yBcHAbEGejEhoi3U90gn18=2k5d-dCk_oECkPfP55vafQ9Yf8NbapRCDkwD7w-vQXk=
> 
> Signed-off-by: Anand Kumar <kumaran...@vmware.com>

Thanks for the fix.

Acked-by: Nithin Raju <nit...@vmware.com>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Fix potential memory leak while creating conntrack entry

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com<mailto:nit...@vmware.com>>

Thanks,
-- Nithin
R Manager, NSBU

On Jun 21, 2017, at 10:08 AM, Sairam Venugopal 
<vsai...@vmware.com<mailto:vsai...@vmware.com>> wrote:

OvsCtAddEntry returns TRUE or FALSE depending on whether
OvsNatTranslateCtEntry was successful or not. In the case of an
unsuccesful NAT translation, this will fail to insert the newly created
entry to the Conntrack Table. This entry needs to be freed and the states
should be accordingly in the flowKey instead of returning out.

Consolidated the parentEntry lookup and assignment portion across
different protocols and some minor refactoring to make the code more
readable.

Tests Done: Enabled driver verifier and tested the following:
- TCP & ICMP traffic through Conntrack Module.
- Flushed Conntrack Entries while traffic was flowing.
- Uninstalled and re-installed the driver when traffic was in progress.

Signed-off-by: Sairam Venugopal <vsai...@vmware.com<mailto:vsai...@vmware.com>>
---
datapath-windows/ovsext/Conntrack.c | 123 +---
1 file changed, 57 insertions(+), 66 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 68ed395..b010484 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -214,87 +214,78 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
 BOOLEAN *entryCreated)
{
POVS_CT_ENTRY entry = NULL;
-*entryCreated = FALSE;
UINT32 state = 0;
+POVS_CT_ENTRY parentEntry;
PNET_BUFFER_LIST curNbl = fwdCtx->curNbl;
-switch (ipProto)
-{
-case IPPROTO_TCP:
-{
-TCPHdr tcpStorage;
-const TCPHdr *tcp;
-tcp = OvsGetTcp(curNbl, l4Offset, );
-if (!OvsConntrackValidateTcpPacket(tcp)) {
-goto invalid;
-}
-
-state |= OVS_CS_F_NEW;
-POVS_CT_ENTRY parentEntry;
-parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
-if (parentEntry != NULL) {
-state |= OVS_CS_F_RELATED;
-}

-if (commit) {
-entry = OvsConntrackCreateTcpEntry(tcp, curNbl, currentTime);
-if (!entry) {
-return NULL;
-}
+*entryCreated = FALSE;
+state |= OVS_CS_F_NEW;

-/* Set parent entry for related FTP connections */
-entry->parent = parentEntry;
+parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
+if (parentEntry != NULL) {
+state |= OVS_CS_F_RELATED;
+}

-*entryCreated = TRUE;
-}
+switch (ipProto) {
+case IPPROTO_TCP:
+{
+TCPHdr tcpStorage;
+const TCPHdr *tcp;
+tcp = OvsGetTcp(curNbl, l4Offset, );
+if (!OvsConntrackValidateTcpPacket(tcp)) {
+state = OVS_CS_F_INVALID;
break;
}
-case IPPROTO_ICMP:
-{
-ICMPHdr storage;
-const ICMPHdr *icmp;
-icmp = OvsGetIcmp(curNbl, l4Offset, );
-if (!OvsConntrackValidateIcmpPacket(icmp)) {
-goto invalid;
-}

-state |= OVS_CS_F_NEW;
-if (commit) {
-entry = OvsConntrackCreateIcmpEntry(currentTime);
-if (entry) {
-/* XXX Add support for ICMP-Related */
-entry->parent = NULL;
-}
-*entryCreated = TRUE;
-}
+if (commit) {
+entry = OvsConntrackCreateTcpEntry(tcp, curNbl, currentTime);
+}
+break;
+}
+case IPPROTO_ICMP:
+{
+ICMPHdr storage;
+const ICMPHdr *icmp;
+icmp = OvsGetIcmp(curNbl, l4Offset, );
+if (!OvsConntrackValidateIcmpPacket(icmp)) {
+state = OVS_CS_F_INVALID;
break;
}
-case IPPROTO_UDP:
-{
-state |= OVS_CS_F_NEW;
-if (commit) {
-entry = OvsConntrackCreateOtherEntry(currentTime);
-if (entry) {
-/* Default UDP related to NULL until TFTP is supported */
-entry->parent = NULL;
-}
+
+if (commit) {
+entry = OvsConntrackCreateIcmpEntry(currentTime);
+}
+break;
+}
+case IPPROTO_UDP:
+{
+if (commit) {
+entry = OvsConntrackCreateOtherEntry(currentTime);
+}
+break;
+}
+default:
+state = OVS_CS_F_INVALID;
+break;
+}
+
+if (state != OVS_CS_F_INVALID && commit) {
+if (entry) {
+entry->parent = parentEntry;
+if (OvsCtAddEntry(entry, ctx, natInfo, currentTime)) {
*entryCreated = TRUE;
+} else {
+/* Unable to add entry to the

Re: [ovs-dev] [PATCH] datapath-windows: Add validations for IP_HEADER_LEN

[Nithin Raju]

> On Jun 15, 2017, at 3:15 PM, Shashank Ram <r...@vmware.com> wrote:
> 
> Adds validations in OvsGetIp() to make sure the IHL is
> within valid bounds. If IHL is invalid, then the packet
> is dropped by the callers of this function.
> 
> Signed-off-by: Shashank Ram <r...@vmware.com>

Acked-by: Nithin Raju <nit...@vmware.com>

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Define NAT_ACTION enum correctly

[Nithin Raju]

On Jun 15, 2017, at 12:46 PM, Shashank Ram 
<r...@vmware.com<mailto:r...@vmware.com>> wrote:

The existing code throws a warning when compiled
with the Windows 10 SDK:
'typedef ': ignored on left of 'NAT_ACTION' when no variable is declared

Signed-off-by: Shashank Ram <r...@vmware.com<mailto:r...@vmware.com>>

Acked-by: Nithin Raju <nit...@vmware.com<mailto:nit...@vmware.com>>

Thanks,
-- Nithin

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] datapath-windows: use NlAttrGet() in Conntrack.c

[Nithin Raju]

Couple of minor fixes that got flagged with a static checker.

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Conntrack.c| 14 ++
 datapath-windows/ovsext/Netlink/Netlink.c  |  2 +-
 datapath-windows/ovsext/Netlink/NetlinkProto.h |  2 +-
 3 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 68ed395..07a9583 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -863,23 +863,13 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
 ? NAT_ACTION_SRC : NAT_ACTION_DST);
 break;
 case OVS_NAT_ATTR_IP_MIN:
-   if (natAttr->nlaLen < NLA_HDRLEN) {
-OVS_LOG_ERROR("Incorrect header length for "
-  "OVS_NAT_ATTR_IP_MIN message.");
-break;
-}
 memcpy(,
-   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
+   NlAttrData(natAttr), NlAttrGetSize(natAttr));
 hasMinIp = TRUE;
 break;
 case OVS_NAT_ATTR_IP_MAX:
-if (natAttr->nlaLen < NLA_HDRLEN) {
-OVS_LOG_ERROR("Incorrect header length for "
-  "OVS_NAT_ATTR_IP_MAX message.");
-break;
-}
 memcpy(,
-   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
+   NlAttrData(natAttr), NlAttrGetSize(natAttr));
 hasMaxIp = TRUE;
 break;
 case OVS_NAT_ATTR_PROTO_MIN:
diff --git a/datapath-windows/ovsext/Netlink/Netlink.c 
b/datapath-windows/ovsext/Netlink/Netlink.c
index a63f066..156732c 100644
--- a/datapath-windows/ovsext/Netlink/Netlink.c
+++ b/datapath-windows/ovsext/Netlink/Netlink.c
@@ -1000,7 +1000,7 @@ PCHAR
 NlAttrGetString(const PNL_ATTR nla)
 {
 ASSERT(nla->nlaLen >= NLA_HDRLEN);
-if (!memchr(NlAttrGet(nla), '\0', nla->nlaLen - NLA_HDRLEN)) {
+if (!memchr(NlAttrGet(nla), '\0', NlAttrGetSize(nla))) {
 return NULL;
 }
 return NlAttrGet(nla);
diff --git a/datapath-windows/ovsext/Netlink/NetlinkProto.h 
b/datapath-windows/ovsext/Netlink/NetlinkProto.h
index 5175311..59b5656 100644
--- a/datapath-windows/ovsext/Netlink/NetlinkProto.h
+++ b/datapath-windows/ovsext/Netlink/NetlinkProto.h
@@ -123,7 +123,7 @@ BUILD_ASSERT_DECL(sizeof(NL_ATTR) == 4);
 #define GENL_HDRLEN NLMSG_ALIGN(sizeof(GENL_MSG_HDR))
 #define NF_GEN_MSG_HDRLEN NLMSG_ALIGN(sizeof(NF_GEN_MSG_HDR))
 #define OVS_HDRLEN NLMSG_ALIGN(sizeof(OVS_HDR))
-#define NLA_HDRLEN ((INT) NLA_ALIGN(sizeof(NL_ATTR)))
+#define NLA_HDRLEN ((UINT16) NLA_ALIGN(sizeof(NL_ATTR)))
 
 #define NETLINK_NETFILTER   12
 #define NETLINK_GENERIC 16
-- 
2.7.1.windows.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] windows: Broken internal netdevs

[Nithin Raju]

Thanks for the fix.

Acked-by: Nithin Raju <nit...@vmware.com>



From: ovs-dev-boun...@openvswitch.org <ovs-dev-boun...@openvswitch.org> on 
behalf of Alin Serdean <aserd...@cloudbasesolutions.com>
Sent: Friday, February 17, 2017 3:10 AM
To: d...@openvswitch.org
Subject: [ovs-dev] [PATCH] windows: Broken internal netdevs

Commit fa07525f9cf3fa698ebc23ea09da477d3d881a87 fixed error logging for
for regular netdevs, however it overlooked "internal" netdevs.

This patch allows "internal" netdev objects to be created and passed to
dpif_port_add().

Reported-by: Nithin Raju <nit...@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserd...@cloudbasesolutions.com>
---
Intended for branch-2.5,branch-2.6,branch-2.7,master
---
 lib/netdev-windows.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/netdev-windows.c b/lib/netdev-windows.c
index b22bd09..375cb32 100644
--- a/lib/netdev-windows.c
+++ b/lib/netdev-windows.c
@@ -159,7 +159,10 @@ netdev_windows_system_construct(struct netdev *netdev_)

 /* Query the attributes and runtime status of the netdev. */
 ret = query_netdev(netdev_get_name(>up), , );
-if (ret) {
+/* "Internal" netdevs do not exist in the kernel yet.  They need to be
+ * transformed into a netdev object and passed to dpif_port_add(), which
+ * will add them to the kernel.  */
+if (strcmp(netdev_get_type(>up), "internal") && ret) {
 return ret;
 }
 ofpbuf_delete(buf);
--
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=P92jgkw_e8yXcobASp3agdOOn_TbmMcTLXwVjH037sY=z1OeB_nNoNtLKaQeFUZ-JfP_-aZiU4CmjF5VVblMHuc=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/4] doc-windows: Remove obsolete documentation

[Nithin Raju]

Alin,
My suggestion would be to hold off on finalizing the documentation until we 
squash all the pending bugs. Looks like we are getting there.

Thanks,
-- Nithin

On Feb 4, 2017, at 12:21 AM, Alin Serdean 
> wrote:

Hard dependancy on default internal port (AllowManagementOS) has been
removed.
Software checksums are part of the windows datapath.
Disconnecting/Connecting the VIF is no longer required.
Unit tests are enabled and passing for some time now...
The option to create a MSI has been added.

Signed-off-by: Alin Gabriel Serdean 
>
---
Documentation/intro/install/windows.rst | 50 +
1 file changed, 13 insertions(+), 37 deletions(-)

diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index caa9f40..1e7707f 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -117,21 +117,6 @@ The following explains the steps in some detail.
   under Bash. The remainder, prefixed by ``>``, are PowerShell commands and
   must be run in PowerShell.

-Install Requirements
-
-
-* Share network adaptors
-
-  We require that you don't disable the "Allow management operating system to
-  share this network adapter" under 'Virtual Switch Properties' > 'Connection
-  type: External network', in the HyperV virtual network switch configuration.
-
-* Checksum Offloads
-
-  While there is some support for checksum/segmentation offloads in software,
-  this is still a work in progress. Till the support is complete we recommend
-  disabling TX/RX offloads for both the VM's as well as the HyperV.
-
Bootstrapping
-

@@ -287,16 +272,15 @@ Enforcement' during boot.  The following commands can be 
used:
  You may have to restart the machine for the settings to take effect.

In the Virtual Switch Manager configuration you can enable the Open vSwitch
-Extension on an existing switch or create a new switch.  If you are using an
-existing switch, make sure to enable the "Allow Management OS" option for VXLAN
-to work (covered later).
+Extension on an existing switch or create a new switch.

The command to create a new switch named 'OVS-Extended-Switch' using a physical
NIC named 'Ethernet 1' is:

.. code-block:: ps1con

-   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1"
+   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1" `
+  -AllowManagementOS $false

.. note::

@@ -517,22 +501,17 @@ assign a 'OVS port name' which is a unique name across 
all VIFs on this
Hyper-V.  The next step is to add the VIF to the ovsdb using its 'OVS port
name' as key.

-First, assign a unique 'OVS port name' to the VIF. The VIF needs to have been
-disconnected from the Hyper-V switch before assigning a 'OVS port name' to it.
-In the example below, we assign a 'OVS port name' called ``ovs-port-a`` to a
-VIF on a VM ``VM1``.  By using index 0 for ``$vnic``, the first VIF of the VM
-is being addressed.  After assigning the name ``ovs-port-a``, the VIF is
-connected back to the Hyper-V switch with name ``OVS-HV-Switch``, which is
-assumed to be the Hyper-V switch with OVS extension enabled.:
+First, assign a unique 'OVS port name' to the VIF.  In the example below, we
+assign a 'OVS port name' called ``ovs-port-a`` to a VIF on a VM ``VM1``.  By
+using index 0 for ``$vnic``, the first VIF of the VM is being addressed.  We
+assume that OVS extension is enabled on the Hyper-V vSwitch to which the VIF is
+connected:

.. code-block:: ps1con

   PS > import-module .\datapath-windows\misc\OVS.psm1
   PS > $vnic = Get-VMNetworkAdapter 
-   PS > Disconnect-VMNetworkAdapter -VMNetworkAdapter $vnic[0]
   PS > $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-a
-   PS > Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \
- -SwitchName OVS-Extended-Switch

Next, add the VIFs to ``br-int``:

@@ -556,8 +535,6 @@ Dumping the ports should show the additional ports that 
were just added:
ovs-vsctl show
   4cd86499-74df-48bd-a64d-8d115b12a9f2
   Bridge br-pif
-   Port "vEthernet (external)"
-   Interface "vEthernet (external)"
   Port "Ethernet0"
   Interface "Ethernet0"
   Port br-pif
@@ -677,9 +654,9 @@ Re-Add the VIF ports with the VLAN tag:
Add tunnels
~~~

-The Windows Open vSwitch implementation support VXLAN and STT tunnels. To add
-tunnels. For example, first add the tunnel port between 172.168.201.101 <->
-172.168.201.102:
+Let us add tunnels between two endpoints.
+For example, first add the tunnel port between
+172.168.201.101 <-> 172.168.201.102:

.. code-block:: doscon

@@ -791,9 +768,8 @@ his development repository in github and triggering a new 
build.
TODO


-* Investigate the working of sFlow on Windows and re-enable the unit tests.
+* 

Re: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in documentation

[Nithin Raju]

hi Alin,
I second Shashank’s thoughts. I prefer the name “OVS-Extended-Switch”, it makes 
documentation explicit. I’d prefer to keep it that way.

I’m sure that once users are familiar with the documentation, they can pretty 
much pick whatever name they want.

Thanks,
-- Nithin

On Feb 4, 2017, at 11:20 PM, Shashank Ram 
> wrote:

Hi Alin, I don't see a big value from this patch if I understand it correctly. 
Firstly, your commit is not clear about what it means when it says "typing it 
later on". Are you referring to typing it later on in the documentation? 
Secondly, since Hyper-V has different switch types such as "internal", 
"external", "private", replacing the switch name in the documentation with 
"external" might confuse readers unnecessarily, since its also a type. If you 
want to rename it, you could just call it something like "ovsext-switch" or 
just "ovsext".

Please find the other comments inline.

Thanks,
Shashank

From: ovs-dev-boun...@openvswitch.org 
> on 
behalf of Alin Serdean 
>
Sent: Saturday, February 4, 2017 12:21 AM
To: d...@openvswitch.org
Subject: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in 
documentation

Use shorter name for the Hyper-V vSwitch for simplicity of typing it
later on.

Signed-off-by: Alin Gabriel Serdean 
>
---
Documentation/intro/install/windows.rst | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index ece207d..2341b5c 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -274,12 +274,12 @@ Enforcement' during boot.  The following commands can be 
used:
In the Virtual Switch Manager configuration you can enable the Open vSwitch
Extension on an existing switch or create a new switch.

-The command to create a new switch named 'OVS-Extended-Switch' using a physical
-NIC named 'Ethernet0' is:
+The command to create a new switch named 'external' using a physical NIC named
+'Ethernet0' is:

.. code-block:: ps1con

-   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet0" `
+   PS > New-VMSwitch external -NetAdapterName "Ethernet0" `
  -AllowManagementOS $false
[SR]: The commit msgh does not mention anything about the "AllowManagementOS" 
flag being added. What's the reason for this?

.. note::
@@ -293,7 +293,7 @@ An alternative way to do the same is to run the following 
command:

.. code-block:: ps1con

-   PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch
+   PS > Enable-VMSwitchExtension "Open vSwitch Extension" external

.. note::

--
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=6OuVHk-mnufSWzkKa74UkQ=ANt1MyWGWPCfbl8o7d8EK5wC138sS4Uuzm8XX4IsouA=WtqG4fs_RRxuNxJrrZZ7cK19KcdlqwhuzYpesaRapeE=
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=ZJZdXeUyJK0yT5jDOnWAeAQaGx-FHZF4KNy12XRtQaM=3N8RJlWhGyZ1TYeGFMgqeb57WFfsO10eg2H7J2erhg0=

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS-Hyper-V-Discovery-Agent Design Document

[Nithin Raju]

Ben,
The current proposal that Yin has put out calls for a new daemon that monitors 
VIFs that show up on the native HyperV swtitch, gives them a name and adds it 
to OVSDB. It does  it change the existing workflow. You can think of it as how 
libvirt integrates with OVS in terms of adding ports to OVSDB.

Alin's argument is to integrate this new daemon into ovs-vSwitchd and have 
ovs-vswitchd add ports to OVSDB when ports show up on the HyperV switch. Is 
there any precedence to ovs-vswitchd adding ports to OVSDB? Would this be a 
divergence?

Thanks,
-- Nithin




On Mon, Nov 28, 2016 at 4:00 PM -0800, "Ben Pfaff" 
<b...@ovn.org<mailto:b...@ovn.org>> wrote:

Does this actually call for vswitchd to add ports?  Reading it, it looks
like the new daemon does that.  But I didn't read it carefully enough to
understand it in full.

On Mon, Nov 28, 2016 at 11:13:21PM +, Nithin Raju wrote:
> hi Alin,
> Thanks for the comments.
>
> There has not been a case so far (AFAIK) where vswitchd added ports to OVSDB. 
> This would be a diversion from that. We’ll have to take this up with Ben or 
> Justin to see how they feel.
>
> Thanks,
> -- Nithin
>
> On Nov 28, 2016, at 11:18 AM, Alin Serdean 
> <aserd...@cloudbasesolutions.com<mailto:aserd...@cloudbasesolutions.com>> 
> wrote:
>
> Hi Yin,
>
> Thanks a lot for the patch and the document!
>
> There are a few concerns that I have with this implementation:
> - the need for a new daemon,
> - use of cmd calls to add/delete ports,
> - addition of .NET to compile the binaries.
>
> As previously discussed in the meetings, we could just use 'ovs-vswitchd' 
> with an argument i.e. '--integration_bridge=' to add the ports. We 
> see the port creations in the kernel and we could issue an event to the 
> userspace to add ports under that bridge. We could add a new type of 'action' 
> or try to reuse the events that are already present in the implementation.
> Another advantage to use ovs-vswitchd is that we could talk directly to 
> ovsdb. Also, no additional dependency needed.
>
> We could add the argument '--integration_bridge=' when creating the 
> service via the installer with a nice text to inform the user about what it 
> does. Changing the service properties is normal activity for a system 
> administrator, so he could easily remove it afterwards.
>
> Thanks,
> Alin.
>
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org<mailto:ovs-dev-boun...@openvswitch.org> 
> [mailto:ovs-dev-
> boun...@openvswitch.org<mailto:boun...@openvswitch.org>] On Behalf Of Yin Lin
> Sent: Monday, November 21, 2016 10:07 PM
> To: d...@openvswitch.org<mailto:d...@openvswitch.org>
> Subject: [ovs-dev] OVS-Hyper-V-Discovery-Agent Design Document
>
> Hi,
>
> Below is a document that describes the design and implementation of VIF
> discovery agent for Hyper-V that I have been working on. The coding has
> already been completed and will be sent out for review in a follow up patch.
> The document describes the effort and the choices made. Thanks Sairam
> Venugopal for the initial review and edit of the document
>
>
>
> Please have a look, and get in touch for any questions or comments.
>
>
>
> Thanks!
>
> -- Yin
> ___
> dev mailing list
> d...@openvswitch.org<mailto:d...@openvswitch.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DgICAg=uilaK90D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=GMr-AZul4UsNIDzghSvQVWBWWf9ZXBYbRf5TFXxEtFg=tAcMGwbQ11t617kkksED_MalGT4y_bWtSDojOFp58vc=
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS-Hyper-V-Discovery-Agent Design Document

[Nithin Raju]

hi Alin,
Thanks for the comments.

There has not been a case so far (AFAIK) where vswitchd added ports to OVSDB. 
This would be a diversion from that. We’ll have to take this up with Ben or 
Justin to see how they feel.

Thanks,
-- Nithin

On Nov 28, 2016, at 11:18 AM, Alin Serdean 
> wrote:

Hi Yin,

Thanks a lot for the patch and the document!

There are a few concerns that I have with this implementation:
- the need for a new daemon,
- use of cmd calls to add/delete ports,
- addition of .NET to compile the binaries.

As previously discussed in the meetings, we could just use 'ovs-vswitchd' with 
an argument i.e. '--integration_bridge=' to add the ports. We see the 
port creations in the kernel and we could issue an event to the userspace to 
add ports under that bridge. We could add a new type of 'action' or try to 
reuse the events that are already present in the implementation.
Another advantage to use ovs-vswitchd is that we could talk directly to ovsdb. 
Also, no additional dependency needed.

We could add the argument '--integration_bridge=' when creating the 
service via the installer with a nice text to inform the user about what it 
does. Changing the service properties is normal activity for a system 
administrator, so he could easily remove it afterwards.

Thanks,
Alin.

-Original Message-
From: ovs-dev-boun...@openvswitch.org 
[mailto:ovs-dev-
boun...@openvswitch.org] On Behalf Of Yin Lin
Sent: Monday, November 21, 2016 10:07 PM
To: d...@openvswitch.org
Subject: [ovs-dev] OVS-Hyper-V-Discovery-Agent Design Document

Hi,

Below is a document that describes the design and implementation of VIF
discovery agent for Hyper-V that I have been working on. The coding has
already been completed and will be sent out for review in a follow up patch.
The document describes the effort and the choices made. Thanks Sairam
Venugopal for the initial review and edit of the document



Please have a look, and get in touch for any questions or comments.



Thanks!

-- Yin
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DgICAg=uilaK90D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=GMr-AZul4UsNIDzghSvQVWBWWf9ZXBYbRf5TFXxEtFg=tAcMGwbQ11t617kkksED_MalGT4y_bWtSDojOFp58vc=

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Avoid busy wait in OvsStartIpHelper

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com<mailto:nit...@vmware.com>>

Thanks,
-- Nithin

On Nov 22, 2016, at 9:53 AM, Shashank Ram 
<r...@vmware.com<mailto:r...@vmware.com>> wrote:

Previously, the IP Helper thread would wait for an event
but with a timeout of 0, which resulted in the thread
busy waiting causing high CPU usage by the kernel.
Since the IP Helper thread is only required based on
certain events, it makes sense to wait indefinitely
till we receieve such an event notification to wake up
the thread. This change aims to address this issue.

When OvsEnqueueIpHelperRequest() or OvsInternalAdapterUp()
is called, the ovsNumIpHelperRequests counter is incremented,
but upon consumption of the request, is not decremented.
Since the wakeup logic for the thread is determined by this
counter value, we need to reset the counter back correctly
once the request has been consumed by the IP Helper thread.

Signed-off-by: Shashank Ram <r...@vmware.com<mailto:r...@vmware.com>>
---
datapath-windows/ovsext/IpHelper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/datapath-windows/ovsext/IpHelper.c 
b/datapath-windows/ovsext/IpHelper.c
index d747e8c..559ddaa 100644
--- a/datapath-windows/ovsext/IpHelper.c
+++ b/datapath-windows/ovsext/IpHelper.c
@@ -1455,12 +1455,14 @@ OvsStartIpHelper(PVOID data)
POVS_IPNEIGH_ENTRY ipn;
PLIST_ENTRY link;
UINT64   timeVal, timeout;
+PLARGE_INTEGER threadSleepTimeout;

OVS_LOG_INFO("Start the IP Helper Thread, context: %p", context);

NdisAcquireSpinLock();
while (!context->exit) {

+threadSleepTimeout = NULL;
timeout = 0;
while (!IsListEmpty()) {
if (context->exit) {
@@ -1468,6 +1470,7 @@ OvsStartIpHelper(PVOID data)
}
link = ovsIpHelperRequestList.Flink;
RemoveEntryList(link);
+ovsNumIpHelperRequests--;
NdisReleaseSpinLock();
req = CONTAINING_RECORD(link, OVS_IP_HELPER_REQUEST, link);
switch (req->command) {
@@ -1497,6 +1500,7 @@ OvsStartIpHelper(PVOID data)
KeQuerySystemTime((LARGE_INTEGER *));
if (ipn->timeout > timeVal) {
timeout = ipn->timeout;
+threadSleepTimeout = (PLARGE_INTEGER)
break;
}
ipAddr = ipn->ipAddr;
@@ -1519,8 +1523,13 @@ ip_helper_wait:
KeClearEvent(>event);
NdisReleaseSpinLock();

+/*
+ * Wait indefinitely for the thread to be woken up.
+ * Passing NULL as the Timeout value in the below
+ * call to KeWaitForSingleObject achieves this.
+ */
KeWaitForSingleObject(>event, Executive, KernelMode,
-  FALSE, (LARGE_INTEGER *));
+  FALSE, threadSleepTimeout);
NdisAcquireSpinLock();
}
NdisReleaseSpinLock();
--
2.6.2

___
dev mailing list
d...@openvswitch.org<mailto:d...@openvswitch.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DgICAg=uilaK90D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=6fD_xauFoeCgUQ64ESIdyYjG1eN7yn3K5XQTt52x2vU=z7Lhu77GqZMfm6kt2L5bi12_aev-nrQcazE3Yb6Krhc=

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] datapath-windows: else-if block in OvsExtNetPnPEvent

[Nithin Raju]

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Switch.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/datapath-windows/ovsext/Switch.c b/datapath-windows/ovsext/Switch.c
index 825fa3c..87dbc5e 100644
--- a/datapath-windows/ovsext/Switch.c
+++ b/datapath-windows/ovsext/Switch.c
@@ -599,8 +599,8 @@ OvsExtNetPnPEvent(NDIS_HANDLE filterModuleContext,
 OVS_LOG_TRACE("Enter: filterModuleContext: %p, NetEvent: %d",
   filterModuleContext, (netPnPEvent->NetPnPEvent).NetEvent);
 /*
- * The only interesting event is the NetEventSwitchActivate. It provides
- * an asynchronous notification of the switch completing activation.
+ * NetEventSwitchActivate provides an asynchronous notification of
+ * the switch completing activation.
  */
 if (netPnPEvent->NetPnPEvent.NetEvent == NetEventSwitchActivate) {
 ASSERT(switchContext->isActivated == FALSE);
@@ -610,9 +610,7 @@ OvsExtNetPnPEvent(NDIS_HANDLE filterModuleContext,
   "status: %s", switchContext,
   status ? "TRUE" : "FALSE");
 }
-}
-
-if (netPnPEvent->NetPnPEvent.NetEvent == NetEventFilterPreDetach) {
+} else if (netPnPEvent->NetPnPEvent.NetEvent == NetEventFilterPreDetach) {
 switchContext->dataFlowState = OvsSwitchPaused;
 KeMemoryBarrier();
 }
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Set isActivated flag only on success

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

Thanks,
-- Nithin






-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Monday, October 10, 2016 at 3:43 PM
To: Shashank Ram <r...@vmware.com>, "dev@openvswitch.org"
<dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH v2] datapath-windows: Set isActivated flag
only on success

>Acked-by: Sairam Venugopal <vsai...@vmware.com>
>
>
>On 10/10/16, 3:15 PM, "Shashank Ram" <r...@vmware.com> wrote:
>
>>@Switch.c: Modifies OvsActivateSwitch() function
>>to mark the switch as activated only if the
>>the status is success. The callers itself
>>only call this method when the isActivated
>>flag is unset.
>>
>>Signed-off-by: Shashank Ram <r...@vmware.com>
>>---
>> datapath-windows/ovsext/Switch.c | 7 ++-
>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>
>>diff --git a/datapath-windows/ovsext/Switch.c
>>b/datapath-windows/ovsext/Switch.c
>>index 825fa3c..49711a9 100644
>>--- a/datapath-windows/ovsext/Switch.c
>>+++ b/datapath-windows/ovsext/Switch.c
>>@@ -556,7 +556,6 @@ OvsActivateSwitch(POVS_SWITCH_CONTEXT switchContext)
>> OVS_LOG_TRACE("Enter: activate switch %p, dpNo: %ld",
>>   switchContext, switchContext->dpNo);
>>
>>-switchContext->isActivated = TRUE;
>> status = OvsAddConfiguredSwitchPorts(switchContext);
>>
>> if (status != NDIS_STATUS_SUCCESS) {
>>@@ -572,11 +571,9 @@ OvsActivateSwitch(POVS_SWITCH_CONTEXT switchContext)
>> goto cleanup;
>> }
>>
>>-cleanup:
>>-if (status != NDIS_STATUS_SUCCESS) {
>>-switchContext->isActivated = TRUE;
>>-}
>>+switchContext->isActivated = TRUE;
>>
>>+cleanup:
>> OVS_LOG_TRACE("Exit: activate switch:%p, isActivated: %s, status =
>>%lx",
>>   switchContext,
>>   (switchContext->isActivated ? "TRUE" : "FALSE"),
>>status);
>>--
>>2.6.2
>>
>>___
>>dev mailing list
>>dev@openvswitch.org
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailm
>>a
>>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=D
>>c
>>ruz40PROJ40ROzSpxyQSLw6fcrOWpJgEcEmNR3JEQ=JTQF9lK7WrFRmjxQdtU7cHaXMjUSV
>>N
>>R88qRe8HumYqs=sIOOdG_D2MkFJp_802P-OYepagoY0W56f4q75MyFr8Q=
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=_ZtGBUyhuomRlS4fnlG7I23NS4pvgd
>sN0pnQDt9zuNg=m0Vl611an4DlpDnyTiMeQlvCBQjwMAdpXNG5YZu3VZg= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3] datapath-windows: Add define for last module number

[Nithin Raju]

-Original Message-
From: dev  on behalf of Guru Shetty

Date: Tuesday, September 20, 2016 at 7:40 AM
To: Shashank Ram 
Cc: ovs dev 
Subject: Re: [ovs-dev] [PATCH v3] datapath-windows: Add define for
lastmodule number

>On 19 September 2016 at 16:16, Shashank Ram  wrote:
>
>> Adds a define for the last defined module number.
>>
>> Change-Id: I1ea9230317a849e911900cf69e96ed85a65d3a8c
>> Signed-off-by: Shashank Ram 
>>
>
>I removed the Change-Id, added you to AUTHORS and applied this to master
>and 2.6

Thanks Guru.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3] datapath-windows: Add define for last module number

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Monday, September 19, 2016 at 4:21 PM
To: Shashank Ram <r...@vmware.com>, "dev@openvswitch.org"
<dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH v3] datapath-windows: Add define for last
module number

>Thanks for fixing this.
>
>Acked-by: Sairam Venugopal <vsai...@vmware.com>
>
>
>
>On 9/19/16, 4:16 PM, "Shashank Ram" <r...@vmware.com> wrote:
>
>>Adds a define for the last defined module number.
>>
>>Change-Id: I1ea9230317a849e911900cf69e96ed85a65d3a8c
>>Signed-off-by: Shashank Ram <r...@vmware.com>
>>---
>> datapath-windows/ovsext/Debug.c | 1 +
>> datapath-windows/ovsext/Debug.h | 4 ++--
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>>diff --git a/datapath-windows/ovsext/Debug.c
>>b/datapath-windows/ovsext/Debug.c
>>index a96d38d..c3d14ae 100644
>>--- a/datapath-windows/ovsext/Debug.c
>>+++ b/datapath-windows/ovsext/Debug.c
>>@@ -25,6 +25,7 @@
>> 
>> UINT32  ovsLogFlags = 0x;
>> UINT32  ovsLogLevel = OVS_DBG_DEFAULT;
>>+BUILD_ASSERT(OVS_DBG_LAST < 31); /* 'ovsLogLevel' is 32 bits. */
>> 
>> #define OVS_LOG_BUFFER_SIZE 384
>> 
>>diff --git a/datapath-windows/ovsext/Debug.h
>>b/datapath-windows/ovsext/Debug.h
>>index 935f858..cae6ac9 100644
>>--- a/datapath-windows/ovsext/Debug.h
>>+++ b/datapath-windows/ovsext/Debug.h
>>@@ -43,8 +43,8 @@
>> #define OVS_DBG_CONTRK   BIT32(23)
>> #define OVS_DBG_GENEVE   BIT32(24)
>> 
>>-#define OVS_DBG_RESERVED BIT32(31)
>>-//Please add above OVS_DBG_RESERVED.
>>+#define OVS_DBG_LAST 24  /* Set this to the last defined module
>>number. */
>>+/* Please add above OVS_DBG_LAST. */
>> 
>> #define OVS_DBG_ERRORDPFLTR_ERROR_LEVEL
>> #define OVS_DBG_WARN DPFLTR_WARNING_LEVEL
>>-- 
>>2.9.3.windows.2
>>
>>___
>>dev mailing list
>>dev@openvswitch.org
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailm
>>a
>>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=D
>>c
>>ruz40PROJ40ROzSpxyQSLw6fcrOWpJgEcEmNR3JEQ=TOmB5UNcg-zFOda-mCbQv18k8tPK5
>>t
>>Ym77eotJR0pnk=sYgoL2PsKAO-t1fQ6K-YkddMZxD8v35UogStZIhQD24=
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=KrXss9NJ7JRZh4IY1EmPSvyJzScW73
>GyOZ0FvvQ6R0k=V0Qbul9QWt-TInWnBTIT8EdyxAbbhynFi3uTQ79Wixw= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Add define for last module number

[Nithin Raju]

Much better. Thanks for addressing the comments.

Acked-by: Nithin Raju <nit...@vmware.com>


-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Shashank Ram
<r...@vmware.com>
Date: Monday, September 19, 2016 at 3:24 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Cc: Shashank Ram <r...@vmware.com>
Subject: [ovs-dev] [PATCH v2] datapath-windows: Add define for last
module  number

>Adds a define for the last defined module number.
>
>Change-Id: I1ea9230317a849e911900cf69e96ed85a65d3a8c
>Signed-off-by: Shashank Ram <r...@vmware.com>
>---
> datapath-windows/ovsext/Debug.c | 1 +
> datapath-windows/ovsext/Debug.h | 5 ++---
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Debug.c
>b/datapath-windows/ovsext/Debug.c
>index a96d38d..c3d14ae 100644
>--- a/datapath-windows/ovsext/Debug.c
>+++ b/datapath-windows/ovsext/Debug.c
>@@ -25,6 +25,7 @@
> 
> UINT32  ovsLogFlags = 0x;
> UINT32  ovsLogLevel = OVS_DBG_DEFAULT;
>+BUILD_ASSERT(OVS_DBG_LAST < 31); /* 'ovsLogLevel' is 32 bits. */
> 
> #define OVS_LOG_BUFFER_SIZE 384
> 
>diff --git a/datapath-windows/ovsext/Debug.h
>b/datapath-windows/ovsext/Debug.h
>index 2175130..cae6ac9 100644
>--- a/datapath-windows/ovsext/Debug.h
>+++ b/datapath-windows/ovsext/Debug.h
>@@ -43,9 +43,8 @@
> #define OVS_DBG_CONTRK   BIT32(23)
> #define OVS_DBG_GENEVE   BIT32(24)
> 
>-#define OVS_DBG_LAST 24  // Set this to the last defined module
>number.
>-#define OVS_DBG_RESERVED BIT32(31)
>-//Please add above OVS_DBG_LAST.
>+#define OVS_DBG_LAST 24  /* Set this to the last defined module
>number. */
>+/* Please add above OVS_DBG_LAST. */
> 
> #define OVS_DBG_ERRORDPFLTR_ERROR_LEVEL
> #define OVS_DBG_WARN DPFLTR_WARNING_LEVEL
>-- 
>2.9.3.windows.2
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=aBoHFSv-pDjXxHXQ343r2asnUI_rF7
>c56636ZLZPhGs=rocZ4Y35Yytzqr9xocQc_zJGzGH0E2RcwXYM9hmbueY= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Add define for last module number

[Nithin Raju]

Only comment I had was to nuke the OVS_DBG_RESERVED and treat OVS_DBG_LAST
itself as the last bit. Basically, we are restricting this to 32 since
ŒovsLogLevel¹ is 32 bits.

We can probably do:
BUILD_ASSERT(OVS_DBG_LAST < 31)
BUILD_ASSERT(OVS_DBG_LAST < sizeof ovsLogLevel).


Thanks for the cleanup.

Thanks,
-- Nithin

-Original Message-
From: dev  on behalf of Shashank Ram

Date: Thursday, September 15, 2016 at 5:46 PM
To: "dev@openvswitch.org" 
Cc: Shashank Ram 
Subject: [ovs-dev] [PATCH] datapath-windows: Add define for last
module  number

>Adds a define for the last defined module number.
>
>Signed-off-by: Shashank Ram 
>---
> datapath-windows/ovsext/Debug.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/Debug.h
>b/datapath-windows/ovsext/Debug.h
>index 935f858..2175130 100644
>--- a/datapath-windows/ovsext/Debug.h
>+++ b/datapath-windows/ovsext/Debug.h
>@@ -43,8 +43,9 @@
> #define OVS_DBG_CONTRK   BIT32(23)
> #define OVS_DBG_GENEVE   BIT32(24)
> 
>+#define OVS_DBG_LAST 24  // Set this to the last defined module
>number.
> #define OVS_DBG_RESERVED BIT32(31)
>-//Please add above OVS_DBG_RESERVED.
>+//Please add above OVS_DBG_LAST.
> 
> #define OVS_DBG_ERRORDPFLTR_ERROR_LEVEL
> #define OVS_DBG_WARN DPFLTR_WARNING_LEVEL
>-- 
>2.6.2
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=0pvAR9XWuxljf0K9blx9ZCxughyOW7
>ZxdCZDoaAM8Fs=Fy1eCZ44TmWJuBW9BBSsMnkVx4skKLYWOFpK876C7Eg= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Fix conntrack event handler

[Nithin Raju]

Loos good. Can you pls. add the following comment as well:
/* Driver intiated messages should have zero seq number */


Acked-by: Nithin Raju <nit...@vmware.com>

>>Fix an issue with the OvsReadEventCmdHandler when handling conntrack
>>events. Reverting the previous review comment since the inputBuffer in
>>this case will be NULL.
>>
>>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>>---
>> datapath-windows/ovsext/Datapath.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>>diff --git a/datapath-windows/ovsext/Datapath.c
>>b/datapath-windows/ovsext/Datapath.c
>>index 745cdb6..e2b3273 100644
>>--- a/datapath-windows/ovsext/Datapath.c
>>+++ b/datapath-windows/ovsext/Datapath.c
>>@@ -1673,7 +1673,6 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
>>usrParamsCtx,
>>UINT32 *replyLen)
>> {
>> POVS_MESSAGE msgOut = (POVS_MESSAGE)usrParamsCtx->outputBuffer;
>>-POVS_MESSAGE msgIn = (POVS_MESSAGE)usrParamsCtx->inputBuffer;
>> POVS_OPEN_INSTANCE instance =
>> (POVS_OPEN_INSTANCE)usrParamsCtx->ovsInstance;
>> NL_BUFFER nlBuf;
>>@@ -1712,7 +1711,7 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
>>usrParamsCtx,
>>usrParamsCtx->outputBuffer,
>>usrParamsCtx->outputLength,
>>ctEventEntry.type,
>>-   msgIn->nlMsg.nlmsgSeq,
>>+   0, /* No input msg */
>> 
>>usrParamsCtx->ovsInstance->pid,
>>NFNETLINK_V0,
>>gOvsSwitchContext->dpNo);
>>-- 
>>2.9.0.windows.1
>>
>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] datapath-windows: update CodingStyle

[Nithin Raju]

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/CodingStyle | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/datapath-windows/CodingStyle b/datapath-windows/CodingStyle
index 3550cdb..40873e8 100644
--- a/datapath-windows/CodingStyle
+++ b/datapath-windows/CodingStyle
@@ -67,6 +67,8 @@ OvsDetectTunnelRxPkt(POVS_FORWARDING_CONTEXT ovsFwdCtx,
 flowKey->ipKey.l4.tpDst == VXLAN_UDP_PORT_NBO) {
 tunnelVport = OvsGetTunnelVport(OVSWIN_VPORT_TYPE_VXLAN);
 ovsActionStats.rxVxlan++;
+} else {
+return FALSE;
 }
 
 if (tunnelVport) {
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] Windows: Update the Driver and MSI properties

[Nithin Raju]

LGTM. One quick question:

> + 
Is this because we are using NDIS 6.30? Otherwise, we should keep it
closer to the OVS version.


Acked-by: Nithin Raju <nit...@vmware.com>

-- Nithin



-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, September 7, 2016 at 11:55 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH] Windows: Update the Driver and MSI properties

>Fix the legal notice section in OVSEXT.SYS properties. Update the MSI to
>include the properties mentioned in MSDN - 'Extension driver MSI packaging
>requirements' section -
>https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_wi
>ndows_hardware_drivers_network_extension-2Ddriver-2Dmsi-2Dpackaging-2Drequ
>irements=CwIDaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pNHQcdr7
>B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=te_VudSnncTlArUDlqRfpCxCP-VdRxr5Gh7b
>DDo9Y9U=cqJ5fXOM5FCo8lNYL6RMqQu_lnIAAKVFkkCZoQbB32Q=
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>---
> datapath-windows/ovsext/ovsext.rc| 2 +-
> windows/ovs-windows-installer/UI.wxs | 6 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/ovsext.rc
>b/datapath-windows/ovsext/ovsext.rc
>index 8dc6882..0b92e2e 100644
>--- a/datapath-windows/ovsext/ovsext.rc
>+++ b/datapath-windows/ovsext/ovsext.rc
>@@ -34,7 +34,7 @@ BEGIN
> VALUE "FileDescription", "Open vSwitch Extension"
> VALUE "FileVersion", "6.3.9600.17298"
> VALUE "InternalName", "OVSExt.SYS"
>-VALUE "LegalCopyright", "ï¿1Ž2 Licensed under the Apache
>License, Version 2.0 (the ""License"")"
>+VALUE "LegalCopyright", "Licensed under the Apache License,
>Version 2.0 (the ""License"")"
> VALUE "OriginalFilename", "OVSExt.SYS"
> VALUE "ProductName", "Open vSwitch 8/8.1 DDK driver"
> VALUE "ProductVersion", "6.3.9600.17298"
>diff --git a/windows/ovs-windows-installer/UI.wxs
>b/windows/ovs-windows-installer/UI.wxs
>index 5df4f4f..a2d36ae 100644
>--- a/windows/ovs-windows-installer/UI.wxs
>+++ b/windows/ovs-windows-installer/UI.wxs
>@@ -25,6 +25,12 @@
> 
>   
>   
>+  
>+  Value="{583CC151-73EC-4A6A-8B47-578297AD7623}" />
>+  
>+  
>+  
>+  
> 
>   
>   
>-- 
>2.9.0.windows.1
>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Encapsulate packet when src port is tunnel port

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

>On 9/1/16, 2:54 PM, "Sairam Venugopal" <vsai...@vmware.com> wrote:
>
>>If a packet arrives on a tunnel port and is again transmitted on a tunnel
>>port, the packet needs to be encapsulated.
>>
>>Eg:
>>Sample flow which arrives on a tunnel port and gets encapsulated again.
>>
>>eth(src=00:15:5d:ae:b7:b1,dst=ff:ff:ff:ff:ff:ff),in_port(5),eth_type(0x08
>>0
>>6),
>>arp(sip=192.168.1.12,tip=192.168.1.78,op=1,sha=00:15:5d:ae:b7:b1,tha=00:0
>>0
>>:00:00:00:00),
>>tunnel(tun_id=0x5b88,dst=192.165.226.191,src=192.166.255.253,tos=0,ttl=63
>>,
>>geneve({class=0x104,type=0x80,len=4,0x11680100}),flags(key))
>>
>>actions:set(tunnel(tun_id=0x5b88,dst=192.165.226.190,ttl=64,
>>
>>geneve({class=0x104,type=0x80,len=4,0x1680100}),flags(df|csum|key))),5,4
>>
>>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>>---
>> datapath-windows/ovsext/Actions.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>>diff --git a/datapath-windows/ovsext/Actions.c
>>b/datapath-windows/ovsext/Actions.c
>>index 722a2a8..f46309a 100644
>>--- a/datapath-windows/ovsext/Actions.c
>>+++ b/datapath-windows/ovsext/Actions.c
>>@@ -311,7 +311,7 @@ OvsDetectTunnelPkt(OvsForwardingContext *ovsFwdCtx,
>>  * - a VIF port
>>  * - a bridge-internal port (packets generated from userspace)
>>  * - no port.
>>- *
>>+ * - tunnel port
>>  * If the packet will not be encapsulated, consume the tunnel
>>context
>>  * by clearing it.
>>  */
>>@@ -322,7 +322,8 @@ OvsDetectTunnelPkt(OvsForwardingContext *ovsFwdCtx,
>> 
>> if (!vport ||
>> (vport->ovsType != OVS_VPORT_TYPE_NETDEV &&
>>- !OvsIsBridgeInternalVport(vport))) {
>>+ !OvsIsBridgeInternalVport(vport) &&
>>+ !OvsIsTunnelVportType(vport->ovsType))) {
>> ovsFwdCtx->tunKey.dst = 0;
>> }
>> }
>>-- 
>>2.9.0.windows.1
>>
>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v2] datapath-windows: add assert in OvsHashFlow()

[Nithin Raju]

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Flow.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index 439fb28..2e8b42b 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -2595,6 +2595,7 @@ OvsHashFlow(const OvsFlowKey *key)
 UINT8 *start;
 
 ASSERT(key->tunKey.dst || offset == sizeof(OvsIPv4TunnelKey));
+ASSERT(!key->tunKey.dst || offset == OvsGetFlowL2Offset(>tunKey));
 start = (UINT8 *)key + offset;
 return OvsJhashBytes(start, size, 0);
 }
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] datapath-windows: add assert in OvsHashFlow()

[Nithin Raju]

Also fix a minor indentation issue in User.c

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Flow.c | 1 +
 datapath-windows/ovsext/User.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index 439fb28..2e8b42b 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -2595,6 +2595,7 @@ OvsHashFlow(const OvsFlowKey *key)
 UINT8 *start;
 
 ASSERT(key->tunKey.dst || offset == sizeof(OvsIPv4TunnelKey));
+ASSERT(!key->tunKey.dst || offset == OvsGetFlowL2Offset(>tunKey));
 start = (UINT8 *)key + offset;
 return OvsJhashBytes(start, size, 0);
 }
diff --git a/datapath-windows/ovsext/User.c b/datapath-windows/ovsext/User.c
index c7ac284..6ca0991 100644
--- a/datapath-windows/ovsext/User.c
+++ b/datapath-windows/ovsext/User.c
@@ -463,7 +463,7 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
 NdisAcquireRWLockRead(gOvsSwitchContext->dispatchLock, , 0);
 ndisStatus = OvsActionsExecute(gOvsSwitchContext, NULL, pNbl,
vport ? vport->portNo :
-   OVS_DPPORT_NUMBER_INVALID,
+   OVS_DPPORT_NUMBER_INVALID,

NDIS_SEND_FLAGS_SWITCH_DESTINATION_GROUP,
, NULL, , actions,
execute->actionsLen);
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: remove invalid ASSERT in Flow.c

[Nithin Raju]

Ok. Thanks for the review.

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Yin Lin
<yinli...@gmail.com>
Date: Wednesday, August 31, 2016 at 5:05 PM
To: Nithin Raju <nit...@vmware.com>
Cc: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH] datapath-windows: remove invalid ASSERT
in  Flow.c

>Hi Nithin,
>
>Instead of removing the assertion, can you change it to:
>
>ASSERT(!key->tunKey.dst || offset == OvsGetFlowL2Offset(>tunKey));
>
>I fixed it for OvsLookupFlow but somehow overlooked OvsHashFlow in my
>Geneve patch.
>
>Best regards,
>Yin Lin
>
>On Wed, Aug 31, 2016 at 3:33 AM, Nithin Raju <nit...@vmware.com> wrote:
>
>> Since the Geneve changes, the key->l2.offset will no longer be 0 when
>> the tunnel key is valid within the OVS flow key. key->l2.offset would
>> be determined by the amount of tunnel options.
>>
>> Signed-off-by: Nithin Raju <nit...@vmware.com>
>> ---
>>  datapath-windows/ovsext/DpInternal.h | 9 ++---
>>  datapath-windows/ovsext/Flow.c   | 1 -
>>  2 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/datapath-windows/ovsext/DpInternal.h
>> b/datapath-windows/ovsext/DpInternal.h
>> index 22599a0..f62fc55 100644
>> --- a/datapath-windows/ovsext/DpInternal.h
>> +++ b/datapath-windows/ovsext/DpInternal.h
>> @@ -157,17 +157,20 @@ typedef union OvsIPv4TunnelKey {
>>  uint64_t attr[NUM_PKT_ATTR_REQUIRED];
>>  } OvsIPv4TunnelKey; /* Size of 280 byte. */
>>
>> -__inline uint8_t TunnelKeyGetOptionsOffset(const OvsIPv4TunnelKey *key)
>> +static __inline uint8_t
>> +TunnelKeyGetOptionsOffset(const OvsIPv4TunnelKey *key)
>>  {
>>  return TUN_OPT_MAX_LEN - key->tunOptLen;
>>  }
>>
>> -__inline uint8_t* TunnelKeyGetOptions(OvsIPv4TunnelKey *key)
>> +static __inline uint8_t *
>> +TunnelKeyGetOptions(OvsIPv4TunnelKey *key)
>>  {
>>  return key->tunOpts + TunnelKeyGetOptionsOffset(key);
>>  }
>>
>> -__inline uint16_t TunnelKeyGetRealSize(OvsIPv4TunnelKey *key)
>> +static __inline uint16_t
>> +TunnelKeyGetRealSize(OvsIPv4TunnelKey *key)
>>  {
>>  return sizeof(OvsIPv4TunnelKey) - TunnelKeyGetOptionsOffset(key);
>>  }
>> diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/
>> Flow.c
>> index 7a57f96..439fb28 100644
>> --- a/datapath-windows/ovsext/Flow.c
>> +++ b/datapath-windows/ovsext/Flow.c
>> @@ -2595,7 +2595,6 @@ OvsHashFlow(const OvsFlowKey *key)
>>  UINT8 *start;
>>
>>  ASSERT(key->tunKey.dst || offset == sizeof(OvsIPv4TunnelKey));
>> -ASSERT(!key->tunKey.dst || offset == 0);
>>  start = (UINT8 *)key + offset;
>>  return OvsJhashBytes(start, size, 0);
>>  }
>> --
>> 2.6.2
>>
>> ___
>> dev mailing list
>> dev@openvswitch.org
>> 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailm
>>an_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=
>>pNHQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=ttBbDaTv1p_PPtq4qgnL0BbIb9O
>>T_rkW3AWb7P0lzFM=rBwNPWqgmC58QLqBHyPye8euC456dxuFXuLoDXANbZY=
>>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=ttBbDaTv1p_PPtq4qgnL0BbIb9OT_r
>kW3AWb7P0lzFM=rBwNPWqgmC58QLqBHyPye8euC456dxuFXuLoDXANbZY= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] datapath-windows: remove invalid ASSERT in Flow.c

[Nithin Raju]

Since the Geneve changes, the key->l2.offset will no longer be 0 when
the tunnel key is valid within the OVS flow key. key->l2.offset would
be determined by the amount of tunnel options.

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/DpInternal.h | 9 ++---
 datapath-windows/ovsext/Flow.c   | 1 -
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/datapath-windows/ovsext/DpInternal.h 
b/datapath-windows/ovsext/DpInternal.h
index 22599a0..f62fc55 100644
--- a/datapath-windows/ovsext/DpInternal.h
+++ b/datapath-windows/ovsext/DpInternal.h
@@ -157,17 +157,20 @@ typedef union OvsIPv4TunnelKey {
 uint64_t attr[NUM_PKT_ATTR_REQUIRED];
 } OvsIPv4TunnelKey; /* Size of 280 byte. */
 
-__inline uint8_t TunnelKeyGetOptionsOffset(const OvsIPv4TunnelKey *key)
+static __inline uint8_t
+TunnelKeyGetOptionsOffset(const OvsIPv4TunnelKey *key)
 {
 return TUN_OPT_MAX_LEN - key->tunOptLen;
 }
 
-__inline uint8_t* TunnelKeyGetOptions(OvsIPv4TunnelKey *key)
+static __inline uint8_t *
+TunnelKeyGetOptions(OvsIPv4TunnelKey *key)
 {
 return key->tunOpts + TunnelKeyGetOptionsOffset(key);
 }
 
-__inline uint16_t TunnelKeyGetRealSize(OvsIPv4TunnelKey *key)
+static __inline uint16_t
+TunnelKeyGetRealSize(OvsIPv4TunnelKey *key)
 {
 return sizeof(OvsIPv4TunnelKey) - TunnelKeyGetOptionsOffset(key);
 }
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index 7a57f96..439fb28 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -2595,7 +2595,6 @@ OvsHashFlow(const OvsFlowKey *key)
 UINT8 *start;
 
 ASSERT(key->tunKey.dst || offset == sizeof(OvsIPv4TunnelKey));
-ASSERT(!key->tunKey.dst || offset == 0);
 start = (UINT8 *)key + offset;
 return OvsJhashBytes(start, size, 0);
 }
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC] datapath-windows: Allow validation ports processing

[Nithin Raju]

Alin,
Do you intend to add them to the vport hash tables? What is the use of
doing this?

Also, will it not create a collision in the hash table? When the vport
gets added from userspace, we should make sure that we don¹t use the
validation port as a valid port.

-- Nithin

-Original Message-
From: dev  on behalf of Alin Serdean

Date: Thursday, July 14, 2016 at 8:38 PM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [RFC] datapath-windows: Allow validation ports
processing

>Currently we do not validate ports prior a VM being started. This patch
>allows ports to be validated during creation.
>
>Validation ports have the same lifecycle as an operational port so allow
>them to have the same treatment as an operational port.
>
>Beside the above this also allows us to add OVS ports prior the VM to
>being
>started.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> datapath-windows/ovsext/Oid.c   | 8 
> datapath-windows/ovsext/Vport.c | 4 
> 2 files changed, 12 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Oid.c b/datapath-windows/ovsext/Oid.c
>index 7c7ffe7..d5ba821 100644
>--- a/datapath-windows/ovsext/Oid.c
>+++ b/datapath-windows/ovsext/Oid.c
>@@ -159,14 +159,6 @@ OvsProcessSetOidPort(POVS_SWITCH_CONTEXT
>switchObject,
> goto done;
> }
> 
>-if (portParam->IsValidationPort) {
>-/* Validation ports are used internally by the Hyper-V switch
>- * to validate and verify settings. We must skip handling them,
>- * and return STATUS_SUCCESS as the OID result
>- */
>-return NDIS_STATUS_SUCCESS;
>-}
>-
> switch(setInfo->Oid) {
> case OID_SWITCH_PORT_CREATE:
> status = HvCreatePort(switchObject, portParam, 0);
>diff --git a/datapath-windows/ovsext/Vport.c
>b/datapath-windows/ovsext/Vport.c
>index 1462453..294fd7f 100644
>--- a/datapath-windows/ovsext/Vport.c
>+++ b/datapath-windows/ovsext/Vport.c
>@@ -1451,10 +1451,6 @@ OvsAddConfiguredSwitchPorts(POVS_SWITCH_CONTEXT
>switchContext)
> for (arrIndex = 0; arrIndex < portArray->NumElements; arrIndex++) {
>  portParam = NDIS_SWITCH_PORT_AT_ARRAY_INDEX(portArray,
>arrIndex);
> 
>- if (portParam->IsValidationPort) {
>- continue;
>- }
>-
>  status = HvCreatePort(switchContext, portParam, 0);
>  if (status != STATUS_SUCCESS && status !=
>STATUS_DATA_NOT_ACCEPTED) {
>  break;
>-- 
>1.9.5.msysgit.0
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=h3ZpmSAbU9vCcm137IPWUXX5sGlUrq
>mrTf_ZBjJIXFo=7mvYeMxSHNmNI3UrtU57bmhSN0qnni8TYfNtl8sGEm4= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Fix various Geneve bugs

[Nithin Raju]

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Yin Lin
<li...@vmware.com>
Date: Wednesday, July 13, 2016 at 8:21 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Cc: Yin Lin <li...@vmware.com>
Subject: [ovs-dev] [PATCH] datapath-windows: Fix various Geneve bugs

>Signed-off-by: Yin Lin <li...@vmware.com>

Acked-by: Nithin Raju <nit...@vmware.com>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 2/2] Windows: Use NETLINK_NETFILTER instead of NETLINK_GENERIC

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

One another change that comes to mind is the validation that a socket of
type NETLINK_GENERIC does not send a CT command and vice-versa. It should
be a small change within Datapath.c and can be done as a incremental patch.

-Original Message-
From: Sairam Venugopal <vsai...@vmware.com>
Date: Tuesday, July 12, 2016 at 2:41 PM
To: Nithin Raju <nit...@vmware.com>
Subject: FW: [PATCH v3 2/2] Windows: Use NETLINK_NETFILTER instead of
NETLINK_GENERIC

>
>
>On 7/11/16, 2:59 PM, "Sairam Venugopal" <vsai...@vmware.com> wrote:
>
>>Windows datapath lacked support for different Netlink Family protocols.
>>Now that Windows supports different Netlink protocol, revert the change
>>to
>>override NETLINK_NETFILTER to use NETLINK_GENERIC.
>>
>>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>>---
>> lib/netlink-conntrack.c | 8 
>> lib/netlink-protocol.h  | 1 +
>> 2 files changed, 1 insertion(+), 8 deletions(-)
>>
>>diff --git a/lib/netlink-conntrack.c b/lib/netlink-conntrack.c
>>index 5132bf2..d83b09a 100644
>>--- a/lib/netlink-conntrack.c
>>+++ b/lib/netlink-conntrack.c
>>@@ -75,14 +75,6 @@ static struct vlog_rate_limit rl =
>>VLOG_RATE_LIMIT_INIT(1, 5);
>> #define IPS_UNTRACKED_BIT 12
>> #define IPS_UNTRACKED (1 << IPS_UNTRACKED_BIT)
>> 
>>-#ifdef _WIN32
>>-#ifdef NETLINK_NETFILTER
>>-#undef NETLINK_NETFILTER
>>-#endif
>>-/* Reuse same socket for nfgenmsg and genlmsghdr in Windows*/
>>-#define NETLINK_NETFILTER   NETLINK_GENERIC
>>-#endif
>>-
>> static const struct nl_policy nfnlgrp_conntrack_policy[] = {
>> [CTA_TUPLE_ORIG] = { .type = NL_A_NESTED, .optional = false },
>> [CTA_TUPLE_REPLY] = { .type = NL_A_NESTED, .optional = false },
>>diff --git a/lib/netlink-protocol.h b/lib/netlink-protocol.h
>>index 8938055..a7b9a65 100644
>>--- a/lib/netlink-protocol.h
>>+++ b/lib/netlink-protocol.h
>>@@ -38,6 +38,7 @@
>> #include 
>> 
>> #else
>>+#define NETLINK_NETFILTER   12
>> #define NETLINK_GENERIC 16
>> 
>> /* nlmsg_flags bits. */
>>-- 
>>2.9.0.windows.1
>>
>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 1/2] Windows: Add support for handling protocol (netlink family)

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: Sairam Venugopal <vsai...@vmware.com>
Date: Tuesday, July 12, 2016 at 2:41 PM
To: Nithin Raju <nit...@vmware.com>
Subject: FW: [PATCH v3 1/2] Windows: Add support for handling protocol
(netlink family)

>
>
>On 7/11/16, 2:59 PM, "Sairam Venugopal" <vsai...@vmware.com> wrote:
>
>>Windows datapath currently has no notion of netlink family.
>>It assumes all netlink messages to belong to NETLINK_GENERIC family.
>>This patch adds support for handling other protocols if the userspace
>>sends it down to kernel.
>>
>>This patch introduces a new NETLINK_CMD - OVS_CTRL_CMD_SOCK_PROP to
>>manage
>>all properties associated with a socket. The properties are passed down
>>as
>>netlink message attributes. This makes it easier to introduce other
>>properties in the future.
>>
>>v2: Addressed review comments from Nithin Raju <nit...@vmware.com>
>>
>>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>>Acked-by: Nithin Raju <nit...@vmware.com>
>>---
>> datapath-windows/include/OvsDpInterfaceExt.h |  17 -
>> datapath-windows/ovsext/Datapath.c   | 104
>>++-
>> datapath-windows/ovsext/Datapath.h   |   1 +
>> lib/netlink-socket.c |  75 +++
>> 4 files changed, 194 insertions(+), 3 deletions(-)
>>
>>diff --git a/datapath-windows/include/OvsDpInterfaceExt.h
>>b/datapath-windows/include/OvsDpInterfaceExt.h
>>index 8850535..db91c3e 100644
>>--- a/datapath-windows/include/OvsDpInterfaceExt.h
>>+++ b/datapath-windows/include/OvsDpInterfaceExt.h
>>@@ -92,9 +92,12 @@ enum ovs_win_control_cmd {
>> OVS_CTRL_CMD_MC_SUBSCRIBE_REQ,
>> OVS_CTRL_CMD_PACKET_SUBSCRIBE_REQ,
>> 
>>-/* This command is logically belong to the Vport family */
>>+/* This command logically belongs to the Vport family */
>> OVS_CTRL_CMD_EVENT_NOTIFY,
>>-OVS_CTRL_CMD_READ_NOTIFY
>>+OVS_CTRL_CMD_READ_NOTIFY,
>>+
>>+/* Used for Socket property */
>>+OVS_CTRL_CMD_SOCK_PROP
>> };
>> 
>> /* NL Attributes for joining/unjoining an MC group */
>>@@ -163,4 +166,14 @@ enum ovs_win_netdev_attr {
>> typedef struct ovs_dp_stats OVS_DP_STATS;
>> typedef enum ovs_vport_type OVS_VPORT_TYPE;
>> 
>>+/* NL Attributes for setting socket attributes */
>>+enum ovs_nl_sock_attr {
>>+/* (UINT32) Netlink Protocol set in Userspace and read in Kernel */
>>+OVS_NL_ATTR_SOCK_PROTO,
>>+/* (UINT32) Instance PID set in Kernel and read in Userspace */
>>+OVS_NL_ATTR_SOCK_PID,
>>+__OVS_NL_ATTR_SOCK_MAX
>>+};
>>+#define OVS_WIN_SOCK_ATTR_MAX (__OVS_NL_ATTR_SOCK_MAX - 1)
>>+
>> #endif /* __OVS_DP_INTERFACE_EXT_H_ */
>>diff --git a/datapath-windows/ovsext/Datapath.c
>>b/datapath-windows/ovsext/Datapath.c
>>index 16d58ef..4f47be5 100644
>>--- a/datapath-windows/ovsext/Datapath.c
>>+++ b/datapath-windows/ovsext/Datapath.c
>>@@ -87,7 +87,8 @@ static NetlinkCmdHandler OvsPendEventCmdHandler,
>>  OvsReadEventCmdHandler,
>>  OvsNewDpCmdHandler,
>>  OvsGetDpCmdHandler,
>>- OvsSetDpCmdHandler;
>>+ OvsSetDpCmdHandler,
>>+ OvsSockPropCmdHandler;
>> 
>> NetlinkCmdHandlerOvsGetNetdevCmdHandler,
>>  OvsGetVportCmdHandler,
>>@@ -147,6 +148,11 @@ NETLINK_CMD nlControlFamilyCmdOps[] = {
>>   .handler = OvsReadPacketCmdHandler,
>>   .supportedDevOp = OVS_READ_DEV_OP,
>>   .validateDpIndex = FALSE,
>>+},
>>+{ .cmd = OVS_CTRL_CMD_SOCK_PROP,
>>+  .handler = OvsSockPropCmdHandler,
>>+  .supportedDevOp = OVS_TRANSACTION_DEV_OP,
>>+  .validateDpIndex = FALSE,
>> }
>> };
>> 
>>@@ -1685,3 +1691,99 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
>>usrParamsCtx,
>> cleanup:
>> return status;
>> }
>>+
>>+/*
>>+ * 
>>-
>>-
>>+ *  Command Handler for 'OVS_CTRL_CMD_SOCK_PROP'.
>>+ *
>>+ *  Handler to set and verify socket properties between userspace and
>>kernel.
>>+ *
>>+ *  Protocol is passed down by the userspace. It refers to the NETLINK
>>family
>>+ *  and could be of different types (NETLINK_GENERIC/NETLINK_NETFILTER
>>etc.,)
>>+ *  This fun

Re: [ovs-dev] [PATCH] Windows: Add support for handling protocol (netlink family)

[Nithin Raju]

Thanks for doing this. Looks good but for a few cosmetic comments.

Also, remember to flip the protocol for nf sockets in userspace to
NETLINK_NETFILTER. IIRC, we use NETLINK_GENERIC.

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Thursday, July 7, 2016 at 6:14 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH] Windows: Add support for handling
protocol(netlink family)

>Windows datapath currently has no notion of netlink family.
>It assumes all netlink messages to belong to NETLINK_GENERIC family.
>This patch adds support for handling other protocols if the userspace
>sends it down to kernel.
>
>This patch introduces a new NETLINK_CMD - OVS_CTRL_CMD_SOCK_PROP to manage
>all properties associated with a socket. The properties are passed down as
>netlink message attributes. This makes it easier to introduce other
>properties in the future.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>---
> datapath-windows/include/OvsDpInterfaceExt.h |  15 +++-
> datapath-windows/ovsext/Datapath.c   | 102
>++-
> datapath-windows/ovsext/Datapath.h   |   1 +
> lib/netlink-socket.c |  75 
> 4 files changed, 191 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/include/OvsDpInterfaceExt.h
>b/datapath-windows/include/OvsDpInterfaceExt.h
>index 8850535..e75ce28 100644
>--- a/datapath-windows/include/OvsDpInterfaceExt.h
>+++ b/datapath-windows/include/OvsDpInterfaceExt.h
>@@ -94,7 +94,10 @@ enum ovs_win_control_cmd {
> 
> /* This command is logically belong to the Vport family */

minor: ³is logically belong² => ³logically belongs²
(not your code)

> OVS_CTRL_CMD_EVENT_NOTIFY,
>-OVS_CTRL_CMD_READ_NOTIFY
>+OVS_CTRL_CMD_READ_NOTIFY,
>+
>+/* Used for Socket property */
>+OVS_CTRL_CMD_SOCK_PROP
> };
> 
> /* NL Attributes for joining/unjoining an MC group */
>@@ -163,4 +166,14 @@ enum ovs_win_netdev_attr {
> typedef struct ovs_dp_stats OVS_DP_STATS; 
> typedef enum ovs_vport_type OVS_VPORT_TYPE;
> 
>+/* NL Attributes for setting socket attributes */
>+enum ovs_nl_sock_attr {
>+/* (UINT32) Netlink Protocol set in Userspace and read in Kernel */
>+OVS_NL_ATTR_SOCK_PROTO,
>+/* (UINT32) Instance PID set in Kernel and read in Userspace */
>+OVS_NL_ATTR_SOCK_PID,
>+__OVS_NL_ATTR_SOCK_MAX
>+};
>+#define OVS_WIN_SOCK_ATTR_MAX (__OVS_NL_ATTR_SOCK_MAX - 1)
>+
> #endif /* __OVS_DP_INTERFACE_EXT_H_ */
>diff --git a/datapath-windows/ovsext/Datapath.c
>b/datapath-windows/ovsext/Datapath.c
>index 16d58ef..210184d 100644
>--- a/datapath-windows/ovsext/Datapath.c
>+++ b/datapath-windows/ovsext/Datapath.c
>@@ -87,7 +87,8 @@ static NetlinkCmdHandler OvsPendEventCmdHandler,
>  OvsReadEventCmdHandler,
>  OvsNewDpCmdHandler,
>  OvsGetDpCmdHandler,
>- OvsSetDpCmdHandler;
>+ OvsSetDpCmdHandler,
>+ OvsManageSocketProperty;

Minor: All NL handlers are called: *CmdHandler. So, maybe
OvsSockPropCmdHandler().

> 
> NetlinkCmdHandlerOvsGetNetdevCmdHandler,
>  OvsGetVportCmdHandler,
>@@ -147,6 +148,11 @@ NETLINK_CMD nlControlFamilyCmdOps[] = {
>   .handler = OvsReadPacketCmdHandler,
>   .supportedDevOp = OVS_READ_DEV_OP,
>   .validateDpIndex = FALSE,
>+},
>+{ .cmd = OVS_CTRL_CMD_SOCK_PROP,
>+  .handler = OvsManageSocketProperty,
>+  .supportedDevOp = OVS_TRANSACTION_DEV_OP,
>+  .validateDpIndex = FALSE,
> }
> };
> 
>@@ -1685,3 +1691,97 @@ OvsReadEventCmdHandler(POVS_USER_PARAMS_CONTEXT
>usrParamsCtx,
> cleanup:
> return status;
> }
>+
>+/*
>+ * 
>--
>+ *  Command Handler for 'OVS_CTRL_CMD_SOCK_PROP'.
>+ *
>+ *  Handler to set and verify socket properties between userspace and
>kernel.
>+ *
>+ *  Protocol is passed down by the userspace. It refers to the NETLINK
>family
>+ *  and could be of different types (NETLINK_GENERIC/NETLINK_NETFILTER
>etc.,)
>+ *  This function parses out the protocol and adds it to the open
>instance.
>+ *
>+ *  PID is generated by the kernel and is set in userspace after
>querying the
>+ *  kernel for it. This function does not modify PID set in the kernel,
>+ *  instead it verifies if it was sent down correctly.
>+ *
>+ *  XXX -This method can be modified to handle all Socket properties
>th

[ovs-dev] [PATCH] datapath-windows: remove unused 'ovsUserTimestampDelta'

[Nithin Raju]

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Flow.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/datapath-windows/ovsext/Flow.h b/datapath-windows/ovsext/Flow.h
index 0744d30..23d252c 100644
--- a/datapath-windows/ovsext/Flow.h
+++ b/datapath-windows/ovsext/Flow.h
@@ -44,7 +44,6 @@ typedef struct _OvsLayers {
 UINT32 l7Ofs; // L4 protocol's payload.
 } OvsLayers;
 
-extern UINT64 ovsUserTimestampDelta;
 extern UINT64 ovsTimeIncrementPerTick;
 
 NDIS_STATUS OvsDeleteFlowTable(OVS_DATAPATH *datapath);
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v5 00/11] Windows: Add support for debugging conntrack from userspace

[Nithin Raju]

Good job with all the patches! I believe I have acked all of them. Thanks
for addressing all the comments.

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, July 1, 2016 at 1:49 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v5 00/11] Windows: Add support for
debugging   conntrack from userspace

>Conntrack module is part of OVS datapath on Windows and lacks netlink
>support. The following patches adds support in Windows datapath for
>accepting netfilter-netlink messages from userspace and executing the
>command. The supported commands include flushing conntrack entries and
>dumping them.
>
>v2: Addresed review comments from Paul Boca <pb...@cloudbasesolutions.com>
>v3: Added the ACKED-BY for the ones that were acked
>v4: Addresed review comments from Nithin Raju <nit...@vmware.com>
>v5: Addresed review comments from Nithin Raju <nit...@vmware.com>
>
>Sairam Venugopal (11):
>  Windows: Add conntrack netfilter netlink definitions to kernel and
>userspace
>  datapath-windows: Add support for Netfilter netlink message
>  datapath-windows: Add new NlFillOvsMsgForNfGenMsg method in Netlink.c
>  datapath-windows: Add support for flushing conntrack entries
>  datapath-windows: Add support for Conntrack IPCTNL_MSG_CT_DELETE cmd
>in Datapath.c
>  datapath-windows: Add support for dump-conntrack in datapath
>  datapath-windows: Conntrack - Handle memory allocation failure
>  datapath-windows: Add support for Conntrack IPCTNL_MSG_CT_GET cmd in
>  Datapath.c
>  datapath-windows: Track the number of conntrack entries
>  Windows: Add conntrack dump and flush support in userspace
>  Windows: Ignore the dpif conversions for windows in
>netlink-conntrack.c
>
> build-aux/extract-odp-netlink-h|   1 +
> datapath-windows/automake.mk   |   1 +
> datapath-windows/include/OvsDpInterfaceCtExt.h | 423 +++
> datapath-windows/include/OvsDpInterfaceExt.h   |   7 +
> datapath-windows/ovsext/Conntrack-other.c  |   5 +-
> datapath-windows/ovsext/Conntrack-tcp.c|  63 +++
> datapath-windows/ovsext/Conntrack.c| 566
>-
> datapath-windows/ovsext/Conntrack.h|   5 +
> datapath-windows/ovsext/Datapath.c |  70 ++-
> datapath-windows/ovsext/Netlink/Netlink.c  |  50 ++
> datapath-windows/ovsext/Netlink/Netlink.h  |  13 +-
> datapath-windows/ovsext/Netlink/NetlinkProto.h |   9 +
> datapath-windows/ovsext/Util.h |   4 +
> datapath-windows/ovsext/ovsext.vcxproj |   1 +
> datapath-windows/ovsext/precomp.h  |   1 +
> include/windows/automake.mk|   6 +
> .../windows/linux/netfilter/nf_conntrack_common.h  |   0
> include/windows/linux/netfilter/nf_conntrack_ftp.h |   0
> .../windows/linux/netfilter/nf_conntrack_sctp.h|   0
> include/windows/linux/netfilter/nf_conntrack_tcp.h |   0
> include/windows/linux/netfilter/nfnetlink.h|   0
> .../windows/linux/netfilter/nfnetlink_conntrack.h  |   0
> lib/automake.mk|   2 +
> lib/dpif-netlink.c |  15 +-
> lib/netlink-conntrack.c|  51 +-
> 25 files changed, 1261 insertions(+), 32 deletions(-)
> create mode 100644 datapath-windows/include/OvsDpInterfaceCtExt.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_common.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_ftp.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_sctp.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_tcp.h
> create mode 100644 include/windows/linux/netfilter/nfnetlink.h
> create mode 100644 include/windows/linux/netfilter/nfnetlink_conntrack.h
>
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=59qaGLQBispOboXb0ITbRJf3MBSe48
>ShAXR-JycKVIg=zkOfiUo78vJHFGojVp2OwwZoiao7w9kQAF66qDLbnME= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v5 10/11] Windows: Add conntrack dump and flush support in userspace

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, July 1, 2016 at 1:49 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v5 10/11] Windows: Add conntrack dump and
flush   support in userspace

>Modify dpif-netlink.c and netlink-conntrack.c to send down dump and flush
>command
>to Windows datapath. Include netlink-conntrack.c and netlink-conntrack.h
>in automake.mk for Windows binaries.
>
>Windows currently supports only NETLINK_GENERIC port. In order to support
>the NETLINK_NETFILTER messages, the port id is being overwritten to
>NETLINK_GENERIC on Windows and datapath has been updated to support the
>new message format.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>Acked-by: Nithin Raju <nit...@vmware.com>
>---
> lib/automake.mk |  2 ++
> lib/dpif-netlink.c  | 15 +++
> lib/netlink-conntrack.c | 41 +
> 3 files changed, 42 insertions(+), 16 deletions(-)
>
>diff --git a/lib/automake.mk b/lib/automake.mk
>index eabc0e7..4d4ee01 100644
>--- a/lib/automake.mk
>+++ b/lib/automake.mk
>@@ -372,6 +372,8 @@ lib_libopenvswitch_la_SOURCES += \
>   lib/dpif-netlink.c \
>   lib/dpif-netlink.h \
>   lib/netdev-windows.c \
>+  lib/netlink-conntrack.c \
>+  lib/netlink-conntrack.h \
>   lib/netlink-notifier.c \
>   lib/netlink-notifier.h \
>   lib/netlink-protocol.h \
>diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
>index 9bff3a8..e2bea23 100644
>--- a/lib/dpif-netlink.c
>+++ b/lib/dpif-netlink.c
>@@ -2274,7 +2274,6 @@ dpif_netlink_get_datapath_version(void)
> return version_str;
> }
> 
>-#ifdef __linux__
> struct dpif_netlink_ct_dump_state {
> struct ct_dpif_dump_state up;
> struct nl_ct_dump_state *nl_ct_dump;
>@@ -2335,7 +2334,6 @@ dpif_netlink_ct_flush(struct dpif *dpif OVS_UNUSED,
>const uint16_t *zone)
> return nl_ct_flush();
> }
> }
>-#endif
> 
> const struct dpif_class dpif_netlink_class = {
> "system",
>@@ -2377,17 +2375,10 @@ const struct dpif_class dpif_netlink_class = {
> NULL,   /* enable_upcall */
> NULL,   /* disable_upcall */
> dpif_netlink_get_datapath_version, /* get_datapath_version */
>-#ifdef __linux__
> dpif_netlink_ct_dump_start,
> dpif_netlink_ct_dump_next,
> dpif_netlink_ct_dump_done,
>-dpif_netlink_ct_flush,
>-#else
>-NULL,   /* ct_dump_start */
>-NULL,   /* ct_dump_next */
>-NULL,   /* ct_dump_done */
>-NULL,   /* ct_flush */
>-#endif
>+dpif_netlink_ct_flush
> };
> 
> static int
>@@ -2442,7 +2433,7 @@ dpif_netlink_is_internal_device(const char *name)
> 
> return reply.type == OVS_VPORT_TYPE_INTERNAL;
> }
>-?
>+
> /* Parses the contents of 'buf', which contains a "struct ovs_header"
>followed
>  * by Netlink attributes, into 'vport'.  Returns 0 if successful,
>otherwise a
>  * positive errno value.
>@@ -2946,7 +2937,7 @@ dpif_netlink_flow_get_stats(const struct
>dpif_netlink_flow *flow,
> stats->used = flow->used ? get_32aligned_u64(flow->used) : 0;
> stats->tcp_flags = flow->tcp_flags ? *flow->tcp_flags : 0;
> }
>-?
>+
> /* Logs information about a packet that was recently lost in 'ch' (in
>  * 'dpif_'). */
> static void
>diff --git a/lib/netlink-conntrack.c b/lib/netlink-conntrack.c
>index 47a3c62..ad9f0b7 100644
>--- a/lib/netlink-conntrack.c
>+++ b/lib/netlink-conntrack.c
>@@ -75,6 +75,14 @@ static struct vlog_rate_limit rl =
>VLOG_RATE_LIMIT_INIT(1, 5);
> #define IPS_UNTRACKED_BIT 12
> #define IPS_UNTRACKED (1 << IPS_UNTRACKED_BIT)
> 
>+#ifdef _WIN32
>+#ifdef NETLINK_NETFILTER
>+#undef NETLINK_NETFILTER
>+#endif
>+/* Reuse same socket for nfgenmsg and genlmsghdr in Windows*/
>+#define NETLINK_NETFILTER   NETLINK_GENERIC
>+#endif
>+
> static const struct nl_policy nfnlgrp_conntrack_policy[] = {
> [CTA_TUPLE_ORIG] = { .type = NL_A_NESTED, .optional = false },
> [CTA_TUPLE_REPLY] = { .type = NL_A_NESTED, .optional = false },
>@@ -118,7 +126,7 @@ struct nl_ct_dump_state {
> bool filter_zone;
> uint16_t zone;
> };
>-?
>+
> /* Conntrack netlink dumping. */
> 
> /* Initialize a conntrack netlink dump. */
>@@ -200,7 +208,7 @@ nl_ct_dump_done(struct nl_ct_dump_state *state)
> free

Re: [ovs-dev] [PATCH v5 04/11] datapath-windows: Add support for flushing conntrack entries

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>


-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, July 1, 2016 at 1:49 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v5 04/11] datapath-windows: Add support
for flushing conntrack entries

>Flush out all conntrack entries or those that match a given zone. Since
>the conntrack module is internal to OVS in Windows, this functionality
>needs to be added in.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>---
> datapath-windows/ovsext/Conntrack.c | 93
>+
> 1 file changed, 93 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c
>b/datapath-windows/ovsext/Conntrack.c
>index b78ba26..f21acd4 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -624,3 +624,96 @@ ovsConntrackEntryCleaner(PVOID data)
> 
> PsTerminateSystemThread(STATUS_SUCCESS);
> }
>+
>+/*
>+ 
>*-
>---
>+ * OvsCtFlush
>+ * Flushes out all Conntrack Entries that match the given zone
>+ 
>*-
>---
>+ */
>+static __inline NDIS_STATUS
>+OvsCtFlush(UINT16 zone)
>+{
>+PLIST_ENTRY link, next;
>+POVS_CT_ENTRY entry;
>+
>+LOCK_STATE_EX lockState;
>+NdisAcquireRWLockWrite(ovsConntrackLockObj, , 0);
>+
>+for (int i = 0; i < CT_HASH_TABLE_SIZE; i++) {
>+LIST_FORALL_SAFE([i], link, next) {
>+entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
>+/* zone is a non-zero value */
>+if (!zone || zone == entry->key.zone)
>+OvsCtEntryDelete(entry);
>+}
>+}
>+
>+NdisReleaseRWLock(ovsConntrackLockObj, );
>+return NDIS_STATUS_SUCCESS;
>+}
>+
>+NTSTATUS
>+OvsCtDeleteCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
>+  UINT32 *replyLen)
>+{
>+POVS_MESSAGE msgIn = (POVS_MESSAGE)usrParamsCtx->inputBuffer;
>+POVS_MESSAGE msgOut = (POVS_MESSAGE)usrParamsCtx->outputBuffer;
>+PNL_MSG_HDR nlMsgHdr = &(msgIn->nlMsg);
>+PNL_ATTR ctAttrs[__CTA_MAX];
>+UINT32 attrOffset = NLMSG_HDRLEN + NF_GEN_MSG_HDRLEN + OVS_HDRLEN;
>+NL_ERROR nlError = NL_ERROR_SUCCESS;
>+NTSTATUS status;
>+UINT16 zone = 0;
>+NL_BUFFER nlBuf;
>+UINT16 nlmsgType;
>+PNL_MSG_HDR nlMsg;
>+
>+static const NL_POLICY ctZonePolicy[] = {
>+[CTA_ZONE] = { .type = NL_A_BE16, .optional = TRUE },
>+};
>+
>+if ((NlAttrParse(nlMsgHdr, attrOffset, NlNfMsgAttrsLen(nlMsgHdr),
>+ctZonePolicy, ARRAY_SIZE(ctZonePolicy),
>+ctAttrs, ARRAY_SIZE(ctAttrs)))
>+!= TRUE) {
>+OVS_LOG_ERROR("Zone attr parsing failed for msg: %p", nlMsgHdr);
>+status = STATUS_INVALID_PARAMETER;
>+goto done;
>+}
>+
>+if (ctAttrs[CTA_ZONE]) {
>+zone = NlAttrGetU16(ctAttrs[CTA_ZONE]);
>+}
>+
>+status = OvsCtFlush(zone);
>+if (status == STATUS_SUCCESS) {
>+nlmsgType = (NFNL_SUBSYS_CTNETLINK << 8 | IPCTNL_MSG_CT_DELETE);
>+NlBufInit(,
>+  usrParamsCtx->outputBuffer,
>+  usrParamsCtx->outputLength);
>+status = NlFillOvsMsgForNfGenMsg(, nlmsgType, NLM_F_CREATE,
>+ msgIn->nlMsg.nlmsgSeq,
>+ msgIn->nlMsg.nlmsgPid,
>+ AF_UNSPEC,
>+ msgIn->nfGenMsg.version,
>+ 0);
>+nlMsg = (PNL_MSG_HDR)NlBufAt(, 0, 0);
>+nlMsg->nlmsgLen = NlBufSize();
>+*replyLen = msgOut->nlMsg.nlmsgLen;
>+}
>+
>+done:
>+nlError = NlMapStatusToNlErr(status);
>+if (nlError != NL_ERROR_SUCCESS) {
>+POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
>+   usrParamsCtx->outputBuffer;
>+
>+ASSERT(msgError);
>+NlBuildErrorMsg(msgIn, msgError, nlError, replyLen);
>+ASSERT(*replyLen != 0);
>+status = STATUS_SUCCESS;
>+}
>+
>+return status;
>+}
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=5ykz23RNfdGpL3QHXRgy-587PFdAji
>SXzTF2SjTVOzU=EoHzYcFTcQS4fXXXmuxoiSX_7UrJ_rg6ypro3z7qVto= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 11/11] Windows: Ignore the dpif conversions for windows in netlink-conntrack.c

[Nithin Raju]

>
>+/* Windows currently sends down CT_DPIF_TCP state */

³sends up² would probably be more appropriate :)

>static uint8_t
> ip_ct_tcp_flags_to_dpif(uint8_t flags)
> {
>+#ifdef _WIN32
>+/* Windows currently sends down CT_DPIF_TCP flags */

³sends up² would probably be more appropriate :)


Looks good otherwise.

Acked-by: Nithin Raju <nit...@vmware.com>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 10/11] Windows: Add conntrack dump and flush support in userspace

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 10/11] Windows: Add conntrack dump and
flush   support in userspace

>Modify dpif-netlink.c and netlink-conntrack.c to send down dump and flush
>command
>to Windows datapath. Include netlink-conntrack.c and netlink-conntrack.h
>in automake.mk for Windows binaries.
>
>Windows currently supports only NETLINK_GENERIC port. In order to support
>the NETLINK_NETFILTER messages, the port id is being overwritten to
>NETLINK_GENERIC on Windows and datapath has been updated to support the
>new message format.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>Acked-by: Nithin Raju <nit...@vmware.com>
>---
> lib/automake.mk |  2 ++
> lib/dpif-netlink.c  | 15 +++
> lib/netlink-conntrack.c | 37 +
> 3 files changed, 38 insertions(+), 16 deletions(-)
>
>diff --git a/lib/automake.mk b/lib/automake.mk
>index eabc0e7..4d4ee01 100644
>--- a/lib/automake.mk
>+++ b/lib/automake.mk
>@@ -372,6 +372,8 @@ lib_libopenvswitch_la_SOURCES += \
>   lib/dpif-netlink.c \
>   lib/dpif-netlink.h \
>   lib/netdev-windows.c \
>+  lib/netlink-conntrack.c \
>+  lib/netlink-conntrack.h \
>   lib/netlink-notifier.c \
>   lib/netlink-notifier.h \
>   lib/netlink-protocol.h \
>diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
>index 9bff3a8..e2bea23 100644
>--- a/lib/dpif-netlink.c
>+++ b/lib/dpif-netlink.c
>@@ -2274,7 +2274,6 @@ dpif_netlink_get_datapath_version(void)
> return version_str;
> }
> 
>-#ifdef __linux__
> struct dpif_netlink_ct_dump_state {
> struct ct_dpif_dump_state up;
> struct nl_ct_dump_state *nl_ct_dump;
>@@ -2335,7 +2334,6 @@ dpif_netlink_ct_flush(struct dpif *dpif OVS_UNUSED,
>const uint16_t *zone)
> return nl_ct_flush();
> }
> }
>-#endif
> 
> const struct dpif_class dpif_netlink_class = {
> "system",
>@@ -2377,17 +2375,10 @@ const struct dpif_class dpif_netlink_class = {
> NULL,   /* enable_upcall */
> NULL,   /* disable_upcall */
> dpif_netlink_get_datapath_version, /* get_datapath_version */
>-#ifdef __linux__
> dpif_netlink_ct_dump_start,
> dpif_netlink_ct_dump_next,
> dpif_netlink_ct_dump_done,
>-dpif_netlink_ct_flush,
>-#else
>-NULL,   /* ct_dump_start */
>-NULL,   /* ct_dump_next */
>-NULL,   /* ct_dump_done */
>-NULL,   /* ct_flush */
>-#endif
>+dpif_netlink_ct_flush
> };
> 
> static int
>@@ -2442,7 +2433,7 @@ dpif_netlink_is_internal_device(const char *name)
> 
> return reply.type == OVS_VPORT_TYPE_INTERNAL;
> }
>-?
>+
> /* Parses the contents of 'buf', which contains a "struct ovs_header"
>followed
>  * by Netlink attributes, into 'vport'.  Returns 0 if successful,
>otherwise a
>  * positive errno value.
>@@ -2946,7 +2937,7 @@ dpif_netlink_flow_get_stats(const struct
>dpif_netlink_flow *flow,
> stats->used = flow->used ? get_32aligned_u64(flow->used) : 0;
> stats->tcp_flags = flow->tcp_flags ? *flow->tcp_flags : 0;
> }
>-?
>+
> /* Logs information about a packet that was recently lost in 'ch' (in
>  * 'dpif_'). */
> static void
>diff --git a/lib/netlink-conntrack.c b/lib/netlink-conntrack.c
>index 47a3c62..329d446 100644
>--- a/lib/netlink-conntrack.c
>+++ b/lib/netlink-conntrack.c
>@@ -75,6 +75,14 @@ static struct vlog_rate_limit rl =
>VLOG_RATE_LIMIT_INIT(1, 5);
> #define IPS_UNTRACKED_BIT 12
> #define IPS_UNTRACKED (1 << IPS_UNTRACKED_BIT)
> 
>+#ifdef _WIN32
>+#ifdef NETLINK_NETFILTER
>+#undef NETLINK_NETFILTER
>+#endif
>+/* Reuse same socket for nfgenmsg and genlmsghdr in Windows*/
>+#define NETLINK_NETFILTER   NETLINK_GENERIC
>+#endif
>+
> static const struct nl_policy nfnlgrp_conntrack_policy[] = {
> [CTA_TUPLE_ORIG] = { .type = NL_A_NESTED, .optional = false },
> [CTA_TUPLE_REPLY] = { .type = NL_A_NESTED, .optional = false },
>@@ -118,7 +126,7 @@ struct nl_ct_dump_state {
> bool filter_zone;
> uint16_t zone;
> };
>-?
>+
> /* Conntrack netlink dumping. */
> 
> /* Initialize a conntrack netlink dump. */
>@@ -200,7 +208,7 @@ nl_ct_dump_done(struct nl_ct_dump_state *state)
> free

Re: [ovs-dev] [PATCH v4 09/11] datapath-windows: Track the number of conntrack entries

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 09/11] datapath-windows: Track the number
of  conntrack entries

>Add a counter to track the number of connection tracking entries. Iterate
>over the conntrack entry table only if there are entries.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>---
> datapath-windows/ovsext/Conntrack.c | 108
>
> 1 file changed, 60 insertions(+), 48 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c
>b/datapath-windows/ovsext/Conntrack.c
>index 1780f60..6cc0fb8 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -39,6 +39,7 @@ static PLIST_ENTRY ovsConntrackTable;
> static OVS_CT_THREAD_CTX ctThreadCtx;
> static PNDIS_RW_LOCK_EX ovsConntrackLockObj;
> extern POVS_SWITCH_CONTEXT gOvsSwitchContext;
>+static UINT64 ctTotalEntries;
> 
> /*
>  
>*-
>---
>@@ -51,6 +52,7 @@ OvsInitConntrack(POVS_SWITCH_CONTEXT context)
> {
> NTSTATUS status;
> HANDLE threadHandle = NULL;
>+ctTotalEntries = 0;
> 
> /* Init the sync-lock */
> ovsConntrackLockObj = NdisAllocateRWLock(context->NdisFilterHandle);
>@@ -160,6 +162,7 @@ OvsCtAddEntry(POVS_CT_ENTRY entry,
>OvsConntrackKeyLookupCtx *ctx, UINT64 now)
> entry->timestampStart = now;
> InsertHeadList([ctx->hash & CT_HASH_TABLE_MASK],
>>link);
>+ctTotalEntries++;
>}
> 
> static __inline POVS_CT_ENTRY
>@@ -252,6 +255,7 @@ OvsCtEntryDelete(POVS_CT_ENTRY entry)
> {
> RemoveEntryList(>link);
> OvsFreeMemoryWithTag(entry, OVS_CT_POOL_TAG);
>+ctTotalEntries--;
> }
> 
> static __inline BOOLEAN
>@@ -322,6 +326,11 @@ OvsCtLookup(OvsConntrackKeyLookupCtx *ctx)
> BOOLEAN reply = FALSE;
> POVS_CT_ENTRY found = NULL;
> 
>+if (!ctTotalEntries)
>+{
>+return found;
>+}
>+
> LIST_FORALL([ctx->hash & CT_HASH_TABLE_MASK],
>link) {
> entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
> 
>@@ -636,15 +645,16 @@ ovsConntrackEntryCleaner(PVOID data)
> NdisGetCurrentSystemTime((LARGE_INTEGER *));
> threadSleepTimeout = currentTime + CT_CLEANUP_INTERVAL;
> 
>-for (int i = 0; i < CT_HASH_TABLE_SIZE; i++) {
>-LIST_FORALL_SAFE([i], link, next) {
>-entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
>-if (entry->expiration < currentTime) {
>-OvsCtEntryDelete(entry);
>+if (ctTotalEntries) {
>+for (int i = 0; i < CT_HASH_TABLE_SIZE; i++) {
>+LIST_FORALL_SAFE([i], link, next) {
>+entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
>+if (entry->expiration < currentTime) {
>+OvsCtEntryDelete(entry);
>+}
> }
> }
> }
>-
> NdisReleaseRWLock(ovsConntrackLockObj, );
> KeWaitForSingleObject(>event, Executive, KernelMode,
>   FALSE, (LARGE_INTEGER
>*));
>@@ -667,12 +677,13 @@ OvsCtFlush(UINT16 zone)
> 
> LOCK_STATE_EX lockState;
> NdisAcquireRWLockWrite(ovsConntrackLockObj, , 0);
>-
>-for (int i = 0; i < CT_HASH_TABLE_SIZE; i++) {
>-LIST_FORALL_SAFE([i], link, next) {
>-entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
>-if (!zone || zone == entry->key.zone)
>-OvsCtEntryDelete(entry);
>+if (ctTotalEntries) {
>+for (int i = 0; i < CT_HASH_TABLE_SIZE; i++) {
>+LIST_FORALL_SAFE([i], link, next) {
>+entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
>+if (!zone || zone == entry->key.zone)
>+OvsCtEntryDelete(entry);
>+}
> }
> }
> 
>@@ -1081,7 +1092,6 @@ OvsCtDumpCmdHandler(POVS_USER_PARAMS_CONTEXT
>usrParamsCtx,
> POVS_OPEN_INSTANCE instance =
> (POVS_OPEN_INSTANCE)usrParamsCtx->ovsInstance;
> POVS_MESSAGE msgIn;
>-UINT32 i;
> 
> ASSERT(usrParamsCtx->devOp == OVS_READ_DEV_OP);
> if (instance->dumpState.ovsMsg == NULL) {
>@@ -1094,54 +1104,56 @@ OvsCtDumpCmdHandler(POVS_USER_PARAMS_CONTEXT
>usrParamsCtx,
> msgIn = instance->dumpState.ovsMsg;
>   

Re: [ovs-dev] [PATCH v4 08/11] datapath-windows: Add support for Conntrack IPCTNL_MSG_CT_GET cmd in Datapath.c

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 08/11] datapath-windows: Add support
for Conntrack IPCTNL_MSG_CT_GET cmd in Datapath.c

>This will be used by userspace for dumping conntrack entries - "ovs-dpctl
>dump-conntrack".
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>---
> datapath-windows/ovsext/Datapath.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Datapath.c
>b/datapath-windows/ovsext/Datapath.c
>index c9e3709..2f33420 100644
>--- a/datapath-windows/ovsext/Datapath.c
>+++ b/datapath-windows/ovsext/Datapath.c
>@@ -104,7 +104,8 @@ NetlinkCmdHandlerOvsGetNetdevCmdHandler,
>  OvsPendPacketCmdHandler,
>  OvsSubscribePacketCmdHandler,
>  OvsReadPacketCmdHandler,
>- OvsCtDeleteCmdHandler;
>+ OvsCtDeleteCmdHandler,
>+ OvsCtDumpCmdHandler;
> 
> static NTSTATUS HandleGetDpTransaction(POVS_USER_PARAMS_CONTEXT
>usrParamsCtx,
>UINT32 *replyLen);
>@@ -288,7 +289,12 @@ NETLINK_CMD nlCtFamilyCmdOps[] = {
> { .cmd  = IPCTNL_MSG_CT_DELETE,
>   .handler  = OvsCtDeleteCmdHandler,
>   .supportedDevOp   = OVS_TRANSACTION_DEV_OP,
>-  .validateDpIndex  = TRUE
>+  .validateDpIndex  = FALSE
>+},
>+{ .cmd  = IPCTNL_MSG_CT_GET,
>+  .handler  = OvsCtDumpCmdHandler,
>+  .supportedDevOp   = OVS_WRITE_DEV_OP | OVS_READ_DEV_OP,
>+  .validateDpIndex  = FALSE
> }
> };
> 
>@@ -904,6 +910,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
> 
> ASSERT(ovsMsg);
> switch (ovsMsg->nlMsg.nlmsgType) {
>+case NFNL_TYPE_CT_GET:
> case NFNL_TYPE_CT_DEL:
> nlFamilyOps = 
> break;
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=beA9Tq4IJdCKdsriwThwdXvRo3wzhf
>lrQ52u1agGBQM=cWs8Vgf9hnrDzKU2GwFwsWzdcaPXzR-GUmFhJTGU3LM= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 07/11] datapath-windows: Conntrack - Handle memory allocation failure

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 07/11] datapath-windows: Conntrack -
Handle  memory allocation failure

>Return null if Windows fails to allocate memory for the conntrack entry.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>Acked-by: Nithin Raju <nit...@vmware.com>
>---
> datapath-windows/ovsext/Conntrack-other.c | 5 +++--
> datapath-windows/ovsext/Conntrack-tcp.c   | 4 
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack-other.c
>b/datapath-windows/ovsext/Conntrack-other.c
>index 5d39389..b853020 100644
>--- a/datapath-windows/ovsext/Conntrack-other.c
>+++ b/datapath-windows/ovsext/Conntrack-other.c
>@@ -73,8 +73,9 @@ OvsConntrackCreateOtherEntry(UINT64 now)
> struct conn_other *conn;
> conn = OvsAllocateMemoryWithTag(sizeof(struct conn_other),
> OVS_CT_POOL_TAG);
>-/* XXX Handle memory allocation error (by returning a status) */
>-ASSERT(conn);
>+if (!conn) {
>+return NULL;
>+}
> conn->up = (OVS_CT_ENTRY) {0};
> conn->state = OTHERS_FIRST;
> OvsConntrackUpdateExpiration(conn, now);
>diff --git a/datapath-windows/ovsext/Conntrack-tcp.c
>b/datapath-windows/ovsext/Conntrack-tcp.c
>index 1d60323..a0ee791 100644
>--- a/datapath-windows/ovsext/Conntrack-tcp.c
>+++ b/datapath-windows/ovsext/Conntrack-tcp.c
>@@ -490,6 +490,10 @@ OvsConntrackCreateTcpEntry(const TCPHdr *tcp,
> 
> newconn = OvsAllocateMemoryWithTag(sizeof(struct conn_tcp),
>OVS_CT_POOL_TAG);
>+if (!newconn) {
>+return NULL;
>+}
>+
> newconn->up = (OVS_CT_ENTRY) {0};
> src = >peer[0];
> dst = >peer[1];
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=gRdkH8L2HL7tdelx4jAppou9gNxCNG
>vwMJb1OtJmT1o=7UBWxV1zD7bnlbNbPiO6QTFr-EjSfS0KT_l-Qf4L678= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 06/11] datapath-windows: Add support for dump-conntrack in datapath

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 06/11] datapath-windows: Add support
for dump-conntrack in datapath

>Create the methods used for dumping conntrack entries from the hyper-v
>datapath to userspace by means of netfilter netlink messages. Some of the
>attributes are not supported by the datapath and have been defaulted to 0.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>Acked-by: Nithin Raju <nit...@vmware.com>
>---
> datapath-windows/ovsext/Conntrack-tcp.c |  59 +
> datapath-windows/ovsext/Conntrack.c | 449
>+++-
> datapath-windows/ovsext/Conntrack.h |   5 +
> datapath-windows/ovsext/Util.h  |   4 +
> 4 files changed, 514 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack-tcp.c
>b/datapath-windows/ovsext/Conntrack-tcp.c
>index 19925c3..1d60323 100644
>--- a/datapath-windows/ovsext/Conntrack-tcp.c
>+++ b/datapath-windows/ovsext/Conntrack-tcp.c
>@@ -523,3 +523,62 @@ OvsConntrackCreateTcpEntry(const TCPHdr *tcp,
> 
> return >up;
> }
>+
>+static __inline uint8_t
>+OvsCtTcpPeerToProtoInfoFlags(const struct tcp_peer *peer)
>+{
>+uint8_t res = 0;
>+
>+if (peer->wscale & CT_WSCALE_FLAG) {
>+res |= CT_DPIF_TCPF_WINDOW_SCALE;
>+}
>+
>+if (peer->wscale & CT_WSCALE_UNKNOWN) {
>+res |= CT_DPIF_TCPF_BE_LIBERAL;
>+}
>+
>+return res;
>+}
>+
>+NDIS_STATUS
>+OvsCtMapTcpProtoInfoToNl(PNL_BUFFER nlBuf, OVS_CT_ENTRY *conn_)
>+{
>+struct conn_tcp *conn = OvsCastConntrackEntryToTcpEntry(conn_);
>+NDIS_STATUS status = NDIS_STATUS_SUCCESS;
>+UINT32 offset = 0;
>+
>+offset = NlMsgStartNested(nlBuf, CTA_PROTOINFO_TCP);
>+if (!offset) {
>+return NDIS_STATUS_FAILURE;
>+}
>+
>+if (!NlMsgPutTailU8(nlBuf, CTA_PROTOINFO_TCP_STATE,
>+conn->peer[0].state)) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU8(nlBuf, CTA_PROTOINFO_TCP_WSCALE_ORIGINAL,
>+(conn->peer[0].wscale & CT_WSCALE_MASK))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU8(nlBuf, CTA_PROTOINFO_TCP_WSCALE_REPLY,
>+(conn->peer[1].wscale & CT_WSCALE_MASK))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU16(nlBuf, CTA_PROTOINFO_TCP_FLAGS_ORIGINAL,
>+ OvsCtTcpPeerToProtoInfoFlags(>peer[0]))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU16(nlBuf, CTA_PROTOINFO_TCP_FLAGS_REPLY,
>+ OvsCtTcpPeerToProtoInfoFlags(>peer[1]))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+
>+done:
>+NlMsgEndNested(nlBuf, offset);
>+return status;
>+}
>diff --git a/datapath-windows/ovsext/Conntrack.c
>b/datapath-windows/ovsext/Conntrack.c
>index b547f7e..1780f60 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -24,6 +24,10 @@
> #include "PacketParser.h"
> #include "Debug.h"
> 
>+#define WINDOWS_TICK 1000
>+#define SEC_TO_UNIX_EPOCH 11644473600LL
>+#define SEC_TO_NANOSEC 10LL
>+
> typedef struct _OVS_CT_THREAD_CTX {
> KEVENT  event;
> PVOID   threadObject;
>@@ -148,11 +152,12 @@ OvsCtUpdateFlowKey(struct OvsFlowKey *key,
> }
> 
> static __inline VOID
>-OvsCtAddEntry(POVS_CT_ENTRY entry, OvsConntrackKeyLookupCtx *ctx)
>+OvsCtAddEntry(POVS_CT_ENTRY entry, OvsConntrackKeyLookupCtx *ctx, UINT64
>now)
> {
> NdisMoveMemory(>key, >key, sizeof (OVS_CT_KEY));
> NdisMoveMemory(>rev_key, >key, sizeof (OVS_CT_KEY));
> OvsCtKeyReverse(>rev_key);
>+entry->timestampStart = now;
> InsertHeadList([ctx->hash & CT_HASH_TABLE_MASK],
>>link);
> }
>@@ -182,7 +187,10 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
> state |= OVS_CS_F_NEW;
> if (commit) {
> entry = OvsConntrackCreateTcpEntry(tcp, curNbl,
>currentTime);
>-OvsCtAddEntry(entry, ctx);
>+if (!entry) {
>+return NULL;
>+}
>+Ov

Re: [ovs-dev] [PATCH v4 05/11] datapath-windows: Add support for Conntrack IPCTNL_MSG_CT_DELETE cmd in Datapath.c

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

>+
> /* Windows kernel datapath extensions to the standard datapath
>interface. */
> 
> /* Version number of the datapath interface extensions. */
>@@ -65,6 +68,8 @@
> #define OVS_WIN_NL_VPORT_FAMILY_ID   (NLMSG_MIN_TYPE + 4)
> #define OVS_WIN_NL_FLOW_FAMILY_ID(NLMSG_MIN_TYPE + 5)
> #define OVS_WIN_NL_NETDEV_FAMILY_ID  (NLMSG_MIN_TYPE + 6)
>+/* Conntrack Family is defined in OvsDpInterfaceCtExt.h */
>+#define OVS_WIN_NL_CT_FAMILY_ID  (NLMSG_MIN_TYPE + 7)

Also, pls. add a comment that ŒOVS_WIN_NL_CT_FAMILY_ID¹ is not used in the
messages per-se but is used internally in the kernel. We define it here as
a placeholder since we handle the CT family of commands.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 04/11] datapath-windows: Add support for flushing conntrack entries

[Nithin Raju]

Looks good but for a few comments.

>+static __inline NDIS_STATUS
>+OvsCtFlush(UINT16 zone)
>+{
>+PLIST_ENTRY link, next;
>+POVS_CT_ENTRY entry;
>+
>+LOCK_STATE_EX lockState;
>+NdisAcquireRWLockWrite(ovsConntrackLockObj, , 0);
>+
>+for (int i = 0; i < CT_HASH_TABLE_SIZE; i++) {
>+LIST_FORALL_SAFE([i], link, next) {
>+entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
>+if (!zone || zone == entry->key.zone)

Is 0 a valid value for zone? If yes, we¹ll end up deleting all the entries
when zone == 0.


>+nlmsgType = (NFNL_SUBSYS_CTNETLINK << 8 | IPCTNL_MSG_CT_DELETE);
>+NlBufInit(,
>+  usrParamsCtx->outputBuffer,
>+  usrParamsCtx->outputLength);
>+status = NlFillOvsMsgForNfGenMsg(, nlmsgType, NLM_F_CREATE,
>+ msgIn->nlMsg.nlmsgSeq,
>+ msgIn->nlMsg.nlmsgPid,
>+ AF_UNSPEC,
>+ msgIn->nfGenMsg.version,
>+ gOvsSwitchContext->dpNo);

'gOvsSwitchContext->dpNo¹ is not part of the struct nlhdr + struct
nfgenmsg combination. You¹ll have to decrement the size of the output by
Œsizeof gOvsSwitchContext->dpNo¹.


Also, if there¹s an error, you¹ll end up writing to the output buffer
twice. You should probably structure the code as:

status = OvsCtFlush(zone);
if (status == STATUS_SUCCESS) {
/* fill success message. */
*replyLen = blah;
}

done:
nlError = NlMapStatusToNlErr(status);

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 03/11] datapath-windows: Add new NlFillOvsMsgForNfGenMsg method in Netlink.c

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 03/11] datapath-windows: Add
new NlFillOvsMsgForNfGenMsg method in Netlink.c

>Create a new method to create and fill OvsMessage with NfGenMsg. This will
>be used for sending Netfilter based Netlink messages.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>Acked-by: Nithin Raju <nit...@vmware.com>
>---
> datapath-windows/ovsext/Netlink/Netlink.c | 39
>+++
> datapath-windows/ovsext/Netlink/Netlink.h |  4 
> 2 files changed, 43 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Netlink/Netlink.c
>b/datapath-windows/ovsext/Netlink/Netlink.c
>index ccf9ec1..2432205 100644
>--- a/datapath-windows/ovsext/Netlink/Netlink.c
>+++ b/datapath-windows/ovsext/Netlink/Netlink.c
>@@ -73,6 +73,45 @@ NlFillOvsMsg(PNL_BUFFER nlBuf, UINT16 nlmsgType,
> 
> /*
>  * 
>--
>-
>+ * Prepare netlink message headers. This API adds
>+ * NL_MSG_HDR + GENL_HDR + OVS_HDR to the tail of input NLBuf.
>+ * Attributes should be added by caller.
>+ * 
>--
>-
>+ */
>+BOOLEAN
>+NlFillOvsMsgForNfGenMsg(PNL_BUFFER nlBuf, UINT16 nlmsgType,
>+UINT16 nlmsgFlags, UINT32 nlmsgSeq,
>+UINT32 nlmsgPid, UINT8 nfgenFamily,
>+UINT8 nfGenVersion, UINT32 dpNo)
>+{
>+BOOLEAN writeOk;
>+OVS_MESSAGE msgOut;
>+UINT32 offset = NlBufSize(nlBuf);
>+
>+/* To keep compiler happy for release build. */
>+UNREFERENCED_PARAMETER(offset);
>+ASSERT(NlBufAt(nlBuf, offset, 0) != 0);
>+
>+msgOut.nlMsg.nlmsgType = nlmsgType;
>+msgOut.nlMsg.nlmsgFlags = nlmsgFlags;
>+msgOut.nlMsg.nlmsgSeq = nlmsgSeq;
>+msgOut.nlMsg.nlmsgPid = nlmsgPid;
>+msgOut.nlMsg.nlmsgLen = sizeof(struct _OVS_MESSAGE);
>+
>+msgOut.nfGenMsg.nfgenFamily = nfgenFamily;
>+msgOut.nfGenMsg.version = nfGenVersion;
>+msgOut.nfGenMsg.resId = 0;
>+
>+msgOut.ovsHdr.dp_ifindex = dpNo;
>+
>+writeOk = NlMsgPutTail(nlBuf, (PCHAR)(),
>+   sizeof (struct _OVS_MESSAGE));
>+
>+return writeOk;
>+}
>+
>+/*
>+ * 
>--
>-
>  * Prepare NL_MSG_HDR only. This API appends a NL_MSG_HDR to the tail of
>  * input NlBuf.
>  * 
>--
>-
>diff --git a/datapath-windows/ovsext/Netlink/Netlink.h
>b/datapath-windows/ovsext/Netlink/Netlink.h
>index 5261b9e..363f575 100644
>--- a/datapath-windows/ovsext/Netlink/Netlink.h
>+++ b/datapath-windows/ovsext/Netlink/Netlink.h
>@@ -95,6 +95,10 @@ BOOLEAN NlFillOvsMsg(PNL_BUFFER nlBuf,
>  UINT16 nlmsgType, UINT16 nlmsgFlags,
>  UINT32 nlmsgSeq, UINT32 nlmsgPid,
>  UINT8 genlCmd, UINT8 genlVer, UINT32 dpNo);
>+BOOLEAN NlFillOvsMsgForNfGenMsg(PNL_BUFFER nlBuf, UINT16 nlmsgType,
>+UINT16 nlmsgFlags, UINT32 nlmsgSeq,
>+UINT32 nlmsgPid, UINT8 nfgenFamily,
>+UINT8 nfGenVersion, UINT32 dpNo);
> BOOLEAN NlFillNlHdr(PNL_BUFFER nlBuf,
> UINT16 nlmsgType, UINT16 nlmsgFlags,
> UINT32 nlmsgSeq, UINT32 nlmsgPid);
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=OQEY2-mikNlKNEBo4-B3kT02Dh1muQ
>pIycaH5QArnkU=yZkZ3-o8MzkiIyTxPqi7fgU0g6kVaFy1OoRvTfWmCgc= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 02/11] datapath-windows: Add support for Netfilter netlink message

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 02/11] datapath-windows: Add support
for Netfilter netlink message

>Introduce NF_GEN_MSG_HDR similar to GENL_MSG_HDR that will be used for
>communicating via netfilter-netlink channel. This will be used by
>userspace to retrieve and modify Conntrack data in Windows.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>Acked-by: Nithin Raju <nit...@vmware.com>
>---
> datapath-windows/ovsext/Netlink/Netlink.c  | 11 +++
> datapath-windows/ovsext/Netlink/Netlink.h  |  9 +++--
> datapath-windows/ovsext/Netlink/NetlinkProto.h |  9 +
> 3 files changed, 27 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Netlink/Netlink.c
>b/datapath-windows/ovsext/Netlink/Netlink.c
>index 1eec320..ccf9ec1 100644
>--- a/datapath-windows/ovsext/Netlink/Netlink.c
>+++ b/datapath-windows/ovsext/Netlink/Netlink.c
>@@ -672,6 +672,17 @@ NlMsgAttrsLen(const PNL_MSG_HDR nlh)
> return NlHdrPayloadLen(nlh) - GENL_HDRLEN - OVS_HDRLEN;
> }
> 
>+/*
>+ * 
>--
>-
>+ * Returns size of to nfnlmsg attributes.
>+ * 
>--
>-
>+ */
>+UINT32
>+NlNfMsgAttrsLen(const PNL_MSG_HDR nlh)
>+{
>+return NlHdrPayloadLen(nlh) - NF_GEN_MSG_HDRLEN - OVS_HDRLEN;
>+}
>+
> /* Netlink message parse. */
> 
> /*
>diff --git a/datapath-windows/ovsext/Netlink/Netlink.h
>b/datapath-windows/ovsext/Netlink/Netlink.h
>index b1b3bed..5261b9e 100644
>--- a/datapath-windows/ovsext/Netlink/Netlink.h
>+++ b/datapath-windows/ovsext/Netlink/Netlink.h
>@@ -27,10 +27,14 @@
>  */
> typedef struct _OVS_MESSAGE {
> NL_MSG_HDR nlMsg;
>-GENL_MSG_HDR genlMsg;
>+union {
>+GENL_MSG_HDR genlMsg;
>+NF_GEN_MSG_HDR nfGenMsg;
>+};
> OVS_HDR ovsHdr;
> /* Variable length nl_attrs follow. */
> } OVS_MESSAGE, *POVS_MESSAGE;
>+BUILD_ASSERT_DECL(sizeof(GENL_MSG_HDR) == sizeof(NF_GEN_MSG_HDR));
> 
> /*
>  * Structure of an error message sent as a reply from kernel.
>@@ -107,6 +111,7 @@ PCHAR NlHdrPayload(const PNL_MSG_HDR nlh);
> UINT32 NlHdrPayloadLen(const PNL_MSG_HDR nlh);
> PNL_ATTR NlMsgAttrs(const PNL_MSG_HDR nlh);
> UINT32 NlMsgAttrsLen(const PNL_MSG_HDR nlh);
>+UINT32 NlNfMsgAttrsLen(const PNL_MSG_HDR nlh);
> 
> /* Netlink message parse */
> PNL_MSG_HDR NlMsgNext(const PNL_MSG_HDR nlh);
>@@ -135,7 +140,7 @@ const PNL_ATTR NlAttrFindNested(const PNL_ATTR nla,
> UINT16 type);
> BOOLEAN NlAttrParse(const PNL_MSG_HDR nlMsg, UINT32 attrOffset,
> UINT32 totalAttrLen, const NL_POLICY policy[],
>-const UINT32 numPolicy, PNL_ATTR attrs[],
>+const UINT32 numPolicy, PNL_ATTR attrs[],
> UINT32 numAttrs);
> BOOLEAN NlAttrParseNested(const PNL_MSG_HDR nlMsg, UINT32 attrOffset,
>   UINT32 totalAttrLen, const NL_POLICY policy[],
>diff --git a/datapath-windows/ovsext/Netlink/NetlinkProto.h
>b/datapath-windows/ovsext/Netlink/NetlinkProto.h
>index f2e9aee..beb14d5 100644
>--- a/datapath-windows/ovsext/Netlink/NetlinkProto.h
>+++ b/datapath-windows/ovsext/Netlink/NetlinkProto.h
>@@ -98,6 +98,14 @@ typedef struct _GENL_MSG_HDR {
> } GENL_MSG_HDR, *PGENL_MSG_HDR;
> BUILD_ASSERT_DECL(sizeof(GENL_MSG_HDR) == 4);
> 
>+/* Netfilter Generic Message */
>+typedef struct _NF_GEN_MSG_HDR {
>+UINT8 nfgenFamily;   /* AF_xxx */
>+UINT8 version;   /* nfnetlink version */
>+UINT16 resId;/* resource id */
>+} NF_GEN_MSG_HDR, *PNF_GEN_MSG_HDR;
>+BUILD_ASSERT_DECL(sizeof(NF_GEN_MSG_HDR) == 4);
>+
> /* Netlink attributes */
> typedef struct _NL_ATTR {
> UINT16 nlaLen;
>@@ -113,6 +121,7 @@ BUILD_ASSERT_DECL(sizeof(NL_ATTR) == 4);
> 
> #define NLMSG_HDRLEN ((INT) NLMSG_ALIGN(sizeof(NL_MSG_HDR)))
> #define GENL_HDRLEN NLMSG_ALIGN(sizeof(GENL_MSG_HDR))
>+#define NF_GEN_MSG_HDRLEN NLMSG_ALIGN(sizeof(NF_GEN_MSG_HDR))
> #define OVS_HDRLEN NLMSG_ALIGN(sizeof(OVS_HDR))
> #define NLA_HDRLEN ((INT) NLA_ALIGN(sizeof(NL_ATTR)))
> 
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=ZzkqjQjg3Q4DbWawhwkkaFTLf9amIl
>DsFBztOwnvRao=_u5VachrMIJPE-v7lSRJ15LmzK30ZAk4Rmmd9qLW2MI= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 01/11] Windows: Add conntrack netfilter netlink definitions to kernel and userspace

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Wednesday, June 29, 2016 at 5:08 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4 01/11] Windows: Add conntrack netfilter
netlink definitions to kernel and userspace

>Include netfilter-conntrack header definitions. This will be used by
>Windows userspace for adding debugging support in Conntrack. Few of these
>files are intentionally left blank to avoid removing #includes in
>userspace. New file - OvsDpInterfaceCtExt.h has been defined similar to
>OvsDpInterfaceExt.h to be reused by userspace and kernel.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>---
> build-aux/extract-odp-netlink-h|   1 +
> datapath-windows/automake.mk   |   1 +
> datapath-windows/include/OvsDpInterfaceCtExt.h | 423
>+
> datapath-windows/ovsext/ovsext.vcxproj |   1 +
> datapath-windows/ovsext/precomp.h  |   1 +
> include/windows/automake.mk|   6 +
> .../windows/linux/netfilter/nf_conntrack_common.h  |   0
> include/windows/linux/netfilter/nf_conntrack_ftp.h |   0
> .../windows/linux/netfilter/nf_conntrack_sctp.h|   0
> include/windows/linux/netfilter/nf_conntrack_tcp.h |   0
> include/windows/linux/netfilter/nfnetlink.h|   0
> .../windows/linux/netfilter/nfnetlink_conntrack.h  |   0
> 12 files changed, 433 insertions(+)
> create mode 100644 datapath-windows/include/OvsDpInterfaceCtExt.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_common.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_ftp.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_sctp.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_tcp.h
> create mode 100644 include/windows/linux/netfilter/nfnetlink.h
> create mode 100644 include/windows/linux/netfilter/nfnetlink_conntrack.h
>
>diff --git a/build-aux/extract-odp-netlink-h
>b/build-aux/extract-odp-netlink-h
>index aafe69a..111c5cb 100755
>--- a/build-aux/extract-odp-netlink-h
>+++ b/build-aux/extract-odp-netlink-h
>@@ -18,6 +18,7 @@ s/_LINUX_OPENVSWITCH_H/ODP_NETLINK_H/
> $i\
> #ifdef _WIN32\
> #include "OvsDpInterfaceExt.h"\
>+#include "OvsDpInterfaceCtExt.h"\
> #endif\
> 
> # Use OVS's own struct eth_addr instead of a 6-byte char array.
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index 668cf2c..c34934b 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -4,6 +4,7 @@ EXTRA_DIST += \
>   datapath-windows/Package/package.VcxProj \
>   datapath-windows/Package/package.VcxProj.user \
>   datapath-windows/include/OvsDpInterfaceExt.h \
>+  datapath-windows/include/OvsDpInterfaceCtExt.h \
>   datapath-windows/misc/OVS.psm1 \
>   datapath-windows/misc/install.cmd \
>   datapath-windows/misc/uninstall.cmd \
>diff --git a/datapath-windows/include/OvsDpInterfaceCtExt.h
>b/datapath-windows/include/OvsDpInterfaceCtExt.h
>new file mode 100644
>index 000..2795edc
>--- /dev/null
>+++ b/datapath-windows/include/OvsDpInterfaceCtExt.h
>@@ -0,0 +1,423 @@
>+/*
>+ * Copyright (c) 2016 VMware, Inc.
>+ *
>+ * Licensed under the Apache License, Version 2.0 (the "License");
>+ * you may not use this file except in compliance with the License.
>+ * You may obtain a copy of the License at:
>+ *
>+ * 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_license
>s_LICENSE-2D2.0=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=p
>NHQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=1pUfCWy4l0NuhIqJSNKiI4fLJGLXq
>rlJ9N1QEIxd9mk=pnCUJGnWFBH4mx0yAcuM-X4vygzcG4NVBp9TKV1sADE=
>+ *
>+ * Unless required by applicable law or agreed to in writing, software
>+ * distributed under the License is distributed on an "AS IS" BASIS,
>+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>implied.
>+ * See the License for the specific language governing permissions and
>+ * limitations under the License.
>+ */
>+
>+#ifndef __OVS_DP_INTERFACE_CT_EXT_H_
>+#define __OVS_DP_INTERFACE_CT_EXT_H_ 1
>+
>+/* Conntrack Netlink headers */
>+#define NFNL_TYPE_CT_GET (NFNL_SUBSYS_CTNETLINK << 8 | IPCTNL_MSG_CT_GET)
>+#define NFNL_TYPE_CT_DEL (NFNL_SUBSYS_CTNETLINK << 8 |
>IPCTNL_MSG_CT_DELETE)
>+#define IS_NFNL_CMD(nlmsgType) ((nlmsgType == NFNL_TYPE_CT_GET) \
>+ || (nlmsgType == NFNL_TYPE_CT_DEL))
>+#define OVS_NL_CT_ATTR_MAX (IPCTNL_MSG_MAX - 1)
>+
&g

Re: [ovs-dev] [PATCH] datapath-windows: Cleanup conntrack-tcp.c

[Nithin Raju]

>>On 6/24/16, 6:14 PM, "Sairam Venugopal" <vsai...@vmware.com> wrote:
>>
>>>Update the code to use tcp->flags. This keeps the kernel conntrack-tcp.c
>>>file in sync with userspace version.
>>>
>>>This patch also addresses an warning - 'Comparison of a boolean
>>>expression with an integer other than 0 or 1' - (tcp_flags &
>>>(TCP_ACK|TCP_RST)) == (TCP_ACK|TCP_RST))
>>>
>>>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>
>>>@@ -232,31 +226,33 @@ OvsConntrackUpdateTcpEntry(OVS_CT_ENTRY* conn_,
>>> /* The peer that should receive 'pkt' */
>>> struct tcp_peer *dst = >peer[reply ? 0 : 1];
>>> uint8_t sws = 0, dws = 0;
>>>+UINT16 tcp_flags = tcp->flags;
>>> uint16_t win = ntohs(tcp->window);
>>> uint32_t ack, end, seq, orig_seq;
>>> uint32_t p_len = OvsGetTcpPayloadLength(nbl);
>>> int ackskew;
>>> 
>>>-if (OvsConntrackValidateTcpFlags(tcp)) {
>>>+if (OvsCtInvalidTcpFlags(tcp->flags)) {
>>> return CT_UPDATE_INVALID;
>>> }
>>> 
>>>-if ((tcp->syn) && dst->state >= CT_DPIF_TCPS_FIN_WAIT_2 &&
>>>-src->state >= CT_DPIF_TCPS_FIN_WAIT_2) {
>>>+if (((tcp_flags & (TCP_SYN|TCP_ACK)) == TCP_SYN)
>
>Why do we need to include TCP_ACK in the check?

We spoke offline. This is a bug fix.

Acked-by: Nithin Raju <nit...@vmware.com>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Cleanup conntrack-tcp.c

[Nithin Raju]

Looks good but for a comment.

Acked-by: Nithin Raju <nit...@vmware.com>

>On 6/24/16, 6:14 PM, "Sairam Venugopal" <vsai...@vmware.com> wrote:
>
>>Update the code to use tcp->flags. This keeps the kernel conntrack-tcp.c
>>file in sync with userspace version.
>>
>>This patch also addresses an warning - 'Comparison of a boolean
>>expression with an integer other than 0 or 1' - (tcp_flags &
>>(TCP_ACK|TCP_RST)) == (TCP_ACK|TCP_RST))
>>
>>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>

>>@@ -232,31 +226,33 @@ OvsConntrackUpdateTcpEntry(OVS_CT_ENTRY* conn_,
>> /* The peer that should receive 'pkt' */
>> struct tcp_peer *dst = >peer[reply ? 0 : 1];
>> uint8_t sws = 0, dws = 0;
>>+UINT16 tcp_flags = tcp->flags;
>> uint16_t win = ntohs(tcp->window);
>> uint32_t ack, end, seq, orig_seq;
>> uint32_t p_len = OvsGetTcpPayloadLength(nbl);
>> int ackskew;
>> 
>>-if (OvsConntrackValidateTcpFlags(tcp)) {
>>+if (OvsCtInvalidTcpFlags(tcp->flags)) {
>> return CT_UPDATE_INVALID;
>> }
>> 
>>-if ((tcp->syn) && dst->state >= CT_DPIF_TCPS_FIN_WAIT_2 &&
>>-src->state >= CT_DPIF_TCPS_FIN_WAIT_2) {
>>+if (((tcp_flags & (TCP_SYN|TCP_ACK)) == TCP_SYN)

Why do we need to include TCP_ACK in the check?


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 9/9] datapath-windows: Add support for Conntrack IPCTNL_MSG_CT_GET cmd in Datapath.c

[Nithin Raju]

-Original Message-
From: dev  on behalf of Sairam Venugopal

Date: Friday, June 24, 2016 at 12:03 PM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH v3 9/9] datapath-windows: Add support
for Conntrack IPCTNL_MSG_CT_GET cmd in Datapath.c

>This will be used by userspace for dumping conntrack entries - "ovs-dpctl
>dump-conntrack".
>
>Signed-off-by: Sairam Venugopal 
>---
> datapath-windows/ovsext/Datapath.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Datapath.c
>b/datapath-windows/ovsext/Datapath.c
>index 7cc8390..5cc0614 100644
>--- a/datapath-windows/ovsext/Datapath.c
>+++ b/datapath-windows/ovsext/Datapath.c
>@@ -104,7 +104,8 @@ NetlinkCmdHandlerOvsGetNetdevCmdHandler,
>  OvsPendPacketCmdHandler,
>  OvsSubscribePacketCmdHandler,
>  OvsReadPacketCmdHandler,
>- OvsCtDeleteCmdHandler;
>+ OvsCtDeleteCmdHandler,
>+ OvsCtDumpCmdHandler;
> 
> static NTSTATUS HandleGetDpTransaction(POVS_USER_PARAMS_CONTEXT
>usrParamsCtx,
>UINT32 *replyLen);
>@@ -288,7 +289,13 @@ NETLINK_CMD nlCtFamilyCmdOps[] = {
> { .cmd  = IPCTNL_MSG_CT_DELETE,
>   .handler  = OvsCtDeleteCmdHandler,
>   .supportedDevOp   = OVS_TRANSACTION_DEV_OP,
>-  .validateDpIndex  = TRUE
>+  .validateDpIndex  = FALSE
>+},
>+{ .cmd  = IPCTNL_MSG_CT_GET,
>+  .handler  = OvsCtDumpCmdHandler,
>+  .supportedDevOp   = OVS_TRANSACTION_DEV_OP |
>+  OVS_WRITE_DEV_OP | OVS_READ_DEV_OP,
>+  .validateDpIndex  = FALSE

In 7/9, it does not look like we handle OVS_TRANSACTION_DEV_OP.

How is IPCTNL_MSG_CT_GET invoked? If nl_transact() is not used, there¹s no
transaction. If we need to support transaction semantics, you¹ll have to
write a slightly different function to do a lookup and then return the
value.

‹ Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 8/9] datapath-windows: Conntrack - Handle memory allocation failure

[Nithin Raju]

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, June 24, 2016 at 12:03 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v3 8/9] datapath-windows: Conntrack -
Handle  memory allocation failure

>Return null if Windows fails to allocate memory for the conntrack entry.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>

Acked-by: Nithin Raju <nit...@vmware.com

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 7/9] datapath-windows: Add support for dump-conntrack in datapath

[Nithin Raju]

Looks good but for a few comments.

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, June 24, 2016 at 12:03 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v3 7/9] datapath-windows: Add support
for dump-conntrack in datapath

>Create the methods used for dumping conntrack entries from the hyper-v
>datapath to userspace by means of netfilter netlink messages. Some of the
>attributes are not supported by the datapath and have been defaulted to 0.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>---
> datapath-windows/ovsext/Conntrack-tcp.c |  59 +
> datapath-windows/ovsext/Conntrack.c | 447
>+++-
> datapath-windows/ovsext/Conntrack.h |   5 +
> datapath-windows/ovsext/Util.h  |   4 +
> 4 files changed, 512 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack-tcp.c
>b/datapath-windows/ovsext/Conntrack-tcp.c
>index 19925c3..1d60323 100644
>--- a/datapath-windows/ovsext/Conntrack-tcp.c
>+++ b/datapath-windows/ovsext/Conntrack-tcp.c
>@@ -523,3 +523,62 @@ OvsConntrackCreateTcpEntry(const TCPHdr *tcp,
> 
> return >up;
> }
>+
>+static __inline uint8_t
>+OvsCtTcpPeerToProtoInfoFlags(const struct tcp_peer *peer)
>+{
>+uint8_t res = 0;
>+
>+if (peer->wscale & CT_WSCALE_FLAG) {
>+res |= CT_DPIF_TCPF_WINDOW_SCALE;
>+}
>+
>+if (peer->wscale & CT_WSCALE_UNKNOWN) {
>+res |= CT_DPIF_TCPF_BE_LIBERAL;
>+}
>+
>+return res;
>+}
>+
>+NDIS_STATUS
>+OvsCtMapTcpProtoInfoToNl(PNL_BUFFER nlBuf, OVS_CT_ENTRY *conn_)
>+{
>+struct conn_tcp *conn = OvsCastConntrackEntryToTcpEntry(conn_);
>+NDIS_STATUS status = NDIS_STATUS_SUCCESS;
>+UINT32 offset = 0;
>+
>+offset = NlMsgStartNested(nlBuf, CTA_PROTOINFO_TCP);
>+if (!offset) {
>+return NDIS_STATUS_FAILURE;
>+}
>+
>+if (!NlMsgPutTailU8(nlBuf, CTA_PROTOINFO_TCP_STATE,
>+conn->peer[0].state)) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU8(nlBuf, CTA_PROTOINFO_TCP_WSCALE_ORIGINAL,
>+(conn->peer[0].wscale & CT_WSCALE_MASK))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU8(nlBuf, CTA_PROTOINFO_TCP_WSCALE_REPLY,
>+(conn->peer[1].wscale & CT_WSCALE_MASK))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU16(nlBuf, CTA_PROTOINFO_TCP_FLAGS_ORIGINAL,
>+ OvsCtTcpPeerToProtoInfoFlags(>peer[0]))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+if (!NlMsgPutTailU16(nlBuf, CTA_PROTOINFO_TCP_FLAGS_REPLY,
>+ OvsCtTcpPeerToProtoInfoFlags(>peer[1]))) {
>+status = NDIS_STATUS_FAILURE;
>+goto done;
>+}
>+
>+done:
>+NlMsgEndNested(nlBuf, offset);
>+return status;
>+}
>diff --git a/datapath-windows/ovsext/Conntrack.c
>b/datapath-windows/ovsext/Conntrack.c
>index 15c495d..ebfdeef 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -24,6 +24,10 @@
> #include "PacketParser.h"
> #include "Debug.h"
> 
>+#define WINDOWS_TICK 1000
>+#define SEC_TO_UNIX_EPOCH 11644473600LL
>+#define SEC_TO_NANOSEC 10LL
>+
> typedef struct _OVS_CT_THREAD_CTX {
> KEVENT  event;
> PVOID   threadObject;
>@@ -34,6 +38,7 @@ KSTART_ROUTINE ovsConntrackEntryCleaner;
> static PLIST_ENTRY ovsConntrackTable;
> static OVS_CT_THREAD_CTX ctThreadCtx;
> static PNDIS_RW_LOCK_EX ovsConntrackLockObj;
>+extern POVS_SWITCH_CONTEXT gOvsSwitchContext;
> 
> /*
>  
>*-
>---
>@@ -147,11 +152,12 @@ OvsCtUpdateFlowKey(struct OvsFlowKey *key,
> }
> 
> static __inline VOID
>-OvsCtAddEntry(POVS_CT_ENTRY entry, OvsConntrackKeyLookupCtx *ctx)
>+OvsCtAddEntry(POVS_CT_ENTRY entry, OvsConntrackKeyLookupCtx *ctx, UINT64
>now)
> {
> NdisMoveMemory(>key, >key, sizeof (OVS_CT_KEY));
> NdisMoveMemory(>rev_key, >key, sizeof (OVS_CT_KEY));
> OvsCtKeyReverse(>rev_key);
>+entry->timestampStart = now;
> InsertHeadList([ctx->hash & CT_HASH_TABLE_MASK],
>>link);
> }
>@@ -181,7 +187,10 @@ OvsCtEntryCreate(PNET_B

Re: [ovs-dev] [PATCH v3 6/9] datapath-windows: Add new NlFillOvsMsgForNfGenMsg method in Netlink.c

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, June 24, 2016 at 12:03 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v3 6/9] datapath-windows: Add
new NlFillOvsMsgForNfGenMsg method in Netlink.c

>Create a new method to create and fill OvsMessage with NfGenMsg. This will
>be used for sending Netfilter based Netlink messages.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 5/9] Windows: Add conntrack-flush support in userspace

[Nithin Raju]

Just one suggestion, but looks good otherwise.

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, June 24, 2016 at 12:03 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v3 5/9] Windows: Add conntrack-flush support
in  userspace

>Modify dpif-netlink.c and netlink-conntrack.c to send down flush command
>to Windows datapath. Include netlink-conntrack.c and netlink-conntrack.h
>in automake.mk for Windows binaries.
>
>Windows currently supports only NETLINK_GENERIC port. In order to support
>the NETLINK_NETFILTER messages, the port id is being overwritten to
>NETLINK_GENERIC on Windows and datapath has been updated to support the
>new message format.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>


>diff --git a/lib/netlink-conntrack.c b/lib/netlink-conntrack.c
>index 47a3c62..799887d 100644
>--- a/lib/netlink-conntrack.c
>+++ b/lib/netlink-conntrack.c
>@@ -75,6 +75,13 @@ static struct vlog_rate_limit rl =
>VLOG_RATE_LIMIT_INIT(1, 5);
> #define IPS_UNTRACKED_BIT 12
> #define IPS_UNTRACKED (1 << IPS_UNTRACKED_BIT)
> 
>+#ifdef _WIN32
>+#ifdef NETLINK_NETFILTER
>+#undef NETLINK_NETFILTER
>+#endif
>+#define NETLINK_NETFILTER   NETLINK_GENERIC /* Override for Windows
>*/
>+#endif

Might be helpful to document the reason also since it is a design
decision. Basically, we use the same sockets for nfgenmsg and genlmsghdr
messages.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 4/9] datapath-windows: Add support for Conntrack IPCTNL_MSG_CT_DELETE cmd in Datapath.c

[Nithin Raju]

Looks good but for a couple of suggestions.

>/* Windows kernel datapath extensions to the standard datapath interface.
>*/
> 
> /* Version number of the datapath interface extensions. */
>@@ -65,6 +68,7 @@
> #define OVS_WIN_NL_VPORT_FAMILY_ID   (NLMSG_MIN_TYPE + 4)
> #define OVS_WIN_NL_FLOW_FAMILY_ID(NLMSG_MIN_TYPE + 5)
> #define OVS_WIN_NL_NETDEV_FAMILY_ID  (NLMSG_MIN_TYPE + 6)
>+#define OVS_WIN_NL_CT_FAMILY_ID  (NLMSG_MIN_TYPE + 7)
> 
> #define OVS_WIN_NL_INVALID_MCGRP_ID  0
> #define OVS_WIN_NL_MCGRP_START_ID100
>@@ -156,4 +160,17 @@ enum ovs_win_netdev_attr {
> typedef struct ovs_dp_stats OVS_DP_STATS;
> typedef enum ovs_vport_type OVS_VPORT_TYPE;
> 
>+/* Conntrack Netlink */
>+#define NFNL_TYPE_CT_GET (NFNL_SUBSYS_CTNETLINK << 8 | IPCTNL_MSG_CT_GET)
>+#define NFNL_TYPE_CT_DEL (NFNL_SUBSYS_CTNETLINK << 8 |
>IPCTNL_MSG_CT_DELETE)
>+#define NFNL_SUBSYSTEM_TYPE(nlmsgType) (nlmsgType >> 8)
>+#define NFNL_CT_CMD(nlmsgType) (nlmsgType & 0xff)
>+#define IS_NFNL_CMD(nlmsgType) ((nlmsgType == NFNL_TYPE_CT_GET) ||
>(nlmsgType == NFNL_TYPE_CT_DEL))
>+#define OVS_NL_CT_ATTR_MAX (IPCTNL_MSG_MAX - 1)

This will probably change with the discussion we are having about where
the netlink defines should go to. If we decide to go with an approach of
OvsDpInterfaceCtExt.h, it would be nice to put these in enums, with
comments around them.

The only thing we need to be careful about adding code in any of the
OvsDpInterface*h. is that we¹ll be stuck with it for the foreseeable
future. We¹ll always have to make future code adhere to this interface.

> /* Netlink netdev family. */
> NETLINK_CMD nlNetdevFamilyCmdOps[] = {
> { .cmd = OVS_WIN_NETDEV_CMD_GET,
>@@ -885,6 +904,9 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
> 
> ASSERT(ovsMsg);
> switch (ovsMsg->nlMsg.nlmsgType) {
>+case NFNL_TYPE_CT_DEL:
>+nlFamilyOps = 
>+break;
> case OVS_WIN_NL_CTRL_FAMILY_ID:
> nlFamilyOps = 
> break;
>@@ -961,6 +983,30 @@ ValidateNetlinkCmd(UINT32 devOp,
> goto done;
> }
> 
>+/*
>+Verify if the Netlink message is part of Netfilter Netlink
>+This is currently used by Conntrack
>+*/

minor: comment styling should be:
/*
 *
 *
 */
>@@ -1022,14 +1068,29 @@ InvokeNetlinkCmdHandler(POVS_USER_PARAMS_CONTEXT
>usrParamsCtx,
> NTSTATUS status = STATUS_INVALID_PARAMETER;
> UINT16 i;
> 
>-for (i = 0; i < nlFamilyOps->opsCount; i++) {
>-if (nlFamilyOps->cmds[i].cmd ==
>usrParamsCtx->ovsMsg->genlMsg.cmd) {
>-NetlinkCmdHandler *handler = nlFamilyOps->cmds[i].handler;
>-ASSERT(handler);
>-if (handler) {
>-status = handler(usrParamsCtx, replyLen);
>+if (IS_NFNL_CMD(usrParamsCtx->ovsMsg->nlMsg.nlmsgType)) {
>+/* If nlMsg is of type Netfilter-Netlink parse the Cmd
>accordingly */
>+UINT8 cmd = NFNL_CT_CMD(usrParamsCtx->ovsMsg->nlMsg.nlmsgType);
>+for (i = 0; i < nlFamilyOps->opsCount; i++) {
>+if (nlFamilyOps->cmds[i].cmd == cmd) {
>+NetlinkCmdHandler *handler =
>nlFamilyOps->cmds[i].handler;
>+ASSERT(handler);
>+if (handler) {
>+status = handler(usrParamsCtx, replyLen);
>+}
>+break;
>+}
>+}
>+} else {
>+for (i = 0; i < nlFamilyOps->opsCount; i++) {
>+if (nlFamilyOps->cmds[i].cmd ==
>usrParamsCtx->ovsMsg->genlMsg.cmd) {
>+NetlinkCmdHandler *handler =
>nlFamilyOps->cmds[i].handler;
>+ASSERT(handler);
>+if (handler) {
>+status = handler(usrParamsCtx, replyLen);
>+}
>+break;
> }
>-break;
> }

Suggestion:
This code could be refactored:
if (NF) {
  cmd = xx;
} else {
  cmd = usrParamsCtx->ovsMsg->genlMsg.cmd;
}

for (i = 0; i < nlFamilyOps->opsCount; i++) {
if (nlFamilyOps->cmds[i].cmd == usrParamsCtx->ovsMsg->genlMsg.cmd) {
[Š]


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 1/9] Windows: Add netfilter-conntrack header files to Include folder

[Nithin Raju]

>On Mon, Jun 27, 2016 at 11:57 AM, Nithin Raju <nit...@vmware.com> wrote:
>> Only comment is to add the OVS license on top of each non-empty file.
>> Looks like the original code does not have any licence, but it would
>>still
>> make sense to add a license I think. Looks good otherwise,
>> Acked-by: Nithin Raju <nit...@vmware.com>
>>
>> Ben or Jesse can confirm what the best practice is.
>
>Well, these files came from the Linux kernel so the copyright on them
>is GPL and I don't think that we should be importing them into OVS
>wholesale. Using the actual values should be fine but other things -
>particularly the comments - likely is not.

Jesse,
Even the code in linux kernel does not have a license:
https://github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/
nfnetlink_conntrack.h


This seems to be true for netfilter code.

>In other places for OVS, including Windows, we have clean netlink
>definitions inside of OVS header files. I think that would be the best
>course for this as well.

If we replicate the definitions, it would probably be a verbatim
replication with some cleanup. Is that the approach you are suggesting?
Something like what netlink.c/h is doing in OVS userspace?

Thanks,
-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 3/9] datapath-windows: Add support for flushing conntrack entries

[Nithin Raju]

CTA_ZONE is not defined yet, and I see it is defined in 4/9.


Don¹t you have to return anything upon success in OvsCtDeleteCmdHandler().
The operation type is a OVS_TRANSACTION_DEV_OP. See Flow.c for example:
https://github.com/openvswitch/ovs/blob/master/datapath-windows/ovsext/Flow
.c#L301

-- Nithin

-Original Message-
From: dev  on behalf of Sairam Venugopal

Date: Friday, June 24, 2016 at 12:03 PM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH v3 3/9] datapath-windows: Add support for
flushingconntrack entries

>Flush out all conntrack entries or those that match a given zone. Since
>the conntrack module is internal to OVS in Windows, this functionality
>needs to be added in.
>
>Signed-off-by: Sairam Venugopal 
>Acked-by: Paul-Daniel Boca 
>---
> datapath-windows/ovsext/Conntrack.c | 75
>+
> 1 file changed, 75 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c
>b/datapath-windows/ovsext/Conntrack.c
>index 5fc9282..15c495d 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -624,3 +624,78 @@ ovsConntrackEntryCleaner(PVOID data)
> 
> PsTerminateSystemThread(STATUS_SUCCESS);
> }
>+
>+/*
>+ 
>*-
>---
>+ * OvsCtFlush
>+ * Flushes out all Conntrack Entries that match the given zone
>+ 
>*-
>---
>+ */
>+static __inline NDIS_STATUS
>+OvsCtFlush(UINT16 zone)
>+{
>+PLIST_ENTRY link, next;
>+POVS_CT_ENTRY entry;
>+
>+LOCK_STATE_EX lockState;
>+NdisAcquireRWLockWrite(ovsConntrackLockObj, , 0);
>+
>+for (int i = 0; i < CT_HASH_TABLE_SIZE; i++) {
>+LIST_FORALL_SAFE([i], link, next) {
>+entry = CONTAINING_RECORD(link, OVS_CT_ENTRY, link);
>+if (!zone || zone == entry->key.zone)
>+OvsCtEntryDelete(entry);
>+}
>+}
>+
>+NdisReleaseRWLock(ovsConntrackLockObj, );
>+return NDIS_STATUS_SUCCESS;
>+}
>+
>+NTSTATUS
>+OvsCtDeleteCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
>+  UINT32 *replyLen)
>+{
>+POVS_MESSAGE msgIn = (POVS_MESSAGE)usrParamsCtx->inputBuffer;
>+PNL_MSG_HDR nlMsgHdr = &(msgIn->nlMsg);
>+PNL_ATTR ctAttrs[__CTA_MAX];
>+UINT32 attrOffset = NLMSG_HDRLEN + NF_GEN_MSG_HDRLEN + OVS_HDRLEN;
>+NL_ERROR nlError = NL_ERROR_SUCCESS;
>+NTSTATUS status;
>+UINT16 zone = 0;
>+
>+static const NL_POLICY ctZonePolicy[] = {
>+[CTA_ZONE] = { .type = NL_A_BE16, .optional = TRUE },
>+};
>+
>+if ((NlAttrParse(nlMsgHdr, attrOffset, NfNlMsgAttrsLen(nlMsgHdr),
>+ctZonePolicy, ARRAY_SIZE(ctZonePolicy),
>+ctAttrs, ARRAY_SIZE(ctAttrs)))
>+!= TRUE) {
>+OVS_LOG_ERROR("Zone attr parsing failed for msg: %p", nlMsgHdr);
>+status = STATUS_INVALID_PARAMETER;
>+goto done;
>+}
>+
>+if (ctAttrs[CTA_ZONE]) {
>+zone = NlAttrGetU16(ctAttrs[CTA_ZONE]);
>+}
>+
>+status = OvsCtFlush(zone);
>+
>+done:
>+if (status) {
>+nlError = NlMapStatusToNlErr(status);
>+}
>+if (nlError != NL_ERROR_SUCCESS) {
>+POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
>+   usrParamsCtx->outputBuffer;
>+
>+ASSERT(msgError);
>+NlBuildErrorMsg(msgIn, msgError, nlError, replyLen);
>+ASSERT(*replyLen != 0);
>+status = STATUS_SUCCESS;
>+}
>+
>+return status;
>+}
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=sDVTDLzIeFV8CdglHvFqzyKhA4D5UY
>7yjpBedaeSPVs=_p8ReK6W74YrArXBrNwcGs8vk_DSWMGS5Vbd6mfmXic= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 2/9] datapath-windows: Add support for Netfilter netlink message

[Nithin Raju]

A couple of minor comments, but looks good otherwise.

Acked-by: Nithin Raju <nit...@vmware.com>


>+/*
>+ * 
>--
>-
>+ * Returns size of to nfnlmsg attributes.
>+ * 
>--
>-
>+ */
>+UINT32
>+NfNlMsgAttrsLen(const PNL_MSG_HDR nlh)

NlNfMsgAttrsLen() might be a more suitable name, given that all of the
other functions in that file start with Nlxxx.

>+{
>+return NlHdrPayloadLen(nlh) - NF_GEN_MSG_HDRLEN - OVS_HDRLEN;
>+}
>+
> /* Netlink message parse. */
> 
> /*
>diff --git a/datapath-windows/ovsext/Netlink/Netlink.h
>b/datapath-windows/ovsext/Netlink/Netlink.h
>index b1b3bed..cce7ec3 100644
>--- a/datapath-windows/ovsext/Netlink/Netlink.h
>+++ b/datapath-windows/ovsext/Netlink/Netlink.h
>@@ -27,7 +27,10 @@
>  */
> typedef struct _OVS_MESSAGE {
> NL_MSG_HDR nlMsg;
>-GENL_MSG_HDR genlMsg;
>+union {
>+GENL_MSG_HDR genlMsg;
>+NF_GEN_MSG_HDR nfGenMsg;
>+};

Can you pls. BUILD_ASSERT(sizeof (GENL_MSG_HDR) == sizeof
(NF_GEN_MSG_HDR))?

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 1/9] Windows: Add netfilter-conntrack header files to Include folder

[Nithin Raju]

Only comment is to add the OVS license on top of each non-empty file.
Looks like the original code does not have any licence, but it would still
make sense to add a license I think. Looks good otherwise,
Acked-by: Nithin Raju <nit...@vmware.com>

Ben or Jesse can confirm what the best practice is.

Thanks,
-- Nithin



-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
<vsai...@vmware.com>
Date: Friday, June 24, 2016 at 12:03 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v3 1/9] Windows: Add netfilter-conntrack
header  files to Include folder

>Include netfilter-conntrack header files in user-space. This will be used
>by Windows userspace for adding debugging support in Conntrack. Some of
>these files
>are intentionally left blank and will be updated once relevant support is
>added in Windows datapath.
>
>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>
>Acked-by: Paul-Daniel Boca <pb...@cloudbasesolutions.com>
>---
> include/windows/automake.mk|   6 +
> .../windows/linux/netfilter/nf_conntrack_common.h  | 113 ++
> include/windows/linux/netfilter/nf_conntrack_ftp.h |   0
> .../windows/linux/netfilter/nf_conntrack_sctp.h|   0
> include/windows/linux/netfilter/nf_conntrack_tcp.h |  49 
> include/windows/linux/netfilter/nfnetlink.h|  63 ++
> .../windows/linux/netfilter/nfnetlink_conntrack.h  | 249
>+
> 7 files changed, 480 insertions(+)
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_common.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_ftp.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_sctp.h
> create mode 100644 include/windows/linux/netfilter/nf_conntrack_tcp.h
> create mode 100644 include/windows/linux/netfilter/nfnetlink.h
> create mode 100644 include/windows/linux/netfilter/nfnetlink_conntrack.h
>
>diff --git a/include/windows/automake.mk b/include/windows/automake.mk
>index 58b52f1..382627b 100644
>--- a/include/windows/automake.mk
>+++ b/include/windows/automake.mk
>@@ -9,6 +9,12 @@ noinst_HEADERS += \
>   include/windows/arpa/inet.h \
>   include/windows/dirent.h \
>   include/windows/getopt.h \
>+  include/windows/linux/netfilter/nf_conntrack_common.h \
>+  include/windows/linux/netfilter/nf_conntrack_ftp.h \
>+  include/windows/linux/netfilter/nf_conntrack_sctp.h \
>+  include/windows/linux/netfilter/nf_conntrack_tcp.h \
>+  include/windows/linux/netfilter/nfnetlink.h \
>+  include/windows/linux/netfilter/nfnetlink_conntrack.h \
>   include/windows/linux/pkt_sched.h \
>   include/windows/linux/types.h \
>   include/windows/net/if.h \
>diff --git a/include/windows/linux/netfilter/nf_conntrack_common.h
>b/include/windows/linux/netfilter/nf_conntrack_common.h
>new file mode 100644
>index 000..9904003
>--- /dev/null
>+++ b/include/windows/linux/netfilter/nf_conntrack_common.h
>@@ -0,0 +1,113 @@
>+#ifndef _NF_CONNTRACK_COMMON_H
>+#define _NF_CONNTRACK_COMMON_H
>+/* Connection state tracking for netfilter.  This is separated from,
>+   but required by, the NAT layer; it can also be used by an iptables
>+   extension. */
>+enum ip_conntrack_info {
>+/* Part of an established connection (either direction). */
>+IP_CT_ESTABLISHED,
>+
>+/* Like NEW, but related to an existing connection, or ICMP error
>+   (in either direction). */
>+IP_CT_RELATED,
>+
>+/* Started a new connection to track (only
>+   IP_CT_DIR_ORIGINAL); may be a retransmission. */
>+IP_CT_NEW,
>+
>+/* >= this indicates reply direction */
>+IP_CT_IS_REPLY,
>+
>+IP_CT_ESTABLISHED_REPLY = IP_CT_ESTABLISHED + IP_CT_IS_REPLY,
>+IP_CT_RELATED_REPLY = IP_CT_RELATED + IP_CT_IS_REPLY,
>+IP_CT_NEW_REPLY = IP_CT_NEW + IP_CT_IS_REPLY,
>+/* Number of distinct IP_CT types (no NEW in reply dirn). */
>+IP_CT_NUMBER = IP_CT_IS_REPLY * 2 - 1
>+};
>+
>+/* Bitset representing status of connection. */
>+enum ip_conntrack_status {
>+/* It's an expected connection: bit 0 set.  This bit never changed */
>+IPS_EXPECTED_BIT = 0,
>+IPS_EXPECTED = (1 << IPS_EXPECTED_BIT),
>+
>+/* We've seen packets both ways: bit 1 set.  Can be set, not unset.
>*/
>+IPS_SEEN_REPLY_BIT = 1,
>+IPS_SEEN_REPLY = (1 << IPS_SEEN_REPLY_BIT),
>+
>+/* Conntrack should never be early-expired. */
>+IPS_ASSURED_BIT = 2,
>+IPS_ASSURED = (1 << IPS_ASSURED_BIT),
>+
>+/* Connection is confirmed: originating packet has left box */
>+IPS_CONFIRMED_BIT = 3,
>+IPS_CONFIRMED = 

Re: [ovs-dev] [PATCH] datapath-windows: Conntrack - Fix variable initialization

[Nithin Raju]

>>-Original Message-
>>From: dev <dev-boun...@openvswitch.org> on behalf of Sairam Venugopal
>><vsai...@vmware.com>
>>Date: Friday, June 24, 2016 at 6:16 PM
>>To: "dev@openvswitch.org" <dev@openvswitch.org>
>>Subject: [ovs-dev] [PATCH] datapath-windows: Conntrack - Fix
>>variable  initialization
>>
>>>Initialize the variable pktMdLabel.
>>>
>>>Signed-off-by: Sairam Venugopal <vsai...@vmware.com>

Never mind my previous oversight.

Acked-by: Nithin Raju <nit...@vmware.com>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Conntrack - Fix variable initialization

[Nithin Raju]

Sai,
There¹s not correctness issue with the existing code. There are 2 fields
in pktMdLabel, and they are being set in the function. Do you see any
correctness issues?

-- Nithin

-Original Message-
From: dev  on behalf of Sairam Venugopal

Date: Friday, June 24, 2016 at 6:16 PM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH] datapath-windows: Conntrack - Fix
variableinitialization

>Initialize the variable pktMdLabel.
>
>Signed-off-by: Sairam Venugopal 
>---
> datapath-windows/ovsext/Conntrack.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c
>b/datapath-windows/ovsext/Conntrack.c
>index ebfdeef..bb28b65 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -500,7 +500,7 @@ OvsConntrackSetLabels(OvsFlowKey *key,
>   struct ovs_key_ct_labels *val,
>   struct ovs_key_ct_labels *mask)
> {
>-ovs_u128 v, m, pktMdLabel;
>+ovs_u128 v, m, pktMdLabel = {0};
> memcpy(, val, sizeof v);
> memcpy(, mask, sizeof m);
> 
>-- 
>2.5.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=eoy2XpJIpS2H0d5a5h8cdT5HzcVrIX
>SMvsEnv2anmBE=qAcvDtyPrDy99WdgB1keL3C6CXI9NXvTT0UwAmyxlm8= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] FAQ: Update support for NAT and Geneve.

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Jesse Gross
<je...@kernel.org>
Date: Friday, June 24, 2016 at 2:58 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH] FAQ: Update support for NAT and Geneve.

>Signed-off-by: Jesse Gross <je...@kernel.org>
>---
> FAQ.md | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/FAQ.md b/FAQ.md
>index cc4fdf6..9f3dc61 100644
>--- a/FAQ.md
>+++ b/FAQ.md
>@@ -192,13 +192,13 @@ A: Open vSwitch supports different datapaths on
>different platforms.  Each
> 
> Feature   | Linux upstream | Linux OVS tree | Userspace |
>Hyper-V |
> 
>--|:--:|:--:|:-:|:
>---:|
>-NAT   |  4.6   |   NO   |NO |
>NO|
>+NAT   |  4.6   |   YES  |NO |
>NO|
> Connection tracking   |  4.3   |   YES  |NO |
>PARTIAL |
> Tunnel - LISP |  NO|   YES  |NO |
>NO|
> Tunnel - STT  |  NO|   YES  |NO |
>YES   |
> Tunnel - GRE  |  3.11  |   YES  |YES|
>YES   |
> Tunnel - VXLAN|  3.12  |   YES  |YES|
>YES   |
>-Tunnel - Geneve   |  3.18  |   YES  |YES|
>NO|
>+Tunnel - Geneve   |  3.18  |   YES  |YES|
>YES   |
> QoS - Policing|  YES   |   YES  |NO |
>NO|
> QoS - Shaping |  YES   |   YES  |NO |
>NO|
> sFlow |  YES   |   YES  |YES|
>NO|
>-- 
>2.7.4
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=R1Cw0JSSmgY98wC-R8JHwlDyxd7owP
>cextAf_gCLQJ0=mojtotreiXrvWX67TzvdANWiMQ_dygMslrr0r9n9B14= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] datapath-windows: Address minor alignment issues in Stt code.

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Yin Lin
<li...@vmware.com>
Date: Friday, June 24, 2016 at 2:44 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Cc: Yin Lin <li...@vmware.com>
Subject: [ovs-dev] [PATCH 2/2] datapath-windows: Address minor
alignment   issues in Stt code.

>Signed-off-by: Yin Lin <li...@vmware.com>
>---
> datapath-windows/ovsext/Stt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/Stt.c b/datapath-windows/ovsext/Stt.c
>index 0bac5f2..5aaf6fe 100644
>--- a/datapath-windows/ovsext/Stt.c
>+++ b/datapath-windows/ovsext/Stt.c
>@@ -875,7 +875,7 @@ OvsDecapStt(POVS_SWITCH_CONTEXT switchContext,
> advanceCnt = hdrLen;
> 
> ipHdr = NdisGetDataBuffer(curNb, sizeof *ipHdr, (PVOID) ,
>-1 /*no align*/, 0);
>+  1 /*no align*/, 0);
> ASSERT(ipHdr);
> 
> TCPHdr *tcp = (TCPHdr *)((PCHAR)ipHdr + ipHdr->ihl * 4);
>-- 
>2.8.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=U5RIiG8Ghkgc-E8QlKXvj9zXH4PB9W
>C0i95_iPb0msw=BcX3Pe8t_rrBYPx3rJchcXjG5O9s3jxSXgv0-2p02fk= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4] datapath-windows: Add GRE checksum

[Nithin Raju]

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Alin Serdean
<aserd...@cloudbasesolutions.com>
Date: Friday, June 17, 2016 at 1:00 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v4] datapath-windows: Add GRE checksum

>This patch introduces GRE checksum computation if the userspace requires
>it on Tx. On Rx we verify the GRE checksum if the checksum bit was
>specified and also inform the userspace about it.
>
>Also fix the GRE header length as specified by the GRE flags not the
>tunnel flags.
>
>Signed-off-by: Alin Gabriel Serdean <aserd...@cloudbasesolutions.com>
>---
>v4: Account for all memory fragmentation cases
>v3: Fix access length and address comments
>v2: Initial commit

Acked-by: Nithin Raju <nit...@vmware.com>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2][PATCH v7] datapath-windows: Add Geneve support

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Yin Lin
<li...@vmware.com>
Date: Friday, June 17, 2016 at 5:13 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH 1/2][PATCH v7] datapath-windows: Add Geneve
support

>Signed-off-by: Yin Lin <li...@vmware.com>
>---
> datapath-windows/automake.mk   |   2 +
> datapath-windows/ovsext/Actions.c  |  72 ++-
> datapath-windows/ovsext/Debug.h|   1 +
> datapath-windows/ovsext/DpInternal.h   |  29 ++-
> datapath-windows/ovsext/Flow.c | 179 +++--
> datapath-windows/ovsext/Flow.h |   7 +
> datapath-windows/ovsext/Geneve.c   | 356
>+
> datapath-windows/ovsext/Geneve.h   | 122 +++
> datapath-windows/ovsext/Util.h |   1 +
> datapath-windows/ovsext/Vport.c|  20 +-
> datapath-windows/ovsext/ovsext.vcxproj |   2 +
> 11 files changed, 716 insertions(+), 75 deletions(-)
> create mode 100644 datapath-windows/ovsext/Geneve.c
> create mode 100644 datapath-windows/ovsext/Geneve.h

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v6] datapath-windows: Add Geneve support

[Nithin Raju]

From: Yin Lin <yinli...@gmail.com<mailto:yinli...@gmail.com>>
Date: Friday, June 17, 2016 at 5:10 PM
To: "aserd...@cloudbasesolutions.com<mailto:aserd...@cloudbasesolutions.com>" 
<aserd...@cloudbasesolutions.com<mailto:aserd...@cloudbasesolutions.com>>, 
Nithin Raju <nit...@vmware.com<mailto:nit...@vmware.com>>
Cc: Yin Lin <li...@vmware.com<mailto:li...@vmware.com>>, 
"dev@openvswitch.org<mailto:dev@openvswitch.org>" 
<dev@openvswitch.org<mailto:dev@openvswitch.org>>
Subject: Re: [ovs-dev] [PATCH v6] datapath-windows: Add Geneve support

Thanks Alin and Nithin for the review and Jesse for the clarification.

I've addressed all the comments except this one:

"One general comment is that we are validating the tunnel options in the
hot path - basically for each packet when we execute the actions for the
flow. Obvious solution for this is to validate the flow ONLY during flow
add. Can you add a flag to OvsTunnelAttrToGeneveOptions() that tells the
function to validate only during flow add?"

In order to address this we need to propagate the flag all the way down.
Besides, there are other callers to this function such as OvsExecuteSetAction.
We need to evaluate whether validation is required in such cases.
Can I address the optimization in a separate patch? It looks like we always
do the validation on Linux and didn't optimize either.

Thanks Yin. Like Jesse mentioned, we don't have a full fledged flow-validation 
logic on Hyper-V. It is a pending work item.

While we get to it, this is what I had in mind in the meantime:
MapTunAttrToFlowPut() -> OvsTunnelAttrToGeneveOptions(validate = TRUE)
OvsTunnelAttrToIPv4TunnelKey() -> OvsTunnelAttrToGeneveOptions(validate = FALSE)

Do you see issues with this?

Thanks,
-- Nithin
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v4] datapath-windows: use ip proto for tunnel port lookup

[Nithin Raju]

In Actions.c, based on the IP Protocol type and L4 port of
the outer packet, we lookup the tunnel port. The function
that made this happen took the tunnel type as an argument.
Semantically, is is better to pass the IP protocol type and
let the lookup code map IP protocol type to tunnel type.

In the vport add code, we make sure that we block tunnel
port addition if there's already a tunnel port that uses
the same IP protocol type and L4 port number.

Signed-off-by: Nithin Raju <nit...@vmware.com>
Acked-by: Sairam Venugopal <vsai...@vmware.com>
Acked-by: Yin Lin <li...@vmware.com>
---
 datapath-windows/ovsext/Actions.c | 42 -
 datapath-windows/ovsext/Tunnel.c  |  6 ++--
 datapath-windows/ovsext/Vport.c   | 64 +--
 datapath-windows/ovsext/Vport.h   |  9 --
 4 files changed, 91 insertions(+), 30 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 72ebc04..7ac6bb7 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -215,32 +215,32 @@ OvsDetectTunnelRxPkt(OvsForwardingContext *ovsFwdCtx,
 /* XXX: we should also check for the length of the UDP payload to pick
  * packets only if they are at least VXLAN header size.
  */
+
+/*
+ * For some of the tunnel types such as GRE, the dstPort is not applicable
+ * since GRE does not have a L4 port. We use '0' for convenience.
+ */
 if (!flowKey->ipKey.nwFrag) {
 UINT16 dstPort = htons(flowKey->ipKey.l4.tpDst);
-switch (flowKey->ipKey.nwProto) {
-case IPPROTO_GRE:
-tunnelVport = 
OvsFindTunnelVportByPortType(ovsFwdCtx->switchContext,
-   OVS_VPORT_TYPE_GRE);
-if (tunnelVport) {
-ovsActionStats.rxGre++;
-}
-break;
-case IPPROTO_TCP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_STT);
-if (tunnelVport) {
+
+ASSERT(flowKey->ipKey.nwProto != IPPROTO_GRE || dstPort == 0);
+
+tunnelVport =
+OvsFindTunnelVportByDstPortAndNWProto(ovsFwdCtx->switchContext,
+  dstPort,
+  flowKey->ipKey.nwProto);
+if (tunnelVport) {
+switch(tunnelVport->ovsType) {
+case OVS_VPORT_TYPE_STT:
 ovsActionStats.rxStt++;
-}
-break;
-case IPPROTO_UDP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_VXLAN);
-if (tunnelVport) {
+break;
+case OVS_VPORT_TYPE_VXLAN:
 ovsActionStats.rxVxlan++;
+break;
+case OVS_VPORT_TYPE_GRE:
+ovsActionStats.rxGre++;
+break;
 }
-break;
 }
 }
 
diff --git a/datapath-windows/ovsext/Tunnel.c b/datapath-windows/ovsext/Tunnel.c
index 97d2020..c5aae1a 100644
--- a/datapath-windows/ovsext/Tunnel.c
+++ b/datapath-windows/ovsext/Tunnel.c
@@ -285,9 +285,9 @@ OvsInjectPacketThroughActions(PNET_BUFFER_LIST pNbl,
 
 SendFlags |= NDIS_SEND_FLAGS_DISPATCH_LEVEL;
 
-vport = OvsFindTunnelVportByDstPort(gOvsSwitchContext,
-htons(tunnelKey.dst_port),
-OVS_VPORT_TYPE_VXLAN);
+vport = OvsFindTunnelVportByDstPortAndType(gOvsSwitchContext,
+   htons(tunnelKey.dst_port),
+   OVS_VPORT_TYPE_VXLAN);
 
 if (vport == NULL){
 status = STATUS_UNSUCCESSFUL;
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index b4234e9..fbab61b 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -689,9 +689,9 @@ OvsFindVportByPortNo(POVS_SWITCH_CONTEXT switchContext,
 
 
 POVS_VPORT_ENTRY
-OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT switchContext,
-UINT16 dstPort,
-OVS_VPORT_TYPE ovsPortType)
+OvsFindTunnelVportByDstPortAndType(POVS_SWITCH_CONTEXT switchContext,
+   UINT16 dstPort,
+   OVS_VPORT_TYPE ovsPortType)
 {
 POVS_VPORT_ENTRY vport;
 PLIST_ENTRY head, link;
@@ -709,6 +709,41 @@ OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT 
switchContext,
 }
 
 POVS_VPORT_ENTRY
+OvsFindTunnelVportByDstPortAndNWProto(POVS_SWITCH_CONTEXT switchContex

Re: [ovs-dev] [PATCH v3] datapath-windows: use ip proto for tunnel port lookup

[Nithin Raju]

>>
>>+case IPPROTO_GRE:
>[Alin Gabriel Serdean: ] break;
>> +default:
>[Alin Gabriel Serdean: ] return NULL;
>> +break;
>> +}
>> +return vport;
>> +}
>> +}
>> +return NULL;
>> +}
>We need to exact match the IP proto. In the case of GRE you will get a
>valid vport although you have an L2 packet with dstPort == 0.
>I hope I was clear enough this time, if not I can post a debugging
>session :).
>The rest is all good.

Oops. Thanks for catching the bug. v4 out in a bit

-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] datapath-windows: comment cleanup and indentation

[Nithin Raju]

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Flow.c  | 20 ++--
 datapath-windows/ovsext/Vxlan.c |  5 -
 2 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index 2a91855..595518f 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -1650,19 +1650,19 @@ MapTunAttrToFlowPut(PNL_ATTR *keyAttrs,
 if (keyAttrs[OVS_KEY_ATTR_TUNNEL]) {
 
 if (tunAttrs[OVS_TUNNEL_KEY_ATTR_ID]) {
-destKey->tunKey.tunnelId = NlAttrGetU64
-   (tunAttrs[OVS_TUNNEL_KEY_ATTR_ID]);
+destKey->tunKey.tunnelId =
+NlAttrGetU64(tunAttrs[OVS_TUNNEL_KEY_ATTR_ID]);
 destKey->tunKey.flags |= OVS_TNL_F_KEY;
 }
 
 if (tunAttrs[OVS_TUNNEL_KEY_ATTR_IPV4_DST]) {
-destKey->tunKey.dst = NlAttrGetU32
-  (tunAttrs[OVS_TUNNEL_KEY_ATTR_IPV4_DST]);
+destKey->tunKey.dst =
+NlAttrGetU32(tunAttrs[OVS_TUNNEL_KEY_ATTR_IPV4_DST]);
 }
 
 if (tunAttrs[OVS_TUNNEL_KEY_ATTR_IPV4_SRC]) {
-destKey->tunKey.src = NlAttrGetU32
-  (tunAttrs[OVS_TUNNEL_KEY_ATTR_IPV4_SRC]);
+destKey->tunKey.src =
+NlAttrGetU32(tunAttrs[OVS_TUNNEL_KEY_ATTR_IPV4_SRC]);
 }
 
 if (tunAttrs[OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT]) {
@@ -1674,13 +1674,13 @@ MapTunAttrToFlowPut(PNL_ATTR *keyAttrs,
 }
 
 if (tunAttrs[OVS_TUNNEL_KEY_ATTR_TOS]) {
-destKey->tunKey.tos = NlAttrGetU8
-  (tunAttrs[OVS_TUNNEL_KEY_ATTR_TOS]);
+destKey->tunKey.tos =
+NlAttrGetU8(tunAttrs[OVS_TUNNEL_KEY_ATTR_TOS]);
 }
 
 if (tunAttrs[OVS_TUNNEL_KEY_ATTR_TTL]) {
-destKey->tunKey.ttl = NlAttrGetU8
-  (tunAttrs[OVS_TUNNEL_KEY_ATTR_TTL]);
+destKey->tunKey.ttl =
+NlAttrGetU8(tunAttrs[OVS_TUNNEL_KEY_ATTR_TTL]);
 }
 
 destKey->tunKey.pad = 0;
diff --git a/datapath-windows/ovsext/Vxlan.c b/datapath-windows/ovsext/Vxlan.c
index f6a55f0..ddd8d8e 100644
--- a/datapath-windows/ovsext/Vxlan.c
+++ b/datapath-windows/ovsext/Vxlan.c
@@ -194,11 +194,6 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
 ULONG mss = 0;
 NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
 
-/*
- * XXX: the assumption currently is that the NBL is owned by OVS, and
- * headroom has already been allocated as part of allocating the NBL and
- * MDL.
- */
 curNb = NET_BUFFER_LIST_FIRST_NB(curNbl);
 packetLength = NET_BUFFER_DATA_LENGTH(curNb);
 
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] datapath-windows: comment cleanup and indentation

[Nithin Raju]

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Vxlan.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/datapath-windows/ovsext/Vxlan.c b/datapath-windows/ovsext/Vxlan.c
index f6a55f0..ddd8d8e 100644
--- a/datapath-windows/ovsext/Vxlan.c
+++ b/datapath-windows/ovsext/Vxlan.c
@@ -194,11 +194,6 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
 ULONG mss = 0;
 NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
 
-/*
- * XXX: the assumption currently is that the NBL is owned by OVS, and
- * headroom has already been allocated as part of allocating the NBL and
- * MDL.
- */
 curNb = NET_BUFFER_LIST_FIRST_NB(curNbl);
 packetLength = NET_BUFFER_DATA_LENGTH(curNb);
 
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v6] datapath-windows: Add Geneve support

[Nithin Raju]

Hi Jesse,
Thanks for the comments. My responses inlined.

>>> /* Number of packet attributes required to store OVS tunnel key. */
>>>-#define NUM_PKT_ATTR_REQUIRED 3
>>>+#define NUM_PKT_ATTR_REQUIRED 35
>>>+#define TUN_OPT_MAX_LEN 255
>>
>> Wouldn¹t it have been better for alignment purposes to have
>> TUN_OPT_MAX_LEN as 252, and tunOptLen to be a UINT32. Since the size of
>> the tunnel options has to be a multiple of 4, the last 3 bytes are going
>> to be unused anyway. That way you don¹t have to go through any of the
>> alignment math later.
>>
>> I know this is the same on Linux code also, but might be worth finding
>>out
>> if there¹s any strong reason to keep this 255 and not the more
>>convenient
>> 252.
>
>The reason is to avoid making this overly tunnel specific.
>
>I don't really see the benefits making it 252 bytes plus a 4 byte
>length though. The length field is representing the amount of data in
>the array, so 1 byte is completely sufficient. And the alignment is
>rounding to 8 byte multiples but Geneve metadata is in 4 byte chunks,
>so I don't see how it could be avoided.

For Geneve, 252 would have been sufficient. The fact that we want to keep
it generic is a good reason to maximize the number of bytes we can pack.
But, I still find the 255 as an odd number odd :)

You are right about alignment.

>>>+#define OVS_TNL_F_GENEVE_OPT(1 << 5)
>>>+#define OVS_TNL_F_VXLAN_OPT (1 << 6)
>>
>> Does VXLAN support options? If not, let¹s remove this define;
>
>OVS supports extensions to VXLAN, some of which use the tunnel option
>space.

Sure, we don’t support it in Hyper-V datapath. But, it is probably ok to
keep the define.

>>>diff --git a/datapath-windows/ovsext/Geneve.c
>>>b/datapath-windows/ovsext/Geneve.c
>>>new file mode 100644
>>>index 000..8190a15
>>>--- /dev/null
>>>+++ b/datapath-windows/ovsext/Geneve.c
>[...]
>>>+geneveHdr = (GeneveHdr *)((PCHAR)udpHdr + sizeof *udpHdr);
>>>+if (geneveHdr->protocol != htons(ETH_P_TEB)) {
>>>+status = STATUS_NDIS_INVALID_PACKET;
>>>+goto dropNbl;
>>>+}
>>>+tunKey->flags = OVS_TNL_F_KEY;
>>>+if (geneveHdr->oam) {
>>>+tunKey->flags |= OVS_TNL_F_OAM;
>>>+}
>>
>> VXLAN code has been recently updated to set OVS_TNL_F_KEY conditionally.
>> Can you pls. udpate Geneve code as well?
>
>The key is always present in the Geneve header, so I'm not sure what
>it would be conditional on.

What should be the behavior if the VNI is 0? Is the packet considered a
valid packet?

>
>>>+tunKey->tunnelId = GENEVE_VNI_TO_TUNNELID(geneveHdr->vni);
>>>+tunKey->tunOptLen = (uint8)geneveHdr->optLen * 4;
>>
>> This can obviously overflow right? Max value is 0x3f * 8. I really think
>> you should use uint32 for ŒtunKey->tunOptLen¹.
>
>Geneve options are 4 byte multiples, not 8, so the max length is 252.

Thanks for correcting. I was mistaken.

>
>>>+if (tunKey->tunOptLen > TUN_OPT_MAX_LEN ||
>>>+packetLength < tunnelSize + tunKey->tunOptLen) {
>>>+status = NDIS_STATUS_INVALID_LENGTH;
>>>+goto dropNbl;
>>>+}
>>>+/* Clear out the receive flag for the inner packet. */
>>>+NET_BUFFER_LIST_INFO(curNbl, TcpIpChecksumNetBufferListInfo) = 0;
>>>+
>>>+NdisAdvanceNetBufferDataStart(curNb, tunnelSize, FALSE, NULL);
>>>+if (tunKey->tunOptLen > 0) {
>>>+optStart = NdisGetDataBuffer(curNb, tunKey->tunOptLen,
>>>+ TunnelKeyGetOptions(tunKey), 1
>>>/*no
>>>align*/, 0);
>>>+
>>>+/* If data is contiguous in the buffer, NdisGetDataBuffer will
>>>not copy
>>>+   data to the storage. Manual copy is needed. */
>>>+if (optStart != TunnelKeyGetOptions(tunKey)) {
>>>+memcpy(TunnelKeyGetOptions(tunKey), optStart,
>>>tunKey->tunOptLen);
>>>+}
>>>+NdisAdvanceNetBufferDataStart(curNb, tunKey->tunOptLen, FALSE,
>>>NULL);
>>>+}
>>
>> Don¹t we need to set the OVS_TNL_F_CRT_OPT flag based on Geneve header?
>
>This flag doesn't get reported to userspace so as long as it isn't
>added when the flow is setup by the datapath, there's no need to scan
>the options on a per-packet basis.

Sure.

>
>> Also, who takes care of validating if we can handle all of the critical
>> options? Are the critical options part of the flow key?
>
>Userspace handles critical vs. non-critical options. The datapath just
>needs to faithfully report what was received.

Thanks for the info. I am assuming that ALL the options are part of the
flow key - regardless of whether they are critical or not. So, once
userspace sets up the flow in the datapath, any subsequent packet with the
same Geneve header + options will match the flow.

Thanks,
-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v6] datapath-windows: Add Geneve support

[Nithin Raju]

Hi Yin,
Thanks for the patch. The code looks good overall, but for the comments.

One general observation is that I saw a few instances where you were
declaring variables in the middle of a scope. While it is legal, IMO, it
makes the code ugly esp. if the code is not written in blocks. So, I¹d
request you to declare them at the top of the scope.

Also, pls. remove the Gre.c code. Alin is addressing the same piece of
code in a different patch that is out for review.

Welcome to the club!

Thanks,
-- Nithin

-Original Message-
From: Yin Lin <li...@vmware.com>
Date: Monday, June 13, 2016 at 1:39 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>, Nithin Raju
<nit...@vmware.com>
Subject: [PATCH v6] datapath-windows: Add Geneve support

>Signed-off-by: Yin Lin <li...@vmware.com>
>---
> datapath-windows/automake.mk   |   2 +
> datapath-windows/ovsext/Actions.c  |  74 ++-
> datapath-windows/ovsext/Debug.h|   1 +
> datapath-windows/ovsext/DpInternal.h   |  29 ++-
> datapath-windows/ovsext/Flow.c | 173 ++--
> datapath-windows/ovsext/Flow.h |   7 +
> datapath-windows/ovsext/Geneve.c   | 361
>+
> datapath-windows/ovsext/Geneve.h   | 122 +++
> datapath-windows/ovsext/Gre.c  |   7 +-
> datapath-windows/ovsext/Stt.c  |   2 +-
> datapath-windows/ovsext/Util.h |   1 +
> datapath-windows/ovsext/Vport.c|  19 +-
> datapath-windows/ovsext/ovsext.vcxproj |   2 +
> 13 files changed, 715 insertions(+), 85 deletions(-)
> create mode 100644 datapath-windows/ovsext/Geneve.c
> create mode 100644 datapath-windows/ovsext/Geneve.h
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index c9af806..53fb5c5 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -68,6 +68,8 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/Vport.h \
>   datapath-windows/ovsext/Vxlan.c \
>   datapath-windows/ovsext/Vxlan.h \
>+  datapath-windows/ovsext/Geneve.c \
>+  datapath-windows/ovsext/Geneve.h \
>   datapath-windows/ovsext/ovsext.inf \
>   datapath-windows/ovsext/ovsext.rc \
>   datapath-windows/ovsext/ovsext.vcxproj \
>diff --git a/datapath-windows/ovsext/Actions.c
>b/datapath-windows/ovsext/Actions.c
>index 53be718..644dcfd 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -48,6 +48,8 @@ typedef struct _OVS_ACTION_STATS {
> UINT64 txVxlan;
> UINT64 rxStt;
> UINT64 txStt;
>+UINT64 rxGeneve;
>+UINT64 txGeneve;
> UINT64 flowMiss;
> UINT64 flowUserspace;
> UINT64 txTcp;
>@@ -229,11 +231,9 @@ OvsDetectTunnelRxPkt(OvsForwardingContext *ovsFwdCtx,
> case OVS_VPORT_TYPE_VXLAN:
> ovsActionStats.rxVxlan++;
> break;
>-#if 0
> case OVS_VPORT_TYPE_GENEVE:
> ovsActionStats.rxGeneve++;
> break;
>-#endif
> case OVS_VPORT_TYPE_GRE:
> ovsActionStats.rxGre++;
> break;
>@@ -330,6 +330,9 @@ OvsDetectTunnelPkt(OvsForwardingContext *ovsFwdCtx,
> case OVS_VPORT_TYPE_STT:
> ovsActionStats.txStt++;
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+   ovsActionStats.txGeneve++;
>+   break;
> }
> ovsFwdCtx->tunnelTxNic = dstVport;
> }
>@@ -686,6 +689,11 @@ OvsTunnelPortTx(OvsForwardingContext *ovsFwdCtx)
>  >tunKey,
>ovsFwdCtx->switchContext,
>  >layers, );
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+status = OvsEncapGeneve(ovsFwdCtx->tunnelTxNic,
>ovsFwdCtx->curNbl,
>+>tunKey,
>ovsFwdCtx->switchContext,
>+>layers, );
>+break;
> default:
> ASSERT(! "Tx: Unhandled tunnel type");
> }
>@@ -764,6 +772,10 @@ OvsTunnelPortRx(OvsForwardingContext *ovsFwdCtx)
> dropReason = L"OVS-STT segment is cached";
> }
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+status = OvsDecapGeneve(ovsFwdCtx->switchContext,
>ovsFwdCtx->curNbl,
>+>tunKey, );
>+break;
> default:
> OVS_LOG_ERROR("Rx: Unhandled tunnel type: %d\n",
>   tunnelRxVport->ovsType);
>@@ -1230,57 +1242,6 @@ OvsActionMplsPush(OvsForwardingContext *ovsFwdCtx,
> }
> 
> /*
>- * 
>

Re: [ovs-dev] [PATCH v3] datapath-windows: Add GRE checksum

[Nithin Raju]

Glad we were able to resolve this :)

-Original Message-
From: Alin Serdean <aserd...@cloudbasesolutions.com>
Date: Tuesday, June 14, 2016 at 9:12 AM
To: Nithin Raju <nit...@vmware.com>, "dev@openvswitch.org"
<dev@openvswitch.org>
Subject: RE: [ovs-dev] [PATCH v3] datapath-windows: Add GRE checksum

>> >greater than the maximum header size which is configurable. In the case
>
>> >of VXLAN / STT we can be in the case above, because of the UDP/TCP like
>
>> >packet
>
>> 
>
>> [Nithin]: Yes, in fact even for NICs that support header-split (mostly
>>Intel),
>
>[Alin Gabriel Serdean: ] I looked over some Intel specs and they said you
>could header split after eth header on a RQ.
>
>The documentation is very shady between NDIS versions, you are right, I
>will allocate a buffer if the memory was not contiguous.
>
>I found this in the document when header data split was introduced:
>
>" €Do not assume that the minimum size of the data in the first MDL
>contains all of the TCP/IP headers."
>
>Thanks for the patience of reiterating that we should not make
>assumptions :).
>
>> the payload of the packet WILL NOT be in the first MDL. In case of GRE,
>>the
>
>> split would happen at the IP header itself. So, GRE header would not be
>>in
>
>> the contigous buffer.
>
>> 
>
>> >, but for GRE things differ since there are cards which support
>
>> >offloading:
>
>> >https://urldefense.proofpoint.com/v2/url?u=https-
>
>> 3A__msdn.microsoft.com
>
>> >_en
>
>> >-2Dus_library_windows_hardware_dn605832-28v-3Dvs.85-
>
>> 29.aspx=CwIFAA=
>
>> >Sqc
>
>> >l0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
>
>> uEs=pNHQcdr7B40b4h6Yb7FIedI1dnBs
>
>> >xdD
>
>> >uTLBYD3JqV80=Xih_0c1MPDafKSkW1nO5-
>
>> mIutm1WK_ZmMcu7likx3jM=A4LA4vS20h
>
>> >f4l
>
>> >keq-wjCc6N9kbBMqswRnC-SSulTF6s=
>
>> >"The protocol driver will guarantee that all the prepended
>
>> >encapsulation headers (ETH, IP, GRE) will be physically contiguous and
>
>> >will be in the first MDL of the packet."
>
>> 
>
>> 
>
>> >I do not think we will be in a situation in which a GRE header will not
>
>> >be continuous.
>
>> >If you consider we should still have a fragmented header problem, I
>
>> >will allocate a buffer and execute another NdisGetDataBuffer call if
>
>> >the first one failed.
>
>> 
>
>> [Nithin]: The documention you point to is to the send direction. In
>>case of
>
>> receive, where does it say that the protocol/filter driver can expect
>>the
>
>> miniport driver to pack the ETH + IP + GRE header in one contiguous
>>buffer?
>
>[Alin Gabriel Serdean: ]
>https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_en
>-2Dus_library_windows_hardware_dn605831-28v-3Dvs.85-29.aspx=CwIGaQ=Sqc
>l0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pNHQcdr7B40b4h6Yb7FIedI1dnBsxdD
>uTLBYD3JqV80=VugC5mFPTpNpx0R-jC10W_uinFfZOY_F1Hi4gFstsFA=h7DHGykgAZtg3
>nSvp5hoJlvoAHoucP3l3niTl3PmxnI=
>
>> 
>
>> In any case, if you are particular that the code is correct, I am ok
>>with the
>
>> patch. I was trying to give suggestions to make the code solid.
>
>> 
>
>> Acked-by: Nithin Raju <nit...@vmware.com>
>
>> 
>
>> -- Nithin
>
>
>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v3] datapath-windows: use ip proto for tunnel port lookup

[Nithin Raju]

In Actions.c, based on the IP Protocol type and L4 port of
the outer packet, we lookup the tunnel port. The function
that made this happen took the tunnel type as an argument.
Semantically, is is better to pass the IP protocol type and
let the lookup code map IP protocol type to tunnel type.

In the vport add code, we make sure that we block tunnel
port addition if there's already a tunnel port that uses
the same IP protocol type and L4 port number.

Signed-off-by: Nithin Raju <nit...@vmware.com>
Acked-by: Sairam Venugopal <vsai...@vmware.com>
Acked-by: Yin Lin <li...@vmware.com>
---
v3: addresed Alin's comments
v2: addresed Yin's comments

 datapath-windows/ovsext/Actions.c | 42 +-
 datapath-windows/ovsext/Tunnel.c  |  6 ++--
 datapath-windows/ovsext/Vport.c   | 63 +--
 datapath-windows/ovsext/Vport.h   |  9 --
 4 files changed, 90 insertions(+), 30 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 72ebc04..7ac6bb7 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -215,32 +215,32 @@ OvsDetectTunnelRxPkt(OvsForwardingContext *ovsFwdCtx,
 /* XXX: we should also check for the length of the UDP payload to pick
  * packets only if they are at least VXLAN header size.
  */
+
+/*
+ * For some of the tunnel types such as GRE, the dstPort is not applicable
+ * since GRE does not have a L4 port. We use '0' for convenience.
+ */
 if (!flowKey->ipKey.nwFrag) {
 UINT16 dstPort = htons(flowKey->ipKey.l4.tpDst);
-switch (flowKey->ipKey.nwProto) {
-case IPPROTO_GRE:
-tunnelVport = 
OvsFindTunnelVportByPortType(ovsFwdCtx->switchContext,
-   OVS_VPORT_TYPE_GRE);
-if (tunnelVport) {
-ovsActionStats.rxGre++;
-}
-break;
-case IPPROTO_TCP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_STT);
-if (tunnelVport) {
+
+ASSERT(flowKey->ipKey.nwProto != IPPROTO_GRE || dstPort == 0);
+
+tunnelVport =
+OvsFindTunnelVportByDstPortAndNWProto(ovsFwdCtx->switchContext,
+  dstPort,
+  flowKey->ipKey.nwProto);
+if (tunnelVport) {
+switch(tunnelVport->ovsType) {
+case OVS_VPORT_TYPE_STT:
 ovsActionStats.rxStt++;
-}
-break;
-case IPPROTO_UDP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_VXLAN);
-if (tunnelVport) {
+break;
+case OVS_VPORT_TYPE_VXLAN:
 ovsActionStats.rxVxlan++;
+break;
+case OVS_VPORT_TYPE_GRE:
+ovsActionStats.rxGre++;
+break;
 }
-break;
 }
 }
 
diff --git a/datapath-windows/ovsext/Tunnel.c b/datapath-windows/ovsext/Tunnel.c
index 97d2020..c5aae1a 100644
--- a/datapath-windows/ovsext/Tunnel.c
+++ b/datapath-windows/ovsext/Tunnel.c
@@ -285,9 +285,9 @@ OvsInjectPacketThroughActions(PNET_BUFFER_LIST pNbl,
 
 SendFlags |= NDIS_SEND_FLAGS_DISPATCH_LEVEL;
 
-vport = OvsFindTunnelVportByDstPort(gOvsSwitchContext,
-htons(tunnelKey.dst_port),
-OVS_VPORT_TYPE_VXLAN);
+vport = OvsFindTunnelVportByDstPortAndType(gOvsSwitchContext,
+   htons(tunnelKey.dst_port),
+   OVS_VPORT_TYPE_VXLAN);
 
 if (vport == NULL){
 status = STATUS_UNSUCCESSFUL;
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index b4234e9..f8639f2 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -689,9 +689,9 @@ OvsFindVportByPortNo(POVS_SWITCH_CONTEXT switchContext,
 
 
 POVS_VPORT_ENTRY
-OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT switchContext,
-UINT16 dstPort,
-OVS_VPORT_TYPE ovsPortType)
+OvsFindTunnelVportByDstPortAndType(POVS_SWITCH_CONTEXT switchContext,
+   UINT16 dstPort,
+   OVS_VPORT_TYPE ovsPortType)
 {
 POVS_VPORT_ENTRY vport;
 PLIST_ENTRY head, link;
@@ -709,6 +709,40 @@ OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT 
switchContext,
 }
 
 POVS_VPORT_ENTRY
+OvsFindTu

Re: [ovs-dev] [PATCH] datapath-windows: use ip proto for tunnel port lookup

[Nithin Raju]

Hi Alin,
Thanks for the review. I¹ve taken care of the extra whitespace and also
the dead (placeholder) code.


>> --- a/datapath-windows/ovsext/Vport.c
>
>> +++ b/datapath-windows/ovsext/Vport.c
>
>>  POVS_VPORT_ENTRY
>
>> +OvsFindTunnelVportByDstPortAndNWProto(POVS_SWITCH_CONTEXT
>
>> switchContext,
>
>> +  UINT16 dstPort,
>
>> +  UINT8 nwProto) {
>
>> +POVS_VPORT_ENTRY vport;
>
>> +PLIST_ENTRY head, link;
>
>> +UINT32 hash = OvsJhashBytes((const VOID *),
>>sizeof(dstPort),
>
>> +OVS_HASH_BASIS);
>
>> +head = &(switchContext->tunnelVportsArray[hash &
>
>> OVS_VPORT_MASK]);
>
>> +LIST_FORALL(head, link) {
>
>> +vport = CONTAINING_RECORD(link, OVS_VPORT_ENTRY,
>
>> tunnelVportLink);
>
>> +if (GetPortFromPriv(vport) == dstPort) {
>
>> +switch (nwProto) {
>
>[Alin Gabriel Serdean: ] This will break in case we have a GRE tunnel set
>up. They rely only on the IP protocol; their destination port will be
>always set to zero. We can have packets which have l4 port zero and a gre
>tunnel which will result in a misinterpreted patcket. Please leave the
>function OvsFindTunnelVportByPortType the way it was and create a new one.

[Nithin]: There¹s no notion of a L4 port in a GRE packet, hence we use Œ0¹
as a convenient placeholder L4 port. What is the concern here? I don¹t
mind leaving the function OvsFindTunnelVportByPortType() alone, but I am
not sure how the patch is wrong. I¹ll add OvsFindTunnelVportByPortType()
back.

As such, I don¹t see any functionality breakage here.

>> 
>
>> +/*
>
>> + * We don't allow two tunnel ports on identical N/W
>>protocol and
>
>> + * L4 port number. This is applicable even if the two
>>ports are of
>
>> + * different tunneling types.
>
>> + */
>
>> +dupVport =
>
>> +   
>>OvsFindTunnelVportByDstPortAndNWProto(gOvsSwitchContext,
>
>> +   
>>transportPortDest,
>
>> +  nwProto);
>
>[Alin Gabriel Serdean: ] Please skip this check in the case of GRE( it
>relies only on the IP protocol).


[Nithin]: The code is simpler this way. No? I can add a comment to clarify
and an ASSERT as well. BTW, we already make assumptions in the code w.r.t
the L4 port number for GRE ports. Pls. have a look at the following code:

NDIS_STATUS
InitOvsVportCommon(POVS_SWITCH_CONTEXT switchContext,
   POVS_VPORT_ENTRY vport)
{  
UINT32 hash;  
   
switch(vport->ovsType) {
case OVS_VPORT_TYPE_GRE:
case OVS_VPORT_TYPE_VXLAN:
case OVS_VPORT_TYPE_STT:
{ 
UINT16 dstPort = GetPortFromPriv(vport); < L4 port # is 0 for GRE
port.
hash = OvsJhashBytes(,
sizeof(dstPort),
OVS_HASH_BASIS);
InsertHeadList(   
>tunnelVportsArray[hash & OVS_VPORT_MASK],
>tunnelVportLink);
switchContext->numNonHvVports++;
break;
} 


I¹ll send out a v3. Pls. have a look.

Thanks,
-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Sample action support.

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Sorin Vinturis
<svintu...@cloudbasesolutions.com>
Date: Wednesday, June 1, 2016 at 8:50 AM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v2] datapath-windows: Sample action support.

>This patch adds support for sampling to the OVS extension.
>
>The following flow was used for generating sample actions:
>  ovs-ofctl add-flow tcp:127.0.0.1: "actions=sample(
>probability=12345,collector_set_id=23456,obs_domain_id=34567,
>obs_point_id=45678)"
>
>Signed-off-by: Sorin Vinturis <svintu...@cloudbasesolutions.com>
>---
>v2: Moved random functions to Util.h and removed Random.h.
>---
> datapath-windows/ovsext/Actions.c | 181
>+++---
> datapath-windows/ovsext/Util.h|  27 ++
> 2 files changed, 175 insertions(+), 33 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Actions.c
>b/datapath-windows/ovsext/Actions.c
>index 4edf7d0..1e894eb 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -1596,6 +1596,131 @@ OvsExecuteHash(OvsFlowKey *key,
> hash = 1;
> 
> key->dpHash = hash;
>+}
>+
>+/*
>+ * 
>--
>+ * OvsOutputUserspaceAction --
>+ *  This function sends the packet to userspace according to nested
>+ *  %OVS_USERSPACE_ATTR_* attributes.
>+ * 
>--
>+ */
>+static __inline NDIS_STATUS
>+OvsOutputUserspaceAction(OvsForwardingContext *ovsFwdCtx,
>+ OvsFlowKey *key,
>+ const PNL_ATTR attr)
>+{
>+NTSTATUS status = NDIS_STATUS_SUCCESS;
>+PNL_ATTR userdataAttr;
>+PNL_ATTR queueAttr;
>+POVS_PACKET_QUEUE_ELEM elem;
>+POVS_PACKET_HDR_INFO layers = >layers;
>+BOOLEAN isRecv = FALSE;
>+
>+POVS_VPORT_ENTRY vport =
>OvsFindVportByPortNo(ovsFwdCtx->switchContext,
>+  ovsFwdCtx->srcVportNo);
>+
>+if (vport) {
>+if (vport->isExternal ||
>+OvsIsTunnelVportType(vport->ovsType)) {
>+isRecv = TRUE;
>+}
>+}
>+
>+queueAttr = NlAttrFindNested(attr, OVS_USERSPACE_ATTR_PID);
>+userdataAttr = NlAttrFindNested(attr, OVS_USERSPACE_ATTR_USERDATA);
>+
>+elem = OvsCreateQueueNlPacket(NlAttrData(userdataAttr),
>+  NlAttrGetSize(userdataAttr),
>+  OVS_PACKET_CMD_ACTION,
>+  vport, key, ovsFwdCtx->curNbl,
>+ 
>NET_BUFFER_LIST_FIRST_NB(ovsFwdCtx->curNbl),
>+  isRecv,
>+  layers);
>+if (elem) {
>+LIST_ENTRY missedPackets;
>+InitializeListHead();
>+InsertTailList(, >link);
>+OvsQueuePackets(, 1);
>+} else {
>+status = NDIS_STATUS_FAILURE;
>+}
>+
>+return status;
>+}
>+
>+/*
>+ * 
>--
>+ * OvsExecuteSampleAction --
>+ *  Executes actions based on probability, as specified in the nested
>+ *  %OVS_SAMPLE_ATTR_* attributes.
>+ * 
>--
>+ */
>+static __inline NDIS_STATUS
>+OvsExecuteSampleAction(OvsForwardingContext *ovsFwdCtx,
>+   OvsFlowKey *key,
>+   const PNL_ATTR attr)
>+{
>+PNET_BUFFER_LIST newNbl = NULL;
>+PNL_ATTR actionsList = NULL;
>+PNL_ATTR a = NULL;
>+INT rem = 0;
>+
>+SRand();
>+NL_ATTR_FOR_EACH_UNSAFE(a, rem, NlAttrData(attr),
>NlAttrGetSize(attr)) {
>+switch (NlAttrType(a)) {
>+case OVS_SAMPLE_ATTR_PROBABILITY:
>+{
>+UINT32 probability = NlAttrGetU32(a);
>+
>+if (!probability || Rand() > probability) {
>+return 0;
>+}
>+break;
>+}
>+case OVS_SAMPLE_ATTR_ACTIONS:
>+actionsList = a;
>+break;
>+}
>+}
>+
>+if (actionsList) {
>+rem = NlAttrGetSize(actionsList);
>+a = (PNL_ATTR)NlAttrData(actionsList);
>+}
>+
>+if (!rem) {
>+/* Actions list is empty, do nothing */
>+return STATUS_SUCCESS;
>+}
>+
>+/*
>+ * The only known usage of sample action is having a single

Re: [ovs-dev] [PATCH v3] datapath-windows: Add GRE checksum

[Nithin Raju]

>>
>>-Mesaj original-
>> De la: Nithin Raju [mailto:nit...@vmware.com]
>> Trimis: Wednesday, June 8, 2016 10:10 PM
>> Către: Alin Serdean <aserd...@cloudbasesolutions.com>;
>> dev@openvswitch.org
>> Subiect: Re: [ovs-dev] [PATCH v3] datapath-windows: Add GRE checksum
>> 
>> 
>> >+/* Get a contignuous buffer for the maxmimum length of a GRE
>> >+ header
>> >*/
>> >+bufferStart = NdisGetDataBuffer(curNb, OVS_MAX_GRE_LGTH, NULL, 1,
>> >+ 0);
>> 
>> Sorry we have to go back and forth on this. Like I mentioned in the
>>previous
>> email, the idea is to get a contiguous chunk of memory so we can walk
>>all the
>> header until the GRE header. It is a good idea to use
>> NdisGetDataBuffer() instead of copying the NBL. But, we won¹t avoid the
>> copied NBL anyway since decap has to happen on the copied NBL.
>[Alin Gabriel Serdean: ] Agreed. I only wanted a check to make sure the
>whole ETH, IP, GRE was contiguous.
>> 
>> In any case, NdisGetDataBuffer() has some pitfalls:
>> "If the requested data in the buffer is contiguous, this return value
>>is a
>> pointer to a location that NDIS provides. If the data is not
>>contiguous, NDIS
>> uses the Storage parameter as follows:
>> 
>> * If the Storage parameter is non-NULL, NDIS copies the data to the
>>buffer at
>> Storage. This return value is the pointer passed to the Storage
>>parameter.
>> * If the Storage parameter is NULL, this return value is NULL.²
>> 
>> So, if the first MDL does not fit the headers until the GRE headers, we
>>need
>> to pass explicit memory to NdisGetDataBuffer() in argument #3 in order
>>for
>> NDIS to copy it over to a contiguous chunk of memory.
>[Alin Gabriel Serdean: ] We have to take into consideration that NDIS 6.3
>supports NVGRE and in NDIS 6.4 GRE
>(https://urldefense.proofpoint.com/v2/url?u=https-3A__support.microsoft.co
>m_en-2Dus_kb_3022776=CwIFAA=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uE
>s=pNHQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=Xih_0c1MPDafKSkW1nO5-mIu
>tm1WK_ZmMcu7likx3jM=OR7CpNr_D_lG7SqFfSsi2qb63XGh1WaXVKtbLqjfT8s=  ).

[Nithin]: I am not sure how NDIS supporting GRE and NVGRE would affect
help with putting the ETH + IP + GRE header in a contiguous buffer. The
MDLs are typically formed by the mini port driver, and NDIS will either
run a parser on top of it or use an offload if the NIC supports it.

>Packets can be split in multiple Mdl's, if the miniport supports it, as
>early as at the beginning of the upper-layer-protocol
>(https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_e
>n-2Dus_library_windows_hardware_ff571065-28v-3Dvs.85-29.aspx=CwIFAA=Sq
>cl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pNHQcdr7B40b4h6Yb7FIedI1dnBsxd
>DuTLBYD3JqV80=Xih_0c1MPDafKSkW1nO5-mIutm1WK_ZmMcu7likx3jM=sZElhQvcdQPd
>zDWCX8jmxd33zxPVzkGsudCT0Z8pdr4= ) and if the split header is not
>greater than the maximum header size which is configurable. In the case
>of VXLAN / STT we can be in the case above, because of the UDP/TCP like
>packet

[Nithin]: Yes, in fact even for NICs that support header-split (mostly
Intel), the payload of the packet WILL NOT be in the first MDL. In case of
GRE, the split would happen at the IP header itself. So, GRE header would
not be in the contigous buffer.

>, but for GRE things differ since there are cards which support
>offloading:
>https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_en
>-2Dus_library_windows_hardware_dn605832-28v-3Dvs.85-29.aspx=CwIFAA=Sqc
>l0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pNHQcdr7B40b4h6Yb7FIedI1dnBsxdD
>uTLBYD3JqV80=Xih_0c1MPDafKSkW1nO5-mIutm1WK_ZmMcu7likx3jM=A4LA4vS20hf4l
>keq-wjCc6N9kbBMqswRnC-SSulTF6s=
>"The protocol driver will guarantee that all the prepended encapsulation
>headers (ETH, IP, GRE) will be physically contiguous and will be in the
>first MDL of the packet."


>I do not think we will be in a situation in which a GRE header will not
>be continuous.
>If you consider we should still have a fragmented header problem, I will
>allocate a buffer and execute another NdisGetDataBuffer call if the first
>one failed.

[Nithin]: The documention you point to is to the send direction. In case
of receive, where does it say that the protocol/filter driver can expect
the miniport driver to pack the ETH + IP + GRE header in one contiguous
buffer?

In any case, if you are particular that the code is correct, I am ok with
the patch. I was trying to give suggestions to make the code solid.

Acked-by: Nithin Raju <nit...@vmware.com>

-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3] datapath-windows: Add GRE checksum

[Nithin Raju]

> #endif
>@@ -299,34 +312,21 @@ OvsDecapGre(POVS_SWITCH_CONTEXT switchContext,
> EthHdr *ethHdr;
> IPHdr *ipHdr;
> GREHdr *greHdr;
>-UINT32 tunnelSize = 0, packetLength = 0;
>+UINT32 tunnelSize, packetLength;
> UINT32 headRoom = 0;
> PUINT8 bufferStart;
> NDIS_STATUS status;
> 
> curNb = NET_BUFFER_LIST_FIRST_NB(curNbl);
> packetLength = NET_BUFFER_DATA_LENGTH(curNb);
>-tunnelSize = GreTunHdrSize(tunKey->flags);
>+curMdl = NET_BUFFER_CURRENT_MDL(curNb);
>+tunnelSize = GreTunHdrSize(0);
> if (packetLength <= tunnelSize) {
> return NDIS_STATUS_INVALID_LENGTH;
> }
> 
>-/*
>- * Create a copy of the NBL so that we have all the headers in one
>MDL.
>- */
>-*newNbl = OvsPartialCopyNBL(switchContext, curNbl,
>-tunnelSize + OVS_DEFAULT_COPY_SIZE, 0,
>-TRUE /*copy NBL info */);
>-
>-if (*newNbl == NULL) {
>-return NDIS_STATUS_RESOURCES;
>-}
>-
>-curNbl = *newNbl;
>-curNb = NET_BUFFER_LIST_FIRST_NB(curNbl);
>-curMdl = NET_BUFFER_CURRENT_MDL(curNb);
>-bufferStart = (PUINT8)MmGetSystemAddressForMdlSafe(curMdl,
>LowPagePriority) +
>-  NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
>+/* Get a contignuous buffer for the maxmimum length of a GRE header
>*/
>+bufferStart = NdisGetDataBuffer(curNb, OVS_MAX_GRE_LGTH, NULL, 1, 0);

Sorry we have to go back and forth on this. Like I mentioned in the
previous email, the idea is to get a contiguous chunk of memory so we can
walk all the header until the GRE header. It is a good idea to use
NdisGetDataBuffer() instead of copying the NBL. But, we won¹t avoid the
copied NBL anyway since decap has to happen on the copied NBL.

In any case, NdisGetDataBuffer() has some pitfalls:
"If the requested data in the buffer is contiguous, this return value is a
pointer to a location that NDIS provides. If the data is not contiguous,
NDIS uses the Storage parameter as follows:

* If the Storage parameter is non-NULL, NDIS copies the data to the buffer
at Storage. This return value is the pointer passed to the Storage
parameter.
* If the Storage parameter is NULL, this return value is NULL.²

So, if the first MDL does not fit the headers until the GRE headers, we
need to pass explicit memory to NdisGetDataBuffer() in argument #3 in
order for NDIS to copy it over to a contiguous chunk of memory.

Thanks,
-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] [PATCH v5] datapath-windows: Add Geneve support

[Nithin Raju]

-Original Message-
From: Ben Pfaff <b...@ovn.org>
Date: Friday, June 3, 2016 at 11:55 AM
To: Nithin Raju <nit...@vmware.com>
Cc: Yin Lin <li...@vmware.com>, "dev@openvswitch.org" <dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH 2/2] [PATCH v5] datapath-windows: Add Geneve
support

>I wasn't sure how to interpret this.  Does this mean that you will
>review this patch later, or does it mean something else?

Ben,
We were going back and forth on a subset of the patch. I¹ve sent out a
patch myself for that portion.

Yin will be rebasing the larger Geneve support patch on top of it and
incorporate any other comments as well.

-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v2] datapath-windows: use ip proto for tunnel port lookup

[Nithin Raju]

In Actions.c, based on the IP Protocol type and L4 port of
the outer packet, we lookup the tunnel port. The function
that made this happen took the tunnel type as an argument.
Semantically, is is better to pass the IP protocol type and
let the lookup code map IP protocol type to tunnel type.

In the vport add code, we make sure that we block tunnel
port addition if there's already a tunnel port that uses
the same IP protocol type and L4 port number.

This is required for Geneve port lookups the references to
which can find in the patch.

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Actions.c | 39 +---
 datapath-windows/ovsext/Tunnel.c  |  6 ++---
 datapath-windows/ovsext/Vport.c   | 53 +--
 datapath-windows/ovsext/Vport.h   | 11 
 4 files changed, 73 insertions(+), 36 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 4edf7d0..53be718 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -217,30 +217,27 @@ OvsDetectTunnelRxPkt(OvsForwardingContext *ovsFwdCtx,
  */
 if (!flowKey->ipKey.nwFrag) {
 UINT16 dstPort = htons(flowKey->ipKey.l4.tpDst);
-switch (flowKey->ipKey.nwProto) {
-case IPPROTO_GRE:
-tunnelVport = 
OvsFindTunnelVportByPortType(ovsFwdCtx->switchContext,
-   OVS_VPORT_TYPE_GRE);
-if (tunnelVport) {
-ovsActionStats.rxGre++;
-}
-break;
-case IPPROTO_TCP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_STT);
-if (tunnelVport) {
+tunnelVport =
+OvsFindTunnelVportByDstPortAndNWProto(ovsFwdCtx->switchContext,
+  dstPort,
+  flowKey->ipKey.nwProto);
+if (tunnelVport) {
+switch(tunnelVport->ovsType) {
+case OVS_VPORT_TYPE_STT:
 ovsActionStats.rxStt++;
-}
-break;
-case IPPROTO_UDP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_VXLAN);
-if (tunnelVport) {
+break;
+case OVS_VPORT_TYPE_VXLAN:
 ovsActionStats.rxVxlan++;
+break;
+#if 0
+case OVS_VPORT_TYPE_GENEVE:
+ovsActionStats.rxGeneve++;
+break;
+#endif
+case OVS_VPORT_TYPE_GRE:
+ovsActionStats.rxGre++;
+break;
 }
-break;
 }
 }
 
diff --git a/datapath-windows/ovsext/Tunnel.c b/datapath-windows/ovsext/Tunnel.c
index 97d2020..c5aae1a 100644
--- a/datapath-windows/ovsext/Tunnel.c
+++ b/datapath-windows/ovsext/Tunnel.c
@@ -285,9 +285,9 @@ OvsInjectPacketThroughActions(PNET_BUFFER_LIST pNbl,
 
 SendFlags |= NDIS_SEND_FLAGS_DISPATCH_LEVEL;
 
-vport = OvsFindTunnelVportByDstPort(gOvsSwitchContext,
-htons(tunnelKey.dst_port),
-OVS_VPORT_TYPE_VXLAN);
+vport = OvsFindTunnelVportByDstPortAndType(gOvsSwitchContext,
+   htons(tunnelKey.dst_port),
+   OVS_VPORT_TYPE_VXLAN);
 
 if (vport == NULL){
 status = STATUS_UNSUCCESSFUL;
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index 222b2c1..ed14553 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -691,9 +691,9 @@ OvsFindVportByPortNo(POVS_SWITCH_CONTEXT switchContext,
 
 
 POVS_VPORT_ENTRY
-OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT switchContext,
-UINT16 dstPort,
-OVS_VPORT_TYPE ovsPortType)
+OvsFindTunnelVportByDstPortAndType(POVS_SWITCH_CONTEXT switchContext,
+   UINT16 dstPort,
+   OVS_VPORT_TYPE ovsPortType)
 {
 POVS_VPORT_ENTRY vport;
 PLIST_ENTRY head, link;
@@ -711,18 +711,34 @@ OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT 
switchContext,
 }
 
 POVS_VPORT_ENTRY
-OvsFindTunnelVportByPortType(POVS_SWITCH_CONTEXT switchContext,
- OVS_VPORT_TYPE ovsPortType)
+OvsFindTunnelVportByDstPortAndNWProto(POVS_SWITCH_CONTEXT switchContext,
+  UINT16 dstPort,
+  UINT8 nwProto)
 {
 POVS_VPORT_ENTRY v

Re: [ovs-dev] [PATCH] datapath-windows: use ip proto for tunnel port lookup

[Nithin Raju]

Thanks for the review.

From: Yin Lin <yinli...@gmail.com<mailto:yinli...@gmail.com>>
Date: Thursday, June 2, 2016 at 3:00 PM
To: Nithin Raju <nit...@vmware.com<mailto:nit...@vmware.com>>
Cc: "dev@openvswitch.org<mailto:dev@openvswitch.org>" 
<dev@openvswitch.org<mailto:dev@openvswitch.org>>
Subject: Re: [ovs-dev] [PATCH] datapath-windows: use ip proto for tunnel port 
lookup

Thanks Nithin for working on this! The fix overall looks pretty good.

Can we get rid of OvsFindTunnelVportByPortType since it doesn't make much sense 
and is dangerous to call if user doesn't understand what it actually does?

Done in the v2.


Also, there is some misalignment in the following code. Did you use tab?

-if (tunnelVport) {
+tunnelVport =
+OvsFindTunnelVportByDstPortAndNWProto(ovsFwdCtx->switchContext,
+  dstPort,
+  flowKey->ipKey.nwProto);
+if (tunnelVport) {
+switch(tunnelVport->ovsType) {
+case OVS_VPORT_TYPE_STT:
 ovsActionStats.rxStt++;
-}

Alignment looks correct. I have checked it after applying the patch.

-- Nithin
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] [PATCH v5] datapath-windows: Add Geneve support

[Nithin Raju]

Yin,
I went ahead and sent out a patch for the updates w.r.t
OvsFindTunnelVportByDstPort(). Pls have a look:
https://patchwork.ozlabs.org/patch/628483/

I¹ll send out the comments for the remainder of the patch.

Thanks,
-- Nithin


-Original Message-
From: dev  on behalf of Yin Lin

Date: Tuesday, May 24, 2016 at 4:28 PM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH 2/2] [PATCH v5] datapath-windows: Add
Geneve  support

>Signed-off-by: Yin Lin 
>---
>Fixed checksum flag issue brought up by Jesse and automake.mk issue by
>Nithin.
>---
> datapath-windows/automake.mk   |   2 +
> datapath-windows/ovsext/Actions.c  |  82 +++-
> datapath-windows/ovsext/Debug.h|   1 +
> datapath-windows/ovsext/DpInternal.h   |  29 ++-
> datapath-windows/ovsext/Flow.c | 172 ++--
> datapath-windows/ovsext/Flow.h |   7 +
> datapath-windows/ovsext/Geneve.c   | 356
>+
> datapath-windows/ovsext/Geneve.h   | 122 +++
> datapath-windows/ovsext/Gre.c  |   7 +-
> datapath-windows/ovsext/Stt.c  |   2 +-
> datapath-windows/ovsext/Tunnel.c   |   3 +-
> datapath-windows/ovsext/Util.h |   1 +
> datapath-windows/ovsext/Vport.c|  23 ++-
> datapath-windows/ovsext/Vport.h|  10 +-
> datapath-windows/ovsext/ovsext.vcxproj |   2 +
> 15 files changed, 727 insertions(+), 92 deletions(-)
> create mode 100644 datapath-windows/ovsext/Geneve.c
> create mode 100644 datapath-windows/ovsext/Geneve.h
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index c9af806..53fb5c5 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -68,6 +68,8 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/Vport.h \
>   datapath-windows/ovsext/Vxlan.c \
>   datapath-windows/ovsext/Vxlan.h \
>+  datapath-windows/ovsext/Geneve.c \
>+  datapath-windows/ovsext/Geneve.h \
>   datapath-windows/ovsext/ovsext.inf \
>   datapath-windows/ovsext/ovsext.rc \
>   datapath-windows/ovsext/ovsext.vcxproj \
>diff --git a/datapath-windows/ovsext/Actions.c
>b/datapath-windows/ovsext/Actions.c
>index 5ad29ee..560f7a1 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -48,6 +48,8 @@ typedef struct _OVS_ACTION_STATS {
> UINT64 txVxlan;
> UINT64 rxStt;
> UINT64 txStt;
>+UINT64 rxGeneve;
>+UINT64 txGeneve;
> UINT64 flowMiss;
> UINT64 flowUserspace;
> UINT64 txTcp;
>@@ -227,18 +229,22 @@ OvsDetectTunnelRxPkt(OvsForwardingContext
>*ovsFwdCtx,
> break;
> case IPPROTO_TCP:
> tunnelVport =
>OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
>-  dstPort,
>- 
>OVS_VPORT_TYPE_STT);
>+  dstPort);
> if (tunnelVport) {
>+ASSERT(tunnelVport->ovsType == OVS_VPORT_TYPE_STT);
> ovsActionStats.rxStt++;
> }
> break;
> case IPPROTO_UDP:
> tunnelVport =
>OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
>-  dstPort,
>- 
>OVS_VPORT_TYPE_VXLAN);
>+  dstPort);
> if (tunnelVport) {
>-ovsActionStats.rxVxlan++;
>+if (tunnelVport->ovsType == OVS_VPORT_TYPE_VXLAN) {
>+ovsActionStats.rxVxlan++;
>+} else {
>+ASSERT(tunnelVport->ovsType ==
>OVS_VPORT_TYPE_GENEVE);
>+ovsActionStats.rxGeneve++;
>+}
> }
> break;
> }
>@@ -333,6 +339,9 @@ OvsDetectTunnelPkt(OvsForwardingContext *ovsFwdCtx,
> case OVS_VPORT_TYPE_STT:
> ovsActionStats.txStt++;
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+   ovsActionStats.txGeneve++;
>+   break;
> }
> ovsFwdCtx->tunnelTxNic = dstVport;
> }
>@@ -689,6 +698,11 @@ OvsTunnelPortTx(OvsForwardingContext *ovsFwdCtx)
>  >tunKey,
>ovsFwdCtx->switchContext,
>  >layers, );
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+status = OvsEncapGeneve(ovsFwdCtx->tunnelTxNic,
>ovsFwdCtx->curNbl,
>+>tunKey,
>ovsFwdCtx->switchContext,
>+>layers, );
>+break;
> default:
> ASSERT(! "Tx: Unhandled tunnel type");
> }
>@@ -767,6 +781,10 @@ OvsTunnelPortRx(OvsForwardingContext *ovsFwdCtx)
> dropReason = L"OVS-STT segment is cached";
> }
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+status = 

[ovs-dev] [PATCH] datapath-windows: use ip proto for tunnel port lookup

[Nithin Raju]

In Actions.c, based on the IP Protocol type and L4 port of
the outer packet, we lookup the tunnel port. The function
that made this happen took the tunnel type as an argument.
Semantically, is is better to pass the IP protocol type and
let the lookup code map IP protocol type to tunnel type.

In the vport add code, we make sure that we block tunnel
port addition if there's already a tunnel port that uses
the same IP protocol type and L4 port number.

This is required for Geneve port lookups the references to
which can find in the patch.

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Actions.c | 39 +++-
 datapath-windows/ovsext/Tunnel.c  |  6 ++--
 datapath-windows/ovsext/Vport.c   | 64 +--
 datapath-windows/ovsext/Vport.h   |  9 --
 4 files changed, 88 insertions(+), 30 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 4edf7d0..53be718 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -217,30 +217,27 @@ OvsDetectTunnelRxPkt(OvsForwardingContext *ovsFwdCtx,
  */
 if (!flowKey->ipKey.nwFrag) {
 UINT16 dstPort = htons(flowKey->ipKey.l4.tpDst);
-switch (flowKey->ipKey.nwProto) {
-case IPPROTO_GRE:
-tunnelVport = 
OvsFindTunnelVportByPortType(ovsFwdCtx->switchContext,
-   OVS_VPORT_TYPE_GRE);
-if (tunnelVport) {
-ovsActionStats.rxGre++;
-}
-break;
-case IPPROTO_TCP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_STT);
-if (tunnelVport) {
+tunnelVport =
+OvsFindTunnelVportByDstPortAndNWProto(ovsFwdCtx->switchContext,
+  dstPort,
+  flowKey->ipKey.nwProto);
+if (tunnelVport) {
+switch(tunnelVport->ovsType) {
+case OVS_VPORT_TYPE_STT:
 ovsActionStats.rxStt++;
-}
-break;
-case IPPROTO_UDP:
-tunnelVport = OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
-  dstPort,
-  OVS_VPORT_TYPE_VXLAN);
-if (tunnelVport) {
+break;
+case OVS_VPORT_TYPE_VXLAN:
 ovsActionStats.rxVxlan++;
+break;
+#if 0
+case OVS_VPORT_TYPE_GENEVE:
+ovsActionStats.rxGeneve++;
+break;
+#endif
+case OVS_VPORT_TYPE_GRE:
+ovsActionStats.rxGre++;
+break;
 }
-break;
 }
 }
 
diff --git a/datapath-windows/ovsext/Tunnel.c b/datapath-windows/ovsext/Tunnel.c
index 97d2020..c5aae1a 100644
--- a/datapath-windows/ovsext/Tunnel.c
+++ b/datapath-windows/ovsext/Tunnel.c
@@ -285,9 +285,9 @@ OvsInjectPacketThroughActions(PNET_BUFFER_LIST pNbl,
 
 SendFlags |= NDIS_SEND_FLAGS_DISPATCH_LEVEL;
 
-vport = OvsFindTunnelVportByDstPort(gOvsSwitchContext,
-htons(tunnelKey.dst_port),
-OVS_VPORT_TYPE_VXLAN);
+vport = OvsFindTunnelVportByDstPortAndType(gOvsSwitchContext,
+   htons(tunnelKey.dst_port),
+   OVS_VPORT_TYPE_VXLAN);
 
 if (vport == NULL){
 status = STATUS_UNSUCCESSFUL;
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index 222b2c1..f5eeaa5 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -691,9 +691,9 @@ OvsFindVportByPortNo(POVS_SWITCH_CONTEXT switchContext,
 
 
 POVS_VPORT_ENTRY
-OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT switchContext,
-UINT16 dstPort,
-OVS_VPORT_TYPE ovsPortType)
+OvsFindTunnelVportByDstPortAndType(POVS_SWITCH_CONTEXT switchContext,
+   UINT16 dstPort,
+   OVS_VPORT_TYPE ovsPortType)
 {
 POVS_VPORT_ENTRY vport;
 PLIST_ENTRY head, link;
@@ -711,6 +711,41 @@ OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT 
switchContext,
 }
 
 POVS_VPORT_ENTRY
+OvsFindTunnelVportByDstPortAndNWProto(POVS_SWITCH_CONTEXT switchContext,
+  UINT16 dstPort,
+  UINT8 nwProto)
+{
+POVS_VPORT_ENTRY vport;
+PLIST_ENTRY head, link;
+UINT32 hash = OvsJhashBytes((const VOID *), sizeof(dstPort),
+ 

Re: [ovs-dev] [PATCH 1/2] [PATCH v5] datapath-windows: Move UDP checksum computation to Offload.c

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Yin Lin
<li...@vmware.com>
Date: Tuesday, May 24, 2016 at 4:28 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH 1/2] [PATCH v5] datapath-windows: Move UDP
checksum computation to Offload.c

>UDP checksum computation is shared by both vxlan and geneve on Windows.
>Move the function so that the code can be shared.
>
>Signed-off-by: Yin Lin<li...@vmware.com>
>
>---
>No change.
>---
> datapath-windows/ovsext/Offload.c | 45
>
> datapath-windows/ovsext/Offload.h |  6 -
> datapath-windows/ovsext/Vxlan.c   | 48
>+++
> 3 files changed, 53 insertions(+), 46 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Offload.c
>b/datapath-windows/ovsext/Offload.c
>index 1e43a9e..921c732 100644
>--- a/datapath-windows/ovsext/Offload.c
>+++ b/datapath-windows/ovsext/Offload.c
>@@ -597,6 +597,51 @@ OvsValidateUDPChecksum(PNET_BUFFER_LIST curNbl,
>BOOLEAN udpCsumZero)
> 
> 
> /*
>+ 
>*-
>---
>+ * OvsCalculateUDPChecksum
>+ * Calculate UDP checksum
>+ 
>*-
>---
>+ */
>+NDIS_STATUS
>+OvsCalculateUDPChecksum(PNET_BUFFER_LIST curNbl,
>+PNET_BUFFER curNb,
>+IPHdr *ipHdr,
>+UDPHdr *udpHdr,
>+UINT32 packetLength)
>+{
>+NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
>+UINT16 checkSum;
>+
>+csumInfo.Value = NET_BUFFER_LIST_INFO(curNbl,
>TcpIpChecksumNetBufferListInfo);
>+
>+/* Next check if UDP checksum has been calculated. */
>+if (!csumInfo.Receive.UdpChecksumSucceeded) {
>+UINT32 l4Payload;
>+
>+checkSum = udpHdr->check;
>+
>+l4Payload = packetLength - sizeof(EthHdr) - ipHdr->ihl * 4;
>+udpHdr->check = 0;
>+udpHdr->check =
>+IPPseudoChecksum((UINT32 *)>saddr,
>+ (UINT32 *)>daddr,
>+ IPPROTO_UDP, (UINT16)l4Payload);
>+udpHdr->check = CalculateChecksumNB(curNb, (UINT16)l4Payload,
>+sizeof(EthHdr) + ipHdr->ihl
>* 4);
>+if (checkSum != udpHdr->check) {
>+OVS_LOG_TRACE("UDP checksum incorrect.");
>+return NDIS_STATUS_INVALID_PACKET;
>+}
>+}
>+
>+csumInfo.Receive.UdpChecksumSucceeded = 1;
>+NET_BUFFER_LIST_INFO(curNbl, TcpIpChecksumNetBufferListInfo) =
>csumInfo.Value;
>+return NDIS_STATUS_SUCCESS;
>+}
>+
>+
>+
>+/*
>  * OvsApplySWChecksumOnNB --
>  *
>  * This function calculates and sets the required sofware offloads given
>by
>diff --git a/datapath-windows/ovsext/Offload.h
>b/datapath-windows/ovsext/Offload.h
>index b5cae2f..d3731b1 100644
>--- a/datapath-windows/ovsext/Offload.h
>+++ b/datapath-windows/ovsext/Offload.h
>@@ -35,7 +35,11 @@ NDIS_STATUS OvsValidateIPChecksum(PNET_BUFFER_LIST
>curNbl,
>   POVS_PACKET_HDR_INFO hdrInfo);
> NDIS_STATUS OvsValidateUDPChecksum(PNET_BUFFER_LIST curNbl,
>BOOLEAN udpCsumZero);
>-
>+NDIS_STATUS OvsCalculateUDPChecksum(PNET_BUFFER_LIST curNbl,
>+PNET_BUFFER curNb,
>+IPHdr *ipHdr,
>+UDPHdr *udpHdr,
>+UINT32 packetLength);
> 
> ULONG OVSGetTcpMSS(PNET_BUFFER_LIST nbl);
> 
>diff --git a/datapath-windows/ovsext/Vxlan.c
>b/datapath-windows/ovsext/Vxlan.c
>index 20214cb..765f5f1 100644
>--- a/datapath-windows/ovsext/Vxlan.c
>+++ b/datapath-windows/ovsext/Vxlan.c
>@@ -353,48 +353,6 @@ OvsEncapVxlan(POVS_VPORT_ENTRY vport,
>switchContext, newNbl);
> }
> 
>-/*
>- 
>*-
>---
>- * OvsCalculateUDPChecksum
>- * Calculate UDP checksum
>- 
>*-
>---
>- */
>-static __inline NDIS_STATUS
>-OvsCalculateUDPChecksum(PNET_BUFFER_LIST curNbl,
>-PNET_BUFFER curNb,
>-IPHdr *ipHdr,
>-UDPHdr *udpHdr,
>-UINT32 packetLength)
>-{
>-NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
>-UI

Re: [ovs-dev] [PATCH v2 3/3] datapath-windows: Add GRE checksum

[Nithin Raju]

-Original Message-
From: dev  on behalf of Alin Serdean

Date: Tuesday, May 24, 2016 at 9:14 AM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH v2 3/3] datapath-windows: Add GRE checksum

>@@ -369,11 +383,25 @@ OvsDecapGre(POVS_SWITCH_CONTEXT switchContext,
> headRoom += 4;
> }
> 
>+/*
>+ * Create a copy of the NBL so that we have all the headers in one
>MDL.
>+ */
>+*newNbl = OvsPartialCopyNBL(switchContext, curNbl,
>+tunnelSize, 0,
>+TRUE /*copy NBL info */);
>+
>+if (*newNbl == NULL) {
>+return NDIS_STATUS_RESOURCES;
>+}
>+
>+curNbl = *newNbl;
>+curNb = NET_BUFFER_LIST_FIRST_NB(curNbl);

The reason we were doing the partial copy earlier is to make sure that ETH
+ IP + GRE headers are all in the first MDL. The code access these headers
assuming they are contiguous in memory. Is there a good reason to move
that code down to here?

Looks good otherwise.

Thanks,
-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2 1/3] datapath-windows: Add UDP checksum verifications for VXLAN

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Alin Serdean
<aserd...@cloudbasesolutions.com>
Date: Tuesday, May 24, 2016 at 9:14 AM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH v2 1/3] datapath-windows: Add UDP checksum
verifications for VXLAN

>Introduce UDP checksum if it was specified in the tunnel information
>on Tx.
>
>Set the tunnel checksum information flag on the flow if the
>UDP checksum was non zero on the Rx.
>
>Signed-off-by: Alin Gabriel Serdean <aserd...@cloudbasesolutions.com>
>---
>v2: Address comments
>---
> datapath-windows/ovsext/Vxlan.c | 43
>+++--
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Vxlan.c
>b/datapath-windows/ovsext/Vxlan.c
>index 20214cb..520f313 100644
>--- a/datapath-windows/ovsext/Vxlan.c
>+++ b/datapath-windows/ovsext/Vxlan.c
>@@ -192,6 +192,7 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> UINT32 headRoom = OvsGetVxlanTunHdrSize();
> UINT32 packetLength;
> ULONG mss = 0;
>+NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
> 
> /*
>  * XXX: the assumption currently is that the NBL is owned by OVS, and
>@@ -230,7 +231,6 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> OVS_LOG_ERROR("Unable to copy NBL");
> return NDIS_STATUS_FAILURE;
> }
>-NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
> csumInfo.Value = NET_BUFFER_LIST_INFO(curNbl,
>  
>TcpIpChecksumNetBufferListInfo);
> status = OvsApplySWChecksumOnNB(layers, *newNbl, );
>@@ -249,7 +249,8 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> }
> 
> curMdl = NET_BUFFER_CURRENT_MDL(curNb);
>-bufferStart = (PUINT8)MmGetSystemAddressForMdlSafe(curMdl,
>LowPagePriority);
>+bufferStart = (PUINT8)MmGetSystemAddressForMdlSafe(curMdl,
>+ 
>LowPagePriority);
> if (!bufferStart) {
> status = NDIS_STATUS_RESOURCES;
> goto ret_error;
>@@ -257,7 +258,8 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> 
> bufferStart += NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
> if (NET_BUFFER_NEXT_NB(curNb)) {
>-OVS_LOG_TRACE("nb length %u next %u",
>NET_BUFFER_DATA_LENGTH(curNb),
>+OVS_LOG_TRACE("nb length %u next %u",
>+  NET_BUFFER_DATA_LENGTH(curNb),
>   NET_BUFFER_DATA_LENGTH(curNb->Next));
> }
> 
>@@ -288,7 +290,6 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> ipHdr->daddr = fwdInfo->dstIpAddr;
> 
> ipHdr->check = 0;
>-ipHdr->check = IPChecksum((UINT8 *)ipHdr, sizeof *ipHdr, 0);
> 
> /* UDP header */
> udpHdr = (UDPHdr *)((PCHAR)ipHdr + sizeof *ipHdr);
>@@ -296,7 +297,13 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> udpHdr->dest = htons(vportVxlan->dstPort);
> udpHdr->len = htons(NET_BUFFER_DATA_LENGTH(curNb) - headRoom +
> sizeof *udpHdr + sizeof *vxlanHdr);
>-udpHdr->check = 0;
>+
>+if (tunKey->flags & OVS_TNL_F_CSUM) {
>+udpHdr->check = IPPseudoChecksum(>saddr,
>>daddr,
>+ IPPROTO_UDP,
>ntohs(udpHdr->len));
>+} else {
>+udpHdr->check = 0;
>+}
> 
> /* VXLAN header */
> vxlanHdr = (VXLANHdr *)((PCHAR)udpHdr + sizeof *udpHdr);
>@@ -308,6 +315,17 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> vxlanHdr->instanceID = 1;
> vxlanHdr->reserved2 = 0;
> }
>+
>+csumInfo.Value = 0;
>+csumInfo.Transmit.IpHeaderChecksum = 1;
>+csumInfo.Transmit.IsIPv4 = 1;
>+if (tunKey->flags & OVS_TNL_F_CSUM) {
>+csumInfo.Transmit.UdpChecksum = 1;
>+}
>+NET_BUFFER_LIST_INFO(curNbl,
>+ TcpIpChecksumNetBufferListInfo) =
>csumInfo.Value;
>+
>+
> return STATUS_SUCCESS;
> 
> ret_error:
>@@ -466,7 +484,9 @@ OvsDecapVxlan(POVS_SWITCH_CONTEXT switchContext,
> 
> /* Calculate and verify UDP checksum if NIC didn't do it. */
> if (udpHdr->check != 0) {
>-status = OvsCalculateUDPChecksum(curNbl, curNb, ipHdr, udpHdr,
>packetLength);
>+tunKey->flags |= OVS_TNL_F_CSUM;
>+status = OvsCalculateUDPChecksum(curNbl, curNb, ipHdr, udpHdr,
>+ packetLength);
> if (status != NDIS_STATUS_SUCCESS) {
> goto dropNbl;
> 

[ovs-dev] [PATCH] list.h: Define OVS_LIST_POISON statically

[Nithin Raju]

Looks like part of the patch committed in e32c1f7c
got left out while moving header files.

Signed-off-by: Nithin Raju <nit...@vmware.com>
Reported-by: Joe Stringer <j...@ovn.org>
---
 include/openvswitch/list.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/openvswitch/list.h b/include/openvswitch/list.h
index 32f83a0..5c2cca4 100644
--- a/include/openvswitch/list.h
+++ b/include/openvswitch/list.h
@@ -39,9 +39,6 @@ struct ovs_list {
 static const struct ovs_list OVS_LIST_POISON =
 { (struct ovs_list *) (UINTPTR_MAX / 0xf * 0xc),
   (struct ovs_list *) (UINTPTR_MAX / 0xf * 0xc) };
-#define OVS_LIST_POISON \
-(struct ovs_list) { (struct ovs_list *) (uintptr_t) 0xULL, \
-(struct ovs_list *) (uintptr_t) 0xULL }
 
 static inline void ovs_list_init(struct ovs_list *);
 static inline void ovs_list_poison(struct ovs_list *);
-- 
2.6.2

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] [PATCH v4] datapath-windows: Add Geneve support

[Nithin Raju]

I’ll review the reminder of the code too since it looks to be closer to
the final version.

If you are interesting in making the patch smaller, I’d recommend that you
move the changes to OvsTunnelAttrToIPv4TunnelKey() into a separate patch.

-- Nithin

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Nithin Raju
<nit...@vmware.com>
Date: Tuesday, May 24, 2016 at 9:32 AM
To: Yin Lin <li...@vmware.com>, "dev@openvswitch.org" <dev@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH 2/2] [PATCH v4] datapath-windows: Add Geneve
support

>Hi Yin,
>You also need to update datapath-windows/automake.mk to add the new files
>you added.
>
>-Original Message-
>From: dev <dev-boun...@openvswitch.org> on behalf of Yin Lin
><li...@vmware.com>
>Date: Friday, May 20, 2016 at 1:57 PM
>To: "dev@openvswitch.org" <dev@openvswitch.org>
>Subject: [ovs-dev] [PATCH 2/2] [PATCH v4] datapath-windows: Add
>Geneve support
>
>> case IPPROTO_UDP:
>> tunnelVport =
>>OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
>>-  dstPort,
>>-
>>OVS_VPORT_TYPE_VXLAN);
>>+  dstPort);
>> if (tunnelVport) {
>>-ovsActionStats.rxVxlan++;
>>+if (tunnelVport->ovsType == OVS_VPORT_TYPE_VXLAN) {
>>+ovsActionStats.rxVxlan++;
>>+} else {
>>+ASSERT(tunnelVport->ovsType ==
>>OVS_VPORT_TYPE_GENEVE);
>>+ovsActionStats.rxGeneve++;
>>+}
>
>You cannot remove the port type from OvsFindTunnelVportByDstPort(). OVS
>should support the case where there¹s a STT port (ie. TCP port) on port
>XYZ, and a VXLAN port (i.e.. UDP) on port XYZ. I am not sure if you need
>to support a case with Geneve and VXLAN ports on the same UDP port #.
>
>
>Your code changes are mostly right, except that you should not be removing
>the port type parameter in OvsFindTunnelVportByDstPort(). If you have
>concurrent STT and VXLAN ports on the same L4 port number, we¹ll end up
>returning the first port in the hash table, and that is not the correct
>behavior.
>
>If we are not going to support the case where Geneve and VXLAN ports can
>co-exist on the same UDP port #, we should add a check in the port add
>functionality.
>
>Thanks,
>-- Nithin
>
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=i3FRL3zYPSXu2hduqcxST52V-73irB
>w7HzZilzhX32g=WCyaO0MAZPFzldjumzehfvvn0OZ-v293izABXwLDfXU= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] [PATCH v4] datapath-windows: Add Geneve support

[Nithin Raju]

Hi Yin,
You also need to update datapath-windows/automake.mk to add the new files
you added.

-Original Message-
From: dev  on behalf of Yin Lin

Date: Friday, May 20, 2016 at 1:57 PM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH 2/2] [PATCH v4] datapath-windows: Add
Geneve  support

> case IPPROTO_UDP:
> tunnelVport =
>OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
>-  dstPort,
>- 
>OVS_VPORT_TYPE_VXLAN);
>+  dstPort);
> if (tunnelVport) {
>-ovsActionStats.rxVxlan++;
>+if (tunnelVport->ovsType == OVS_VPORT_TYPE_VXLAN) {
>+ovsActionStats.rxVxlan++;
>+} else {
>+ASSERT(tunnelVport->ovsType ==
>OVS_VPORT_TYPE_GENEVE);
>+ovsActionStats.rxGeneve++;
>+}

You cannot remove the port type from OvsFindTunnelVportByDstPort(). OVS
should support the case where there¹s a STT port (ie. TCP port) on port
XYZ, and a VXLAN port (i.e.. UDP) on port XYZ. I am not sure if you need
to support a case with Geneve and VXLAN ports on the same UDP port #.


Your code changes are mostly right, except that you should not be removing
the port type parameter in OvsFindTunnelVportByDstPort(). If you have
concurrent STT and VXLAN ports on the same L4 port number, we¹ll end up
returning the first port in the hash table, and that is not the correct
behavior.

If we are not going to support the case where Geneve and VXLAN ports can
co-exist on the same UDP port #, we should add a check in the port add
functionality.

Thanks,
-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] [PATCH v2] datapath-windows: Move UDP checksum computation to Offload.c

[Nithin Raju]

I am assuming that you¹ve run some tests using VXLAN tunnels.

Acked-by: Nithin Raju <nit...@vmware.com>

Thanks for the patch.

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Yin Lin
<li...@vmware.com>
Date: Friday, May 20, 2016 at 1:57 PM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH 1/2] [PATCH v2] datapath-windows: Move UDP
checksum computation to Offload.c

>UDP checksum computation is shared by both vxlan and geneve on Windows.
>Move the function so that the code can be shared.
>
>Signed-off-by: Yin Lin<li...@vmware.com>
>
>---
>Do not copy the inner ethernet header as it's not used.
>---
> datapath-windows/ovsext/Offload.c | 45
>
> datapath-windows/ovsext/Offload.h |  6 -
> datapath-windows/ovsext/Vxlan.c   | 48
>+++
> 3 files changed, 53 insertions(+), 46 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Offload.c
>b/datapath-windows/ovsext/Offload.c
>index 1e43a9e..921c732 100644
>--- a/datapath-windows/ovsext/Offload.c
>+++ b/datapath-windows/ovsext/Offload.c
>@@ -597,6 +597,51 @@ OvsValidateUDPChecksum(PNET_BUFFER_LIST curNbl,
>BOOLEAN udpCsumZero)
> 
> 
> /*
>+ 
>*-
>---
>+ * OvsCalculateUDPChecksum
>+ * Calculate UDP checksum
>+ 
>*-
>---
>+ */
>+NDIS_STATUS
>+OvsCalculateUDPChecksum(PNET_BUFFER_LIST curNbl,
>+PNET_BUFFER curNb,
>+IPHdr *ipHdr,
>+UDPHdr *udpHdr,
>+UINT32 packetLength)
>+{
>+NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
>+UINT16 checkSum;
>+
>+csumInfo.Value = NET_BUFFER_LIST_INFO(curNbl,
>TcpIpChecksumNetBufferListInfo);
>+
>+/* Next check if UDP checksum has been calculated. */
>+if (!csumInfo.Receive.UdpChecksumSucceeded) {
>+UINT32 l4Payload;
>+
>+checkSum = udpHdr->check;
>+
>+l4Payload = packetLength - sizeof(EthHdr) - ipHdr->ihl * 4;
>+udpHdr->check = 0;
>+udpHdr->check =
>+IPPseudoChecksum((UINT32 *)>saddr,
>+ (UINT32 *)>daddr,
>+ IPPROTO_UDP, (UINT16)l4Payload);
>+udpHdr->check = CalculateChecksumNB(curNb, (UINT16)l4Payload,
>+sizeof(EthHdr) + ipHdr->ihl
>* 4);
>+if (checkSum != udpHdr->check) {
>+OVS_LOG_TRACE("UDP checksum incorrect.");
>+return NDIS_STATUS_INVALID_PACKET;
>+}
>+}
>+
>+csumInfo.Receive.UdpChecksumSucceeded = 1;
>+NET_BUFFER_LIST_INFO(curNbl, TcpIpChecksumNetBufferListInfo) =
>csumInfo.Value;
>+return NDIS_STATUS_SUCCESS;
>+}
>+
>+
>+
>+/*
>  * OvsApplySWChecksumOnNB --
>  *
>  * This function calculates and sets the required sofware offloads given
>by
>diff --git a/datapath-windows/ovsext/Offload.h
>b/datapath-windows/ovsext/Offload.h
>index b5cae2f..d3731b1 100644
>--- a/datapath-windows/ovsext/Offload.h
>+++ b/datapath-windows/ovsext/Offload.h
>@@ -35,7 +35,11 @@ NDIS_STATUS OvsValidateIPChecksum(PNET_BUFFER_LIST
>curNbl,
>   POVS_PACKET_HDR_INFO hdrInfo);
> NDIS_STATUS OvsValidateUDPChecksum(PNET_BUFFER_LIST curNbl,
>BOOLEAN udpCsumZero);
>-
>+NDIS_STATUS OvsCalculateUDPChecksum(PNET_BUFFER_LIST curNbl,
>+PNET_BUFFER curNb,
>+IPHdr *ipHdr,
>+UDPHdr *udpHdr,
>+UINT32 packetLength);
> 
> ULONG OVSGetTcpMSS(PNET_BUFFER_LIST nbl);
> 
>diff --git a/datapath-windows/ovsext/Vxlan.c
>b/datapath-windows/ovsext/Vxlan.c
>index 20214cb..765f5f1 100644
>--- a/datapath-windows/ovsext/Vxlan.c
>+++ b/datapath-windows/ovsext/Vxlan.c
>@@ -353,48 +353,6 @@ OvsEncapVxlan(POVS_VPORT_ENTRY vport,
>switchContext, newNbl);
> }
> 
>-/*
>- 
>*-
>---
>- * OvsCalculateUDPChecksum
>- * Calculate UDP checksum
>- 
>*-
>---
>- */
>-static __inline NDIS_STATUS
>-OvsCalculateUDPChecksum(PNET_BUFFER_LIST curNbl,
>-PNET_BUFFER curNb,
>-IPHdr *ipHdr,
>-UDPHdr *udpHdr,
>-  

Re: [ovs-dev] [PATCH 3/3] [PATCH v3] Add Geneve support in Windows datapath

[Nithin Raju]

-Original Message-
From: dev  on behalf of Yin Lin

Date: Thursday, May 19, 2016 at 2:49 PM
To: "dev@openvswitch.org" 
Cc: Yin Lin 
Subject: [ovs-dev] [PATCH 3/3] [PATCH v3] Add Geneve support in
Windows datapath

>OvsFindTunnelVportByDstPort(POVS_SWITCH_CONTEXT switchContext,
>-UINT16 dstPort,
>-OVS_VPORT_TYPE ovsPortType)
>+UINT16 dstPort)

What is the rationale for this change? The reason we are also passing
ŒovsPortType¹ is that you can have a VXLAN and an STT tunnel for instance
on the same L4 port number. So, we need to distinguish between the two.

-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/3] [PATCH v1] Move UDP checksum computation to Offload.c

[Nithin Raju]

Thanks for the patch.

>@@ -414,7 +372,7 @@ OvsDecapVxlan(POVS_SWITCH_CONTEXT switchContext,
> IPHdr *ipHdr;
> UDPHdr *udpHdr;
> VXLANHdr *vxlanHdr;
>-UINT32 tunnelSize = 0, packetLength = 0;
>+UINT32 tunnelSize, packetLength, copySize;
> PUINT8 bufferStart;
> NDIS_STATUS status;
> 
>@@ -422,7 +380,8 @@ OvsDecapVxlan(POVS_SWITCH_CONTEXT switchContext,
> curNb = NET_BUFFER_LIST_FIRST_NB(curNbl);
> packetLength = NET_BUFFER_DATA_LENGTH(curNb);
> tunnelSize = OvsGetVxlanTunHdrSize();
>-if (packetLength <= tunnelSize) {
>+copySize = tunnelSize + OVS_DEFAULT_COPY_SIZE;
>+if (packetLength < copySize) {
> return NDIS_STATUS_INVALID_LENGTH;
> }
> 
>@@ -430,7 +389,7 @@ OvsDecapVxlan(POVS_SWITCH_CONTEXT switchContext,
>  * Create a copy of the NBL so that we have all the headers in one
>MDL.
>  */
> *newNbl = OvsPartialCopyNBL(switchContext, curNbl,
>-tunnelSize + OVS_DEFAULT_COPY_SIZE, 0,
>+copySize, 0,
> TRUE /*copy NBL info */);
> 
> if (*newNbl == NULL) {

We don¹t need to use tunnelSize + OVS_DEFAULT_COPY_SIZE in the partial
copy. Just ŒtunnelSize¹ is sufficient. But, not a big deal.

Acked-by: Nithin Raju <nit...@vmware.com>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/3] ovn test: add '-O OpenFlow13' to ovs-ofctl

[Nithin Raju]

Yin,
Looks like you did a ³git send-email² on a patch that was not yours. It is
fine, I¹ll review the remaining 2 in the series.

Thanks for breaking it up.

-- Nithin

-Original Message-
From: dev  on behalf of Yin Lin

Date: Thursday, May 19, 2016 at 2:49 PM
To: "dev@openvswitch.org" 
Cc: Flavio Fernandes 
Subject: [ovs-dev] [PATCH 1/3] ovn test: add '-O OpenFlow13' to ovs-ofctl

>From: Flavio Fernandes 
>
>Make test calls to ovs-ofctl in test use the protocol parameter
>'-O OpenFlow13', so it is consistent with the existing dump-flows
>invocations.
>
>Signed-off-by: Flavio Fernandes 
>Signed-off-by: Ben Pfaff 
>---
> tests/ovn.at | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/tests/ovn.at b/tests/ovn.at
>index 1127cea..e6ac1d7 100644
>--- a/tests/ovn.at
>+++ b/tests/ovn.at
>@@ -1176,12 +1176,12 @@ ovn-sbctl show
> 
> echo "-- hv1 dump --"
> as hv1 ovs-vsctl show
>-as hv1 ovs-ofctl show br-int
>+as hv1 ovs-ofctl -O OpenFlow13 show br-int
> as hv1 ovs-ofctl -O OpenFlow13 dump-flows br-int
> 
> echo "-- hv2 dump --"
> as hv2 ovs-vsctl show
>-as hv2 ovs-ofctl show br-int
>+as hv2 ovs-ofctl -O OpenFlow13 show br-int
> as hv2 ovs-ofctl -O OpenFlow13 dump-flows br-int
> 
> echo "-- hv3 dump --"
>@@ -1997,17 +1997,17 @@ ovn-sbctl dump-flows -- list multicast_group
> 
> echo "-- hv1 dump --"
> as hv1 ovs-vsctl show
>-as hv1 ovs-ofctl show br-int
>+as hv1 ovs-ofctl -O OpenFlow13 show br-int
> as hv1 ovs-ofctl -O OpenFlow13 dump-flows br-int
> 
> echo "-- hv2 dump --"
> as hv2 ovs-vsctl show
>-as hv2 ovs-ofctl show br-int
>+as hv2 ovs-ofctl -O OpenFlow13 show br-int
> as hv2 ovs-ofctl -O OpenFlow13 dump-flows br-int
> 
> echo "-- hv3 dump --"
> as hv3 ovs-vsctl show
>-as hv3 ovs-ofctl show br-int
>+as hv3 ovs-ofctl -O OpenFlow13 show br-int
> as hv3 ovs-ofctl -O OpenFlow13 dump-flows br-int
> 
> # Now check the packets actually received against the ones expected.
>-- 
>2.8.0.windows.1
>
>___
>dev mailing list
>dev@openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 1/2] datapath-windows: don't map output buffer in OVS_IOCTL_WRITE

[Nithin Raju]

The contract of OVS_IOCTL_WRITE is that write operations
will not need the output buffer. Only the input buffer
will be used in the IRP. So, better to not map the output
buffer at all.

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Datapath.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/datapath-windows/ovsext/Datapath.c 
b/datapath-windows/ovsext/Datapath.c
index 1f89964..e33027c 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -869,19 +869,6 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
 goto done;
 }
 
-/*
- * Output buffer not mandatory but map it in case we have something
- * to return to requester.
-*/
-if (outputBufferLen != 0) {
-status = MapIrpOutputBuffer(irp, outputBufferLen,
-sizeof *ovsMsg, );
-if (status != STATUS_SUCCESS) {
-goto done;
-}
-ASSERT(outputBuffer);
-}
-
 ovsMsg = inputBuffer;
 ovsMsgLength = inputBufferLen;
 devOp = OVS_WRITE_DEV_OP;
-- 
2.7.1.windows.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/2] datapath-windows: o/p buffer must fit NL error message

[Nithin Raju]

OVS_IOCTL_WRITE and OVS_IOCTL_TRANSACT can generate a
netlink error that is represented by a OVS_MESSAGE_ERROR
struct. We want to make sure at the entry point of the
ioctl processing that the output buffer is big enough
to hold the error message. We were earlier checking
for struct OVS_MESSAGE which is smaller.

Since we are ensuring that output buffer can fit
OVS_MESSAGE_ERROR at the top of the ioctl function,
there's no need to check for that later.

Signed-off-by: Nithin Raju <nit...@vmware.com>
---
 datapath-windows/ovsext/Datapath.c| 19 --
 datapath-windows/ovsext/Flow.c| 16 ++--
 datapath-windows/ovsext/Netlink/Netlink.c | 11 ++--
 datapath-windows/ovsext/Netlink/Netlink.h |  1 -
 datapath-windows/ovsext/User.c|  4 +--
 datapath-windows/ovsext/Vport.c   | 42 +--
 6 files changed, 48 insertions(+), 45 deletions(-)

diff --git a/datapath-windows/ovsext/Datapath.c 
b/datapath-windows/ovsext/Datapath.c
index e33027c..b2c7020 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -759,8 +759,10 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
 case OVS_IOCTL_TRANSACT:
 /* Both input buffer and output buffer are mandatory. */
 if (outputBufferLen != 0) {
+ASSERT(sizeof(OVS_MESSAGE_ERROR) >= sizeof *ovsMsg);
 status = MapIrpOutputBuffer(irp, outputBufferLen,
-sizeof *ovsMsg, );
+sizeof(OVS_MESSAGE_ERROR),
+);
 if (status != STATUS_SUCCESS) {
 goto done;
 }
@@ -788,7 +790,8 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
  */
 if (outputBufferLen != 0) {
 status = MapIrpOutputBuffer(irp, outputBufferLen,
-sizeof *ovsMsg, );
+sizeof(OVS_MESSAGE_ERROR),
+);
 if (status != STATUS_SUCCESS) {
 goto done;
 }
@@ -820,7 +823,8 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
 /* Output buffer is mandatory. */
 if (outputBufferLen != 0) {
 status = MapIrpOutputBuffer(irp, outputBufferLen,
-sizeof *ovsMsg, );
+sizeof(OVS_MESSAGE_ERROR),
+);
 if (status != STATUS_SUCCESS) {
 goto done;
 }
@@ -1050,7 +1054,6 @@ InvokeNetlinkCmdHandler(POVS_USER_PARAMS_CONTEXT 
usrParamsCtx,
 POVS_MESSAGE msgIn = NULL;
 POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
 usrParamsCtx->outputBuffer;
-UINT32 msgErrorLen = usrParamsCtx->outputLength;
 
 if (usrParamsCtx->ovsMsg->genlMsg.cmd == OVS_CTRL_CMD_EVENT_NOTIFY 
||
 usrParamsCtx->ovsMsg->genlMsg.cmd == OVS_CTRL_CMD_READ_NOTIFY) 
{
@@ -1066,7 +1069,8 @@ InvokeNetlinkCmdHandler(POVS_USER_PARAMS_CONTEXT 
usrParamsCtx,
 
 ASSERT(msgIn);
 ASSERT(msgError);
-NlBuildErrorMsg(msgIn, msgError, msgErrorLen, nlError, replyLen);
+NlBuildErrorMsg(msgIn, msgError, nlError, replyLen);
+ASSERT(*replyLen != 0);
 }
 
 if (*replyLen != 0) {
@@ -1438,9 +1442,10 @@ cleanup:
 if (nlError != NL_ERROR_SUCCESS) {
 POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
 usrParamsCtx->outputBuffer;
-UINT32 msgErrorLen = usrParamsCtx->outputLength;
 
-NlBuildErrorMsg(msgIn, msgError, msgErrorLen, nlError, replyLen);
+ASSERT(msgError);
+NlBuildErrorMsg(msgIn, msgError, nlError, replyLen);
+ASSERT(*replyLen != 0);
 }
 
 return STATUS_SUCCESS;
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index d9b4f2a..c2e0227 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -398,9 +398,10 @@ done:
 if (nlError != NL_ERROR_SUCCESS) {
 POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
usrParamsCtx->outputBuffer;
-UINT32 msgErrorLen = usrParamsCtx->outputLength;
 
-NlBuildErrorMsg(msgIn, msgError, msgErrorLen, nlError, replyLen);
+ASSERT(msgError);
+NlBuildErrorMsg(msgIn, msgError, nlError, replyLen);
+ASSERT(*replyLen != 0);
 rc = STATUS_SUCCESS;
 }
 
@@ -568,9 +569,10 @@ done:
 if (nlError != NL_ERROR_SUCCESS) {
 POVS_MESSAGE_ERROR msgError = (POVS_MESSAGE_ERROR)
   usrParamsCtx->outputBuffer;
-UINT32 msgErrorLen = usrParamsCtx->outputLength;
 
-NlBuildErrorMsg(msgIn, msgError, msgErrorLen, nlError, replyLen);
+ASSERT(msgErr

Re: [ovs-dev] [PATCH V2] datapath-windows: Validate netlink packets integrity

[Nithin Raju]

Hi Paul,
I looked at the change in detail and it is definitely in the right spirit
to harden the kernel datapath code.

However, I thought a few things could be simplified a little. I will be
sending out a couple of simple reviews on top of your patch (that is
already submitted). Pls. take a look.

Other than that the patch looks good.

Thanks,
-- Nithin

-Original Message-
From: dev  on behalf of Paul Boca

Date: Wednesday, April 27, 2016 at 1:05 AM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH V2] datapath-windows: Validate netlink
packets integrity

>Solved access violation when trying to acces netling message - obtained
>with forged IOCTLs
>
>Signed-off-by: Paul-Daniel Boca 
>Acked-by: Alin Gabriel Serdean 
>---
>V2: Fixed alignement problems
>---
> datapath-windows/ovsext/Datapath.c| 45 ++---
> datapath-windows/ovsext/Flow.c| 42 +++-
> datapath-windows/ovsext/Netlink/Netlink.c | 66
>++-
> datapath-windows/ovsext/Netlink/Netlink.h | 13 --
> datapath-windows/ovsext/User.c|  5 ++-
> datapath-windows/ovsext/Vport.c   | 34 
> lib/netlink-socket.c  |  2 +
> 7 files changed, 152 insertions(+), 55 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Datapath.c
>b/datapath-windows/ovsext/Datapath.c
>index 06f99b3..1f89964 100644
>--- a/datapath-windows/ovsext/Datapath.c
>+++ b/datapath-windows/ovsext/Datapath.c
>@@ -307,6 +307,7 @@ static NTSTATUS MapIrpOutputBuffer(PIRP irp,
> static NTSTATUS ValidateNetlinkCmd(UINT32 devOp,
>POVS_OPEN_INSTANCE instance,
>POVS_MESSAGE ovsMsg,
>+   UINT32 ovsMgsLength,
>NETLINK_FAMILY *nlFamilyOps);
> static NTSTATUS InvokeNetlinkCmdHandler(POVS_USER_PARAMS_CONTEXT
>usrParamsCtx,
> NETLINK_FAMILY *nlFamilyOps,
>@@ -694,6 +695,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
> UINT32 devOp;
> OVS_MESSAGE ovsMsgReadOp;
> POVS_MESSAGE ovsMsg;
>+UINT32 ovsMsgLength = 0;
> NETLINK_FAMILY *nlFamilyOps;
> OVS_USER_PARAMS_CONTEXT usrParamsCtx;
> 
>@@ -774,6 +776,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
> }
> 
> ovsMsg = inputBuffer;
>+ovsMsgLength = inputBufferLen;
> devOp = OVS_TRANSACTION_DEV_OP;
> break;
> 
>@@ -808,6 +811,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
>   OVS_CTRL_CMD_EVENT_NOTIFY :
>   OVS_CTRL_CMD_READ_NOTIFY;
> ovsMsg->genlMsg.version = nlControlFamilyOps.version;
>+ovsMsgLength = outputBufferLen;
> 
> devOp = OVS_READ_DEV_OP;
> break;
>@@ -853,6 +857,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
> 
> /* Create an NL message for consumption. */
> ovsMsg = 
>+ovsMsgLength = sizeof (ovsMsgReadOp);
> devOp = OVS_READ_DEV_OP;
> 
> break;
>@@ -864,7 +869,21 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
> goto done;
> }
> 
>+/*
>+ * Output buffer not mandatory but map it in case we have
>something
>+ * to return to requester.
>+*/
>+if (outputBufferLen != 0) {
>+status = MapIrpOutputBuffer(irp, outputBufferLen,
>+sizeof *ovsMsg, );
>+if (status != STATUS_SUCCESS) {
>+goto done;
>+}
>+ASSERT(outputBuffer);
>+}
>+
> ovsMsg = inputBuffer;
>+ovsMsgLength = inputBufferLen;
> devOp = OVS_WRITE_DEV_OP;
> break;
> 
>@@ -903,7 +922,8 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
>  * "artificial" or was copied from a previously validated 'ovsMsg'.
>  */
> if (devOp != OVS_READ_DEV_OP) {
>-status = ValidateNetlinkCmd(devOp, instance, ovsMsg,
>nlFamilyOps);
>+status = ValidateNetlinkCmd(devOp, instance, ovsMsg,
>+ovsMsgLength, nlFamilyOps);
> if (status != STATUS_SUCCESS) {
> goto done;
> }
>@@ -938,11 +958,18 @@ static NTSTATUS
> ValidateNetlinkCmd(UINT32 devOp,
>POVS_OPEN_INSTANCE instance,
>POVS_MESSAGE ovsMsg,
>+   UINT32 ovsMsgLength,
>NETLINK_FAMILY *nlFamilyOps)
> {
> NTSTATUS status = STATUS_INVALID_PARAMETER;
> UINT16 i;
> 
>+// We need to ensure we have enough data to process
>+if (NlMsgSize(>nlMsg) > ovsMsgLength) {
>+status = STATUS_INVALID_PARAMETER;
>+goto done;
>+}

Sure, this can be a useful check for integrity. We have not relied on
ovsMsg->nlMsg anytime, but it is a general goodness check.

>+
> 

Re: [ovs-dev] [PATCH 1/2] datapath-windows: Add UDP checksum verifications for VXLAN

[Nithin Raju]

Thanks Alin for taking this up.

A couple of nits but looks great otherwise.

Acked-by: Nithin Raju <nit...@vmware.com>

> 
>@@ -287,17 +289,21 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> ipHdr->saddr = fwdInfo->srcIpAddr;
> ipHdr->daddr = fwdInfo->dstIpAddr;
> 
>-ipHdr->check = 0;

We probably still need to initialize ipHdr->check to 0. Does NDIS take
care of resetting the value first, and then running the checksum?

>-ipHdr->check = IPChecksum((UINT8 *)ipHdr, sizeof *ipHdr, 0);
>-
> /* UDP header */
> udpHdr = (UDPHdr *)((PCHAR)ipHdr + sizeof *ipHdr);
> udpHdr->source = htons(tunKey->flow_hash | MAXINT16);
> udpHdr->dest = htons(vportVxlan->dstPort);
> udpHdr->len = htons(NET_BUFFER_DATA_LENGTH(curNb) - headRoom +
> sizeof *udpHdr + sizeof *vxlanHdr);
>-udpHdr->check = 0;
> 
>+if (tunKey->flags & OVS_TNL_F_CSUM) {
>+UINT16 udpChksumLen = (UINT16) NET_BUFFER_DATA_LENGTH(curNb)
>-
>+  sizeof *ipHdr - sizeof *ethHdr;

Nit: udpChksumLen = ntohs(udpHdr->len);

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] datapath-windows: Fix alignment on Offload.c

[Nithin Raju]

Acked-by: Nithin Raju <nit...@vmware.com>

-Original Message-
From: dev <dev-boun...@openvswitch.org> on behalf of Alin Serdean
<aserd...@cloudbasesolutions.com>
Date: Wednesday, May 18, 2016 at 9:32 AM
To: "dev@openvswitch.org" <dev@openvswitch.org>
Subject: [ovs-dev] [PATCH 2/2] datapath-windows: Fix alignment on Offload.c

>Found by inspection.
>
>Signed-off-by: Alin Gabriel Serdean <aserd...@cloudbasesolutions.com>
>---
> datapath-windows/ovsext/Offload.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Offload.c
>b/datapath-windows/ovsext/Offload.c
>index 1e43a9e..e64487d 100644
>--- a/datapath-windows/ovsext/Offload.c
>+++ b/datapath-windows/ovsext/Offload.c
>@@ -578,12 +578,14 @@ OvsValidateUDPChecksum(PNET_BUFFER_LIST curNbl,
>BOOLEAN udpCsumZero)
> {
> NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
> 
>-csumInfo.Value = NET_BUFFER_LIST_INFO(curNbl,
>TcpIpChecksumNetBufferListInfo);
>+csumInfo.Value = NET_BUFFER_LIST_INFO(curNbl,
>+ 
>TcpIpChecksumNetBufferListInfo);
> 
> if (udpCsumZero) {
> /* Zero is valid checksum. */
> csumInfo.Receive.UdpChecksumFailed = 0;
>-NET_BUFFER_LIST_INFO(curNbl, TcpIpChecksumNetBufferListInfo) =
>csumInfo.Value;
>+NET_BUFFER_LIST_INFO(curNbl, TcpIpChecksumNetBufferListInfo) =
>+csumInfo.Value;
> return NDIS_STATUS_SUCCESS;
> }
> 
>@@ -599,7 +601,7 @@ OvsValidateUDPChecksum(PNET_BUFFER_LIST curNbl,
>BOOLEAN udpCsumZero)
> /*
>  * OvsApplySWChecksumOnNB --
>  *
>- * This function calculates and sets the required sofware offloads given
>by
>+ * This function calculates and sets the required software offloads
>given by
>  * csumInfo for a given NBL(nbl) with a single NB.
>  *
>  */
>-- 
>1.9.5.msysgit.0
>___
>dev mailing list
>dev@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailma
>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=pN
>HQcdr7B40b4h6Yb7FIedI1dnBsxdDuTLBYD3JqV80=SkBBwsGTsn5HrP308PwP0RvBbxhKed
>kqtyXbCpycTCM=ucCGBy2_z_e5oCfgzPYn7SWJ7_nquh7gXAPJIxSigXk= 

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] Add Geneve support on Windows datapath.

[Nithin Raju]

Yin,
Thanks for sending the patch for review.

A few things before I take a detailed look:
1. Add a version number to the patch, eg. "[PATCH v2] Add Geneve support Š
³ with each iteration. Also, it would be beneficial if you can annotate
what changed in v2 compared to previous versions.
2. I see that you have changes in multiple files, some of them may be
fixes that are unrelated to Geneve. Can you isolate them into smaller
patches? It makes it easier to review, IMO. This is my personal opinion
though. Some examples of smaller patches are the changes in Offload.c or
changes to FindVport function etc. As you¹ll soon realize, it would be
harder to keep track of all the review comments for big patches esp. if
not all of them are for a particular purpose.
3. If there¹s anything missing w.r.t to Geneve support that you already
know of, please mention it in the commit message.

Other than that, welcome to the club!

I¹ll provide more technical comments.

-- Nithin


-Original Message-
From: dev  on behalf of Yin Lin

Date: Tuesday, May 17, 2016 at 8:27 PM
To: "dev@openvswitch.org" 
Cc: Yin Lin 
Subject: [ovs-dev] [PATCH] Add Geneve support on Windows datapath.

>---
> datapath-windows/ovsext/Actions.c  |  82 +++-
> datapath-windows/ovsext/Debug.h|   1 +
> datapath-windows/ovsext/DpInternal.h   |  29 ++-
> datapath-windows/ovsext/Flow.c | 171 +++--
> datapath-windows/ovsext/Flow.h |   7 +
> datapath-windows/ovsext/Geneve.c   | 342
>+
> datapath-windows/ovsext/Geneve.h   | 122 
> datapath-windows/ovsext/Gre.c  |   8 +-
> datapath-windows/ovsext/Offload.c  |  45 +
> datapath-windows/ovsext/Offload.h  |   6 +-
> datapath-windows/ovsext/Stt.c  |   2 +-
> datapath-windows/ovsext/Tunnel.c   |   3 +-
> datapath-windows/ovsext/Util.h |   1 +
> datapath-windows/ovsext/Vport.c|  23 ++-
> datapath-windows/ovsext/Vport.h|  10 +-
> datapath-windows/ovsext/Vxlan.c|  49 +
> datapath-windows/ovsext/ovsext.vcxproj |   2 +
> 17 files changed, 765 insertions(+), 138 deletions(-)
> create mode 100644 datapath-windows/ovsext/Geneve.c
> create mode 100644 datapath-windows/ovsext/Geneve.h
>
>diff --git a/datapath-windows/ovsext/Actions.c
>b/datapath-windows/ovsext/Actions.c
>index 5ad29ee..560f7a1 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -48,6 +48,8 @@ typedef struct _OVS_ACTION_STATS {
> UINT64 txVxlan;
> UINT64 rxStt;
> UINT64 txStt;
>+UINT64 rxGeneve;
>+UINT64 txGeneve;
> UINT64 flowMiss;
> UINT64 flowUserspace;
> UINT64 txTcp;
>@@ -227,18 +229,22 @@ OvsDetectTunnelRxPkt(OvsForwardingContext
>*ovsFwdCtx,
> break;
> case IPPROTO_TCP:
> tunnelVport =
>OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
>-  dstPort,
>- 
>OVS_VPORT_TYPE_STT);
>+  dstPort);
> if (tunnelVport) {
>+ASSERT(tunnelVport->ovsType == OVS_VPORT_TYPE_STT);
> ovsActionStats.rxStt++;
> }
> break;
> case IPPROTO_UDP:
> tunnelVport =
>OvsFindTunnelVportByDstPort(ovsFwdCtx->switchContext,
>-  dstPort,
>- 
>OVS_VPORT_TYPE_VXLAN);
>+  dstPort);
> if (tunnelVport) {
>-ovsActionStats.rxVxlan++;
>+if (tunnelVport->ovsType == OVS_VPORT_TYPE_VXLAN) {
>+ovsActionStats.rxVxlan++;
>+} else {
>+ASSERT(tunnelVport->ovsType ==
>OVS_VPORT_TYPE_GENEVE);
>+ovsActionStats.rxGeneve++;
>+}
> }
> break;
> }
>@@ -333,6 +339,9 @@ OvsDetectTunnelPkt(OvsForwardingContext *ovsFwdCtx,
> case OVS_VPORT_TYPE_STT:
> ovsActionStats.txStt++;
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+   ovsActionStats.txGeneve++;
>+   break;
> }
> ovsFwdCtx->tunnelTxNic = dstVport;
> }
>@@ -689,6 +698,11 @@ OvsTunnelPortTx(OvsForwardingContext *ovsFwdCtx)
>  >tunKey,
>ovsFwdCtx->switchContext,
>  >layers, );
> break;
>+case OVS_VPORT_TYPE_GENEVE:
>+status = OvsEncapGeneve(ovsFwdCtx->tunnelTxNic,
>ovsFwdCtx->curNbl,
>+>tunKey,
>ovsFwdCtx->switchContext,
>+>layers, );
>+break;
> default:
> ASSERT(! "Tx: Unhandled tunnel type");
> }
>@@ -767,6 +781,10 @@ OvsTunnelPortRx(OvsForwardingContext 

Re: [ovs-dev] [PATCH] Add Geneve support on Windows datapath.

[Nithin Raju]

>>
>>I am not sure why Windows kernel doesn't compute UDP checksum for all
>>tunnels. I added Nithin to the thread to see if he has some idea. My
>>wild guess is that it tries to save some computational workload.
>
>My guess is that it is because VXLAN originally specified that
>checksums should not be used. However, my expectation is the checksums
>will be more common with Geneve and in all cases the request of
>userspace should be honored. It also seemed like GRE was allocating
>space for the checksum but not actually computing/verifying it, which
>is odd. However, it's definitely possible that I'm missing something.

Yes indeed. For VXLAN, UDP checksum was optional and we got by without
calculating it. We seem to be parsing the OVS_TUNNEL_KEY_ATTR_CSUM
attribute. So, might as well add the code to request NDIS to calculate UDP
checksum if OVS_TNL_F_CSUM is set.

For GRE, you are right Jesse. Looks like we are punting on calculating
checksum even though we reserved space for it. On the sending side there¹s
no validation either so, that make Hyper-V to Hyper-V case work. KVM to
Hyper-V interop would probably fail.

-- Nithin

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Sample action support.

[Nithin Raju]

Hi Sorin,
Thanks for this patch, and thanks for the refactoring.

One quick comment is that, we can probably move the new code in Random.h
to Util.h if you think we are not going to be adding any more functions to
Random.h. I am not sure if 2 more functions warrants a new file.

Also, I see a typo in the refactoring. Can you pls. address that?

-Original Message-
From: dev  on behalf of Sorin Vinturis

Date: Saturday, April 16, 2016 at 11:03 AM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH] datapath-windows: Sample action support.

>This patch adds support for sampling to the OVS extension.
>
>The following flow was used for generating sample actions:
>  ovs-ofctl add-flow tcp:127.0.0.1: "actions=sample(
>probability=12345,collector_set_id=23456,obs_domain_id=34567,
>obs_point_id=45678)"
>
>Signed-off-by: Sorin Vinturis 
>---
> datapath-windows/automake.mk   |   1 +
> datapath-windows/ovsext/Actions.c  | 182
>+++--
> datapath-windows/ovsext/Random.h   |  49 +
> datapath-windows/ovsext/ovsext.vcxproj |   1 +
> 4 files changed, 200 insertions(+), 33 deletions(-)
> create mode 100644 datapath-windows/ovsext/Random.h
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index c9af806..9ff6c0b 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -49,6 +49,7 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/PacketIO.h \
>   datapath-windows/ovsext/PacketParser.c \
>   datapath-windows/ovsext/PacketParser.h \
>+  datapath-windows/ovsext/Random.h \
>   datapath-windows/ovsext/Recirc.c \
>   datapath-windows/ovsext/Recirc.h \
>   datapath-windows/ovsext/Stt.c \
>diff --git a/datapath-windows/ovsext/Actions.c
>b/datapath-windows/ovsext/Actions.c
>index cf54ae2..50e6e92 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -27,6 +27,7 @@
> #include "NetProto.h"
> #include "Offload.h"
> #include "PacketIO.h"
>+#include "Random.h"
> #include "Recirc.h"
> #include "Stt.h"
> #include "Switch.h"
>@@ -1592,6 +1593,131 @@ OvsExecuteHash(OvsFlowKey *key,
> hash = 1;
> 
> key->dpHash = hash;
>+}
>+
>+/*
>+ * 
>--
>+ * OvsOutputUserspaceAction --
>+ *  This function sends the packet to userspace according to nested
>+ *  %OVS_USERSPACE_ATTR_* attributes.
>+ * 
>--
>+ */
>+static __inline NDIS_STATUS
>+OvsOutputUserspaceAction(OvsForwardingContext *ovsFwdCtx,
>+ OvsFlowKey *key,
>+ const PNL_ATTR attr)
>+{
>+NTSTATUS status = NDIS_STATUS_SUCCESS;
>+PNL_ATTR userdataAttr;
>+PNL_ATTR queueAttr;
>+POVS_PACKET_QUEUE_ELEM elem;
>+POVS_PACKET_HDR_INFO layers = >layers;
>+BOOLEAN isRecv = FALSE;
>+
>+POVS_VPORT_ENTRY vport =
>OvsFindVportByPortNo(ovsFwdCtx->switchContext,
>+  ovsFwdCtx->srcVportNo);
>+
>+if (vport) {
>+if (vport->isExternal ||
>+OvsIsTunnelVportType(vport->ovsType)) {
>+isRecv = TRUE;
>+}
>+}
>+
>+queueAttr = NlAttrFindNested(attr, OVS_USERSPACE_ATTR_PID);
>+userdataAttr = NlAttrFindNested(attr, OVS_USERSPACE_ATTR_USERDATA);
>+
>+elem = OvsCreateQueueNlPacket(NlAttrData(userdataAttr),
>+  NlAttrGetSize(userdataAttr),

The existing code passes ŒuserdataAttr¹ as-is and not the payload.
Basically, it passes the NL_ATTR structure and not just the payload. Any
reason to strip off the header?

If you follow through to how OvsCreateQueueNlPacket() uses this, you¹ll
end up with NlMsgPutTailUnspec() and that needs the NL_ATTR header to be
present as part of the data.

>+  OVS_PACKET_CMD_ACTION,
>+  vport, key, ovsFwdCtx->curNbl,
>+ 
>NET_BUFFER_LIST_FIRST_NB(ovsFwdCtx->curNbl),
>+  isRecv,
>+  layers);
>+if (elem) {
>+LIST_ENTRY missedPackets;
>+InitializeListHead();
>+InsertTailList(, >link);
>+OvsQueuePackets(, 1);
>+} else {
>+status = NDIS_STATUS_FAILURE;
>+}
>+
>+return status;
>+}
>+
>+/*
>+ * 
>--
>+ * OvsExecuteSampleAction --
>+ *  Executes actions based on probability, as specified in the nested
>+ *  %OVS_SAMPLE_ATTR_* attributes.
>+ * 
>--
>+ */
>+static __inline NDIS_STATUS
>+OvsExecuteSampleAction(OvsForwardingContext *ovsFwdCtx,
>+   OvsFlowKey *key,
>+  

Re: [ovs-dev] [PATCH V2] datapath-windows: Validate netlink packets integrity

[Nithin Raju]

Just a couple of more comments.

-Original Message-
From: dev > on 
behalf of Paul Boca 
>
Date: Wednesday, April 27, 2016 at 1:05 AM
To: "dev@openvswitch.org" 
>
Subject: [ovs-dev] [PATCH V2] datapath-windows: Validate netlink packets 
integrity

Solved access violation when trying to acces netling message - obtained with 
forged IOCTLs

Signed-off-by: Paul-Daniel Boca 
>
Acked-by: Alin Gabriel Serdean 
>
---
V2: Fixed alignement problems
---
datapath-windows/ovsext/Datapath.c| 45 ++---
datapath-windows/ovsext/Flow.c| 42 +++-
datapath-windows/ovsext/Netlink/Netlink.c | 66 ++-
datapath-windows/ovsext/Netlink/Netlink.h | 13 --
datapath-windows/ovsext/User.c|  5 ++-
datapath-windows/ovsext/Vport.c   | 34 
lib/netlink-socket.c  |  2 +
7 files changed, 152 insertions(+), 55 deletions(-)

diff --git a/datapath-windows/ovsext/Datapath.c 
b/datapath-windows/ovsext/Datapath.c
index 06f99b3..1f89964 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -307,6 +307,7 @@ static NTSTATUS MapIrpOutputBuffer(PIRP irp,
static NTSTATUS ValidateNetlinkCmd(UINT32 devOp,
POVS_OPEN_INSTANCE instance,
POVS_MESSAGE ovsMsg,
+   UINT32 ovsMgsLength,
NETLINK_FAMILY *nlFamilyOps);
static NTSTATUS InvokeNetlinkCmdHandler(POVS_USER_PARAMS_CONTEXT usrParamsCtx,
 NETLINK_FAMILY *nlFamilyOps,
@@ -694,6 +695,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
 UINT32 devOp;
 OVS_MESSAGE ovsMsgReadOp;
 POVS_MESSAGE ovsMsg;
+UINT32 ovsMsgLength = 0;
 NETLINK_FAMILY *nlFamilyOps;
 OVS_USER_PARAMS_CONTEXT usrParamsCtx;
@@ -774,6 +776,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
 }
 ovsMsg = inputBuffer;
+ovsMsgLength = inputBufferLen;
 devOp = OVS_TRANSACTION_DEV_OP;
 break;
@@ -808,6 +811,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
   OVS_CTRL_CMD_EVENT_NOTIFY :
   OVS_CTRL_CMD_READ_NOTIFY;
 ovsMsg->genlMsg.version = nlControlFamilyOps.version;
+ovsMsgLength = outputBufferLen;
 devOp = OVS_READ_DEV_OP;
 break;
@@ -853,6 +857,7 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
 /* Create an NL message for consumption. */
 ovsMsg = 
+ovsMsgLength = sizeof (ovsMsgReadOp);
 devOp = OVS_READ_DEV_OP;
 break;
@@ -864,7 +869,21 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
 goto done;
 }
+/*
+ * Output buffer not mandatory but map it in case we have something
+ * to return to requester.
+*/
+if (outputBufferLen != 0) {
+status = MapIrpOutputBuffer(irp, outputBufferLen,
+sizeof *ovsMsg, );
+if (status != STATUS_SUCCESS) {
+goto done;
+}
+ASSERT(outputBuffer);
+}
+
 ovsMsg = inputBuffer;
+ovsMsgLength = inputBufferLen;
 devOp = OVS_WRITE_DEV_OP;

The contract between userspace and kernel is that for "Write" operations, the 
output buffer will not be used. Under what context will the kernel code use the 
output buffer here? If it does, then we are violating the contract. No?

Also, this is the code in userspace that calls into WRITE_OP (in 
lib/netlink-socket.c):

if (!DeviceIoControl(sock->handle, OVS_IOCTL_WRITE,
 msg->data, msg->size, NULL, 0,
 , NULL)) {
retval = -1;
/* XXX: Map to a more appropriate error based on GetLastError(). */
errno = EINVAL;
VLOG_DBG_RL(, "fatal driver failure in write: %s",
ovs_lasterror_to_string());
}

As you can see, we are passing NULL for output buffer. How will your patch work 
with this code?

-- Nithin
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev