[ovs-dev] [PATCH] datapath-windows: Add guards around IpHelper adapter binding calls

[Sairam Venugopal via dev]

Protect internal adapter up/down calls with a dispatch lock. It was
observed that the InternalAdapter bind calls could happen out of order
thereby causing encap packets to not be sent properly.

Add assert around the IpHelper bind calls to ensure Up/Down gets called
only for the appropriate vports.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Switch.h |  2 ++
 datapath-windows/ovsext/Vport.c  | 34 +++---
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/datapath-windows/ovsext/Switch.h b/datapath-windows/ovsext/Switch.h
index 18a9ec6..806ee78 100644
--- a/datapath-windows/ovsext/Switch.h
+++ b/datapath-windows/ovsext/Switch.h
@@ -131,6 +131,8 @@ typedef struct _OVS_SWITCH_CONTEXT
  * vport */
 INT32   countInternalVports;/* the number of internal
  * vports */
+UINT32  ipHelperBoundVportNo;   /* vportNo bound to
+ * IpHelper */
 
 /*
  * 'portIdHashArray' ONLY contains ports that exist on the Hyper-V switch,
diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index e8c4d7f..57e7510 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -100,6 +100,12 @@ static NTSTATUS GetNICAlias(PNDIS_SWITCH_NIC_PARAMETERS 
nicParam,
 static NTSTATUS OvsConvertIfCountedStrToAnsiStr(PIF_COUNTED_STRING wStr,
 CHAR *str,
 UINT16 maxStrLen);
+_Requires_lock_held_(switchContext->dispatchLock)
+static VOID OvsBindVportWithIpHelper(POVS_VPORT_ENTRY vport,
+ POVS_SWITCH_CONTEXT switchContext);
+_Requires_lock_held_(switchContext->dispatchLock)
+static VOID OvsUnBindVportWithIpHelper(POVS_VPORT_ENTRY vport,
+   POVS_SWITCH_CONTEXT switchContext);
 
 /*
  * --
@@ -453,7 +459,7 @@ HvConnectNic(POVS_SWITCH_CONTEXT switchContext,
 vport->nicState = NdisSwitchNicStateConnected;
 
 if (nicParam->NicType == NdisSwitchNicTypeInternal) {
-OvsInternalAdapterUp(vport->portNo, &vport->netCfgInstanceId);
+OvsBindVportWithIpHelper(vport, switchContext);
 }
 
 NdisReleaseRWLock(switchContext->dispatchLock, &lockState);
@@ -633,7 +639,7 @@ HvDisconnectNic(POVS_SWITCH_CONTEXT switchContext,
 }
 
 if (isInternalPort) {
-OvsInternalAdapterDown(vport->portNo, vport->netCfgInstanceId);
+OvsUnBindVportWithIpHelper(vport, switchContext);
 OvsRemoveAndDeleteVport(NULL, switchContext, vport, TRUE, TRUE);
 OvsPostVportEvent(&event);
 }
@@ -1308,7 +1314,7 @@ OvsRemoveAndDeleteVport(PVOID usrParamsContext,
 if (hvDelete && vport->isAbsentOnHv == FALSE) {
 switchContext->countInternalVports--;
 ASSERT(switchContext->countInternalVports >= 0);
-OvsInternalAdapterDown(vport->portNo, vport->netCfgInstanceId);
+OvsUnBindVportWithIpHelper(vport, switchContext);
 }
 hvSwitchPort = TRUE;
 break;
@@ -2814,3 +2820,25 @@ OvsTunnelVportPendingInit(PVOID context,
 ASSERT(*replyLen != 0);
 }
 }
+
+_Use_decl_annotations_
+static VOID
+OvsBindVportWithIpHelper(POVS_VPORT_ENTRY vport,
+ POVS_SWITCH_CONTEXT switchContext)
+{
+OVS_LOG_TRACE("OvsBindVportWithIpHelper: %d", vport->portNo);
+ASSERT(switchContext->ipHelperBoundVportNo == 0);
+switchContext->ipHelperBoundVportNo = vport->portNo;
+OvsInternalAdapterUp(vport->portNo, &vport->netCfgInstanceId);
+}
+
+_Use_decl_annotations_
+static VOID
+OvsUnBindVportWithIpHelper(POVS_VPORT_ENTRY vport,
+   POVS_SWITCH_CONTEXT switchContext)
+{
+OVS_LOG_TRACE("OvsUnBindVportWithIpHelper: %d", vport->portNo);
+ASSERT(switchContext->ipHelperBoundVportNo == vport->portNo);
+switchContext->ipHelperBoundVportNo = 0;
+OvsInternalAdapterDown(vport->portNo, vport->netCfgInstanceId);
+}
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] faq: Update features supported on Hyper-V

[Sairam Venugopal via dev]

Acked-by: Sairam Venugopal 

On 3/11/19, 1:48 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar 
via dev"  
wrote:

These features were added a while back, so updating
the documentation.

Signed-off-by: Anand Kumar 
---
 Documentation/faq/releases.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
index fd45efd..cd5aad1 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -110,8 +110,8 @@ Q: Are all features available with all datapaths?
 == == == = 
===
 Connection tracking 4.3YES  YES  
YES
 Conntrack Fragment Reass.   4.3YES  YES  
YES
-NAT 4.6YES  YES  NO
-Conntrack zone limit4.18   YES  NO   NO
+NAT 4.6YES  YES  
YES
+Conntrack zone limit4.18   YES  NO   
YES
 Tunnel - LISP   NO YES  NO   NO
 Tunnel - STTNO YES  NO   
YES
 Tunnel - GRE3.11   YES  YES  
YES
@@ -125,7 +125,7 @@ Q: Are all features available with all datapaths?
 QoS - Policing  YESYES  YES  NO
 QoS - Shaping   YESYES  NO   NO
 sFlow   YESYES  YES  NO
-IPFIX   3.10   YES  YES  NO
+IPFIX   3.10   YES  YES  
YES
 Set action  YESYES  YES
PARTIAL
 NIC Bonding YESYES  YES  
YES
 Multiple VTEPs  YESYES  YES  
YES
-- 
2.9.3.windows.1

___
dev mailing list
d...@openvswitch.org

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C5f1fa9a3b2ec42de9a2b08d6a662d7ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636879341325458846&sdata=2%2F8XzsQyWcqAaX2kWRtIYweJY6AYf9pq7e3CJ6OYLGk%3D&reserved=0


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

Re: [ovs-dev] [PATCH] datapath-windows: Guard vport usage in user.c

[Sairam Venugopal via dev]

Acked-by: Sairam Venugopal 

On 2/27/19, 6:10 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

When using a vport we need to guard its usage with the dispatch lock.

Signed-off-by: Alin Gabriel Serdean 
---
 datapath-windows/ovsext/User.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/datapath-windows/ovsext/User.c b/datapath-windows/ovsext/User.c
index b43d7cc04..ed1fcbea8 100644
--- a/datapath-windows/ovsext/User.c
+++ b/datapath-windows/ovsext/User.c
@@ -452,14 +452,6 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
 }
 
 fwdDetail = NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL(pNbl);
-vport = OvsFindVportByPortNo(gOvsSwitchContext, execute->inPort);
-if (vport) {
-fwdDetail->SourcePortId = vport->portId;
-fwdDetail->SourceNicIndex = vport->nicIndex;
-} else {
-fwdDetail->SourcePortId = NDIS_SWITCH_DEFAULT_PORT_ID;
-fwdDetail->SourceNicIndex = 0;
-}
 // XXX: Figure out if any of the other members of fwdDetail need to be 
set.
 
 status = OvsGetFlowMetadata(&key, execute->keyAttrs);
@@ -502,6 +494,14 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
 
 if (ndisStatus == NDIS_STATUS_SUCCESS) {
 NdisAcquireRWLockRead(gOvsSwitchContext->dispatchLock, &lockState, 
0);
+vport = OvsFindVportByPortNo(gOvsSwitchContext, execute->inPort);
+if (vport) {
+fwdDetail->SourcePortId = vport->portId;
+fwdDetail->SourceNicIndex = vport->nicIndex;
+} else {
+fwdDetail->SourcePortId = NDIS_SWITCH_DEFAULT_PORT_ID;
+fwdDetail->SourceNicIndex = 0;
+}
 ndisStatus = OvsActionsExecute(gOvsSwitchContext, NULL, pNbl,
vport ? vport->portNo :
OVS_DPPORT_NUMBER_INVALID,
-- 
2.16.1.windows.1

___
dev mailing list
d...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C0bd42693441d43f12bfa08d69cbd589d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636868734400091268&sdata=ShTAK8Qyi4hL3EG8PgLzbIxzSMril0w%2BHEE8VO6qWlU%3D&reserved=0


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

Re: [ovs-dev] [PATCH] datapath-windows: Add annotations to find vport functions

[Sairam Venugopal via dev]

Acked-by: Sairam Venugopal 

On 2/27/19, 9:34 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

Add annotations to find vport functions to check if the dispatch lock is
held.

Signed-off-by: Alin Gabriel Serdean 
---
 datapath-windows/ovsext/Vport.c | 7 ++-
 datapath-windows/ovsext/Vport.h | 5 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/datapath-windows/ovsext/Vport.c 
b/datapath-windows/ovsext/Vport.c
index e08cb90ce..f79324d28 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -135,7 +135,7 @@ HvCreatePort(POVS_SWITCH_CONTEXT switchContext,
  * Lookup by port name to see if this port with this name had been 
added
  * (and deleted) previously.
  */
-vport = OvsFindVportByHvNameW(gOvsSwitchContext,
+vport = OvsFindVportByHvNameW(switchContext,
   portParam->PortFriendlyName.String,
   portParam->PortFriendlyName.Length);
 if (vport && vport->isAbsentOnHv == FALSE) {
@@ -693,6 +693,7 @@ done:
 /*
  * OVS Vport related functionality.
  */
+_Use_decl_annotations_
 POVS_VPORT_ENTRY
 OvsFindVportByPortNo(POVS_SWITCH_CONTEXT switchContext,
  UINT32 portNo)
@@ -787,6 +788,7 @@ OvsFindTunnelVportByPortType(POVS_SWITCH_CONTEXT 
switchContext,
 return NULL;
 }
 
+_Use_decl_annotations_
 POVS_VPORT_ENTRY
 OvsFindVportByOvsName(POVS_SWITCH_CONTEXT switchContext,
   PSTR name)
@@ -810,6 +812,7 @@ OvsFindVportByOvsName(POVS_SWITCH_CONTEXT switchContext,
 }
 
 /* OvsFindVportByHvName: "name" is assumed to be null-terminated */
+_Use_decl_annotations_
 POVS_VPORT_ENTRY
 OvsFindVportByHvNameW(POVS_SWITCH_CONTEXT switchContext,
   PWSTR wsName, SIZE_T wstrSize)
@@ -862,6 +865,7 @@ Cleanup:
 return vport;
 }
 
+_Use_decl_annotations_
 POVS_VPORT_ENTRY
 OvsFindVportByHvNameA(POVS_SWITCH_CONTEXT switchContext,
   PSTR name)
@@ -884,6 +888,7 @@ OvsFindVportByHvNameA(POVS_SWITCH_CONTEXT switchContext,
 return vport;
 }
 
+_Use_decl_annotations_
 POVS_VPORT_ENTRY
 OvsFindVportByPortIdAndNicIndex(POVS_SWITCH_CONTEXT switchContext,
 NDIS_SWITCH_PORT_ID portId,
diff --git a/datapath-windows/ovsext/Vport.h 
b/datapath-windows/ovsext/Vport.h
index 7d88f86fb..32cbf8bcc 100644
--- a/datapath-windows/ovsext/Vport.h
+++ b/datapath-windows/ovsext/Vport.h
@@ -122,15 +122,20 @@ typedef struct _OVS_VPORT_ENTRY {
 
 struct _OVS_SWITCH_CONTEXT;
 
+_Requires_lock_held_(switchContext->dispatchLock)
 POVS_VPORT_ENTRY OvsFindVportByPortNo(POVS_SWITCH_CONTEXT switchContext,
   UINT32 portNo);
 /* "name" is null-terminated */
+_Requires_lock_held_(switchContext->dispatchLock)
 POVS_VPORT_ENTRY OvsFindVportByOvsName(POVS_SWITCH_CONTEXT switchContext,
PSTR name);
+_Requires_lock_held_(switchContext->dispatchLock)
 POVS_VPORT_ENTRY OvsFindVportByHvNameA(POVS_SWITCH_CONTEXT switchContext,
PSTR name);
+_Requires_lock_held_(switchContext->dispatchLock)
 POVS_VPORT_ENTRY OvsFindVportByHvNameW(POVS_SWITCH_CONTEXT switchContext,
PWSTR wsName, SIZE_T wstrSize);
+_Requires_lock_held_(switchContext->dispatchLock)
 POVS_VPORT_ENTRY OvsFindVportByPortIdAndNicIndex(POVS_SWITCH_CONTEXT 
switchContext,
  NDIS_SWITCH_PORT_ID 
portId,
  NDIS_SWITCH_NIC_INDEX 
index);
-- 
2.16.1.windows.1

___
dev mailing list
d...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C5ae778841e0345fbaf6608d69cd9d189%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636868856729356401&sdata=WxRHDA%2BKmMnZQ4N3J9ydzc4252vguQPCNRuXlug48V8%3D&reserved=0


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

[ovs-dev] [PATCH] datapath-windows: Fix nbl cleanup when memory allocation fails

[Sairam Venugopal via dev]

StartNblIngressError should be called only when an NBL hasn't been
modified. In this case the nbl context was initialized. Rely on existing
packet completion mechanism to cleanup the NBL.

Found while testing with DriverVerifier with limited memory setting
enabled.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/PacketIO.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/datapath-windows/ovsext/PacketIO.c 
b/datapath-windows/ovsext/PacketIO.c
index 38e3e5f..57c583c 100644
--- a/datapath-windows/ovsext/PacketIO.c
+++ b/datapath-windows/ovsext/PacketIO.c
@@ -283,9 +283,8 @@ OvsStartNBLIngress(POVS_SWITCH_CONTEXT switchContext,
 RtlInitUnicodeString(&filterReason,
  L"Cannot allocate NBLs with single NB.");
 
-OvsStartNBLIngressError(switchContext, curNbl,
-sendCompleteFlags, &filterReason,
-NDIS_STATUS_RESOURCES);
+OvsAddPktCompletionList(&completionList, TRUE, sourcePort,
+curNbl, 0, &filterReason);
 continue;
 }
 
-- 
2.9.0.windows.1

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

Re: [ovs-dev] Author should not be mailing list

[Sairam Venugopal via dev]

Not really. I subscribed using my regular work email. This was the last patch 
that was delivered properly - https://patchwork.ozlabs.org/patch/997861/

Were there any changes done to the mailing list in the past 3 - 4 months?

Thanks,
Sairam

On 2/27/19, 12:25 PM, "Aaron Conole"  wrote:

    Sairam Venugopal  writes:

> Hey Ben/Aaron,
>
>  
>
> Is there a known fix for this issue? I sent my commit to 
d...@openvswitch.org and ran into this. Currently all
> patches from the mailing list on patchwork show up under my name -
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fopenvswitch%2Flist%2F%3Fsubmitter%3D70723%26state%3D%252A%26archive%3Dboth&data=02%7C01%7Cvsairam%40vmware.com%7C863934645f3a4ca476af08d69cf1b89a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636868959335009489&sdata=cwCFPG43MlbXAn0JnBUNgP7NgJjDfUGOUP1%2B7Q3nHOA%3D&reserved=0
>
>  
>
> Responding to emails (via outlook) on the mailing list also seems to 
change the “from” field to the mailing list
> email. Check my response to Alin’s patch here - 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F1048900%2F&data=02%7C01%7Cvsairam%40vmware.com%7C863934645f3a4ca476af08d69cf1b89a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636868959335009489&sdata=QBNIys4AqW3ZfXqga0lupjyTmPyHr%2Bf4%2F70Ybe913so%3D&reserved=0

Are you subscribed to the mailing list via an alias?  Just throwing out
thoughts.  We've seen the issue happen with a couple of people, but I'm
not sure what the cause could be.

>  
>
> I have been using this command for sending out patches for a while – “git 
send-email -1 -1 -M90% -v0
> -to=d...@openvswitch.org”
>
>  
>
> This looks like some recent misconfiguration in the mailing-list. I will 
try to unsubscribe and re-subscribe in
> meantime.
>
>  
>
> Thanks,
>
> Sairam


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

Re: [ovs-dev] Author should not be mailing list

[Sairam Venugopal via dev]

This is in regards to “Author should not be mailing list” issue where the from 
field in the email gets replaced with 
ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org>.

Thanks,
Sairam

From: Sairam Venugopal 
Date: Wednesday, February 27, 2019 at 11:43 AM
To: Ben Pfaff , Aaron Conole 
Cc: "d...@openvswitch.org" , "ovs-dev@openvswitch.org" 
, Alin Serdean 
Subject: Author should not be mailing list

Hey Ben/Aaron,

Is there a known fix for this issue? I sent my commit to 
d...@openvswitch.org<mailto:d...@openvswitch.org> and ran into this. Currently 
all patches from the mailing list on patchwork show up under my name - 
https://patchwork.ozlabs.org/project/openvswitch/list/?submitter=70723&state=%2A&archive=both

Responding to emails (via outlook) on the mailing list also seems to change the 
“from” field to the mailing list email. Check my response to Alin’s patch here 
- https://patchwork.ozlabs.org/patch/1048900/

I have been using this command for sending out patches for a while – “git 
send-email -1 -1 -M90% -v0 -to=d...@openvswitch.org”

This looks like some recent misconfiguration in the mailing-list. I will try to 
unsubscribe and re-subscribe in meantime.

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

[ovs-dev] Author should not be mailing list

[Sairam Venugopal via dev]

Hey Ben/Aaron,

Is there a known fix for this issue? I sent my commit to 
d...@openvswitch.org and ran into this. Currently 
all patches from the mailing list on patchwork show up under my name - 
https://patchwork.ozlabs.org/project/openvswitch/list/?submitter=70723&state=%2A&archive=both

Responding to emails (via outlook) on the mailing list also seems to change the 
“from” field to the mailing list email. Check my response to Alin’s patch here 
- https://patchwork.ozlabs.org/patch/1048900/

I have been using this command for sending out patches for a while – “git 
send-email -1 -1 -M90% -v0 -to=d...@openvswitch.org”

This looks like some recent misconfiguration in the mailing-list. I will try to 
unsubscribe and re-subscribe in meantime.

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

Re: [ovs-dev] [PATCH] datapath-windows: Guard vport usage in user.c

[Sairam Venugopal via dev]

Do we need to keep the dispatchLock for reading vport structures? If that's the 
case, then we will need to fix it in other areas of the code too. It would be 
better to move the locking inside the relevant vport.c functions instead of 
taking out global ones.

Thanks,
Sairam

On 2/27/19, 6:10 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

When using a vport we need to guard its usage with the dispatch lock.

Signed-off-by: Alin Gabriel Serdean 
---
 datapath-windows/ovsext/User.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/datapath-windows/ovsext/User.c b/datapath-windows/ovsext/User.c
index b43d7cc04..ed1fcbea8 100644
--- a/datapath-windows/ovsext/User.c
+++ b/datapath-windows/ovsext/User.c
@@ -452,14 +452,6 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
 }
 
 fwdDetail = NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL(pNbl);
-vport = OvsFindVportByPortNo(gOvsSwitchContext, execute->inPort);
-if (vport) {
-fwdDetail->SourcePortId = vport->portId;
-fwdDetail->SourceNicIndex = vport->nicIndex;
-} else {
-fwdDetail->SourcePortId = NDIS_SWITCH_DEFAULT_PORT_ID;
-fwdDetail->SourceNicIndex = 0;
-}
 // XXX: Figure out if any of the other members of fwdDetail need to be 
set.
 
 status = OvsGetFlowMetadata(&key, execute->keyAttrs);
@@ -502,6 +494,14 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
 
 if (ndisStatus == NDIS_STATUS_SUCCESS) {
 NdisAcquireRWLockRead(gOvsSwitchContext->dispatchLock, &lockState, 
0);
+vport = OvsFindVportByPortNo(gOvsSwitchContext, execute->inPort);
+if (vport) {
+fwdDetail->SourcePortId = vport->portId;
+fwdDetail->SourceNicIndex = vport->nicIndex;
+} else {
+fwdDetail->SourcePortId = NDIS_SWITCH_DEFAULT_PORT_ID;
+fwdDetail->SourceNicIndex = 0;
+}
 ndisStatus = OvsActionsExecute(gOvsSwitchContext, NULL, pNbl,
vport ? vport->portNo :
OVS_DPPORT_NUMBER_INVALID,
-- 
2.16.1.windows.1

___
dev mailing list
d...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C0bd42693441d43f12bfa08d69cbd589d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636868734400091268&sdata=ShTAK8Qyi4hL3EG8PgLzbIxzSMril0w%2BHEE8VO6qWlU%3D&reserved=0


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

[ovs-dev] [PATCH v2] datapath-windows: Fix potential deadlock in event subscription

[Sairam Venugopal via dev]

Move the EventQueue lock acquisition after the dispatchLock to prevent a
potential deadlock in port creation pipeline. There could be a case where
a port event could try to take up the Dispatch Lock before the Event Queue
lock and the subscription queue event could take up the event queue lock
before the dispatch lock.

Found while testing with Driver Verifier enabled.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Event.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/Event.c b/datapath-windows/ovsext/Event.c
index 348f032..69cdb43 100644
--- a/datapath-windows/ovsext/Event.c
+++ b/datapath-windows/ovsext/Event.c
@@ -245,9 +245,8 @@ OvsSubscribeEventIoctl(PFILE_OBJECT fileObject,
 return STATUS_INVALID_PARAMETER;
 }
 
-OvsAcquireEventQueueLock(eventId);
-
 instance = OvsGetOpenInstance(fileObject, request->dpNo);
+OvsAcquireEventQueueLock(eventId);
 
 if (instance == NULL) {
 status = STATUS_INVALID_PARAMETER;
-- 
2.9.0.windows.1

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

[ovs-dev] [PATCH] datapath-windows: Fix potential deadlock in event subscription

[Sairam Venugopal via dev]

Move the EventQueue lock acquisition after the dispatchLock to prevent a
potential deadlock in port creation pipeline. There could be a case where
a port event could try to take up the Dispatch Lock before the Event Queue
lock and the subscription queue event could take up the event queue lock
before the dispatch lock.

Found while testing with Driver Verifier enabled.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Event.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/Event.c b/datapath-windows/ovsext/Event.c
index 348f032..ef32a1d 100644
--- a/datapath-windows/ovsext/Event.c
+++ b/datapath-windows/ovsext/Event.c
@@ -245,8 +245,6 @@ OvsSubscribeEventIoctl(PFILE_OBJECT fileObject,
 return STATUS_INVALID_PARAMETER;
 }
 
-OvsAcquireEventQueueLock(eventId);
-
 instance = OvsGetOpenInstance(fileObject, request->dpNo);
 
 if (instance == NULL) {
@@ -258,6 +256,7 @@ OvsSubscribeEventIoctl(PFILE_OBJECT fileObject,
 /*
  * XXX for now, we don't allow change mask.
  */
+OvsAcquireEventQueueLock(eventId);
 queue = (POVS_EVENT_QUEUE)instance->eventQueue;
 if (request->subscribe && queue) {
 if (request->protocol == NETLINK_GENERIC
-- 
2.9.0.windows.1

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

[ovs-dev] [PATCH] datapath-windows: Fix race condition during port creation

[Sairam Venugopal via dev]

Hold the dispatch lock until port-add operations are completed.

Found by inspection.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Vport.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/Vport.c b/datapath-windows/ovsext/Vport.c
index e08cb90..bb83c22 100644
--- a/datapath-windows/ovsext/Vport.c
+++ b/datapath-windows/ovsext/Vport.c
@@ -452,12 +452,11 @@ HvConnectNic(POVS_SWITCH_CONTEXT switchContext,
 vport->ovsState = OVS_STATE_CONNECTED;
 vport->nicState = NdisSwitchNicStateConnected;
 
-NdisReleaseRWLock(switchContext->dispatchLock, &lockState);
-
 if (nicParam->NicType == NdisSwitchNicTypeInternal) {
 OvsInternalAdapterUp(vport->portNo, &vport->netCfgInstanceId);
 }
 
+NdisReleaseRWLock(switchContext->dispatchLock, &lockState);
 done:
 VPORT_NIC_EXIT(nicParam);
 }
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[Sairam Venugopal]

Thanks!

On 11/15/18, 10:45 AM, "Ben Pfaff"  wrote:

Alin already did that.

On Thu, Nov 15, 2018 at 06:40:00PM +0000, Sairam Venugopal wrote:
> Is it too late to backport this to 2.10?
> 
> On 11/15/18, 7:03 AM, "Alin Serdean"  
wrote:
> 
> I applied the patch on master and as far as it goes without conflicts.
> 
> --
> Alin.
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele aserd...@ovn.org
>     > Trimis: Thursday, November 15, 2018 4:52 PM
> > Către: 'Sairam Venugopal' ; d...@openvswitch.org
> > Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid 
reference in
> > Buffermgmt.c
> > 
> > Thanks for the fix!
> > 
> > Acked-by: Alin Gabriel Serdean 
> > 
> > > -Mesaj original-
> > > De la: ovs-dev-boun...@openvswitch.org  > > boun...@openvswitch.org> În numele Sairam Venugopal
> > > Trimis: Wednesday, November 14, 2018 10:07 PM
> > > Către: d...@openvswitch.org
> > > Subiect: [ovs-dev] [PATCH] datapath-windows: Fix invalid 
reference in
> > > Buffermgmt.c
> > >
> > > OVS_BUFFER_CONTEXT gets cleared as part of
> > > NdisFreeNetBufferListContext function call. This causes an invalid
> > reference
> > > error.
> > >
> > > Found while testing with driver verifier enabled.
> > >
> > > Signed-off-by: Sairam Venugopal 
> > > ---
> > >  datapath-windows/ovsext/BufferMgmt.c | 6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/datapath-windows/ovsext/BufferMgmt.c b/datapath-
> > > windows/ovsext/BufferMgmt.c index 448cd76..da5c04a 100644
> > > --- a/datapath-windows/ovsext/BufferMgmt.c
> > > +++ b/datapath-windows/ovsext/BufferMgmt.c
> > 
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C0354cc7dee7d477cb53108d64b2a7f97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636779043242021462&sdata=mvAm5BLoz21%2FNhURhoFdj%2FwZY4VcDHzfQx6UMxOh99c%3D&reserved=0
> 
> 
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C0354cc7dee7d477cb53108d64b2a7f97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636779043242021462&sdata=mvAm5BLoz21%2FNhURhoFdj%2FwZY4VcDHzfQx6UMxOh99c%3D&reserved=0


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

Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[Sairam Venugopal]

Is it too late to backport this to 2.10?

On 11/15/18, 7:03 AM, "Alin Serdean"  wrote:

I applied the patch on master and as far as it goes without conflicts.

--
Alin.

> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org  boun...@openvswitch.org> În numele aserd...@ovn.org
> Trimis: Thursday, November 15, 2018 4:52 PM
> Către: 'Sairam Venugopal' ; d...@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> Buffermgmt.c
> 
> Thanks for the fix!
> 
> Acked-by: Alin Gabriel Serdean 
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele Sairam Venugopal
> > Trimis: Wednesday, November 14, 2018 10:07 PM
> > Către: d...@openvswitch.org
> > Subiect: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> > Buffermgmt.c
> >
> > OVS_BUFFER_CONTEXT gets cleared as part of
> > NdisFreeNetBufferListContext function call. This causes an invalid
> reference
> > error.
> >
> > Found while testing with driver verifier enabled.
> >
> > Signed-off-by: Sairam Venugopal 
> > ---
> >  datapath-windows/ovsext/BufferMgmt.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/datapath-windows/ovsext/BufferMgmt.c b/datapath-
> > windows/ovsext/BufferMgmt.c index 448cd76..da5c04a 100644
> > --- a/datapath-windows/ovsext/BufferMgmt.c
> > +++ b/datapath-windows/ovsext/BufferMgmt.c
> 
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7Ccb97b47b8b964d81494708d64b0b6ce3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636778909792412676&sdata=DRZ%2FcHxQoIhqwjl2WZbHNOOI89jwASyJat7oY0qwoD8%3D&reserved=0


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

Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after stopping controller on Windows

[Sairam Venugopal]

Thanks for fixing this. The files normally get deleted when the agent closes. 
Is this a regression or just test related? Ack'ing the fix.

Acked-by: Sairam Venugopal 

On 11/14/18, 7:31 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

On Windows the file which is used for the named pipe connection 
(`punix:file`)
is not deleted when the process is closed.

Try to delete the `controller` file and fail if we can't (on Windows you 
can't
delete a file if there still an opened handle to it).

Also add a check to see if the `ovs-testcontroller` was successfully 
started.

Signed-off-by: Alin Gabriel Serdean 
---
 tests/bridge.at | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/bridge.at b/tests/bridge.at
index ee398bdb1..b94afc194 100644
--- a/tests/bridge.at
+++ b/tests/bridge.at
@@ -84,7 +84,7 @@ AT_SETUP([bridge - add port after stopping controller])
 OVS_VSWITCHD_START
 
 dnl Start ovs-testcontroller
-ovs-testcontroller --detach punix:controller 
--pidfile=ovs-testcontroller.pid
+AT_CHECK([ovs-testcontroller --detach punix:controller --pidfile], [0], 
[ignore])
 OVS_WAIT_UNTIL([test -e controller])
 
 AT_CHECK([ovs-vsctl set-controller br0 unix:controller])
@@ -93,6 +93,9 @@ AT_CHECK([ovs-appctl -t ovs-vswitchd version], [0], 
[ignore])
 
 # Now kill the ovs-testcontroller
 kill `cat ovs-testcontroller.pid`
+if test "$IS_WIN32" = "yes"; then
+AT_CHECK([rm controller], [0], [ignore])
+fi
 OVS_WAIT_UNTIL([! test -e controller])
 AT_CHECK([ovs-vsctl --no-wait add-port br0 p2 -- set Interface p2 
type=internal], [0], [ignore])
 AT_CHECK([ovs-appctl -t ovs-vswitchd version], [0], [ignore])
-- 
2.16.1.windows.1

___
dev mailing list
d...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C074d45f6e70d4431f7a708d64a4639a6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636778062866824077&sdata=EPht5myv2MmYwaY49hSYegAfewIVjkbvNCTf5YBsYJM%3D&reserved=0


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

[ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[Sairam Venugopal]

OVS_BUFFER_CONTEXT gets cleared as part of NdisFreeNetBufferListContext
function call. This causes an invalid reference error.

Found while testing with driver verifier enabled.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/BufferMgmt.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/BufferMgmt.c 
b/datapath-windows/ovsext/BufferMgmt.c
index 448cd76..da5c04a 100644
--- a/datapath-windows/ovsext/BufferMgmt.c
+++ b/datapath-windows/ovsext/BufferMgmt.c
@@ -1622,6 +1622,7 @@ OvsCompleteNBL(PVOID switch_ctx,
 {
 POVS_BUFFER_CONTEXT ctx;
 UINT16 flags;
+UINT32 dataOffsetDelta;
 PNET_BUFFER_LIST parent;
 NDIS_STATUS status;
 NDIS_HANDLE poolHandle;
@@ -1653,6 +1654,7 @@ OvsCompleteNBL(PVOID switch_ctx,
 nb = NET_BUFFER_LIST_FIRST_NB(nbl);
 
 flags = ctx->flags;
+dataOffsetDelta = ctx->dataOffsetDelta;
 if (!(flags & OVS_BUFFER_FRAGMENT) &&
 NET_BUFFER_DATA_LENGTH(nb) != ctx->origDataLength) {
 UINT32 diff;
@@ -1667,7 +1669,7 @@ OvsCompleteNBL(PVOID switch_ctx,
 }
 }
 
-if (ctx->flags & OVS_BUFFER_PRIVATE_CONTEXT) {
+if (flags & OVS_BUFFER_PRIVATE_CONTEXT) {
 NdisFreeNetBufferListContext(nbl, sizeof (OVS_BUFFER_CONTEXT));
 }
 
@@ -1740,7 +1742,7 @@ OvsCompleteNBL(PVOID switch_ctx,
 #ifdef DBG
 InterlockedDecrement((LONG volatile *)&ovsPool->fragNBLCount);
 #endif
-NdisFreeFragmentNetBufferList(nbl, ctx->dataOffsetDelta, 0);
+NdisFreeFragmentNetBufferList(nbl, dataOffsetDelta, 0);
 }
 
 if (parent != NULL) {
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] [RFC][windows]: Remap VPORT socket pool

[Sairam Venugopal]

Hi Alin,

Thanks for the patch. Shashank is giving it a run. How do we prevent this issue 
in the future?

For starters, I think we need to consolidate the usage under nl_* functions to 
ensure it's not doing something differently in vport_*.

We need to look into investing in the test framework for catching basic Windows 
failures like these. 

Thanks,
Sairam

On 11/12/18, 8:51 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

Fixes:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenvswitch%2Fovs-issues%2Fissues%2F164&data=02%7C01%7Cvsairam%40vmware.com%7C76dd26cc93e145b3a12008d648bf0d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636776382753818056&sdata=E%2FWSjXq%2BMfQlsGG9Fw59FblJxGTjOXYVFpNUKJtyp0k%3D&reserved=0

Signed-off-by: Alin Gabriel Serdean 
---
 lib/dpif-netlink.c | 58 
+-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 69c145cc3..5994c3445 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -246,6 +246,38 @@ static int dpif_netlink_port_query__(const struct 
dpif_netlink *dpif,
  odp_port_t port_no, const char 
*port_name,
  struct dpif_port *dpif_port);
 
+
+static struct nl_sock *
+vport_create_socksp_windows(struct dpif_netlink *dpif, int *error)
+OVS_REQ_WRLOCK(dpif->upcall_lock)
+{
+struct nl_sock *socksp;
+size_t i;
+/* Pick netlink sockets to use in a round-robin fashion from each
+ * handler's pool of sockets. */
+struct dpif_handler *handler = &dpif->handlers[0];
+struct dpif_windows_vport_sock *sock_pool = handler->vport_sock_pool;
+size_t index = handler->last_used_pool_idx;
+/* A pool of sockets is allocated when the handler is initialized. */
+if (sock_pool == NULL) {
+*error = EINVAL;
+return NULL;
+}
+ovs_assert(index < VPORT_SOCK_POOL_SIZE);
+socksp = sock_pool[index].nl_sock;
+ovs_assert(socksp);
+index = (index == VPORT_SOCK_POOL_SIZE - 1) ? 0 : index + 1;
+handler->last_used_pool_idx = index;
+*error = 0;
+return socksp;
+}
+static void
+vport_del_socksp_windows(struct dpif_netlink *dpif, struct nl_sock *socksp)
+{
+socksp = NULL;
+}
+
+
 static struct dpif_netlink *
 dpif_netlink_cast(const struct dpif *dpif)
 {
@@ -716,7 +748,12 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, 
const char *name,
 int error = 0;
 
 if (dpif->handlers) {
-if (nl_sock_create(NETLINK_GENERIC, &socksp)) {
+#ifdef _WIN32
+socksp = vport_create_socksp_windows(dpif, &error);
+#else
+error = nl_sock_create(NETLINK_GENERIC, &socksp);
+#endif
+if (!socksp) {
 return error;
 }
 }
@@ -748,7 +785,11 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, 
const char *name,
   dpif_name(&dpif->dpif), *port_nop);
 }
 
+#ifdef _WIN32
+vport_del_socksp_windows(dpif, socksp);
+#else
 nl_sock_destroy(socksp);
+#endif
 goto exit;
 }
 
@@ -763,7 +804,11 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, 
const char *name,
 request.dp_ifindex = dpif->dp_ifindex;
 request.port_no = *port_nop;
 dpif_netlink_vport_transact(&request, NULL, NULL);
+#ifdef _WIN32
+vport_del_socksp_windows(dpif, socksp);
+#else
 nl_sock_destroy(socksp);
+#endif
 goto exit;
 }
 
@@ -2249,15 +2294,26 @@ dpif_netlink_refresh_channels(struct dpif_netlink 
*dpif, uint32_t n_handlers)
 || !vport_get_pid(dpif, port_no, &upcall_pid)) {
 struct nl_sock *socksp;
 
+#ifdef _WIN32
+socksp = vport_create_socksp_windows(dpif, &error);
+if (!socksp) {
+goto error;
+}
+#else
 if (nl_sock_create(NETLINK_GENERIC, &socksp)) {
 goto error;
 }
+#endif
 
 error = vport_add_channel(dpif, vport.port_no, socksp);
 if (error) {
 VLOG_INFO("%s: could not add channels for port %s",
   dpif_name(&dpif->dpif), vport.name);
+#ifdef _WIN32
+vport_del_socksp_windows(dpif, socksp);
+#else
 nl_sock_destroy(socksp);
+#endif
 retval = error;
 goto error;
 }
-- 
2.16.1.windows.1

___
de

Re: [ovs-dev] [RFC PATCH v1 3/3] windows: Allow add/delete ports via HNS API

[Sairam Venugopal]

Can't you use CreateProcess or _popen to trigger the script/function directly?

Thanks,
Sairam

On 10/8/18, 4:28 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

On Windows 2016 LTSC(RTM) the Container feature and Hyper-V feature both had
DCOM API to add and delete internal (management) ports on the Hyper-V 
switch.

Starting from the 1703 release and above, enabling only the Container 
feature
does not fulfil this requirement anymore.

We need new ways to interact with the host API without the Hyper-V 
integration.

Unfortunately, there is no C API for it, only golang and .net:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fhcsshim&data=02%7C01%7Cvsairam%40vmware.com%7C1601769abfd64a60b41708d62d75af52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380831225713&sdata=pvCJPIt%2FOhVeth4fC22%2BlawFM0jvFPOQBFL6xMdvV6o%3D&reserved=0
 (golang)

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fdotnet-computevirtualization&data=02%7C01%7Cvsairam%40vmware.com%7C1601769abfd64a60b41708d62d75af52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380831225713&sdata=hVO%2B6%2BwjL8ZpklKGb6Ti2WA4dS2p20%2Bwy%2BfqS%2BPPCC0%3D&reserved=0
 (.net)
It is also poorly documented and reserved.

Although not pretty and less performant, this will provide a way to
add/delete and query the new APIs across different versions of Windows,
until new API's or documentation are available.

Signed-off-by: Alin Gabriel Serdean 
---
 lib/wmi.c | 95 
---
 1 file changed, 91 insertions(+), 4 deletions(-)

diff --git a/lib/wmi.c b/lib/wmi.c
index e6dc63cde..14451d591 100644
--- a/lib/wmi.c
+++ b/lib/wmi.c
@@ -203,6 +203,93 @@ wait_for_job(IWbemServices *psvc, wchar_t *job_path)
 return retval;
 }
 
+static boolean
+hns_delete(char *name)
+{
+VLOG_DBG("Trying to delete port via HNS API");
+char buffer[1];
+int count;
+count = snprintf(buffer, 1, "-NoLogo -NoProfile -NonInteractive"
+ "-Command \"try {Delete-OVSHNSInternalPort '%s'}"
+ "catch { exit 1 }; exit 0; \"", name);
+if (count < 0 || count > 1) {
+VLOG_WARN("Could not allocate memory for powershell delete 
command");
+return false;
+}
+VLOG_DBG("command = %s", buffer);
+DWORD res = 0;
+SHELLEXECUTEINFOA ShExecInfo;
+ShExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);
+ShExecInfo.fMask = SEE_MASK_NOCLOSEPROCESS;
+ShExecInfo.hwnd = NULL;
+ShExecInfo.lpVerb = NULL;
+ShExecInfo.lpFile = "powershell.exe";
+ShExecInfo.lpParameters = buffer;
+ShExecInfo.lpDirectory = NULL;
+ShExecInfo.nShow = SW_HIDE;
+ShExecInfo.hInstApp = NULL;
+ShellExecuteExA(&ShExecInfo);
+WaitForSingleObject(ShExecInfo.hProcess, 5);
+if (GetExitCodeProcess(ShExecInfo.hProcess, &res)) {
+if (res != 0) {
+VLOG_ERR("Powershell delete command failed with exit code: %d",
+ res);
+CloseHandle(ShExecInfo.hProcess);
+return false;
+}
+} else {
+VLOG_ERR("Failed to get exit code for powershell delete command."
+ "Last Error: %s", ovs_lasterror_to_string());
+CloseHandle(ShExecInfo.hProcess);
+return false;
+}
+CloseHandle(ShExecInfo.hProcess);
+return true;
+}
+
+static boolean
+hns_add(char *name)
+{
+VLOG_WARN("Trying to add port via HNS API");
+char buffer[1];
+int count;
+count = snprintf(buffer, 1, "-NoLogo -NoProfile -NonInteractive"
+ "-Command \"try {Add-OVSHNSInternalPort '%s'}"
+ "catch { exit 1 }; exit 0; \"", name);
+if (count < 0 || count > 1) {
+VLOG_WARN("Could not allocate memory for powershell add command");
+return false;
+}
+VLOG_WARN("command = %s", buffer);
+DWORD res = 0;
+SHELLEXECUTEINFOA ShExecInfo;
+ShExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);
+ShExecInfo.fMask = SEE_MASK_NOCLOSEPROCESS;
+ShExecInfo.hwnd = NULL;
+ShExecInfo.lpVerb = NULL;
+ShExecInfo.lpFile = "powershell.exe";
+ShExecInfo.lpParameters = buffer;
+ShExecInfo.lpDirectory = NULL;
+ShExecInfo.nShow = SW_HIDE;
+ShExecInfo.hInstApp = NULL;
+ShellExecuteExA(&ShExecInfo);
+WaitForSingleObject(ShExecInfo.hProcess, 5);
+if (GetExitCodeProcess(ShExecInfo.hProcess, &res)) {
+if (res != 0) {
+VLOG_ERR("Powershell add

Re: [ovs-dev] [RFC PATCH v1 1/3] datapath-windows: Introduce HNS OVS calls

[Sairam Venugopal]

Hi Alin,

Since the hns.psm1 isn't officially supported by Microsoft, is it safe to use 
the script as part of the OVS repo?  Also, "Invoke-HNSRequest" isn't officially 
documented at this time. I understand that this is an RFC, but do you know if 
Microsoft plans to finalize this api? If not, I would suggest keeping hns.psm1 
out of the OVS repo and instead assume that the end-user has access to it. 
Otherwise, OVS will need to keep parity with the script in Microsoft's project.

Thanks,
Sairam


On 10/8/18, 4:26 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

We introduce a new powershell module for interacting with HNS (host network 
service):

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FSDN%2Fblob%2Fmaster%2FKubernetes%2Fwindows%2Fhns.psm1&data=02%7C01%7Cvsairam%40vmware.com%7Cd3d913f61b40483be5c808d62d757f34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380042797946&sdata=rh%2FrirPPKSOUGvrHUhV36M2f83JUFX%2FkbGSCy%2FBvb%2BM%3D&reserved=0

In our repository this shall be named HNSHelper.psm1.

We also add five new commandlets in our OVS powershell module:
Disable-OVSOnHNSNetwork - disable OVS extension on a given HNS network.
Enable-OVSOnHNSNetwork - enable OVS extension on a given HNS network.
Get-OVSEnabledHNSNetworks - return the HNS network on which OVS is enabled.
Add-OVSHNSInternalPort - will add a new internal port with he name: `name`, 
on
 the HNS network, which has OVS enabled. This port
 shall use the host compartment.
Delete-OVSHNSInternalPort - will delete an internal port with name: `name` 
on a
HNS network which has OVS enabled.

Signed-off-by: Alin Gabriel Serdean 
---
 datapath-windows/automake.mk |   1 +
 datapath-windows/misc/HNSHelper.psm1 | 499 
+++
 datapath-windows/misc/OVS.psm1   |  79 +-
 3 files changed, 578 insertions(+), 1 deletion(-)
 create mode 100644 datapath-windows/misc/HNSHelper.psm1

diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
index 3820041f6..d98ab3c60 100644
--- a/datapath-windows/automake.mk
+++ b/datapath-windows/automake.mk
@@ -3,6 +3,7 @@ EXTRA_DIST += \
datapath-windows/Package/package.VcxProj.user \
datapath-windows/include/OvsDpInterfaceExt.h \
datapath-windows/include/OvsDpInterfaceCtExt.h \
+   datapath-windows/misc/HNSHelper.psm1 \
datapath-windows/misc/OVS.psm1 \
datapath-windows/misc/install.cmd \
datapath-windows/misc/uninstall.cmd \
diff --git a/datapath-windows/misc/HNSHelper.psm1 
b/datapath-windows/misc/HNSHelper.psm1
new file mode 100644
index 0..ac99889cf
--- /dev/null
+++ b/datapath-windows/misc/HNSHelper.psm1
@@ -0,0 +1,499 @@
+# SDN Sample Scripts  v.1.0
+#
+# Copyright (c) Microsoft Corporation
+#
+# All rights reserved. 
+#
+# MIT License
+#
+# Permission is hereby granted, free of charge, to any person obtaining a 
copy
+# of this software and associated documentation files (the ""Software""), 
to
+# deal in the Software without restriction, including without limitation 
the
+# rights to use, copy, modify, merge, publish, distribute, sublicense, 
and/or
+# sell copies of the Software, and to permit persons to whom the Software 
is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included 
in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED *AS IS*, WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
IN THE
+# SOFTWARE.
+#
+#
+# Global Initialize
+function Get-VmComputeNativeMethods()
+{
+$signature = @'
+ [DllImport("vmcompute.dll")]
+ public static extern void 
HNSCall([MarshalAs(UnmanagedType.LPWStr)] string method, 
[MarshalAs(UnmanagedType.LPWStr)] string path, 
[MarshalAs(UnmanagedType.LPWStr)] string request, 
[MarshalAs(UnmanagedType.LPWStr)] out string response);
+'@
+
+# Compile into runtime type
+try { return [VmCompute.PrivatePInvoke.NativeMethods] }
+catch { return (Add-Type -MemberDefinition $signature -Namespace 
VmCompute.PrivatePInvoke 

Re: [ovs-dev] [RFC PATCH v1 2/3] windows, installer: Add a new module file to the installer

[Sairam Venugopal]

Hi Alin,

Thanks for the patch. Can't we have the HNSHelper.psm1 be part of the OVS.psm1 
directory?

Thanks,
Sairam

On 10/8/18, 4:27 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

This patch adds the new powershell module HNSHelper.psm1 to the OVS windows
installer.


Signed-off-by: Alin Gabriel Serdean 
---
 windows/automake.mk   | 1 +
 windows/ovs-windows-installer/Product.wxs | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/windows/automake.mk b/windows/automake.mk
index 80dca1467..79ffe4317 100644
--- a/windows/automake.mk
+++ b/windows/automake.mk
@@ -16,6 +16,7 @@ PTHREAD_TEMP_DIR=`echo "$(PTHREAD_LDFLAGS)" | sed 
's|^.\(.*\).$:\1||'`
 windows_installer: all
 #Userspace files needed for the installer
cp -f $(top_srcdir)/datapath-windows/misc/OVS.psm1 
windows/ovs-windows-installer/Services/OVS.psm1
+   cp -f $(top_srcdir)/datapath-windows/misc/HNSHelper.psm1 
windows/ovs-windows-installer/Services/HNSHelper.psm1
cp -f $(top_srcdir)/vswitchd/vswitch.ovsschema 
windows/ovs-windows-installer/Services/vswitch.ovsschema
cp -f $(top_srcdir)/vswitchd/ovs-vswitchd.exe 
windows/ovs-windows-installer/Services/ovs-vswitchd.exe
cp -f $(top_srcdir)/ovsdb/ovsdb-server.exe 
windows/ovs-windows-installer/Services/ovsdb-server.exe
diff --git a/windows/ovs-windows-installer/Product.wxs 
b/windows/ovs-windows-installer/Product.wxs
index ea1bc6896..9742c1773 100644
--- a/windows/ovs-windows-installer/Product.wxs
+++ b/windows/ovs-windows-installer/Product.wxs
@@ -67,6 +67,7 @@
   
   
   
+  
 
 
 
@@ -147,6 +148,7 @@
   
 
   
+  
 
   
 
@@ -156,6 +158,10 @@
 
   
 
+
+
+  
+
   
 
   
-- 
2.16.1.windows.1

___
dev mailing list
d...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-dev&data=02%7C01%7Cvsairam%40vmware.com%7C31a7ab5d8248475b9ed208d62d75a018%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380628667609&sdata=uTjgL%2BiwcWziG5eqVMEs0KWQkYAjwBQWlldRQxy2KhY%3D&reserved=0


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

[ovs-dev] [PATCH] datapath-windows: Move OVS_IPHELPER_INSTANCE to IpHelper.h

[Sairam Venugopal]

Move the IPHelper Instance to the main header file and update the usage to
explicitly point to POVS_IPHELPER_INSTANCE instead of PVOID. Also rename
the ipn->context to ipn->instance to make it more readable.

Found by inspection.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/IpHelper.c | 32 ++-
 datapath-windows/ovsext/IpHelper.h | 45 ++
 2 files changed, 38 insertions(+), 39 deletions(-)

diff --git a/datapath-windows/ovsext/IpHelper.c 
b/datapath-windows/ovsext/IpHelper.c
index c734b0e..876da92 100644
--- a/datapath-windows/ovsext/IpHelper.c
+++ b/datapath-windows/ovsext/IpHelper.c
@@ -40,34 +40,6 @@ static LIST_ENTRY  ovsInstanceList;
 static ERESOURCE   ovsInstanceListLock;
 
 /*
- * This structure is used to define each adapter instance.
- *
- * Note:
- * Only when the internal IP is configured and virtual
- * internal port is connected, the IP helper request can be
- * queued.
- *
- * We only keep internal IP for reference, it will not be used for determining
- * SRC IP of the Tunnel.
- *
- * The lock must not raise the IRQL higher than PASSIVE_LEVEL in order for the
- * route manipulation functions, i.e. GetBestRoute, to work.
- */
-typedef struct _OVS_IPHELPER_INSTANCE
-{
-LIST_ENTRY  link;
-
-BOOLEAN isIpConfigured;
-UINT32  portNo;
-GUIDnetCfgId;
-MIB_IF_ROW2 internalRow;
-MIB_IPINTERFACE_ROW internalIPRow;
-UINT32  ipAddress;
-
-ERESOURCE   lock;
-} OVS_IPHELPER_INSTANCE, *POVS_IPHELPER_INSTANCE;
-
-/*
  * FWD_ENTRY >  IPFORWARD_ENTRY
  *  |
  *  |--> IPENIGH_ENTRY
@@ -1070,7 +1042,7 @@ OvsCreateIPNeighEntry(PMIB_IPNET_ROW2 ipNeigh,
 RtlCopyMemory(entry->macAddr, ipNeigh->PhysicalAddress,
   ETH_ADDR_LEN);
 InitializeListHead(&entry->fwdList);
-entry->context = (PVOID)instance;
+entry->instance = instance;
 
 return entry;
 }
@@ -1934,7 +1906,7 @@ OvsStartIpHelper(PVOID data)
 ipAddr = ipn->ipAddr;
 MIB_IPNET_ROW2 ipNeigh;
 NTSTATUS status;
-POVS_IPHELPER_INSTANCE instance = 
(POVS_IPHELPER_INSTANCE)ipn->context;
+POVS_IPHELPER_INSTANCE instance = ipn->instance;
 NdisReleaseSpinLock(&ovsIpHelperLock);
 ExAcquireResourceExclusiveLite(&ovsInstanceListLock, TRUE);
 
diff --git a/datapath-windows/ovsext/IpHelper.h 
b/datapath-windows/ovsext/IpHelper.h
index 0556965..25adf6e 100644
--- a/datapath-windows/ovsext/IpHelper.h
+++ b/datapath-windows/ovsext/IpHelper.h
@@ -32,17 +32,44 @@
 
 #define OVS_IPNEIGH_TIMEOUT 1   // 10 s
 
+ /*
+ * This structure is used to define each adapter instance.
+ *
+ * Note:
+ * Only when the internal IP is configured and virtual
+ * internal port is connected, the IP helper request can be
+ * queued.
+ *
+ * We only keep internal IP for reference, it will not be used for determining
+ * SRC IP of the Tunnel.
+ *
+ * The lock must not raise the IRQL higher than PASSIVE_LEVEL in order for the
+ * route manipulation functions, i.e. GetBestRoute, to work.
+ */
+typedef struct _OVS_IPHELPER_INSTANCE
+{
+LIST_ENTRY  link;
+
+BOOLEAN isIpConfigured;
+UINT32  portNo;
+GUIDnetCfgId;
+MIB_IF_ROW2 internalRow;
+MIB_IPINTERFACE_ROW internalIPRow;
+UINT32  ipAddress;
+
+ERESOURCE   lock;
+} OVS_IPHELPER_INSTANCE, *POVS_IPHELPER_INSTANCE;
 
 typedef struct _OVS_IPNEIGH_ENTRY {
-UINT8 macAddr[ETH_ADDR_LEN];
-UINT16refCount;
-UINT32ipAddr;
-UINT32pad;
-UINT64timeout;
-LIST_ENTRYlink;
-LIST_ENTRYslink;
-LIST_ENTRYfwdList;
-PVOID context;
+UINT8   macAddr[ETH_ADDR_LEN];
+UINT16  refCount;
+UINT32  ipAddr;
+UINT32  pad;
+UINT64  timeout;
+LIST_ENTRY  link;
+LIST_ENTRY  slink;
+LIST_ENTRY  fwdList;
+POVS_IPHELPER_INSTANCE  instance;
 } OVS_IPNEIGH_ENTRY, *POVS_IPNEIGH_ENTRY;
 
 typedef struct _OVS_IPFORWARD_ENTRY {
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Add support to configure ct zone limits

[Sairam Venugopal]

Hi Anand,

Thanks for the patch. See comments inline. 

Thanks,
Sairam

On 8/21/18, 2:58 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand 
Kumar"  
wrote:

This patch implements limiting conntrack entries
per zone using dpctl commands.

Example:
ovs-appctl dpctl/ct-set-limits default=5 zone=1,limit=2 zone=1,limit=3
ovs-appctl dpct/ct-del-limits zone=4
ovs-appctl dpct/ct-get-limits zone=1,2,3

- Also update the netlink-socket.c to support netlink family
  'OVS_WIN_NL_CTLIMIT_FAMILY_ID' for conntrack zone limit.

Signed-off-by: Anand Kumar 
---
 datapath-windows/include/OvsDpInterfaceExt.h |   1 +
 datapath-windows/ovsext/Conntrack.c  | 163 
++-
 datapath-windows/ovsext/Conntrack.h  |  12 ++
 datapath-windows/ovsext/Datapath.c   |  34 +-
 lib/netlink-socket.c |   5 +
 5 files changed, 212 insertions(+), 3 deletions(-)

diff --git a/datapath-windows/include/OvsDpInterfaceExt.h 
b/datapath-windows/include/OvsDpInterfaceExt.h
index db91c3e..5fd8000 100644
--- a/datapath-windows/include/OvsDpInterfaceExt.h
+++ b/datapath-windows/include/OvsDpInterfaceExt.h
@@ -72,6 +72,7 @@
  */
 
 #define OVS_WIN_NL_CT_FAMILY_ID  (NLMSG_MIN_TYPE + 7)
+#define OVS_WIN_NL_CTLIMIT_FAMILY_ID (NLMSG_MIN_TYPE + 8)
 
 #define OVS_WIN_NL_INVALID_MCGRP_ID  0
 #define OVS_WIN_NL_MCGRP_START_ID100
diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index dd16602..b806cd7 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -34,6 +34,8 @@ static OVS_CT_THREAD_CTX ctThreadCtx;
 static PNDIS_RW_LOCK_EX *ovsCtBucketLock = NULL;
 extern POVS_SWITCH_CONTEXT gOvsSwitchContext;
 static ULONG ctTotalEntries;
+static POVS_CT_ZONE_INFO zoneInfo = NULL;
+static ULONG defaultCtLimit;
 
 static __inline OvsCtFlush(UINT16 zone, struct ovs_key_ct_tuple_ipv4 
*tuple);
 static __inline NDIS_STATUS
@@ -99,6 +101,19 @@ OvsInitConntrack(POVS_SWITCH_CONTEXT context)
 if (status != STATUS_SUCCESS) {
 OvsCleanupConntrack();
 }
+

Sai: Can you move the following prior to the OvsNatInit or handle 
OvsCleanupConntrack()?
Also, shouldn't zoneInfo have a lock for manipulation?

+zoneInfo = OvsAllocateMemoryWithTag(sizeof(OVS_CT_ZONE_INFO) *
+(UINT16_MAX + 1), OVS_CT_POOL_TAG);
+if (zoneInfo == NULL) {
+status = STATUS_INSUFFICIENT_RESOURCES;
+goto freeBucketLock;
+}
+
+defaultCtLimit = CT_MAX_ENTRIES;
+for (int i = 0; i <= UINT16_MAX; i++) {
+zoneInfo[i].entries = 0;
+zoneInfo[i].limit = defaultCtLimit;
+}
 return STATUS_SUCCESS;
 
 freeBucketLock:
@@ -149,6 +164,22 @@ OvsCleanupConntrack(VOID)
 OvsFreeMemoryWithTag(ovsCtBucketLock, OVS_CT_POOL_TAG);
 ovsCtBucketLock = NULL;
 OvsNatCleanup();
+if (zoneInfo) {
+OvsFreeMemoryWithTag(zoneInfo, OVS_CT_POOL_TAG);
+}
+}
+
+VOID


Sai: can we set zone to UINT16 instead of int?

+OvsCtSetZoneLimit(int zone, ULONG value) {
+   if (zone == -1) {
+/* Set default limit for all zones. */
+defaultCtLimit = value;
+for (UINT32 i = 0; i <= UINT16_MAX; i++) {
+zoneInfo[i].limit = value;
+}
+} else {
+zoneInfo[(UINT16)zone].limit = value;
+}
 }
 
 /*
@@ -263,6 +294,7 @@ OvsCtAddEntry(POVS_CT_ENTRY entry,
&entry->link);
 
 NdisInterlockedIncrement((PLONG)&ctTotalEntries);
+zoneInfo[ctx->key.zone].entries++;
 NdisReleaseRWLock(ovsCtBucketLock[bucketIdx], &lockState);
 return TRUE;
 }
@@ -437,6 +469,7 @@ OvsCtEntryDelete(POVS_CT_ENTRY entry, BOOLEAN 
forceDelete)
 if (entry->natInfo.natAction) {
 OvsNatDeleteKey(&entry->key);
 }
+zoneInfo[entry->key.zone].entries--;
 OvsPostCtEventEntry(entry, OVS_EVENT_CT_DELETE);
 RemoveEntryList(&entry->link);
 OVS_RELEASE_SPIN_LOCK(&(entry->lock), irql);
@@ -877,12 +910,16 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
  &entryCreated);
 
 } else {
-if (commit && ctTotalEntries >= CT_MAX_ENTRIES) {
+if (commit && (ctTotalEntries >= CT_MAX_ENTRIES ||
+zoneInfo[ctx.key.zone].entries >= 
zoneInfo[ctx.key.zone].limit)) {
 /* Don't proceed with processing if the max limit has been hit.
  * This blocks only new entries from being created and doesn't
  * affect e

Re: [ovs-dev] [PATCH v3] ofproto-collectors: Windows - Trigger an ARP request before sending IPFIX packet

[Sairam Venugopal]

Thanks for pointing this out. It might be better to simply add a static ARP 
entry when adding an IPFIX collector. This way we do not trigger this for every 
packet. 

We are currently documenting this as a workaround for using IPFIX collectors on 
the same subnet as the Hyper-V host. This patch  was an RFC to see if we could 
improve this mechanism.

Calling SendArp in a separate thread means that we will somehow need to block 
the IPFIX packet send until ARP resolves. Otherwise, Windows might just 
continue to drop UDP packets. We can also check if there is a route to the 
Collector from the Host and drop the IPFIX packets, but this should've somehow 
been handled better by the Windows Sockets routine.

Thanks,
Sairam

On 5/24/18, 10:09 AM, "Ben Pfaff"  wrote:

The MSDN entry is really unclear.  It says that it sends an ARP request,
if necessary.  I cannot find anything in the entry that says whether, if
it sends an ARP request, it waits for a reply.

However, this stackoverflow entry implies that it does wait for a reply:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_43626184_any-2Dway-2Dto-2Dchange-2Dthe-2Dbehavior-2Dof-2Dsynchronous-2Dwindows-2Dapi-2Dsendarp&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=8GsX0EVrqINs9sASEjOQ9sRGoswFi0dSVQQ7_SEBrfU&s=_TGWYeiurUno6rosPRGPjkeSNycWHjHfqs3e_sWVjL4&e=

I think that's probably unacceptable because blocking the OVS main
thread will break lots of stuff.  If it's necessary to block for ARP
resolution, then I think it will have to happen in a thread dedicated to
that purpose.
    
    On Thu, May 24, 2018 at 03:13:58PM +, Sairam Venugopal wrote:
> This is the snippet from MSDN:  
https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_en-2Dus_library_windows_desktop_aa366358-28v-3Dvs.85-29.aspx&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=8GsX0EVrqINs9sASEjOQ9sRGoswFi0dSVQQ7_SEBrfU&s=XtI9PPWyM9PyrQpzlOEv9m1FFEKysRnXiuYlqImusn8&e=
> 
> The SendARP function is used to request the physical hardware address 
(sometimes referred to as the MAC address) that corresponds to a specified 
destination IPv4 address. If the information requested is not in the ARP table 
on the local computer, then the SendARP function will cause an ARP request to 
be sent to obtain the physical address. If the function is successful, the 
physical address that corresponds to the specified destination IPv4 address is 
returned in the array pointed to by the pMacAddr parameter.
> 
> I don't think this would end up blocking every other thread in OVS. I 
might've relayed this information incorrectly. There isn't an argument to 
specify timeout for the SendArp function.
> 
> Thanks,
> Sairam
    > 
> On 5/23/18, 1:19 PM, "Ben Pfaff"  wrote:
> 
> On Fri, May 18, 2018 at 03:16:43PM -0700, Sairam Venugopal wrote:
> > IPFIX templates and flow packets are silently dropped when a 
corresponding
> > ARP entry is missing for the Collector. The fix is to explicitly 
trigger an
> > ARP request before sending UDP packets to the collector.
> > 
> > Making changes in Windows to maintain the destination IP address as 
part
> > of the Collector Structure. Since the SendARP is a blocking call, 
we do
> > not necessarily need to check for a response before sending the 
IPFIX
> > packets. Keeping the fix specific to Windows since this behavior 
cannot be
> > reproduced in Linux.
> 
> When you say that SendARP is a blocking call, do you mean that it 
sends
> a packet and then waits for a response?  That will delay everything 
else
> happening in the OVS main thread for an arbitrary amount of time.
> Usually this is not acceptable.
> 
> 


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

Re: [ovs-dev] [PATCH v3] ofproto-collectors: Windows - Trigger an ARP request before sending IPFIX packet

[Sairam Venugopal]

This is the snippet from MSDN:  
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366358(v=vs.85).aspx

The SendARP function is used to request the physical hardware address 
(sometimes referred to as the MAC address) that corresponds to a specified 
destination IPv4 address. If the information requested is not in the ARP table 
on the local computer, then the SendARP function will cause an ARP request to 
be sent to obtain the physical address. If the function is successful, the 
physical address that corresponds to the specified destination IPv4 address is 
returned in the array pointed to by the pMacAddr parameter.

I don't think this would end up blocking every other thread in OVS. I might've 
relayed this information incorrectly. There isn't an argument to specify 
timeout for the SendArp function.

Thanks,
Sairam

On 5/23/18, 1:19 PM, "Ben Pfaff"  wrote:

On Fri, May 18, 2018 at 03:16:43PM -0700, Sairam Venugopal wrote:
> IPFIX templates and flow packets are silently dropped when a corresponding
> ARP entry is missing for the Collector. The fix is to explicitly trigger 
an
> ARP request before sending UDP packets to the collector.
> 
> Making changes in Windows to maintain the destination IP address as part
> of the Collector Structure. Since the SendARP is a blocking call, we do
> not necessarily need to check for a response before sending the IPFIX
> packets. Keeping the fix specific to Windows since this behavior cannot be
> reproduced in Linux.

When you say that SendARP is a blocking call, do you mean that it sends
a packet and then waits for a response?  That will delay everything else
happening in the OVS main thread for an arbitrary amount of time.
Usually this is not acceptable.


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

[ovs-dev] [PATCH v3] ofproto-collectors: Windows - Trigger an ARP request before sending IPFIX packet

[Sairam Venugopal]

IPFIX templates and flow packets are silently dropped when a corresponding
ARP entry is missing for the Collector. The fix is to explicitly trigger an
ARP request before sending UDP packets to the collector.

Making changes in Windows to maintain the destination IP address as part
of the Collector Structure. Since the SendARP is a blocking call, we do
not necessarily need to check for a response before sending the IPFIX
packets. Keeping the fix specific to Windows since this behavior cannot be
reproduced in Linux.

Reported-at: https://github.com/openvswitch/ovs-issues/issues/147
Signed-off-by: Sairam Venugopal 
---
 ofproto/collectors.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/ofproto/collectors.c b/ofproto/collectors.c
index bc92332..4ce290e 100644
--- a/ofproto/collectors.c
+++ b/ofproto/collectors.c
@@ -27,11 +27,17 @@
 #include "sset.h"
 #include "util.h"
 #include "openvswitch/vlog.h"
+#ifdef WIN32
+#include 
+#endif WIN32
 
 VLOG_DEFINE_THIS_MODULE(collectors);
 
 struct collectors {
 int *fds; /* Sockets. */
+#ifdef WIN32
+IPAddr *dest_ips; /* Collector's IP address */
+#endif WIN32
 size_t n_fds; /* Number of sockets. */
 };
 
@@ -58,6 +64,9 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 c = xmalloc(sizeof *c);
 c->fds = xmalloc(sizeof *c->fds * sset_count(targets));
+#ifdef WIN32
+c->dest_ips = xmalloc(sizeof *c->dest_ips * sset_count(targets));
+#endif
 c->n_fds = 0;
 SSET_FOR_EACH (name, targets) {
 int error;
@@ -65,6 +74,13 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 error = inet_open_active(SOCK_DGRAM, name, default_port, NULL, &fd, 0);
 if (fd >= 0) {
+#ifdef WIN32
+char *target = xstrdup(name);
+char *p;
+p = target;
+c->dest_ips[c->n_fds] = htonl(inet_addr(inet_parse_token(&p)));
+free(target);
+#endif WIN32
 c->fds[c->n_fds++] = fd;
 } else {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
@@ -97,6 +113,9 @@ collectors_destroy(struct collectors *c)
 for (i = 0; i < c->n_fds; i++) {
 closesocket(c->fds[i]);
 }
+#ifdef WIN32
+free(c->dest_ips);
+#endif
 free(c->fds);
 free(c);
 }
@@ -114,6 +133,17 @@ collectors_send(const struct collectors *c, const void 
*payload, size_t n)
 
 for (i = 0; i < c->n_fds; i++) {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+#ifdef WIN32
+/* Trigger an ARP request before sending an IPFIX packet */
+ULONG mac[2];
+ULONG phys_addr_len = 6;
+DWORD ret_val;
+ret_val = SendARP(c->dest_ips[i], 0, &mac, &phys_addr_len);
+if (ret_val != NO_ERROR) {
+VLOG_ERR_RL(&rl, "Sending ARP failed:%lu for %lu",
+ret_val, c->dest_ips[i]);
+}
+#endif
 if (send(c->fds[i], payload, n, 0) == -1) {
 char *s = describe_fd(c->fds[i]);
 VLOG_WARN_RL(&rl, "%s: sending to collector failed (%s)",
-- 
2.9.0.windows.1

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

[ovs-dev] [PATCH v2] Windows: Trigger an ARP request before sending IPFIX packet

[Sairam Venugopal]

IPFIX templates and flow packets are silently dropped when a corresponding
ARP entry is missing for the Collector. The fix is to explicitly trigger an
ARP request before sending UDP packets to the collector.

Making changes in Windows to maintain the destination IP address as part
of the Collector Structure. Since the SendARP is a blocking call, we do
not necessarily need to check for a response before sending the IPFIX
packets. Keeping the fix specific to Windows since this behavior cannot be
reproduced in Linux.

Reported-at: https://github.com/openvswitch/ovs-issues/issues/147
Signed-off-by: Sairam Venugopal 
---
 ofproto/collectors.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/ofproto/collectors.c b/ofproto/collectors.c
index bc92332..4ce290e 100644
--- a/ofproto/collectors.c
+++ b/ofproto/collectors.c
@@ -27,11 +27,17 @@
 #include "sset.h"
 #include "util.h"
 #include "openvswitch/vlog.h"
+#ifdef WIN32
+#include 
+#endif WIN32
 
 VLOG_DEFINE_THIS_MODULE(collectors);
 
 struct collectors {
 int *fds; /* Sockets. */
+#ifdef WIN32
+IPAddr *dest_ips; /* Collector's IP address */
+#endif WIN32
 size_t n_fds; /* Number of sockets. */
 };
 
@@ -58,6 +64,9 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 c = xmalloc(sizeof *c);
 c->fds = xmalloc(sizeof *c->fds * sset_count(targets));
+#ifdef WIN32
+c->dest_ips = xmalloc(sizeof *c->dest_ips * sset_count(targets));
+#endif
 c->n_fds = 0;
 SSET_FOR_EACH (name, targets) {
 int error;
@@ -65,6 +74,13 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 error = inet_open_active(SOCK_DGRAM, name, default_port, NULL, &fd, 0);
 if (fd >= 0) {
+#ifdef WIN32
+char *target = xstrdup(name);
+char *p;
+p = target;
+c->dest_ips[c->n_fds] = htonl(inet_addr(inet_parse_token(&p)));
+free(target);
+#endif WIN32
 c->fds[c->n_fds++] = fd;
 } else {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
@@ -97,6 +113,9 @@ collectors_destroy(struct collectors *c)
 for (i = 0; i < c->n_fds; i++) {
 closesocket(c->fds[i]);
 }
+#ifdef WIN32
+free(c->dest_ips);
+#endif
 free(c->fds);
 free(c);
 }
@@ -114,6 +133,17 @@ collectors_send(const struct collectors *c, const void 
*payload, size_t n)
 
 for (i = 0; i < c->n_fds; i++) {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+#ifdef WIN32
+/* Trigger an ARP request before sending an IPFIX packet */
+ULONG mac[2];
+ULONG phys_addr_len = 6;
+DWORD ret_val;
+ret_val = SendARP(c->dest_ips[i], 0, &mac, &phys_addr_len);
+if (ret_val != NO_ERROR) {
+VLOG_ERR_RL(&rl, "Sending ARP failed:%lu for %lu",
+ret_val, c->dest_ips[i]);
+}
+#endif
 if (send(c->fds[i], payload, n, 0) == -1) {
 char *s = describe_fd(c->fds[i]);
 VLOG_WARN_RL(&rl, "%s: sending to collector failed (%s)",
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] Windows: Trigger an ARP request before sending IPFIX packet

[Sairam Venugopal]

Will send out a V2 with the correct Commit Msg Title. Consider this as an RFC.

On 5/8/18, 10:07 AM, "Sairam Venugopal"  wrote:

IPFIX templates and flow packets are silently dropped when a corresponding
ARP entry is missing for the Collector. The fix is to explicitly trigger an
ARP request before sending UDP packets to the collector.

Making changes in Windows to maintain the destination IP address as part
of the Collector Structure. Since the SendARP is a blocking call, we do
not necessarily need to check for a response before sending the IPFIX
packets. Keeping the fix specific to Windows since this behavior cannot be
reproduced in Linux.

Reported-at: https://github.com/openvswitch/ovs-issues/issues/147
Signed-off-by: Sairam Venugopal 
---
 ofproto/collectors.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/ofproto/collectors.c b/ofproto/collectors.c
index bc92332..239599a 100644
--- a/ofproto/collectors.c
+++ b/ofproto/collectors.c
@@ -27,11 +27,17 @@
 #include "sset.h"
 #include "util.h"
 #include "openvswitch/vlog.h"
+#ifdef WIN32
+#include 
+#endif WIN32
 
 VLOG_DEFINE_THIS_MODULE(collectors);
 
 struct collectors {
 int *fds; /* Sockets. */
+#ifdef WIN32
+IPAddr *destIPs;  /* Collector's IP address */
+#endif WIN32
 size_t n_fds; /* Number of sockets. */
 };
 
@@ -58,6 +64,9 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 c = xmalloc(sizeof *c);
 c->fds = xmalloc(sizeof *c->fds * sset_count(targets));
+#ifdef WIN32
+c->destIPs = xmalloc(sizeof *c->destIPs * sset_count(targets));
+#endif
 c->n_fds = 0;
 SSET_FOR_EACH (name, targets) {
 int error;
@@ -65,6 +74,13 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 error = inet_open_active(SOCK_DGRAM, name, default_port, NULL, 
&fd, 0);
 if (fd >= 0) {
+#ifdef WIN32
+char *target = xstrdup(name);
+char *p;
+p = target;
+c->destIPs[c->n_fds] = htonl(inet_addr(inet_parse_token(&p)));
+free(target);
+#endif WIN32
 c->fds[c->n_fds++] = fd;
 } else {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
@@ -97,6 +113,9 @@ collectors_destroy(struct collectors *c)
 for (i = 0; i < c->n_fds; i++) {
 closesocket(c->fds[i]);
 }
+#ifdef WIN32
+free(c->destIPs);
+#endif
 free(c->fds);
 free(c);
 }
@@ -114,6 +133,12 @@ collectors_send(const struct collectors *c, const void 
*payload, size_t n)
 
 for (i = 0; i < c->n_fds; i++) {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+#ifdef WIN32
+/* Trigger an ARP request before sending an IPFIX packet */
+ULONG MacAddr[2];
+ULONG PhysAddrLen = 6;
+SendARP(c->destIPs[i], 0, &MacAddr, &PhysAddrLen);
+#endif
 if (send(c->fds[i], payload, n, 0) == -1) {
 char *s = describe_fd(c->fds[i]);
 VLOG_WARN_RL(&rl, "%s: sending to collector failed (%s)",
-- 
2.9.0.windows.1



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

[ovs-dev] [PATCH] Windows: Trigger an ARP request before sending IPFIX packet

[Sairam Venugopal]

IPFIX templates and flow packets are silently dropped when a corresponding
ARP entry is missing for the Collector. The fix is to explicitly trigger an
ARP request before sending UDP packets to the collector.

Making changes in Windows to maintain the destination IP address as part
of the Collector Structure. Since the SendARP is a blocking call, we do
not necessarily need to check for a response before sending the IPFIX
packets. Keeping the fix specific to Windows since this behavior cannot be
reproduced in Linux.

Reported-at: https://github.com/openvswitch/ovs-issues/issues/147
Signed-off-by: Sairam Venugopal 
---
 ofproto/collectors.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/ofproto/collectors.c b/ofproto/collectors.c
index bc92332..239599a 100644
--- a/ofproto/collectors.c
+++ b/ofproto/collectors.c
@@ -27,11 +27,17 @@
 #include "sset.h"
 #include "util.h"
 #include "openvswitch/vlog.h"
+#ifdef WIN32
+#include 
+#endif WIN32
 
 VLOG_DEFINE_THIS_MODULE(collectors);
 
 struct collectors {
 int *fds; /* Sockets. */
+#ifdef WIN32
+IPAddr *destIPs;  /* Collector's IP address */
+#endif WIN32
 size_t n_fds; /* Number of sockets. */
 };
 
@@ -58,6 +64,9 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 c = xmalloc(sizeof *c);
 c->fds = xmalloc(sizeof *c->fds * sset_count(targets));
+#ifdef WIN32
+c->destIPs = xmalloc(sizeof *c->destIPs * sset_count(targets));
+#endif
 c->n_fds = 0;
 SSET_FOR_EACH (name, targets) {
 int error;
@@ -65,6 +74,13 @@ collectors_create(const struct sset *targets, uint16_t 
default_port,
 
 error = inet_open_active(SOCK_DGRAM, name, default_port, NULL, &fd, 0);
 if (fd >= 0) {
+#ifdef WIN32
+char *target = xstrdup(name);
+char *p;
+p = target;
+c->destIPs[c->n_fds] = htonl(inet_addr(inet_parse_token(&p)));
+free(target);
+#endif WIN32
 c->fds[c->n_fds++] = fd;
 } else {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
@@ -97,6 +113,9 @@ collectors_destroy(struct collectors *c)
 for (i = 0; i < c->n_fds; i++) {
 closesocket(c->fds[i]);
 }
+#ifdef WIN32
+free(c->destIPs);
+#endif
 free(c->fds);
 free(c);
 }
@@ -114,6 +133,12 @@ collectors_send(const struct collectors *c, const void 
*payload, size_t n)
 
 for (i = 0; i < c->n_fds; i++) {
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+#ifdef WIN32
+/* Trigger an ARP request before sending an IPFIX packet */
+ULONG MacAddr[2];
+ULONG PhysAddrLen = 6;
+SendARP(c->destIPs[i], 0, &MacAddr, &PhysAddrLen);
+#endif
 if (send(c->fds[i], payload, n, 0) == -1) {
 char *s = describe_fd(c->fds[i]);
 VLOG_WARN_RL(&rl, "%s: sending to collector failed (%s)",
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Update ct stats when packet is processed by conntrack

[Sairam Venugopal]

Anand,

Thanks for the patch. Can you update the commit message to better describe the 
underlying issue?

Prevent conntrack-counters from getting redundantly incremented for 
recirculated packets.  
The counters ought to be incremented only if it's a new lookup or if it's 
recirculated through a different zone for the first time.

Thanks,
Sairam

On 4/25/18, 1:06 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand 
Kumar"  
wrote:

When ct lookup returns a matching ct entry, increment ct stats
even if the zone information in conntrack entry does not match with
flowkey.

Signed-off-by: Anand Kumar 
---
 datapath-windows/ovsext/Conntrack.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 678bedb..add1491 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -886,10 +886,11 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
 return NDIS_STATUS_RESOURCES;
 }
 
-/* Increment the counters soon after the lookup, since we set ct.state
- * to OVS_CS_F_TRACKED after processing the ct entry.
+/* Increment stats for the entry if it wasn't tracked previously or
+ * if they are on different zones
  */
-if (entry && (!(key->ct.state & OVS_CS_F_TRACKED))) {
+if (entry && (entry->key.zone != key->ct.zone ||
+   (!(key->ct.state & OVS_CS_F_TRACKED {
 OvsCtIncrementCounters(entry, ctx.reply, curNbl);
 }
 
-- 
2.9.3.windows.1

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=0j1dB0xbZjupscaOcQmDzLRgDPo5kjVp8k_-HX4w7P8&s=HdqtDC96bCuR7w2P7qVPA5skEcXSEeVqVbqefbaA5pw&e=


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

[ovs-dev] [PATCH] datapath-windows: Block established TCP connections from creating new CT Entry

[Sairam Venugopal]

Established TCP Connections could potentially form invalid Conntrack
Entries when OVS is getting installed or the Conntrack Flows are applied.
Prevent this from happening by explicitly requiring SYN packets to be
present for creating new Conntrack entries.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack-tcp.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack-tcp.c 
b/datapath-windows/ovsext/Conntrack-tcp.c
index 8cbab24..ea43df1 100644
--- a/datapath-windows/ovsext/Conntrack-tcp.c
+++ b/datapath-windows/ovsext/Conntrack-tcp.c
@@ -455,9 +455,15 @@ OvsConntrackValidateTcpPacket(const TCPHdr *tcp)
 return FALSE;
 }
 
+/* Block pre-established connections from going through */
+if (!(tcp_flags & TCP_SYN)) {
+OVS_LOG_TRACE("Pre-established TCP packet detected, non-SYN flags not 
allowed,"
+  "tcp_flags %hu", tcp_flags);
+return FALSE;
+}
+
 /* A syn+ack is not allowed to create a connection.  We want to allow
- * totally new connections (syn) or already established, not partially
- * open (syn+ack). */
+ * totally new connections (syn), not partially open (syn+ack). */
 if ((tcp_flags & TCP_SYN) && (tcp_flags & TCP_ACK)) {
 OVS_LOG_TRACE("Invalid TCP packet detected, SYN+ACK flags not allowed,"
   "tcp_flags %hu", tcp_flags);
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Fix static analysis in Stt.c

[Sairam Venugopal]

Didn't realize this patch wasn't acked. Please push this in.

Acked-by: Sairam Venugopal 

Thanks,
Sairam

On 2/8/18, 9:31 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin Gabriel 
Serdean"  wrote:

The WDK 10 static analysis complains:
stt.c(427): warning C30030: Warning: Allocating executable memory via
specifying a MM_PAGE_PRIORITY type without a bitwise OR with
MdlMappingNoExecute.

Signed-off-by: Alin Gabriel Serdean 
---
 datapath-windows/ovsext/Stt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/Stt.c b/datapath-windows/ovsext/Stt.c
index e3c4b4686..0220a6e80 100644
--- a/datapath-windows/ovsext/Stt.c
+++ b/datapath-windows/ovsext/Stt.c
@@ -424,8 +424,8 @@ OvsValidateTCPChecksum(PNET_BUFFER_LIST curNbl,
 NDIS_STATUS status;
 
 curMdl = NET_BUFFER_CURRENT_MDL(curNb);
-buf = (PUINT8)MmGetSystemAddressForMdlSafe(curMdl, LowPagePriority)
-+ NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
+buf = (PUINT8)OvsGetMdlWithLowPriority(curMdl)
+  + NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
 if (!buf) {
 status = NDIS_STATUS_INVALID_PACKET;
 return status;
-- 
2.16.1.windows.1

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=BY4WXq8DeAmm1qlGIU6_uzzNUDAh5i6EKM5G_IdrUVI&s=ioWzOV69cv-8RilP53-ycbEfxEQ70f9WRH4NxzRWErU&e=


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

Re: [ovs-dev] [PATCH] lib/unaligned.h - Fix C++ compiler issue with BUILD_ASSERT on Windows

[Sairam Venugopal]

Hi Ben,

Sorry about not reading through the comments. If the assumption is to always 
support static_assert inside expressions for all languages and OS, then we can 
go ahead with the workaround prescribed in the post. However, if it’s not 
necessary, then we can skip supporting static_assert for those cases. 
Nevertheless, I think we are in agreement that this needs to be fixed in 
include/openvswitch/compiler.h and not lib/unaligned.h.


Thanks,
Sairam

On 12/20/17, 1:54 PM, "Ben Pfaff"  wrote:

>The basic point here is that the BUILD_ASSERT macro is a build assertion
>that works in an expression.  That is exactly what the comment says:
>
> * Use BUILD_ASSERT_DECL as a declaration or a statement, or BUILD_ASSERT as
> * part of an expression. */
>
>Can you write a build assertion macro that works in an expression in
>C++03 (I guess that's what you mean when you say C++?) and in C++11?
>That is the goal.  I am sure that it can be done.  If it should be done
>without static_assert for languages that do not support static_assert,
>or do not support static_assert in an expression, then that's fine with
>me.
>
>On Wed, Dec 20, 2017 at 09:34:16PM +, Sairam Venugopal wrote:
>> Hi Ben,
>> 
>> That is not correct. Your suggestion would fix C++11 compilation on Linux 
>> and Windows. However,
>> 
>> it would still break on C++ on Windows. static_assert is a keyword on 
>> Windows on both C++ and C++11.
>> However, this isn’t the case on Linux. It’s present only in C++11.
>> 
>> What is the inclination to use static_assert inside expressions on C++? 
>> Since this is an edge-case, I feel that
>> we should isolate this behavior instead of letting it permeate. In future, 
>> if this is supported, it would be easier to fix this single nuance.
>> 
>> Eg: 
>> Something like this:
>> #define BUILD_ASSERT_IN_EXPR(EXPR) []{static_assert(EXPR, "assertion 
>> failed”);}
>> 
>> Thanks,
>> Sairam
>> 
>> On 12/20/17, 8:18 AM, "Ben Pfaff"  wrote:
>> 
>> >I don't know what you mean by "all existing definitions".  BUILD_ASSERT
>> >has a few definitions but only one of them matters in this case:
>> >
>> >#elif defined(__cplusplus) && __cplusplus >= 201103L
>> >#define BUILD_ASSERT(EXPR) static_assert(EXPR, "assertion failed")
>> >
>> >The post you cite implies that adding []{...} to the definition above
>> >would fix the problem.  Is that correct?
>> >
>> >On Wed, Dec 20, 2017 at 12:45:04AM +, Sairam Venugopal wrote:
>> >> Hi Ben,
>> >> 
>> >> I did consider updating the definition of BUILD_ASSERT, however, that 
>> >> would involve changing all existing definitions (even non-expression 
>> >> context).
>> >> This issue is prevalent on both Linux and Windows when we start compiling 
>> >> in C++ 11.
>> >> 
>> >> Associated post:
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_31311748_is-2Dthere-2Dany-2Dway-2Dto-2Dslip-2Da-2Dstatic-2Dassert-2Dinto-2Dan-2Dexpression-2Din-2Diso-2Dc11&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=w5lx09Yyfn1993a2Tdgq4IXnaFsMjRcYiRSRftu2nek&s=6YRaA_irydpTc7N1-EXIctKiFclTsRSrh9XFKKRbQlA&e=
>> >> 
>> >> The ideal fix would be to not use static_assert as an expression in C++11 
>> >> mode. 
>> >> Currently, we hit this issue here : 
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_lib_unaligned.h-23L172&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=w5lx09Yyfn1993a2Tdgq4IXnaFsMjRcYiRSRftu2nek&s=X99J8FVdp3jAiS3mMS4DWKMbIJgphnTA5fptRDK_BXU&e=
>> >> 
>> >> You can disregard this patch for the time being since we will need to fix 
>> >> this on both Linux and Windows.
>> >> 
>> >> Thanks,
>> >> Sairam
>> >> 
>> >> 
>> >> 
>> >> On 12/19/17, 3:45 PM, "Ben Pfaff"  wrote:
>> >> 
>> >> >On Tue, Dec 19, 2017 at 03:32:27PM -0800, Sairam Venugopal wrote:
>> >> >> A static assert declaration may appear at block scope (as a block
>> >> >> declaration) and inside a class body (as a member declaration). 
>> >> >> However,
>> >> >> unlike sizeof, static_assert cannot be used as an expression and this 
>> >> >> is
>> >> >> strictly enforced on MSVC. error C2059: syntax error : static_assert
>> >> >> 
>> >> >> Signed-off-by: Sairam Venugopal 
>> >> >
>> >> >I'd really prefer to adjust the definition of BUILD_ASSERT so that it
>> >> >can be used in any expression context.  Did you consider that?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] lib/unaligned.h - Fix C++ compiler issue with BUILD_ASSERT on Windows

[Sairam Venugopal]

Hi Ben,

That is not correct. Your suggestion would fix C++11 compilation on Linux and 
Windows. However,

it would still break on C++ on Windows. static_assert is a keyword on Windows 
on both C++ and C++11.
However, this isn’t the case on Linux. It’s present only in C++11.

What is the inclination to use static_assert inside expressions on C++? Since 
this is an edge-case, I feel that
we should isolate this behavior instead of letting it permeate. In future, if 
this is supported, it would be easier to fix this single nuance.

Eg: 
Something like this:
#define BUILD_ASSERT_IN_EXPR(EXPR) []{static_assert(EXPR, "assertion failed”);}

Thanks,
Sairam

On 12/20/17, 8:18 AM, "Ben Pfaff"  wrote:

>I don't know what you mean by "all existing definitions".  BUILD_ASSERT
>has a few definitions but only one of them matters in this case:
>
>#elif defined(__cplusplus) && __cplusplus >= 201103L
>#define BUILD_ASSERT(EXPR) static_assert(EXPR, "assertion failed")
>
>The post you cite implies that adding []{...} to the definition above
>would fix the problem.  Is that correct?
>
>On Wed, Dec 20, 2017 at 12:45:04AM +, Sairam Venugopal wrote:
>> Hi Ben,
>> 
>> I did consider updating the definition of BUILD_ASSERT, however, that would 
>> involve changing all existing definitions (even non-expression context).
>> This issue is prevalent on both Linux and Windows when we start compiling in 
>> C++ 11.
>> 
>> Associated post:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_31311748_is-2Dthere-2Dany-2Dway-2Dto-2Dslip-2Da-2Dstatic-2Dassert-2Dinto-2Dan-2Dexpression-2Din-2Diso-2Dc11&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=w5lx09Yyfn1993a2Tdgq4IXnaFsMjRcYiRSRftu2nek&s=6YRaA_irydpTc7N1-EXIctKiFclTsRSrh9XFKKRbQlA&e=
>> 
>> The ideal fix would be to not use static_assert as an expression in C++11 
>> mode. 
>> Currently, we hit this issue here : 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_lib_unaligned.h-23L172&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=w5lx09Yyfn1993a2Tdgq4IXnaFsMjRcYiRSRftu2nek&s=X99J8FVdp3jAiS3mMS4DWKMbIJgphnTA5fptRDK_BXU&e=
>> 
>> You can disregard this patch for the time being since we will need to fix 
>> this on both Linux and Windows.
>> 
>> Thanks,
>> Sairam
>> 
>> 
>> 
>> On 12/19/17, 3:45 PM, "Ben Pfaff"  wrote:
>> 
>> >On Tue, Dec 19, 2017 at 03:32:27PM -0800, Sairam Venugopal wrote:
>> >> A static assert declaration may appear at block scope (as a block
>> >> declaration) and inside a class body (as a member declaration). However,
>> >> unlike sizeof, static_assert cannot be used as an expression and this is
>> >> strictly enforced on MSVC. error C2059: syntax error : static_assert
>> >> 
>> >> Signed-off-by: Sairam Venugopal 
>> >
>> >I'd really prefer to adjust the definition of BUILD_ASSERT so that it
>> >can be used in any expression context.  Did you consider that?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] lib/unaligned.h - Fix C++ compiler issue with BUILD_ASSERT on Windows

[Sairam Venugopal]

Hi Ben,

I did consider updating the definition of BUILD_ASSERT, however, that would 
involve changing all existing definitions (even non-expression context).
This issue is prevalent on both Linux and Windows when we start compiling in 
C++ 11.

Associated post:
https://stackoverflow.com/questions/31311748/is-there-any-way-to-slip-a-static-assert-into-an-expression-in-iso-c11

The ideal fix would be to not use static_assert as an expression in C++11 mode. 
Currently, we hit this issue here : 
https://github.com/openvswitch/ovs/blob/master/lib/unaligned.h#L172

You can disregard this patch for the time being since we will need to fix this 
on both Linux and Windows.

Thanks,
Sairam



On 12/19/17, 3:45 PM, "Ben Pfaff"  wrote:

>On Tue, Dec 19, 2017 at 03:32:27PM -0800, Sairam Venugopal wrote:
>> A static assert declaration may appear at block scope (as a block
>> declaration) and inside a class body (as a member declaration). However,
>> unlike sizeof, static_assert cannot be used as an expression and this is
>> strictly enforced on MSVC. error C2059: syntax error : static_assert
>> 
>> Signed-off-by: Sairam Venugopal 
>
>I'd really prefer to adjust the definition of BUILD_ASSERT so that it
>can be used in any expression context.  Did you consider that?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] lib/unaligned.h - Fix C++ compiler issue with BUILD_ASSERT on Windows

[Sairam Venugopal]

A static assert declaration may appear at block scope (as a block
declaration) and inside a class body (as a member declaration). However,
unlike sizeof, static_assert cannot be used as an expression and this is
strictly enforced on MSVC. error C2059: syntax error : static_assert

Signed-off-by: Sairam Venugopal 
---
 lib/unaligned.h | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/lib/unaligned.h b/lib/unaligned.h
index f40e4e1..6bc9063 100644
--- a/lib/unaligned.h
+++ b/lib/unaligned.h
@@ -51,12 +51,27 @@ static inline void put_unaligned_be64(ovs_be64 *, ovs_be64);
  *
  * Below, "sizeof (*(P) % 1)" verifies that *P has an integer type, since
  * operands to % must be integers.
+ *
+ * On MSVC C++ compiler throws error C2059: syntax error : ‘static_assert’.
+ * A static assert declaration may appear at block scope (as a block 
declaration)
+ * and inside a class body (as a member declaration). However, unlike sizeof,
+ * static_assert cannot be used as an expression and this is strictly enforced
+ * on MSVC. The workaround would be to use a lambda expression for C++.
+ *
  */
+#if defined(__cplusplus) && defined(WIN32)
 #define get_unaligned_u64(P)\
-(BUILD_ASSERT(sizeof *(P) == 8),\
+([P]{BUILD_ASSERT(sizeof *(P) == 8);},  \
  BUILD_ASSERT_GCCONLY(!TYPE_IS_SIGNED(typeof(*(P,   \
  (void) sizeof (*(P) % 1),  \
  get_unaligned_u64__((const uint64_t *) (P)))
+#else
+ #define get_unaligned_u64(P)\
+ (BUILD_ASSERT(sizeof *(P) == 8),\
+  BUILD_ASSERT_GCCONLY(!TYPE_IS_SIGNED(typeof(*(P,   \
+  (void) sizeof (*(P) % 1),  \
+  get_unaligned_u64__((const uint64_t *) (P)))
+#endif
 
 #ifdef __GNUC__
 /* GCC implementations. */
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH v2] windows/lib: Fix Windows C++ compilation issues on common headers

[Sairam Venugopal]

+Alin/Nithin for Windows.

Hi Ben,

Thanks for reviewing the changes. The BUILD_ASSERT change is required in this 
instance primarily because of its usage. Based on CPP reference, A static 
assert declaration may appear at block scope (as a block declaration) and 
inside a class body (as a member declaration). However, unlike sizeof, 
static_assert cannot be used as an expression and this is strictly enforced on 
MSVC. 

In lib/unaligned.h, we call "return get_unaligned_u64(p);” which gets evaluated 
as following on Windows:
return ((static_assert(sizeof *(p) == 8, "sizeof *(p) == 8")), ((void) 0), 
(void) sizeof (*(p) % 1), get_unaligned_u64__((const uint64_t *) (p)));

This usage is deemed invalid by Windows Compiler - error C2059: syntax error : 
‘static_assert’. If the solution is to prevent multiple #ifdef(s), then I need 
to get rid of the following get_unaligned_u64(P) definition and instead split 
this into individual statements. Updating the BUILD_ASSERT macro for Windows 
isn’t ideal since the other usages don’t encounter this error and this would 
end up creating a lambda for all existing usages. It felt simpler to add an 
ifdef for WIN32 && CPP just for this use-case instead of modifying the 
underlying libraries.


Definition:
#define get_unaligned_u64(P)\
(BUILD_ASSERT(sizeof *(P) == 8),\
 BUILD_ASSERT_GCCONLY(!TYPE_IS_SIGNED(typeof(*(P,   \
 (void) sizeof (*(P) % 1),  \
 get_unaligned_u64__((const uint64_t *) (P)))


Please let me know how you would like for me to proceed. I can either get rid 
of the #define get_unaligned_u64(P) and instead convert them to statements or 
retain the current patch while updating the comments around why this workaround 
is required.

Thanks,
Sairam



On 12/14/17, 2:12 PM, "Ben Pfaff"  wrote:

>On Wed, Dec 13, 2017 at 04:13:20PM -0800, Sairam Venugopal wrote:
>> Found when compiling the code with C++ binaries. Most of the issues are
>> due to missing explicit cast.
>> 
>> Changes in PADDED_MEMBERS* is because MSVC does not allow to re-define
>> unnamed structure in union. Thus, this fix defines the struct outside of
>> the anonymous union in order to calculate the padded size.
>> 
>> Signed-off-by: Sairam Venugopal 
>> Signed-off-by: Shireesh Kumar Singh 
>> Co-authored-by: Shireesh Kumar Singh 
>
>Thanks for working on this.
>
>I think that this should actually be a series of patches:
>
>- PADDED_MEMBERS fix.
>
>- Added casts
>
>- Changes to types in the atomics header.
>
>- Initializer changes.
>
>- BUILD_ASSERT change.  I think that this change should actually
>  be a change to the BUILD_ASSERT macro.  It does not make sense
>  to change just one user.
>
>Thanks,
>
>Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] windows/lib: Fix Windows C++ compilation issues on common headers

[Sairam Venugopal]

Found when compiling the code with C++ binaries. Most of the issues are
due to missing explicit cast.

Changes in PADDED_MEMBERS* is because MSVC does not allow to re-define
unnamed structure in union. Thus, this fix defines the struct outside of
the anonymous union in order to calculate the padded size.

Signed-off-by: Sairam Venugopal 
Signed-off-by: Shireesh Kumar Singh 
Co-authored-by: Shireesh Kumar Singh 
---
 AUTHORS.rst|  1 +
 include/openvswitch/util.h | 14 +--
 lib/netlink.h  |  3 ++-
 lib/ovs-atomic-msvc.h  | 59 --
 lib/ovs-thread.h   |  4 ++--
 lib/packets.h  | 15 
 lib/socket-util.h  |  4 ++--
 lib/unaligned.h| 21 ++---
 8 files changed, 78 insertions(+), 43 deletions(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index e17daf0..4370adc 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -295,6 +295,7 @@ Shan Weidavids...@tencent.com
 Shashank Ramr...@vmware.com
 Shashwat Srivastava shashwat.srivast...@tcs.com
 Shih-Hao Li s...@nicira.com
+Shireesh Kumar Singhshireesh...@vmware.com
 Shu Shenshu.s...@radisys.com
 Simon Hormanho...@verge.net.au
 Simon Hormansimon.hor...@netronome.com
diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
index c3e60d5..ad1b184 100644
--- a/include/openvswitch/util.h
+++ b/include/openvswitch/util.h
@@ -185,11 +185,11 @@ OVS_NO_RETURN void ovs_assert_failure(const char *, const 
char *, const char *);
 /* C++ doesn't allow a type declaration within "sizeof", but it does support
  * scoping for member names, so we can just declare a second member, with a
  * name and the same type, and then use its size. */
-#define PADDED_MEMBERS(UNIT, MEMBERS)   \
-union { \
-struct { MEMBERS }; \
-struct { MEMBERS } named_member__;  \
-uint8_t PAD_ID[ROUND_UP(sizeof named_member__, UNIT)];  \
+#define PADDED_MEMBERS(UNIT, MEMBERS)   \
+struct named_member__ { MEMBERS };  \
+union { \
+struct { MEMBERS }; \
+uint8_t PAD_ID[ROUND_UP(sizeof(struct named_member__), UNIT)];  \
 }
 #endif
 
@@ -233,11 +233,11 @@ OVS_NO_RETURN void ovs_assert_failure(const char *, const 
char *, const char *);
 }
 #else
 #define PADDED_MEMBERS_CACHELINE_MARKER(UNIT, CACHELINE, MEMBERS)   \
+struct struct_##CACHELINE { MEMBERS };  \
 union { \
 OVS_CACHE_LINE_MARKER CACHELINE;\
 struct { MEMBERS }; \
-struct { MEMBERS } named_member_##CACHELINE;\
-uint8_t PAD_ID[ROUND_UP(sizeof named_member_##CACHELINE, UNIT)];\
+uint8_t PAD_ID[ROUND_UP(sizeof(struct struct_##CACHELINE), UNIT)];  \
 }
 #endif
 
diff --git a/lib/netlink.h b/lib/netlink.h
index 6dfac27..e4cb2f7 100644
--- a/lib/netlink.h
+++ b/lib/netlink.h
@@ -153,7 +153,8 @@ enum nl_attr_type
 static inline struct nlattr *
 nl_attr_next(const struct nlattr *nla)
 {
-return (void *) ((uint8_t *) nla + NLA_ALIGN(nla->nla_len));
+return ALIGNED_CAST(struct nlattr *,
+((uint8_t *) nla + NLA_ALIGN(nla->nla_len)));
 }
 
 static inline bool
diff --git a/lib/ovs-atomic-msvc.h b/lib/ovs-atomic-msvc.h
index 81f7682..6727d2c 100644
--- a/lib/ovs-atomic-msvc.h
+++ b/lib/ovs-atomic-msvc.h
@@ -98,8 +98,8 @@ atomic_signal_fence(memory_order order)
 
 #define atomic_store32(DST, SRC, ORDER) \
 if (ORDER == memory_order_seq_cst) {\
-InterlockedExchange((int32_t volatile *) (DST), \
-   (int32_t) (SRC));\
+InterlockedExchange((long volatile *) (DST),\
+   (long) (SRC));   \
 } else {\
 *(DST) = (SRC); \
 }
@@ -128,13 +128,18 @@ atomic_signal_fence(memory_order order)
 atomic_storeX(64, DST, SRC, ORDER)
 #endif
 
-/* Used for 8 and 16 bit variations. */
-#define atomic_storeX(X, DST, SRC, ORDER)   \
-if (ORDER == memory_order_seq_cst) {\
-InterlockedExchange##X((int##X

Re: [ovs-dev] [PATCH] datapath-windows: Correct endianness for deleting zone.

[Sairam Venugopal]

We can hold off on back-porting this. This change mainly affects the delete by 
5-tuple API.

https://github.com/openvswitch/ovs/commit/817a76577fec3f03310d7d3a5a10df01340ee8ad

Unless we plan to backport that patch, we should hold off on backporting this 
as well.

Thanks,
Sairam



On 12/6/17, 9:41 AM, "aserd...@ovn.org"  wrote:

>> -Original Message-
>> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
>> boun...@openvswitch.org] On Behalf Of Justin Pettit
>> Sent: Tuesday, December 5, 2017 9:30 AM
>> To: d...@openvswitch.org; Alin Gabriel Serdean ;
>> Sairam Venugopal 
>> Subject: [ovs-dev] [PATCH] datapath-windows: Correct endianness for
>> deleting zone.
>> 
>> The zone Netlink attribute is supposed to be in network-byte order, but
>the
>> Windows code for deleting conntrack entries was treating it as host-byte
>> order.
>> 
>> Found by inspection.
>> 
>> Signed-off-by: Justin Pettit 
>
>Thanks for the patch, Justin.  I tested the patch, and everything looks
>good.
>I want to hold on the acknowledge until all of us are on the same page.
>
>This will make the windows datapath consistent with future patches from the
>userspace.
>For consistency I would like to backport the patch all the way to
>branch-2.6.
>
>What do you think Sai?
>
>Thanks,
>Alin.
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Correct endianness for deleting zone.

[Sairam Venugopal]

Thanks for the patch. Discussed about the patch offline. 

This is required since we have now introduced a newer api for deleting 5-tuples
and this breaks the assumption of zone-id not being in the right byte order.

Acked-by: Sairam Venugopal 





On 12/4/17, 11:30 PM, "Justin Pettit"  wrote:

>The zone Netlink attribute is supposed to be in network-byte order, but
>the Windows code for deleting conntrack entries was treating it as
>host-byte order.
>
>Found by inspection.
>
>Signed-off-by: Justin Pettit 
>---
> datapath-windows/ovsext/Conntrack.c | 2 +-
> lib/netlink-conntrack.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 3203411a8b7a..edc0ec9c5324 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -1076,7 +1076,7 @@ OvsCtDeleteCmdHandler(POVS_USER_PARAMS_CONTEXT 
>usrParamsCtx,
> }
> 
> if (ctAttrs[CTA_ZONE]) {
>-zone = NlAttrGetU16(ctAttrs[CTA_ZONE]);
>+zone = ntohs(NlAttrGetU16(ctAttrs[CTA_ZONE]));
> }
> 
> status = OvsCtFlush(zone);
>diff --git a/lib/netlink-conntrack.c b/lib/netlink-conntrack.c
>index 1e1bb2f79d1d..3c651b6c856a 100644
>--- a/lib/netlink-conntrack.c
>+++ b/lib/netlink-conntrack.c
>@@ -251,7 +251,7 @@ nl_ct_flush_zone(uint16_t flush_zone)
> 
> nl_msg_put_nfgenmsg(&buf, 0, AF_UNSPEC, NFNL_SUBSYS_CTNETLINK,
> IPCTNL_MSG_CT_DELETE, NLM_F_REQUEST);
>-nl_msg_put_be16(&buf, CTA_ZONE, flush_zone);
>+nl_msg_put_be16(&buf, CTA_ZONE, htons(flush_zone));
> 
> err = nl_transact(NETLINK_NETFILTER, &buf, NULL);
> ofpbuf_uninit(&buf);
>-- 
>2.7.4
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] windows/lib: Fix Windows C++ compilation issues on common headers

[Sairam Venugopal]

Found when compiling the code with C++ binaries. Most of the issues are
due to missing explicit cast.

Signed-off-by: Sairam Venugopal 
Signed-off-by: Shireesh Kumar Singh 
Co-authored-by: Shireesh Kumar Singh 
---
 AUTHORS.rst|  1 +
 include/openvswitch/util.h |  8 +++
 lib/netlink.h  |  2 +-
 lib/ovs-atomic-msvc.h  | 57 --
 lib/ovs-thread.h   |  4 ++--
 lib/packets.h  | 15 
 lib/socket-util.h  |  4 ++--
 lib/unaligned.h| 23 +++
 8 files changed, 78 insertions(+), 36 deletions(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index 075b2f7..c046052 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -295,6 +295,7 @@ Shan Weidavids...@tencent.com
 Shashank Ramr...@vmware.com
 Shashwat Srivastava shashwat.srivast...@tcs.com
 Shih-Hao Li s...@nicira.com
+Shireesh Kumar Singhshireesh...@vmware.com
 Shu Shenshu.s...@radisys.com
 Simon Hormanho...@verge.net.au
 Simon Hormansimon.hor...@netronome.com
diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
index c3e60d5..a1781e1 100644
--- a/include/openvswitch/util.h
+++ b/include/openvswitch/util.h
@@ -231,6 +231,14 @@ OVS_NO_RETURN void ovs_assert_failure(const char *, const 
char *, const char *);
 struct { MEMBERS }; \
 uint8_t PAD_ID[ROUND_UP(sizeof(struct { MEMBERS }), UNIT)]; \
 }
+#elif defined(WIN32)
+#define PADDED_MEMBERS_CACHELINE_MARKER(UNIT, CACHELINE, MEMBERS)   \
+union { \
+OVS_CACHE_LINE_MARKER CACHELINE;\
+struct { MEMBERS }; \
+struct named_member_##CACHELINE { MEMBERS };\
+uint8_t PAD_ID[ROUND_UP(sizeof named_member_##CACHELINE, UNIT)];\
+}
 #else
 #define PADDED_MEMBERS_CACHELINE_MARKER(UNIT, CACHELINE, MEMBERS)   \
 union { \
diff --git a/lib/netlink.h b/lib/netlink.h
index 6dfac27..3bee560 100644
--- a/lib/netlink.h
+++ b/lib/netlink.h
@@ -153,7 +153,7 @@ enum nl_attr_type
 static inline struct nlattr *
 nl_attr_next(const struct nlattr *nla)
 {
-return (void *) ((uint8_t *) nla + NLA_ALIGN(nla->nla_len));
+return (struct nlattr *) ((uint8_t *) nla + NLA_ALIGN(nla->nla_len));
 }
 
 static inline bool
diff --git a/lib/ovs-atomic-msvc.h b/lib/ovs-atomic-msvc.h
index 81f7682..5bc0246 100644
--- a/lib/ovs-atomic-msvc.h
+++ b/lib/ovs-atomic-msvc.h
@@ -98,8 +98,8 @@ atomic_signal_fence(memory_order order)
 
 #define atomic_store32(DST, SRC, ORDER) \
 if (ORDER == memory_order_seq_cst) {\
-InterlockedExchange((int32_t volatile *) (DST), \
-   (int32_t) (SRC));\
+InterlockedExchange((long volatile *) (DST),\
+   (long) (SRC));   \
 } else {\
 *(DST) = (SRC); \
 }
@@ -128,13 +128,18 @@ atomic_signal_fence(memory_order order)
 atomic_storeX(64, DST, SRC, ORDER)
 #endif
 
-/* Used for 8 and 16 bit variations. */
-#define atomic_storeX(X, DST, SRC, ORDER)   \
-if (ORDER == memory_order_seq_cst) {\
-InterlockedExchange##X((int##X##_t volatile *) (DST),   \
-   (int##X##_t) (SRC)); \
-} else {\
-*(DST) = (SRC); \
+#define atomic_store8(DST, SRC, ORDER) \
+if (ORDER == memory_order_seq_cst) {   \
+InterlockedExchange8((char volatile *) (DST), (char) (SRC));   \
+} else {   \
+*(DST) = (SRC);\
+}
+
+#define atomic_store16(DST, SRC, ORDER)\
+if (ORDER == memory_order_seq_cst) {   \
+InterlockedExchange16((short volatile *) (DST), (short) (SRC));\
+} else {   \
+*(DST) = (SRC);\
 }
 
 #define atomic_store(DST, SRC)   \
@@ -142,9 +147,9 @@ atomic_signal

[ovs-dev] [PATCH] windows/lib: Fix Windows C++ compilation issues on common headers

[Sairam Venugopal]

Found when compiling the code with C++ binaries. Most of the issues are
due to missing explicit cast.

Signed-off-by: Sairam Venugopal 
Signed-off-by: Shireesh Kumar Singh 
Co-authored-by: Shireesh Kumar Singh 
---
 include/openvswitch/util.h |  8 +++
 lib/netlink.h  |  2 +-
 lib/ovs-atomic-msvc.h  | 57 --
 lib/ovs-thread.h   |  4 ++--
 lib/packets.h  | 15 
 lib/socket-util.h  |  4 ++--
 lib/unaligned.h| 23 +++
 7 files changed, 77 insertions(+), 36 deletions(-)

diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
index c3e60d5..a1781e1 100644
--- a/include/openvswitch/util.h
+++ b/include/openvswitch/util.h
@@ -231,6 +231,14 @@ OVS_NO_RETURN void ovs_assert_failure(const char *, const 
char *, const char *);
 struct { MEMBERS }; \
 uint8_t PAD_ID[ROUND_UP(sizeof(struct { MEMBERS }), UNIT)]; \
 }
+#elif defined(WIN32)
+#define PADDED_MEMBERS_CACHELINE_MARKER(UNIT, CACHELINE, MEMBERS)   \
+union { \
+OVS_CACHE_LINE_MARKER CACHELINE;\
+struct { MEMBERS }; \
+struct named_member_##CACHELINE { MEMBERS };\
+uint8_t PAD_ID[ROUND_UP(sizeof named_member_##CACHELINE, UNIT)];\
+}
 #else
 #define PADDED_MEMBERS_CACHELINE_MARKER(UNIT, CACHELINE, MEMBERS)   \
 union { \
diff --git a/lib/netlink.h b/lib/netlink.h
index 6dfac27..3bee560 100644
--- a/lib/netlink.h
+++ b/lib/netlink.h
@@ -153,7 +153,7 @@ enum nl_attr_type
 static inline struct nlattr *
 nl_attr_next(const struct nlattr *nla)
 {
-return (void *) ((uint8_t *) nla + NLA_ALIGN(nla->nla_len));
+return (struct nlattr *) ((uint8_t *) nla + NLA_ALIGN(nla->nla_len));
 }
 
 static inline bool
diff --git a/lib/ovs-atomic-msvc.h b/lib/ovs-atomic-msvc.h
index 81f7682..5bc0246 100644
--- a/lib/ovs-atomic-msvc.h
+++ b/lib/ovs-atomic-msvc.h
@@ -98,8 +98,8 @@ atomic_signal_fence(memory_order order)
 
 #define atomic_store32(DST, SRC, ORDER) \
 if (ORDER == memory_order_seq_cst) {\
-InterlockedExchange((int32_t volatile *) (DST), \
-   (int32_t) (SRC));\
+InterlockedExchange((long volatile *) (DST),\
+   (long) (SRC));   \
 } else {\
 *(DST) = (SRC); \
 }
@@ -128,13 +128,18 @@ atomic_signal_fence(memory_order order)
 atomic_storeX(64, DST, SRC, ORDER)
 #endif
 
-/* Used for 8 and 16 bit variations. */
-#define atomic_storeX(X, DST, SRC, ORDER)   \
-if (ORDER == memory_order_seq_cst) {\
-InterlockedExchange##X((int##X##_t volatile *) (DST),   \
-   (int##X##_t) (SRC)); \
-} else {\
-*(DST) = (SRC); \
+#define atomic_store8(DST, SRC, ORDER) \
+if (ORDER == memory_order_seq_cst) {   \
+InterlockedExchange8((char volatile *) (DST), (char) (SRC));   \
+} else {   \
+*(DST) = (SRC);\
+}
+
+#define atomic_store16(DST, SRC, ORDER)\
+if (ORDER == memory_order_seq_cst) {   \
+InterlockedExchange16((short volatile *) (DST), (short) (SRC));\
+} else {   \
+*(DST) = (SRC);\
 }
 
 #define atomic_store(DST, SRC)   \
@@ -142,9 +147,9 @@ atomic_signal_fence(memory_order order)
 
 #define atomic_store_explicit(DST, SRC, ORDER)   \
 if (sizeof *(DST) == 1) {\
-atomic_storeX(8, DST, SRC, ORDER)\
+atomic_store8(DST, SRC, ORDER)   \
 } else if (sizeof *(DST) == 2) { \
-atomic_storeX(16, DST, SRC, ORDER)   \
+atomic_store16( DST, SRC, ORDER) \
 } else if (sizeof *(DST

[ovs-dev] [PATCH] datapath-windows: Update OvsCompleteNbl argument to match definition

[Sairam Venugopal]

Update the OvsCompleteNbl to take in a PVOID and explicitly cast to
POVS_SWITCH_CONTEXT. This is useful when finding declarations in Visual
Studio. The mismatch breaks this functionality.

Found by inspection.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/BufferMgmt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/datapath-windows/ovsext/BufferMgmt.c 
b/datapath-windows/ovsext/BufferMgmt.c
index 5c9e562..ff4f9bb 100644
--- a/datapath-windows/ovsext/BufferMgmt.c
+++ b/datapath-windows/ovsext/BufferMgmt.c
@@ -1605,7 +1605,7 @@ copymultiple_error:
  * --
  */
 PNET_BUFFER_LIST
-OvsCompleteNBL(POVS_SWITCH_CONTEXT context,
+OvsCompleteNBL(PVOID switch_ctx,
PNET_BUFFER_LIST nbl,
BOOLEAN updateRef)
 {
@@ -1615,6 +1615,7 @@ OvsCompleteNBL(POVS_SWITCH_CONTEXT context,
 NDIS_STATUS status;
 NDIS_HANDLE poolHandle;
 LONG value;
+POVS_SWITCH_CONTEXT context = (POVS_SWITCH_CONTEXT)switch_ctx;
 POVS_NBL_POOL ovsPool = &context->ovsPool;
 PNET_BUFFER nb;
 
-- 
2.9.0.windows.1

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

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

[Sairam Venugopal]

Thanks for fixing this.

Alin/Guru - Can we back port this to 2.8 too? This causes flow misses when 
geneve options are present.

Acked-by: Sairam Venugopal 






On 10/19/17, 1:26 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand 
Kumar"  
wrote:

>Currently, the OvsLookupFlow fails for the decap packet,
>when the Geneve options are present in the packet as the OvsIPv4TunnelKey
>flags are not set in the Geneve decap.
>
>Set the OvsIPv4TunnelKey flags OVS_TNL_F_OAM and OVS_TNL_F_CRT_OPT
>in OvsDecapGeneve based on the geneve header. Also set OVS_TNL_F_GENEVE_OPT
>if the packet has geneve options.
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Geneve.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Geneve.c 
>b/datapath-windows/ovsext/Geneve.c
>index 43374e2..6dca69b 100644
>--- a/datapath-windows/ovsext/Geneve.c
>+++ b/datapath-windows/ovsext/Geneve.c
>@@ -324,10 +324,10 @@ NDIS_STATUS OvsDecapGeneve(POVS_SWITCH_CONTEXT 
>switchContext,
> status = STATUS_NDIS_INVALID_PACKET;
> goto dropNbl;
> }
>-tunKey->flags = OVS_TNL_F_KEY;
>-if (geneveHdr->oam) {
>-tunKey->flags |= OVS_TNL_F_OAM;
>-}
>+/* Update tunnelKey flags. */
>+tunKey->flags = OVS_TNL_F_KEY | (geneveHdr->oam ? OVS_TNL_F_OAM : 0) |
>+(geneveHdr->critical ? OVS_TNL_F_CRT_OPT : 0);
>+
> tunKey->tunnelId = GENEVE_VNI_TO_TUNNELID(geneveHdr->vni);
> tunKey->tunOptLen = (uint8)geneveHdr->optLen * 4;
> if (tunKey->tunOptLen > TUN_OPT_MAX_LEN ||
>@@ -349,6 +349,7 @@ NDIS_STATUS OvsDecapGeneve(POVS_SWITCH_CONTEXT 
>switchContext,
> memcpy(TunnelKeyGetOptions(tunKey), optStart, tunKey->tunOptLen);
> }
> NdisAdvanceNetBufferDataStart(curNb, tunKey->tunOptLen, FALSE, NULL);
>+tunKey->flags |= OVS_TNL_F_GENEVE_OPT;
> }
> 
> return NDIS_STATUS_SUCCESS;
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=BRjHHHPFJJP1H7BWHjwF0OS4UFpTbBiTQNM1SPvh51w&s=JCowvVY7CQ4CxJWnx8dPPqUbvS346xU066Dd0DnMI8A&e=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Sairam Venugopal]

Anand,

Looks like Linux does make a check to see if there are any metadata present 
before setting these flags - 
https://github.com/openvswitch/ovs/blob/master/datapath/linux/compat/geneve.c#L239

Can you verify this and update the patch? (un-ack in meantime??)

Thanks,
Sairam




On 10/18/17, 3:45 PM, "ovs-dev-boun...@openvswitch.org on behalf of Sairam 
Venugopal"  
wrote:

>Thanks for fixing this. Should we check for geneveHdr->opts before setting 
>OVS_TNL_F_GENEVE_OPT?
>
>I know the current code maintains consistency with Linux. But we need to 
>understand if this is intended.
>
>Acked-by: Sairam Venugopal 
>
>
>
>
>
>On 10/17/17, 5:31 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand 
>Kumar"  
>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&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=ntDbsrs3dZtqbGfAIQnQA7qzLK8SlLouMDV36u0JsGQ&s=TtHsQ-7YSUu8XJHpn4iiQkhaothJamn3dU7_FKuRptE&e=
>>
>>Signed-off-by: Anand Kumar 
>>---
>> datapath-windows/ovsext/Geneve.c | 8 
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>>diff --git a/datapath-windows/ovsext/Geneve.c 
>>b/datapath-windows/ovsext/Geneve.c
>>index 43374e2..77244b1 100644
>>--- a/datapath-windows/ovsext/Geneve.c
>>+++ b/datapath-windows/ovsext/Geneve.c
>>@@ -324,10 +324,10 @@ NDIS_STATUS OvsDecapGeneve(POVS_SWITCH_CONTEXT 
>>switchContext,
>> status = STATUS_NDIS_INVALID_PACKET;
>> goto dropNbl;
>> }
>>-tunKey->flags = OVS_TNL_F_KEY;
>>-if (geneveHdr->oam) {
>>-tunKey->flags |= OVS_TNL_F_OAM;
>>-}
>>+/* Update tunnelKey flags. */
>>+tunKey->flags = OVS_TNL_F_KEY | OVS_TNL_F_GENEVE_OPT |
>>+(geneveHdr->oam ? OVS_TNL_F_OAM : 0) |
>>+(geneveHdr->critical ? OVS_TNL_F_CRT_OPT : 0);
>> tunKey->tunnelId = GENEVE_VNI_TO_TUNNELID(geneveHdr->vni);
>> tunKey->tunOptLen = (uint8)geneveHdr->optLen * 4;
>> if (tunKey->tunOptLen > TUN_OPT_MAX_LEN ||
>>-- 
>>2.9.3.windows.1
>>
>>___
>>dev mailing list
>>d...@openvswitch.org
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=ntDbsrs3dZtqbGfAIQnQA7qzLK8SlLouMDV36u0JsGQ&s=weAfeEKoncNrwUrh3c5va-Efy3yApbOLqPd2LZleZkM&e=
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=eMSUuuWxH9h1UeKSVIcTwgE8ktXUUIht3ybSd8WphY8&s=Y6LNJpoXU2BdIsXqef34Gk0al6E4EaHcbISPLhClhVc&e=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Sairam Venugopal]

Thanks for fixing this. Should we check for geneveHdr->opts before setting 
OVS_TNL_F_GENEVE_OPT?

I know the current code maintains consistency with Linux. But we need to 
understand if this is intended.

Acked-by: Sairam Venugopal 





On 10/17/17, 5:31 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand 
Kumar"  
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&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=ntDbsrs3dZtqbGfAIQnQA7qzLK8SlLouMDV36u0JsGQ&s=TtHsQ-7YSUu8XJHpn4iiQkhaothJamn3dU7_FKuRptE&e=
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Geneve.c | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Geneve.c 
>b/datapath-windows/ovsext/Geneve.c
>index 43374e2..77244b1 100644
>--- a/datapath-windows/ovsext/Geneve.c
>+++ b/datapath-windows/ovsext/Geneve.c
>@@ -324,10 +324,10 @@ NDIS_STATUS OvsDecapGeneve(POVS_SWITCH_CONTEXT 
>switchContext,
> status = STATUS_NDIS_INVALID_PACKET;
> goto dropNbl;
> }
>-tunKey->flags = OVS_TNL_F_KEY;
>-if (geneveHdr->oam) {
>-tunKey->flags |= OVS_TNL_F_OAM;
>-}
>+/* Update tunnelKey flags. */
>+tunKey->flags = OVS_TNL_F_KEY | OVS_TNL_F_GENEVE_OPT |
>+(geneveHdr->oam ? OVS_TNL_F_OAM : 0) |
>+(geneveHdr->critical ? OVS_TNL_F_CRT_OPT : 0);
> tunKey->tunnelId = GENEVE_VNI_TO_TUNNELID(geneveHdr->vni);
> tunKey->tunOptLen = (uint8)geneveHdr->optLen * 4;
> if (tunKey->tunOptLen > TUN_OPT_MAX_LEN ||
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=ntDbsrs3dZtqbGfAIQnQA7qzLK8SlLouMDV36u0JsGQ&s=weAfeEKoncNrwUrh3c5va-Efy3yApbOLqPd2LZleZkM&e=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Remove the workaround in NAT for TCP checksum

[Sairam Venugopal]

Hi Alin,

Any update on this one? I believe you had raised this issue and had sent out a 
patch to address this earlier.

Thanks,
Sairam




On 9/15/17, 3:04 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>When checksum offload is enabled, compute checksum using the
>TCP pseudo header.
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Actions.c | 60 +++
> 1 file changed, 11 insertions(+), 49 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index 41d1c7b..0af4a66 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -1528,6 +1528,11 @@ OvsUpdateAddressAndPort(OvsForwardingContext *ovsFwdCtx,
> ((BOOLEAN)csumInfo.Receive.UdpChecksumSucceeded ||
>  (BOOLEAN)csumInfo.Receive.UdpChecksumFailed);
> }
>+if (l4Offload) {
>+*checkField = IPPseudoChecksum(&newAddr, &ipHdr->daddr,
>+tcpHdr ? IPPROTO_TCP : IPPROTO_UDP,
>+ntohs(ipHdr->tot_len) - ipHdr->ihl * 4);
>+}
> } else {
> addrField = &ipHdr->daddr;
> if (tcpHdr) {
>@@ -1538,19 +1543,13 @@ OvsUpdateAddressAndPort(OvsForwardingContext 
>*ovsFwdCtx,
> checkField = &udpHdr->check;
> }
> }
>+
> if (*addrField != newAddr) {
> UINT32 oldAddr = *addrField;
>-if (checkField && *checkField != 0) {
>-if (l4Offload) {
>-/* Recompute IP pseudo checksum */
>-*checkField = ~(*checkField);
>-*checkField = ChecksumUpdate32(*checkField, oldAddr,
>-   newAddr);
>-*checkField = ~(*checkField);
>-} else {
>-*checkField = ChecksumUpdate32(*checkField, oldAddr,
>-   newAddr);
>-}
>+if (checkField && *checkField != 0 && !l4Offload) {
>+/* Recompute total checksum. */
>+*checkField = ChecksumUpdate32(*checkField, oldAddr,
>+newAddr);
> }
> if (ipHdr->check != 0) {
> ipHdr->check = ChecksumUpdate32(ipHdr->check, oldAddr,
>@@ -1561,49 +1560,12 @@ OvsUpdateAddressAndPort(OvsForwardingContext 
>*ovsFwdCtx,
> 
> if (portField && *portField != newPort) {
> if (checkField && !l4Offload) {
>+/* Recompute total checksum. */
> *checkField = ChecksumUpdate16(*checkField, *portField,
>newPort);
> }
> *portField = newPort;
> }
>-PNET_BUFFER_LIST curNbl = ovsFwdCtx->curNbl;
>-PNET_BUFFER_LIST newNbl = NULL;
>-if (layers->isTcp) {
>-UINT32 mss = OVSGetTcpMSS(curNbl);
>-if (mss) {
>-OVS_LOG_TRACE("l4Offset %d", layers->l4Offset);
>-newNbl = OvsTcpSegmentNBL(ovsFwdCtx->switchContext, curNbl, 
>layers,
>-  mss, 0, FALSE);
>-if (newNbl == NULL) {
>-OVS_LOG_ERROR("Unable to segment NBL");
>-return NDIS_STATUS_FAILURE;
>-}
>-/* Clear out LSO flags after this point */
>-NET_BUFFER_LIST_INFO(newNbl, TcpLargeSendNetBufferListInfo) = 0;
>-}
>-}
>-/* If we didn't split the packet above, make a copy now */
>-if (newNbl == NULL) {
>-csumInfo.Value = NET_BUFFER_LIST_INFO(curNbl,
>-  TcpIpChecksumNetBufferListInfo);
>-OvsApplySWChecksumOnNB(layers, curNbl, &csumInfo);
>-}
>-
>-if (newNbl) {
>-curNbl = newNbl;
>-OvsCompleteNBLForwardingCtx(ovsFwdCtx,
>-L"Complete after cloning NBL for 
>encapsulation");
>-OvsInitForwardingCtx(ovsFwdCtx, ovsFwdCtx->switchContext,
>- newNbl, ovsFwdCtx->srcVportNo, 0,
>- NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL(newNbl),
>- ovsFwdCtx->completionList,
>- &ovsFwdCtx->layers, FALSE);
>-ovsFwdCtx->curNbl = newNbl;
>-}
>-
>-NET_BUFFER_LIST_INFO(curNbl,
>- TcpIpChecksumNetBufferListInfo) = 0;
>-
> return NDIS_STATUS_SUCCESS;
> }
> 
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=SBcJfA7atJ6aGjBxtOlOR2r14HlYT8CY-K1DpMvgt4A&s=oP6eHfHcXJwo9vAhJbfEzIDJtQ6u-WkjnbIOxErltVY&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Increment ct packet counters based on ct_state.

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 9/5/17, 4:53 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>For a given packet, packet counters in conntrack should be accounted only
>once, even if the packet is processed multiple times by conntrack.
>
>When a packet is processed by conntrack, ct_state flag is set to
>OVS_CS_F_TRACKED. Use this state to identify if a packet has been
>processed previously by conntrack.
>
>Also update the ct packet counters when ct entry is created.
>
>With this patch, the conntrack's packet counters behavior is similar
>to linux
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Conntrack.c | 34 +-
> 1 file changed, 21 insertions(+), 13 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 8bcda05..0adb6d5 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -169,6 +169,18 @@ OvsPostCtEventEntry(POVS_CT_ENTRY entry, UINT8 type)
> OvsPostCtEvent(&ctEventEntry);
> }
> 
>+static __inline VOID
>+OvsCtIncrementCounters(POVS_CT_ENTRY entry, BOOLEAN reply, PNET_BUFFER_LIST 
>nbl)
>+{
>+if (reply) {
>+entry->rev_key.byteCount+= OvsPacketLenNBL(nbl);
>+entry->rev_key.packetCount++;
>+} else {
>+entry->key.byteCount += OvsPacketLenNBL(nbl);
>+entry->key.packetCount++;
>+}
>+}
>+
> static __inline BOOLEAN
> OvsCtAddEntry(POVS_CT_ENTRY entry, OvsConntrackKeyLookupCtx *ctx,
>   PNAT_ACTION_INFO natInfo, UINT64 now)
>@@ -287,6 +299,9 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
> }
> 
> OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
>+if (entry) {
>+OvsCtIncrementCounters(entry, ctx->reply, curNbl);
>+}
> return entry;
> }
> 
>@@ -382,18 +397,6 @@ OvsCtKeyAreSame(OVS_CT_KEY ctxKey, OVS_CT_KEY entryKey)
> (ctxKey.zone == entryKey.zone));
> }
> 
>-static __inline VOID
>-OvsCtIncrementCounters(POVS_CT_ENTRY entry, BOOLEAN reply, PNET_BUFFER_LIST 
>nbl)
>-{
>-if (reply) {
>-entry->rev_key.byteCount+= OvsPacketLenNBL(nbl);
>-entry->rev_key.packetCount++;
>-} else {
>-entry->key.byteCount += OvsPacketLenNBL(nbl);
>-entry->key.packetCount++;
>-}
>-}
>-
> POVS_CT_ENTRY
> OvsCtLookup(OvsConntrackKeyLookupCtx *ctx)
> {
>@@ -730,6 +733,12 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> NdisReleaseRWLock(ovsConntrackLockObj, &lockState);
> OVS_LOG_ERROR("Conntrack Limit hit: %lu", ctTotalEntries);
> return NDIS_STATUS_RESOURCES;
>+
>+/* Increment the counters soon after the lookup, since we set ct.state
>+ * to OVS_CS_F_TRACKED after processing the ct entry.
>+ */
>+if (entry && (!(key->ct.state & OVS_CS_F_TRACKED))) {
>+OvsCtIncrementCounters(entry, ctx.reply, curNbl);
> }
> 
> if (!entry) {
>@@ -740,7 +749,6 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
>  &entryCreated);
> } else {
> /* Process the entry and update CT flags */
>-OvsCtIncrementCounters(entry, ctx.reply, curNbl);
> entry = OvsProcessConntrackEntry(fwdCtx, layers->l4Offset, &ctx, key,
>  zone, natInfo, commit, currentTime,
>  &entryCreated);
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=UUkY3ld1vxNjRMbNPm79bHFxEAWK0F9-VhuWaYlU0KM&s=W9Yf7wNSiWN-x1a9C_wSYqDGpCswFcmcyoNzE8rpuwk&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Remove unnecessary call to OvsInitForwardingCtx

[Sairam Venugopal]

Good catch.

Acked-by: Sairam Venugopal 





On 8/30/17, 4:03 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>Only curNbl in the forwarding context needs to be updated with
>fragmented NBL.
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Actions.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index 684b316..41d1c7b 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -160,14 +160,7 @@ OvsDoFragmentNbl(OvsForwardingContext *ovsFwdCtx, UINT16 
>mru)
> 
>if (fragNbl != NULL) {
> OvsCompleteNBL(ovsFwdCtx->switchContext, ovsFwdCtx->curNbl, TRUE);
>-OvsInitForwardingCtx(ovsFwdCtx,
>-ovsFwdCtx->switchContext,
>- fragNbl,
>- ovsFwdCtx->srcVportNo,
>- ovsFwdCtx->sendFlags,
>- 
>NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL(fragNbl),
>- ovsFwdCtx->completionList,
>- &ovsFwdCtx->layers, FALSE);
>+ovsFwdCtx->curNbl = fragNbl;
> } else {
> OVS_LOG_INFO("Fragment NBL failed for MRU = %u", mru);
> }
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=Blm4rRbJawNtVUIwJBOWdpXZXYoC5m1pWTeIwnTXzrw&s=nFm5w0cTb7IN2ZR5CyOtAHQq6desheZnbuNYTFg0SYc&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] datapath-windows: Add an upper limit to conntrack entries

[Sairam Venugopal]

The current implementation lacked an upper bound of number of entries in
the system. Set the size to ~2M (2^21) for the time being.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack.c | 10 ++
 datapath-windows/ovsext/Conntrack.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index ce8c1c8..8bcda05 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -722,6 +722,16 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
 entry = NULL;
 }
 
+if (!entry && commit && ctTotalEntries >= CT_MAX_ENTRIES) {
+/* Don't proceed with processing if the max limit has been hit.
+ * This blocks only new entries from being created and doesn't
+ * affect existing connections.
+ */
+NdisReleaseRWLock(ovsConntrackLockObj, &lockState);
+OVS_LOG_ERROR("Conntrack Limit hit: %lu", ctTotalEntries);
+return NDIS_STATUS_RESOURCES;
+}
+
 if (!entry) {
 /* If no matching entry was found, create one and add New state */
 entry = OvsCtEntryCreate(fwdCtx, key->ipKey.nwProto,
diff --git a/datapath-windows/ovsext/Conntrack.h 
b/datapath-windows/ovsext/Conntrack.h
index bca7d90..be5f34d 100644
--- a/datapath-windows/ovsext/Conntrack.h
+++ b/datapath-windows/ovsext/Conntrack.h
@@ -131,6 +131,7 @@ typedef struct OvsConntrackKeyLookupCtx {
 BOOLEAN related;
 } OvsConntrackKeyLookupCtx;
 
+#define CT_MAX_ENTRIES 1 << 21
 #define CT_HASH_TABLE_SIZE ((UINT32)1 << 10)
 #define CT_HASH_TABLE_MASK (CT_HASH_TABLE_SIZE - 1)
 #define CT_INTERVAL_SEC 1000LL //1s
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Add an upper limit to conntrack entries

[Sairam Venugopal]

Please check the comments inline.

Thanks,
Sairam




On 8/28/17, 8:55 PM, "Shashank Ram"  wrote:

>
>
>
>
>From: ovs-dev-boun...@openvswitch.org  on 
>behalf of Sairam Venugopal 
>Sent: Monday, August 28, 2017 4:56 PM
>To: d...@openvswitch.org
>Subject: [ovs-dev] [PATCH] datapath-windows: Add an upper limit to conntrack   
> entries
>
>The current implementation lacked an upper bound of number of entries in
>the system. Set the size to ~2M (2^21) for the time being.
>
>>> Any reason for choosing this arbitrarily?

Not arbitrary - I chose something that we currently use in default OVS Linux 
implementation.

>
>Signed-off-by: Sairam Venugopal 
>---
> datapath-windows/ovsext/Conntrack.c | 6 ++
> datapath-windows/ovsext/Conntrack.h | 1 +
> 2 files changed, 7 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index ce8c1c8..30de806 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -722,6 +722,12 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> entry = NULL;
> }
>
>+if (!entry && commit && ctTotalEntries >= CT_MAX_ENTRIES) {
>+/* Don't proceed with processing if the max limit has been hit */
>+NdisReleaseRWLock(ovsConntrackLockObj, &lockState);
>>> Add a error log here to facilitate easier debugging

It’s already caught and logged as part of the caller. 

>
>+return NDIS_STATUS_RESOURCES;
>+}
>+
>>> It makes more sense to put the check in OvsCtEntryCreate() since there are 
>>> multiple callers to that function.

I just answered this in Anand’s review comments. But the idea is to skip 
complete processing if the limit is hit.
OvsCtEntryCreate is called only by OvsProcessContrack apart from the current 
function. ProcessContrack makes it a point 

To delete and then create the entry.

>
> if (!entry) {
> /* If no matching entry was found, create one and add New state */
> entry = OvsCtEntryCreate(fwdCtx, key->ipKey.nwProto,
>diff --git a/datapath-windows/ovsext/Conntrack.h 
>b/datapath-windows/ovsext/Conntrack.h
>index bca7d90..be5f34d 100644
>--- a/datapath-windows/ovsext/Conntrack.h
>+++ b/datapath-windows/ovsext/Conntrack.h
>@@ -131,6 +131,7 @@ typedef struct OvsConntrackKeyLookupCtx {
> BOOLEAN related;
> } OvsConntrackKeyLookupCtx;
>
>+#define CT_MAX_ENTRIES 1 << 21
>>> Any reason this value is not defined directly?

Yes, to maintain consistency with the other usages.

>
> #define CT_HASH_TABLE_SIZE ((UINT32)1 << 10)
> #define CT_HASH_TABLE_MASK (CT_HASH_TABLE_SIZE - 1)
> #define CT_INTERVAL_SEC 1000LL //1s
>--
>2.9.0.windows.1
>
>___
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Add an upper limit to conntrack entries

[Sairam Venugopal]

Hi Anand,

OvsProcessConntrackEntry ensures that the old entry is deleted before creating 
a new one.
So it would prevent newer entries from being created or the limit being hit. 

I added in the function before processing to exit out quickly only if there was 
no matching entry and commit was specified.

Hope this answers your question.

Thanks,
Sairam 



On 8/29/17, 11:33 AM, "Anand Kumar"  wrote:

>Hi Sairam,
>
>Thanks for the patch. Please find my comment inline.
>
>Regards,
>Anand Kumar
>
>On 8/28/17, 4:56 PM, "ovs-dev-boun...@openvswitch.org on behalf of Sairam 
>Venugopal"  
>wrote:
>
>The current implementation lacked an upper bound of number of entries in
>the system. Set the size to ~2M (2^21) for the time being.
>
>Signed-off-by: Sairam Venugopal 
>---
> datapath-windows/ovsext/Conntrack.c | 6 ++
> datapath-windows/ovsext/Conntrack.h | 1 +
> 2 files changed, 7 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
> b/datapath-windows/ovsext/Conntrack.c
>index ce8c1c8..30de806 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -722,6 +722,12 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> entry = NULL;
> }
> 
>+if (!entry && commit && ctTotalEntries >= CT_MAX_ENTRIES) {
>+/* Don't proceed with processing if the max limit has been hit */
>+NdisReleaseRWLock(ovsConntrackLockObj, &lockState);
>+return NDIS_STATUS_RESOURCES;
>+}
>+
>  [AK]: Can we add this check inside OvsCtEntryCreate() function, as entry can 
> also be created in OvsProcessConntrackEntry()
>  
> https://github.com/openvswitch/ovs/blob/master/datapath-windows/ovsext/Conntrack.c#L613
>  
>
> if (!entry) {
> /* If no matching entry was found, create one and add New state */
> entry = OvsCtEntryCreate(fwdCtx, key->ipKey.nwProto,
>diff --git a/datapath-windows/ovsext/Conntrack.h 
> b/datapath-windows/ovsext/Conntrack.h
>index bca7d90..be5f34d 100644
>--- a/datapath-windows/ovsext/Conntrack.h
>+++ b/datapath-windows/ovsext/Conntrack.h
>@@ -131,6 +131,7 @@ typedef struct OvsConntrackKeyLookupCtx {
> BOOLEAN related;
> } OvsConntrackKeyLookupCtx;
> 
>+#define CT_MAX_ENTRIES 1 << 21
> #define CT_HASH_TABLE_SIZE ((UINT32)1 << 10)
> #define CT_HASH_TABLE_MASK (CT_HASH_TABLE_SIZE - 1)
> #define CT_INTERVAL_SEC 1000LL //1s
>-- 
>2.9.0.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Q5z9tBe-nAOpE7LIHSPV8uy5-437agMXvkeHHMkR8Us&m=EAviB6UFEys3jRhv7hULyGkP2OygltyfdtEaNlvOWDY&s=co2lpZtEG_VyCk3aIxQFVq4L0rnKR5iKtU2rsu8jFxc&e=
>  
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] datapath-windows: Add an upper limit to conntrack entries

[Sairam Venugopal]

The current implementation lacked an upper bound of number of entries in
the system. Set the size to ~2M (2^21) for the time being.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack.c | 6 ++
 datapath-windows/ovsext/Conntrack.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index ce8c1c8..30de806 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -722,6 +722,12 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
 entry = NULL;
 }
 
+if (!entry && commit && ctTotalEntries >= CT_MAX_ENTRIES) {
+/* Don't proceed with processing if the max limit has been hit */
+NdisReleaseRWLock(ovsConntrackLockObj, &lockState);
+return NDIS_STATUS_RESOURCES;
+}
+
 if (!entry) {
 /* If no matching entry was found, create one and add New state */
 entry = OvsCtEntryCreate(fwdCtx, key->ipKey.nwProto,
diff --git a/datapath-windows/ovsext/Conntrack.h 
b/datapath-windows/ovsext/Conntrack.h
index bca7d90..be5f34d 100644
--- a/datapath-windows/ovsext/Conntrack.h
+++ b/datapath-windows/ovsext/Conntrack.h
@@ -131,6 +131,7 @@ typedef struct OvsConntrackKeyLookupCtx {
 BOOLEAN related;
 } OvsConntrackKeyLookupCtx;
 
+#define CT_MAX_ENTRIES 1 << 21
 #define CT_HASH_TABLE_SIZE ((UINT32)1 << 10)
 #define CT_HASH_TABLE_MASK (CT_HASH_TABLE_SIZE - 1)
 #define CT_INTERVAL_SEC 1000LL //1s
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Update ICMP-Type and Code comparison in CT lookup

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 8/11/17, 1:41 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

> - Update the CT comparison function to compare individual fields instead of
>NdisEqualMemory.
>- Add in some padding for the ct_endpoint's union.
>- Update the Orig Tuple to use ICMP Type and Code instead of Port for ICMP
>
>Co-authored-by: Sairam Venugopal 
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Conntrack.c | 27 +--
> datapath-windows/ovsext/Conntrack.h |  5 -
> 2 files changed, 25 insertions(+), 7 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 917ebee..81c2167 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -373,10 +373,18 @@ OvsDetectCtPacket(OvsForwardingContext *fwdCtx,
> BOOLEAN
> OvsCtKeyAreSame(OVS_CT_KEY ctxKey, OVS_CT_KEY entryKey)
> {
>-return ((NdisEqualMemory(&ctxKey.src, &entryKey.src,
>- sizeof(struct ct_endpoint))) &&
>-(NdisEqualMemory(&ctxKey.dst, &entryKey.dst,
>- sizeof(struct ct_endpoint))) &&
>+return ((ctxKey.src.addr.ipv4 == entryKey.src.addr.ipv4) &&
>+(ctxKey.src.addr.ipv4_aligned == entryKey.src.addr.ipv4_aligned) 
>&&
>+(ctxKey.src.port == entryKey.src.port) &&
>+(ctxKey.src.icmp_id == entryKey.src.icmp_id) &&
>+(ctxKey.src.icmp_type == entryKey.src.icmp_type) &&
>+(ctxKey.src.icmp_code == entryKey.src.icmp_code) &&
>+(ctxKey.dst.addr.ipv4 == entryKey.dst.addr.ipv4) &&
>+(ctxKey.dst.addr.ipv4_aligned == entryKey.dst.addr.ipv4_aligned) 
>&&
>+(ctxKey.dst.port == entryKey.dst.port) &&
>+(ctxKey.dst.icmp_id == entryKey.dst.icmp_id) &&
>+(ctxKey.dst.icmp_type == entryKey.dst.icmp_type) &&
>+(ctxKey.dst.icmp_code == entryKey.dst.icmp_code) &&
> (ctxKey.dl_type == entryKey.dl_type) &&
> (ctxKey.nw_proto == entryKey.nw_proto) &&
> (ctxKey.zone == entryKey.zone));
>@@ -782,9 +790,16 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> 
> key->ct.tuple_ipv4.ipv4_src = ctKey->src.addr.ipv4_aligned;
> key->ct.tuple_ipv4.ipv4_dst = ctKey->dst.addr.ipv4_aligned;
>-key->ct.tuple_ipv4.src_port = ctKey->src.port;
>-key->ct.tuple_ipv4.dst_port = ctKey->dst.port;
> key->ct.tuple_ipv4.ipv4_proto = ctKey->nw_proto;
>+
>+/* Orig tuple Port is overloaded to take in ICMP-Type & Code */
>+/* This mimics the behavior in lib/conntrack.c*/
>+key->ct.tuple_ipv4.src_port = ctKey->nw_proto != IPPROTO_ICMP ?
>+  ctKey->src.port :
>+  htons(ctKey->src.icmp_type);
>+key->ct.tuple_ipv4.dst_port = ctKey->nw_proto != IPPROTO_ICMP ?
>+  ctKey->dst.port :
>+  htons(ctKey->src.icmp_code);
> }
> 
> if (entryCreated && entry) {
>diff --git a/datapath-windows/ovsext/Conntrack.h 
>b/datapath-windows/ovsext/Conntrack.h
>index 04ca299..4904c7e 100644
>--- a/datapath-windows/ovsext/Conntrack.h
>+++ b/datapath-windows/ovsext/Conntrack.h
>@@ -41,7 +41,10 @@ struct ct_addr {
> struct ct_endpoint {
> struct ct_addr addr;
> union {
>-ovs_be16 port;
>+struct {
>+ovs_be16 port;
>+uint16 pad_port;
>+};
> struct {
> ovs_be16 icmp_id;
> uint8_t icmp_type;
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=jv5eh3bLA-gmtkDuLhimROtMSTOYl817LE81oKgfKo8&s=zIJGnXCflvEaG9FWrbvkouqo9uSfZ-KoRq7H_GzPiMo&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Do not modify port field for ICMP during SNAT/DNAT

[Sairam Venugopal]

Acked-by: Sairam Venugopal 




On 8/10/17, 8:59 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>During SNAT/DNAT, we should not be updating the port field of ct_endpoint
>struct, as ICMP packets do not have port information. Since port and
>icmp_id are overlapped in ct_endpoint struct, icmp_id gets changed.
>As a result, NAT look up fails to find a matching entry.
>
>This patch addresses this issue by not modifying icmp_id field during
>SNAT/DNAT only for ICMP traffic
>
>The current NAT module doesn't take the ICMP type/id/code into account
>during the lookups. Fix this to make it similar with the other conntrack
>module.
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Conntrack-nat.c | 23 ---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack-nat.c 
>b/datapath-windows/ovsext/Conntrack-nat.c
>index ae6b92c..eb6f9db 100644
>--- a/datapath-windows/ovsext/Conntrack-nat.c
>+++ b/datapath-windows/ovsext/Conntrack-nat.c
>@@ -22,6 +22,12 @@ OvsHashNatKey(const OVS_CT_KEY *key)
> HASH_ADD(src.port);
> HASH_ADD(dst.port);
> HASH_ADD(zone);
>+/* icmp_id and port overlap in the union */
>+HASH_ADD(src.icmp_type);
>+HASH_ADD(dst.icmp_type);
>+HASH_ADD(src.icmp_code);
>+HASH_ADD(dst.icmp_code);
>+
> #undef HASH_ADD
> return hash;
> }
>@@ -44,6 +50,12 @@ OvsNatKeyAreSame(const OVS_CT_KEY *key1, const OVS_CT_KEY 
>*key2)
> FIELD_COMPARE(src.port);
> FIELD_COMPARE(dst.port);
> FIELD_COMPARE(zone);
>+FIELD_COMPARE(src.icmp_id);
>+FIELD_COMPARE(dst.icmp_id);
>+FIELD_COMPARE(src.icmp_type);
>+FIELD_COMPARE(dst.icmp_type);
>+FIELD_COMPARE(src.icmp_code);
>+FIELD_COMPARE(dst.icmp_code);
> return TRUE;
> #undef FIELD_COMPARE
> }
>@@ -253,6 +265,7 @@ OvsNatAddEntry(OVS_NAT_ENTRY* entry)
>  * Update an Conntrack entry with NAT information. Translated address and
>  * port will be generated and write back to the conntrack entry as a
>  * result.
>+ * Note: For ICMP, only address is translated.
>  *
>  */
> BOOLEAN
>@@ -271,7 +284,7 @@ OvsNatTranslateCtEntry(OVS_CT_ENTRY *entry)
> BOOLEAN allPortsTried;
> BOOLEAN originalPortsTried;
> struct ct_addr firstAddr;
>-
>+
> uint32_t hash = OvsNatHashRange(entry, 0);
> 
> if ((entry->natInfo.natAction & NAT_ACTION_SRC) &&
>@@ -310,10 +323,14 @@ OvsNatTranslateCtEntry(OVS_CT_ENTRY *entry)
> for (;;) {
> if (entry->natInfo.natAction & NAT_ACTION_SRC) {
> entry->rev_key.dst.addr = ctAddr;
>-entry->rev_key.dst.port = htons(port);
>+if (entry->rev_key.nw_proto != IPPROTO_ICMP) {
>+entry->rev_key.dst.port = htons(port);
>+}
> } else {
> entry->rev_key.src.addr = ctAddr;
>-entry->rev_key.src.port = htons(port);
>+if (entry->rev_key.nw_proto != IPPROTO_ICMP) {
>+entry->rev_key.src.port = htons(port);
>+}
> }
> 
> OVS_NAT_ENTRY *natEntry = OvsNatLookup(&entry->rev_key, TRUE);
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=DsmJOWCzvx6z5N9EJRhI-qvjbQUILl-ehTn-JLw4RZQ&s=NPGcReKGVlLHh2rvCJh0r8h-l38sSxpm8V-uPaVe9sY&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Include ICMP type and code fields to find a matching ct entry

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 6/23/17, 2:05 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>In conntrack lookup, ICMP type and code fields were not being used to
>determine a matching entry. As a result, ICMP4_ECHO_REQUEST packet could
>be tracked as ICMP4_ECHO_REPLY packet and vice versa, which is invalid.
>
>To fix this, add ICMP type and code fields for matching a conntrack entry.
>
>Signed-off-by: Anand Kumar 
>Acked-by: Sairam Venugopal 
>---
> datapath-windows/ovsext/Conntrack.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 07a9583..e97d6ce 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -383,15 +383,13 @@ OvsDetectCtPacket(OvsForwardingContext *fwdCtx,
> BOOLEAN
> OvsCtKeyAreSame(OVS_CT_KEY ctxKey, OVS_CT_KEY entryKey)
> {
>-return ((ctxKey.src.addr.ipv4 == entryKey.src.addr.ipv4) &&
>-(ctxKey.src.addr.ipv4_aligned == entryKey.src.addr.ipv4_aligned) &&
>-(ctxKey.src.port == entryKey.src.port) &&
>-(ctxKey.dst.addr.ipv4 == entryKey.dst.addr.ipv4) &&
>-(ctxKey.dst.addr.ipv4_aligned == entryKey.dst.addr.ipv4_aligned) &&
>-(ctxKey.dst.port == entryKey.dst.port) &&
>-(ctxKey.dl_type == entryKey.dl_type) &&
>-(ctxKey.nw_proto == entryKey.nw_proto) &&
>-(ctxKey.zone == entryKey.zone));
>+return ((NdisEqualMemory(&ctxKey.src, &entryKey.src,
>+ sizeof(struct ct_endpoint))) &&
>+(NdisEqualMemory(&ctxKey.dst, &entryKey.dst,
>+ sizeof(struct ct_endpoint))) &&
>+(ctxKey.dl_type == entryKey.dl_type) &&
>+(ctxKey.nw_proto == entryKey.nw_proto) &&
>+(ctxKey.zone == entryKey.zone));
> }
> 
> static __inline VOID
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=dZbQHOKOvzZMDRL3iLHrW462Arv61PvgHu7MBbIgGfE&s=J6o8L1w_jhv5yW37xELhRdaqZnN-WcG8UAHw4xlXG7I&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Include ICMP type and code fields to find a matching ct entry

[Sairam Venugopal]

Hi Anand,

Can you split this patch up instead to handle Conntrack.c and Conntrack-Nat.c 
in a separate one? This way we can keep the testing isolated to the changes.

Acking Conntrack.c change:

Acked-by: Sairam Venugopal 




On 6/22/17, 11:54 AM, "ovs-dev-boun...@openvswitch.org on behalf of Anand 
Kumar"  
wrote:

>In conntrack lookup, ICMP type and code fields were not being used to
>determine a matching entry. As a result, ICMP4_ECHO_REQUEST packet could
>be tracked as ICMP4_ECHO_REPLY packet and vice versa, which is invalid.
>
>To fix this, add ICMP type and code fields for matching a conntrack entry.
>Also updated OvsNatKeyAreSame() and OvsHashNatKey() to include these two
>fields.
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Conntrack-nat.c | 32 ++--
> datapath-windows/ovsext/Conntrack.c | 16 +++-
> 2 files changed, 17 insertions(+), 31 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack-nat.c 
>b/datapath-windows/ovsext/Conntrack-nat.c
>index ae6b92c..f3c282c 100644
>--- a/datapath-windows/ovsext/Conntrack-nat.c
>+++ b/datapath-windows/ovsext/Conntrack-nat.c
>@@ -13,17 +13,11 @@ PLIST_ENTRY ovsUnNatTable = NULL;
> static __inline UINT32
> OvsHashNatKey(const OVS_CT_KEY *key)
> {
>-UINT32 hash = 0;
>-#define HASH_ADD(field) \
>-hash = OvsJhashBytes(&key->field, sizeof(key->field), hash)
>-
>-HASH_ADD(src.addr.ipv4_aligned);
>-HASH_ADD(dst.addr.ipv4_aligned);
>-HASH_ADD(src.port);
>-HASH_ADD(dst.port);
>-HASH_ADD(zone);
>-#undef HASH_ADD
>-return hash;
>+UINT32 hash[3];
>+hash[0] = OvsJhashBytes(&key->src, sizeof(key->src), 0);
>+hash[1] = OvsJhashBytes(&key->dst, sizeof(key->dst), 0);
>+hash[2] = OvsJhashBytes(&key->zone, sizeof(key->zone), 0);
>+return OvsJhashWords(hash, 3, OVS_HASH_BASIS);
> }
> 
> /*
>@@ -35,17 +29,11 @@ OvsHashNatKey(const OVS_CT_KEY *key)
> static __inline BOOLEAN
> OvsNatKeyAreSame(const OVS_CT_KEY *key1, const OVS_CT_KEY *key2)
> {
>-// XXX: Compare IPv6 key as well
>-#define FIELD_COMPARE(field) \
>-if (key1->field != key2->field) return FALSE
>-
>-FIELD_COMPARE(src.addr.ipv4_aligned);
>-FIELD_COMPARE(dst.addr.ipv4_aligned);
>-FIELD_COMPARE(src.port);
>-FIELD_COMPARE(dst.port);
>-FIELD_COMPARE(zone);
>-return TRUE;
>-#undef FIELD_COMPARE
>+return ((NdisEqualMemory(&key1->src, &key2->src,
>+ sizeof(struct ct_endpoint))) &&
>+(NdisEqualMemory(&key1->dst, &key2->dst,
>+ sizeof(struct ct_endpoint))) &&
>+(key1->zone == key2->zone));
> }
> 
> /*
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 07a9583..e97d6ce 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -383,15 +383,13 @@ OvsDetectCtPacket(OvsForwardingContext *fwdCtx,
> BOOLEAN
> OvsCtKeyAreSame(OVS_CT_KEY ctxKey, OVS_CT_KEY entryKey)
> {
>-return ((ctxKey.src.addr.ipv4 == entryKey.src.addr.ipv4) &&
>-(ctxKey.src.addr.ipv4_aligned == entryKey.src.addr.ipv4_aligned) &&
>-(ctxKey.src.port == entryKey.src.port) &&
>-(ctxKey.dst.addr.ipv4 == entryKey.dst.addr.ipv4) &&
>-(ctxKey.dst.addr.ipv4_aligned == entryKey.dst.addr.ipv4_aligned) &&
>-(ctxKey.dst.port == entryKey.dst.port) &&
>-(ctxKey.dl_type == entryKey.dl_type) &&
>-(ctxKey.nw_proto == entryKey.nw_proto) &&
>-(ctxKey.zone == entryKey.zone));
>+return ((NdisEqualMemory(&ctxKey.src, &entryKey.src,
>+ sizeof(struct ct_endpoint))) &&
>+(NdisEqualMemory(&ctxKey.dst, &entryKey.dst,
>+ sizeof(struct ct_endpoint))) &&
>+(ctxKey.dl_type == entryKey.dl_type) &&
>+(ctxKey.nw_proto == entryKey.nw_proto) &&
>+(ctxKey.zone == entryKey.zone));
> }
> 
> static __inline VOID
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=RcKP7MCbcn9PTpNRinYsO9Q0x4MrsrHutzBQ0hweH2M&s=7sFDQthiIL809LnOAfhczTX9Lk7iZDvnFhR77N4DfbE&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Add support for UPDATE events in Conntrack

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 6/21/17, 1:33 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>Introduce a new event type OVS_EVENT_CT_UPDATE to send a conntrack event
>whenever a MARK and/or LABEL gets changed for an existing conntrack entry.
>
>  - Parse netlink conntrack attribute OVS_CT_ATTR_EVENTMASK, which is used
>to set the mask of bits specifying which conntrack events (IPCT_*)
>should be delivered via the Netfilter netlink multicast groups.
>  - Send update event only when OVS_CT_ATTR_EVENTMASK attribute has the mask
>of bits set for IPCT_MARK and/or IPCT_LABEL.
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/ovsext/Conntrack.c  | 48 ++--
> datapath-windows/ovsext/Datapath.c   |  3 +++
> datapath-windows/ovsext/DpInternal.h |  3 ++-
> datapath-windows/ovsext/Event.c  |  3 ++-
> 4 files changed, 47 insertions(+), 10 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 07a9583..61c6bc7 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -659,13 +659,15 @@ static __inline VOID
> OvsConntrackSetMark(OvsFlowKey *key,
> POVS_CT_ENTRY entry,
> UINT32 value,
>-UINT32 mask)
>+UINT32 mask,
>+BOOLEAN *markChanged)
> {
> UINT32 newMark;
> newMark = value | (entry->mark & ~(mask));
> if (entry->mark != newMark) {
> entry->mark = newMark;
> key->ct.mark = newMark;
>+*markChanged = TRUE;
> }
> }
> 
>@@ -673,7 +675,8 @@ static __inline void
> OvsConntrackSetLabels(OvsFlowKey *key,
>   POVS_CT_ENTRY entry,
>   struct ovs_key_ct_labels *val,
>-  struct ovs_key_ct_labels *mask)
>+  struct ovs_key_ct_labels *mask,
>+  BOOLEAN *labelChanged)
> {
> ovs_u128 v, m, pktMdLabel = {0};
> memcpy(&v, val, sizeof v);
>@@ -682,6 +685,10 @@ OvsConntrackSetLabels(OvsFlowKey *key,
> pktMdLabel.u64.lo = v.u64.lo | (pktMdLabel.u64.lo & ~(m.u64.lo));
> pktMdLabel.u64.hi = v.u64.hi | (pktMdLabel.u64.hi & ~(m.u64.hi));
> 
>+if (!NdisEqualMemory(&entry->labels, &pktMdLabel,
>+ sizeof(struct ovs_key_ct_labels))) {
>+*labelChanged = TRUE;
>+}
> NdisMoveMemory(&entry->labels, &pktMdLabel,
>sizeof(struct ovs_key_ct_labels));
> NdisMoveMemory(&key->ct.labels, &pktMdLabel,
>@@ -698,9 +705,11 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
>   MD_MARK *mark,
>   MD_LABELS *labels,
>   PCHAR helper,
>-  PNAT_ACTION_INFO natInfo)
>+  PNAT_ACTION_INFO natInfo,
>+  BOOLEAN postUpdateEvent)
> {
> NDIS_STATUS status = NDIS_STATUS_SUCCESS;
>+BOOLEAN triggerUpdateEvent = FALSE;
> POVS_CT_ENTRY entry = NULL;
> PNET_BUFFER_LIST curNbl = fwdCtx->curNbl;
> OvsConntrackKeyLookupCtx ctx = { 0 };
>@@ -752,11 +761,13 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> }
> 
> if (entry && mark) {
>-OvsConntrackSetMark(key, entry, mark->value, mark->mask);
>+OvsConntrackSetMark(key, entry, mark->value, mark->mask,
>+&triggerUpdateEvent);
> }
> 
> if (entry && labels) {
>-OvsConntrackSetLabels(key, entry, &labels->value, &labels->mask);
>+OvsConntrackSetLabels(key, entry, &labels->value, &labels->mask,
>+  &triggerUpdateEvent);
> }
> 
> if (entry && OvsDetectFtpPacket(key)) {
>@@ -790,6 +801,9 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> if (entryCreated && entry) {
> OvsPostCtEventEntry(entry, OVS_EVENT_CT_NEW);
> }
>+if (postUpdateEvent && entry && !entryCreated && triggerUpdateEvent) {
>+OvsPostCtEventEntry(entry, OVS_EVENT_CT_UPDATE);
>+}
> 
> NdisReleaseRWLock(ovsConntrackLockObj, &lockState);
> 
>@@ -811,7 +825,9 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
> PNL_ATTR ctAttr;
> BOOLEAN commit = FALSE;
> BOOLEAN force = FALSE;
>+BOOLEAN postUpdateEvent = FALSE;
> UINT16 zone = 0;
>+UINT32 eventmask = 0;
> MD_MARK *mark = NULL;
> MD_LABELS *labels = NULL;
> PCHAR helper = NULL;
>@@ -922,9 +938,17 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
>

[ovs-dev] [PATCH] datapath-windows: Fix switch-case alignments in Conntrack.c

[Sairam Venugopal]

Minor - Fix the switch case alignments. Found by inspection.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack.c | 83 ++---
 1 file changed, 41 insertions(+), 42 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 07a9583..13c84fd 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -307,24 +307,23 @@ OvsCtUpdateEntry(OVS_CT_ENTRY* entry,
  BOOLEAN reply,
  UINT64 now)
 {
-switch (ipProto)
+switch (ipProto) {
+case IPPROTO_TCP:
 {
-case IPPROTO_TCP:
-{
-TCPHdr tcpStorage;
-const TCPHdr *tcp;
-tcp = OvsGetTcp(nbl, l4Offset, &tcpStorage);
-if (!tcp) {
-return CT_UPDATE_INVALID;
-}
-return OvsConntrackUpdateTcpEntry(entry, tcp, nbl, reply, now);
-}
-case IPPROTO_ICMP:
-return OvsConntrackUpdateIcmpEntry(entry, reply, now);
-case IPPROTO_UDP:
-return OvsConntrackUpdateOtherEntry(entry, reply, now);
-default:
+TCPHdr tcpStorage;
+const TCPHdr *tcp;
+tcp = OvsGetTcp(nbl, l4Offset, &tcpStorage);
+if (!tcp) {
 return CT_UPDATE_INVALID;
+}
+return OvsConntrackUpdateTcpEntry(entry, tcp, nbl, reply, now);
+}
+case IPPROTO_ICMP:
+return OvsConntrackUpdateIcmpEntry(entry, reply, now);
+case IPPROTO_UDP:
+return OvsConntrackUpdateOtherEntry(entry, reply, now);
+default:
+return CT_UPDATE_INVALID;
 }
 }
 
@@ -517,32 +516,32 @@ OvsCtSetupLookupCtx(OvsFlowKey *flowKey,
 /* Related bit is set when ICMP has an error */
 /* XXX parse out the appropriate src and dst from inner pkt */
 switch (icmp->type) {
-   case ICMP4_ECHO_REQUEST:
-   case ICMP4_ECHO_REPLY:
-   case ICMP4_TIMESTAMP_REQUEST:
-   case ICMP4_TIMESTAMP_REPLY:
-   case ICMP4_INFO_REQUEST:
-   case ICMP4_INFO_REPLY:
-   if (icmp->code != 0) {
-   return NDIS_STATUS_INVALID_PACKET;
-   }
-   /* Separate ICMP connection: identified using id */
-   ctx->key.dst.icmp_id = icmp->fields.echo.id;
-   ctx->key.src.icmp_id = icmp->fields.echo.id;
-   ctx->key.src.icmp_type = icmp->type;
-   ctx->key.dst.icmp_type = OvsReverseIcmpType(icmp->type);
-   break;
-   case ICMP4_DEST_UNREACH:
-   case ICMP4_TIME_EXCEEDED:
-   case ICMP4_PARAM_PROB:
-   case ICMP4_SOURCE_QUENCH:
-   case ICMP4_REDIRECT: {
-   /* XXX Handle inner packet */
-   ctx->related = TRUE;
-   break;
-   }
-   default:
-   ctx->related = FALSE;
+case ICMP4_ECHO_REQUEST:
+case ICMP4_ECHO_REPLY:
+case ICMP4_TIMESTAMP_REQUEST:
+case ICMP4_TIMESTAMP_REPLY:
+case ICMP4_INFO_REQUEST:
+case ICMP4_INFO_REPLY:
+if (icmp->code != 0) {
+return NDIS_STATUS_INVALID_PACKET;
+}
+/* Separate ICMP connection: identified using id */
+ctx->key.dst.icmp_id = icmp->fields.echo.id;
+ctx->key.src.icmp_id = icmp->fields.echo.id;
+ctx->key.src.icmp_type = icmp->type;
+ctx->key.dst.icmp_type = OvsReverseIcmpType(icmp->type);
+break;
+case ICMP4_DEST_UNREACH:
+case ICMP4_TIME_EXCEEDED:
+case ICMP4_PARAM_PROB:
+case ICMP4_SOURCE_QUENCH:
+case ICMP4_REDIRECT: {
+/* XXX Handle inner packet */
+ctx->related = TRUE;
+break;
+}
+default:
+ctx->related = FALSE;
 }
 }
 } else if (flowKey->l2.dlType == htons(ETH_TYPE_IPV6)) {
-- 
2.9.0.windows.1

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

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

[Sairam Venugopal]

I have addressed this in V2. The invalid label is not necessary.




On 6/20/17, 2:46 PM, "Shashank Ram"  wrote:

>Thanks for the patch, please find comments inline.
>
>From: ovs-dev-boun...@openvswitch.org  on 
>behalf of Sairam Venugopal 
>Sent: Tuesday, June 20, 2017 1:36 PM
>To: d...@openvswitch.org
>Subject: [ovs-dev] [PATCH] datapath-windows: Fix potential memory leak while   
> creating conntrack entry
>
>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 
>---
> datapath-windows/ovsext/Conntrack.c | 59 +
> 1 file changed, 27 insertions(+), 32 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 68ed395..bf9c4f4 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -214,9 +214,18 @@ 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;
>+
>+*entryCreated = FALSE;
>+state |= OVS_CS_F_NEW;
>+
>+parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
>+if (parentEntry != NULL) {
>+state |= OVS_CS_F_RELATED;
>+}
>+
> switch (ipProto)
> {
> case IPPROTO_TCP:
>@@ -228,23 +237,8 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
> 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;
>-}
>-
>-/* Set parent entry for related FTP connections */
>-entry->parent = parentEntry;
>-
>-*entryCreated = TRUE;
> }
> break;
> }
>@@ -257,14 +251,8 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
> 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;
> }
> break;
> }
>@@ -273,11 +261,6 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
> state |= OVS_CS_F_NEW;
>>>> This is not needed since its initialized at the start?
>
>
> if (commit) {
> entry = OvsConntrackCreateOtherEntry(currentTime);
>-if (entry) {
>-/* Default UDP related to NULL until TFTP is supported */
>-entry->parent = NULL;
>-}
>-*entryCreated = TRUE;
> }
> break;
> }
>@@ -285,12 +268,24 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
> goto invalid;
> }
>
>-if (commit && !entry) {
>-return NULL;
>-}
>-if (entry && !OvsCtAddEntry(entry, ctx, natInfo, currentTime)) {
>-return NULL;
>+if (commit) {
>+if (entry) {
>+entry->parent = parentEntry;
>+if (OvsCtAddEntry(entry, ctx, natInfo, currentTime)) {
>+*entryCreated = TRUE;
>+} else {
>+/* Unable to add entry to the list */
>+OvsFreeMemoryWithTag(entry, OVS_CT_POOL_TAG);
>+state = OVS_CS_F_I

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

[Sairam Venugopal]

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 
---
 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, &tcpStorage);
-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, &tcpStorage);
+if (!OvsConntrackValidateTcpPacket(tcp)) {
+state = OVS_CS_F_INVALID;
 break;
 }
-case IPPROTO_ICMP:
-{
-ICMPHdr storage;
-const ICMPHdr *icmp;
-icmp = OvsGetIcmp(curNbl, l4Offset, &storage);
-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, &storage);
+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 list */
+OvsFreeMemoryWithTag(entry, OVS_CT_POOL_TAG);
+state = OVS_CS_F_INVALID;
+entry = NULL;
 }
-break;
+} else {
+/* OvsAllo

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

[Sairam Venugopal]

Hi Yin,

I would keep it separate. The main intent of this patch is to fix the memory 
leak and reduce the redundancy in the OvsCtCreateEntry switch cases.

Thanks,
Sairam

From: Yin Lin
Date: Tuesday, June 20, 2017 at 3:54 PM
To: Sairam Venugopal, "d...@openvswitch.org<mailto:d...@openvswitch.org>"
Subject: Re: [ovs-dev] [PATCH] datapath-windows: Fix potential memory leak 
while creating conntrack entry

Hi Sai,

I meant that  if an entry is returned by this function, it's always going to be 
"explicitly created", rather than "an existing entry". If that is that case, 
you can remove all lines that is related to entryCreated in this function and 
determine whether entryCreated is true from the caller. I'm bringing it up 
because you are refactoring this function for simplicity and coherence anyway. 
But of course it's your decision whether to make it in a separate patch.

Best regards,
Yin Lin

On Tue, Jun 20, 2017 at 3:29 PM, Sairam Venugopal 
mailto:vsai...@vmware.com>> wrote:
How will you do that in this code? We need to distinguish between an existing 
entry and entry explicitly created. If you want to send out an incremental 
patch, feel free to.

Thanks,
Sairam

From: Yin Lin
Date: Tuesday, June 20, 2017 at 3:26 PM

To: Sairam Venugopal
Subject: Re: [ovs-dev] [PATCH] datapath-windows: Fix potential memory leak 
while creating conntrack entry

Hi Sai,

In that case, can we get rid of the boolean and ask the caller to fire the 
event based on whether entry == NULL? For this particular function I don't see 
any reason to take an extra parameter. If one return value can be easily 
inferred from the other return value, there is no need to return two.

Best regards,
Yin Lin

On Tue, Jun 20, 2017 at 2:38 PM, Sairam Venugopal 
mailto:vsai...@vmware.com>> wrote:
This variable is used to determine if a CT Entry was created without any 
errors. We then rely on this variable to fire an event to state that a new CT 
Entry was created.

This event was previously inside the OvsCtAddEntry but had to be pulled out to 
include Mark and Label fields.


From: Yin Lin
Date: Tuesday, June 20, 2017 at 2:34 PM
To: Sairam Venugopal
Subject: Re: [ovs-dev] [PATCH] datapath-windows: Fix potential memory leak 
while creating conntrack entry

Hi Sai,

Thanks for the fix. One question though. I noticed that entryCreated is TRUE if 
and only if entry == NULL at the end of this function. So why do we need this 
variable?

Best regards,
Yin Lin

On Tue, Jun 20, 2017 at 1:36 PM, Sairam Venugopal 
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 mailto:vsai...@vmware.com>>
---
 datapath-windows/ovsext/Conntrack.c | 59 +
 1 file changed, 27 insertions(+), 32 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 68ed395..bf9c4f4 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -214,9 +214,18 @@ 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;
+
+*entryCreated = FALSE;
+state |= OVS_CS_F_NEW;
+
+parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
+if (parentEntry != NULL) {
+state |= OVS_CS_F_RELATED;
+}
+
 switch (ipProto)
 {
 case IPPROTO_TCP:
@@ -228,23 +237,8 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
 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;
-}
-
-/* Set parent entry for related FTP connections */
-entry->parent = parentEntry;
-
-*entryCre

Re: [ovs-dev] [PATCH] windows: Remove vlog_init() from service_start function

[Sairam Venugopal]

Alin,

Thanks for looking into this!

Acked-by: Sairam Venugopal 





On 6/20/17, 12:14 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Serdean"  wrote:

>Unit tests are passing.
>
>
>
>I also gave it a test via the installer.
>
>
>
>Acked-by: Alin Gabriel Serdean 
>
>
>
>
>
>> -Original Message-
>
>> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
>
>> boun...@openvswitch.org] On Behalf Of Anand Kumar
>
>> Sent: Saturday, June 17, 2017 1:47 AM
>
>> To: Guru Shetty 
>
>> Cc: ovs dev 
>
>> Subject: Re: [ovs-dev] [PATCH] windows: Remove vlog_init() from
>
>> service_start function
>
>> 
>
>> Hi Guru,
>
>> 
>
>> No, I didn’t run unit tests before. But I have verified manually, that ovsdb-
>
>> server and ovs-vswitchd daemons starts normally when run as a
>
>> service/console application.
>
>> 
>
>> I have run the unit tests now, so far 1812 tests have executed and I didn’t
>
>> see any issues. But the test suite got hung at “1813: SSL db: 
>> implementation”,
>
>> so running it again.
>
>> 
>
>> Thanks,
>
>> Anand Kumar
>
>> 
>
>> From: Guru Shetty 
>
>> Date: Friday, June 16, 2017 at 11:06 AM
>
>> To: Anand Kumar 
>
>> Cc: ovs dev 
>
>> Subject: Re: [ovs-dev] [PATCH] windows: Remove vlog_init() from
>
>> service_start function
>
>> 
>
>> 
>
>> 
>
>> On 16 June 2017 at 10:06, Anand Kumar
>
>> mailto:kumaran...@vmware.com>> wrote:
>
>> When --syslog-method is passed as a cmd line argument and ovs daemons
>
>> are started as a service, --syslog-method argument is not honoured, as vlog
>
>> module is initialized by service_start function before parsing the command
>
>> line arguments.
>
>> 
>
>> Easy way to fix this, is to remove vlog_init() from the service start 
>> function
>
>> and let the first log message to initialize the vlog module.
>
>> 
>
>> Signed-off-by: Anand Kumar
>
>> mailto:kumaran...@vmware.com>>
>
>
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=6PSoRMb2_Za8AiSS_bUShxGINRprA-Pjd8OWtXSFNC0&s=F7JVaof-epz2VayD_XtQ5jsyf3SNYodbNoiAw2ZTMbg&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] tests: switch from signed to unsigned when formatting

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 6/20/17, 12:44 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Serdean"  wrote:

>x->errline is a signed int
>(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_934386dd129a3f15b2546562a775f2f43dd3aac6_tests_test-2Dsflow.c-23L88&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=52CvYQ6uQ_8gMUb3CO0zBOQi3EAEo7U12sf_jRaLMto&s=jGs1qklVubrW1fOsUpNILtvW2UjkxaFlMmcyjv1eM1o&e=
> )
>Flagged by static code analysis.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> tests/test-sflow.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/tests/test-sflow.c b/tests/test-sflow.c
>index 6125d38..039a1b1 100644
>--- a/tests/test-sflow.c
>+++ b/tests/test-sflow.c
>@@ -675,7 +675,7 @@ print_sflow(struct ofpbuf *buf)
> process_datagram(x);
> } else {
> // CATCH
>-printf("\n>>>>> ERROR in " __FILE__ " at line %u\n", x->errline);
>+printf("\n>>>>> ERROR in " __FILE__ " at line %d\n", x->errline);
> }
> }
> 
>-- 
>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&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=52CvYQ6uQ_8gMUb3CO0zBOQi3EAEo7U12sf_jRaLMto&s=rOqbBbyjEA6AKF-RlAt-BrQ1BrGinru0mkM-FdoOoks&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Sairam Venugopal]

Thanks for patching this.

Acked-by: Sairam Venugopal 





On 6/15/17, 3:15 PM, "ovs-dev-boun...@openvswitch.org on behalf of Shashank 
Ram"  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 
>---
> datapath-windows/ovsext/Flow.c | 5 +
> datapath-windows/ovsext/Offload.c  | 3 +++
> datapath-windows/ovsext/PacketParser.h | 9 -
> datapath-windows/ovsext/Stt.c  | 2 +-
> datapath-windows/ovsext/User.c | 5 +
> datapath-windows/ovsext/Vxlan.c| 3 ++-
> 6 files changed, 24 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
>index 60f9b1c..852a22f 100644
>--- a/datapath-windows/ovsext/Flow.c
>+++ b/datapath-windows/ovsext/Flow.c
>@@ -2141,6 +2141,9 @@ OvsExtractLayers(const NET_BUFFER_LIST *packet,
> }
> }
> }
>+} else {
>+/* Invalid network header */
>+return NDIS_STATUS_INVALID_PACKET;
> }
> } else if (dlType == htons(ETH_TYPE_IPV6)) {
> NDIS_STATUS status;
>@@ -2360,8 +2363,10 @@ OvsExtractFlow(const NET_BUFFER_LIST *packet,
> }
> }
> } else {
>+/* Invalid network header */
> ((UINT64 *)ipKey)[0] = 0;
> ((UINT64 *)ipKey)[1] = 0;
>+return NDIS_STATUS_INVALID_PACKET;
> }
> } else if (flow->l2.dlType == htons(ETH_TYPE_IPV6)) {
> NDIS_STATUS status;
>diff --git a/datapath-windows/ovsext/Offload.c 
>b/datapath-windows/ovsext/Offload.c
>index 65d3b67..0905c80 100644
>--- a/datapath-windows/ovsext/Offload.c
>+++ b/datapath-windows/ovsext/Offload.c
>@@ -563,6 +563,9 @@ OvsValidateIPChecksum(PNET_BUFFER_LIST curNbl,
> if (checksum != hdrChecksum) {
> return NDIS_STATUS_FAILURE;
> }
>+} else {
>+/* Invalid network header */
>+return NDIS_STATUS_FAILURE;
> }
> }
> return NDIS_STATUS_SUCCESS;
>diff --git a/datapath-windows/ovsext/PacketParser.h 
>b/datapath-windows/ovsext/PacketParser.h
>index f1d7f28..0d5c0a6 100644
>--- a/datapath-windows/ovsext/PacketParser.h
>+++ b/datapath-windows/ovsext/PacketParser.h
>@@ -17,6 +17,8 @@
> #ifndef __PACKET_PARSER_H_
> #define __PACKET_PARSER_H_ 1
> 
>+#define MIN_IPV4_HLEN 20
>+
> #include "precomp.h"
> #include "NetProto.h"
> 
>@@ -107,7 +109,12 @@ OvsGetIp(const NET_BUFFER_LIST *packet,
> const IPHdr *ip = OvsGetPacketBytes(packet, sizeof *ip, ofs, storage);
> if (ip) {
> int ipLen = ip->ihl * 4;
>-if (ipLen >= sizeof *ip && OvsPacketLenNBL(packet) >= ofs + ipLen) {
>+if (ipLen <  MIN_IPV4_HLEN ||
>+ipLen > MAX_IPV4_HLEN ||
>+OvsPacketLenNBL(packet) < ofs + ipLen) {
>+   /* IP header is invalid, flag it */
>+   return NULL;
>+} else {
> return ip;
> }
> }
>diff --git a/datapath-windows/ovsext/Stt.c b/datapath-windows/ovsext/Stt.c
>index 1f36835..676cf0c 100644
>--- a/datapath-windows/ovsext/Stt.c
>+++ b/datapath-windows/ovsext/Stt.c
>@@ -1019,7 +1019,7 @@ OvsDecapStt(POVS_SWITCH_CONTEXT switchContext,
> innerIpHdr->check = IPChecksum((UINT8 *)innerIpHdr,
> innerIpHdr->ihl * 4, 0);
> } else {
>-status = NDIS_STATUS_RESOURCES;
>+status = NDIS_STATUS_INVALID_PACKET;
> goto dropNbl;
> }
> } else if (layers.isIPv6) {
>diff --git a/datapath-windows/ovsext/User.c b/datapath-windows/ovsext/User.c
>index 7880220..22ee7af 100644
>--- a/datapath-windows/ovsext/User.c
>+++ b/datapath-windows/ovsext/User.c
>@@ -465,6 +465,11 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
> ndisStatus = OvsExtractFlow(pNbl, execute->inPort, &key, &layers,
>  tempTunKey.tunKey.dst == 0 ? NULL : &tempTunKey.tunKey);
> 
>+if (ndisStatus != NDIS_STATUS_SUCCESS) {
>+/* Invalid network header */
>+goto dropit;
>+}
>+
> ctx = (POVS_BUFFER_CONTEXT)NET_BUFFER_LIST_CONTEXT_DATA_START(pNbl);
> ctx->mru = execute->mru;
> 
>diff --git a/datapath-windows/ovsext/Vxlan.c b/datapath-windows/ovsext/Vxlan.c
>index 427f31c..f66a7e5 100644
>--- a/datapath-windows/ovsext/Vxlan.c
>+++ b/datapath-windows/ovsext/Vxlan.c
>@@ -489,7 +489,8 @@ OvsSlowPathDecapVxlan(c

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

[Sairam Venugopal]

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 
---
 datapath-windows/ovsext/Conntrack.c | 59 +
 1 file changed, 27 insertions(+), 32 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 68ed395..bf9c4f4 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -214,9 +214,18 @@ 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;
+
+*entryCreated = FALSE;
+state |= OVS_CS_F_NEW;
+
+parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
+if (parentEntry != NULL) {
+state |= OVS_CS_F_RELATED;
+}
+
 switch (ipProto)
 {
 case IPPROTO_TCP:
@@ -228,23 +237,8 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
 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;
-}
-
-/* Set parent entry for related FTP connections */
-entry->parent = parentEntry;
-
-*entryCreated = TRUE;
 }
 break;
 }
@@ -257,14 +251,8 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
 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;
 }
 break;
 }
@@ -273,11 +261,6 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
 state |= OVS_CS_F_NEW;
 if (commit) {
 entry = OvsConntrackCreateOtherEntry(currentTime);
-if (entry) {
-/* Default UDP related to NULL until TFTP is supported */
-entry->parent = NULL;
-}
-*entryCreated = TRUE;
 }
 break;
 }
@@ -285,12 +268,24 @@ OvsCtEntryCreate(OvsForwardingContext *fwdCtx,
 goto invalid;
 }
 
-if (commit && !entry) {
-return NULL;
-}
-if (entry && !OvsCtAddEntry(entry, ctx, natInfo, currentTime)) {
-return NULL;
+if (commit) {
+if (entry) {
+entry->parent = parentEntry;
+if (OvsCtAddEntry(entry, ctx, natInfo, currentTime)) {
+*entryCreated = TRUE;
+} else {
+/* Unable to add entry to the list */
+OvsFreeMemoryWithTag(entry, OVS_CT_POOL_TAG);
+state = OVS_CS_F_INVALID;
+entry = NULL;
+}
+} else {
+/* OvsAllocateMemoryWithTag returned NULL; treat as invalid */
+state = OVS_CS_F_INVALID;
+}
 }
+
+
 OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
 return entry;
 invalid:
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: add open flow defines to Types.h

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 6/20/17, 7:59 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Serdean"  wrote:

>Commit 
>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_commit_81765c00a13882acaaf652df23d7fa76fc3ad743&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=FwVAgiHCHUQ1_ADPYLo1PW-5yRYdrYY-HfoyGFNHsqE&s=HGRjCYv0jqlMIueML9Dg5QDWcQ2OqI86XoKaz_WfBNM&e=
> 
>introduced openflow types to the include interface.
>
>The Windows datapath needs to be aware of the new types included in the
>common interface.
>
>Fixes broken build on Windows.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> datapath-windows/ovsext/Types.h | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Types.h b/datapath-windows/ovsext/Types.h
>index 022c65b..4da335a 100644
>--- a/datapath-windows/ovsext/Types.h
>+++ b/datapath-windows/ovsext/Types.h
>@@ -42,6 +42,10 @@ typedef UINT16 BE16;
> typedef UINT32 BE32;
> typedef UINT64 BE64;
> 
>+typedef uint32_t ofp_port_t;
>+typedef uint32_t odp_port_t;
>+typedef uint32_t ofp11_port_t;
>+
> #define ETH_ALEN 6
> 
> #define SIZE_MAX MAXUINT32
>-- 
>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&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=FwVAgiHCHUQ1_ADPYLo1PW-5yRYdrYY-HfoyGFNHsqE&s=R-wCzL3qf_xeTG-HGN_-c4PFaSnylgtjlbAsU18VvEs&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] datapath-windows: Add validations in fragmentation module

[Sairam Venugopal]

Thanks for adding in the CVE.

Acked-by: Sairam Venugopal 





On 6/9/17, 7:54 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>- Minimum valid fragment size is 400 bytes, any fragment smaller
>is likely to be intentionally crafted (CVE-2000-0305).
>
>- Validate maximum length of an Ip datagram
>
>- Added counters to keep track of number of fragments for a given
>Ip datagram.
>
>Signed-off-by: Anand Kumar 
>Acked-by: Alin Gabriel Serdean 
>---
>v1->v2: Update commmit message to add (CVE-2000-0305) vulnerability
>---
> datapath-windows/ovsext/Actions.c|  2 +-
> datapath-windows/ovsext/IpFragment.c | 41 +---
> datapath-windows/ovsext/IpFragment.h |  2 ++
> 3 files changed, 32 insertions(+), 13 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index c3f0362..4eeaab3 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -2030,7 +2030,7 @@ OvsDoExecuteActions(POVS_SWITCH_CONTEXT switchContext,
> if (status != NDIS_STATUS_SUCCESS) {
> /* Pending NBLs are consumed by Defragmentation. */
> if (status != NDIS_STATUS_PENDING) {
>-OVS_LOG_ERROR("CT Action failed");
>+OVS_LOG_ERROR("CT Action failed status = %lu", status);
> dropReason = L"OVS-conntrack action failed";
> } else {
> /* We added a new pending NBL to be consumed later.
>diff --git a/datapath-windows/ovsext/IpFragment.c 
>b/datapath-windows/ovsext/IpFragment.c
>index 0874cb9..e601a15 100644
>--- a/datapath-windows/ovsext/IpFragment.c
>+++ b/datapath-windows/ovsext/IpFragment.c
>@@ -25,6 +25,10 @@
> #undef OVS_DBG_MOD
> #endif
> #define OVS_DBG_MOD OVS_DBG_IPFRAG
>+/* Based on MIN_FRAGMENT_SIZE.*/
>+#define MAX_FRAGMENTS 164
>+#define MIN_FRAGMENT_SIZE 400
>+#define MAX_IPDATAGRAM_SIZE 65535
> 
> /* Function declarations */
> static VOID OvsIpFragmentEntryCleaner(PVOID data);
>@@ -146,8 +150,9 @@ OvsIpv4Reassemble(POVS_SWITCH_CONTEXT switchContext,
> IPHdr *ipHdr, *newIpHdr;
> CHAR *ethBuf[sizeof(EthHdr)];
> CHAR *packetBuf;
>-UINT16 ipHdrLen, packetLen, packetHeader;
>+UINT16 ipHdrLen, packetHeader;
> POVS_FRAGMENT_LIST head = NULL;
>+UINT32 packetLen;
> 
> curNb = NET_BUFFER_LIST_FIRST_NB(*curNbl);
> ASSERT(NET_BUFFER_NEXT_NB(curNb) == NULL);
>@@ -161,7 +166,10 @@ OvsIpv4Reassemble(POVS_SWITCH_CONTEXT switchContext,
> if (ipHdr == NULL) {
> return NDIS_STATUS_INVALID_PACKET;
> }
>-ipHdrLen = (UINT16)(ipHdr->ihl * 4);
>+ipHdrLen = ipHdr->ihl * 4;
>+if (ipHdrLen + entry->totalLen > MAX_IPDATAGRAM_SIZE) {
>+return NDIS_STATUS_INVALID_LENGTH;
>+}
> packetLen = ETH_HEADER_LENGTH + ipHdrLen + entry->totalLen;
> packetBuf = (CHAR*)OvsAllocateMemoryWithTag(packetLen,
> OVS_IPFRAG_POOL_TAG);
>@@ -185,7 +193,10 @@ OvsIpv4Reassemble(POVS_SWITCH_CONTEXT switchContext,
> packetHeader = ETH_HEADER_LENGTH + ipHdrLen;
> head = entry->head;
> while (head) {
>-ASSERT((packetHeader + head->offset) <= packetLen);
>+if ((UINT32)(packetHeader + head->offset) > packetLen) {
>+status = NDIS_STATUS_INVALID_DATA;
>+goto cleanup;
>+}
> NdisMoveMemory(packetBuf + packetHeader + head->offset,
>head->pbuff, head->len);
> head = head->next;
>@@ -197,10 +208,6 @@ OvsIpv4Reassemble(POVS_SWITCH_CONTEXT switchContext,
> status = NDIS_STATUS_RESOURCES;
> }
> 
>-OvsFreeMemoryWithTag(packetBuf, OVS_IPFRAG_POOL_TAG);
>-/* Timeout the entry so that clean up thread deletes it .*/
>-entry->expiration -= IPFRAG_ENTRY_TIMEOUT;
>-
> /* Complete the fragment NBL */
> ctx = (POVS_BUFFER_CONTEXT)NET_BUFFER_LIST_CONTEXT_DATA_START(*curNbl);
> if (ctx->flags & OVS_BUFFER_NEED_COMPLETE) {
>@@ -214,6 +221,9 @@ OvsIpv4Reassemble(POVS_SWITCH_CONTEXT switchContext,
> ctx = (POVS_BUFFER_CONTEXT)NET_BUFFER_LIST_CONTEXT_DATA_START(*newNbl);
> ctx->mru = entry->mru;
> *curNbl = *newNbl;
>+cleanup:
>+OvsFreeMemoryWithTag(packetBuf, OVS_IPFRAG_POOL_TAG);
>+entry->markedForDelete = TRUE;
> return status;
> }
> /*
>@@ -259,12 +269,15 @@ OvsProcessIpv4Fragment(POVS_SWITCH_CONTEXT switchContext,
> if (ipHdr == NULL) {
> return NDIS_STATUS_INVALID_PACKET;
> }
>-ipHdrLen = (UINT16)(ipHd

Re: [ovs-dev] [PATCH] datapath-windows: Add support for UPDATE events in Conntrack

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 6/12/17, 10:21 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand 
Kumar"  
wrote:

>  - Parse netlink ct attr OVS_CT_ATTR_EVENTMASK
>  - Add a new CT_EVENT_TYPE, OVS_EVENT_CT_UPDATE which is triggered
>only when CT_ATTR_EVENTMASK is set for MARK and LABEL updates.
>
>Signed-off-by: Anand Kumar 
>---
> datapath-windows/include/OvsDpInterfaceCtExt.h |  1 +
> datapath-windows/ovsext/Conntrack.c| 27 --
> datapath-windows/ovsext/Datapath.c |  3 +++
> datapath-windows/ovsext/DpInternal.h   |  3 ++-
> datapath-windows/ovsext/Event.c|  3 ++-
> lib/netlink-conntrack.c|  3 +++
> 6 files changed, 36 insertions(+), 4 deletions(-)
>
>diff --git a/datapath-windows/include/OvsDpInterfaceCtExt.h 
>b/datapath-windows/include/OvsDpInterfaceCtExt.h
>index 3b94778..45e7ff8 100644
>--- a/datapath-windows/include/OvsDpInterfaceCtExt.h
>+++ b/datapath-windows/include/OvsDpInterfaceCtExt.h
>@@ -154,6 +154,7 @@ enum cntl_msg_types {
> IPCTNL_MSG_CT_GET_STATS,
> IPCTNL_MSG_CT_GET_DYING,
> IPCTNL_MSG_CT_GET_UNCONFIRMED,
>+IPCTNL_MSG_CT_UPDATE,
> IPCTNL_MSG_MAX
> };
> 
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 68ed395..ab53993 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -698,9 +698,11 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
>   MD_MARK *mark,
>   MD_LABELS *labels,
>   PCHAR helper,
>-  PNAT_ACTION_INFO natInfo)
>+  PNAT_ACTION_INFO natInfo,
>+  BOOLEAN postUpdateEvent)
> {
> NDIS_STATUS status = NDIS_STATUS_SUCCESS;
>+BOOLEAN sendUpdateEvent = FALSE;
> POVS_CT_ENTRY entry = NULL;
> PNET_BUFFER_LIST curNbl = fwdCtx->curNbl;
> OvsConntrackKeyLookupCtx ctx = { 0 };
>@@ -752,10 +754,16 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> }
> 
> if (entry && mark) {
>+if (!entryCreated) {
>+sendUpdateEvent = TRUE;
>+}
> OvsConntrackSetMark(key, entry, mark->value, mark->mask);
> }
> 
> if (entry && labels) {
>+if (!entryCreated) {
>+sendUpdateEvent = TRUE;
>+}
> OvsConntrackSetLabels(key, entry, &labels->value, &labels->mask);
> }
> 
>@@ -790,6 +798,9 @@ OvsCtExecute_(OvsForwardingContext *fwdCtx,
> if (entryCreated && entry) {
> OvsPostCtEventEntry(entry, OVS_EVENT_CT_NEW);
> }
>+if (postUpdateEvent && sendUpdateEvent) {
>+OvsPostCtEventEntry(entry, OVS_EVENT_CT_UPDATE);
>+}
> 
> NdisReleaseRWLock(ovsConntrackLockObj, &lockState);
> 
>@@ -811,7 +822,9 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
> PNL_ATTR ctAttr;
> BOOLEAN commit = FALSE;
> BOOLEAN force = FALSE;
>+BOOLEAN postUpdateEvent = FALSE;
> UINT16 zone = 0;
>+UINT32 eventmask = 0;
> MD_MARK *mark = NULL;
> MD_LABELS *labels = NULL;
> PCHAR helper = NULL;
>@@ -932,9 +945,17 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
> /* Force implicitly means commit */
> commit = TRUE;
> }
>+ctAttr = NlAttrFindNested(a, OVS_CT_ATTR_EVENTMASK);
>+if (ctAttr) {
>+eventmask = NlAttrGetU32(ctAttr);
>+/* Only mark and label updates are supported. */
>+if (eventmask & (1 << IPCT_MARK | 1 << IPCT_LABEL))
>+postUpdateEvent = TRUE;
>+}
> /* If newNbl is not allocated, use the current Nbl*/
> status = OvsCtExecute_(fwdCtx, key, layers,
>-   commit, force, zone, mark, labels, helper, 
>&natActionInfo);
>+   commit, force, zone, mark, labels, helper, 
>&natActionInfo,
>+   postUpdateEvent);
> return status;
> }
> 
>@@ -1290,6 +1311,8 @@ OvsCreateNlMsgFromCtEntry(POVS_CT_ENTRY entry,
> nlmsgType = (UINT16) (NFNL_SUBSYS_CTNETLINK << 8 | IPCTNL_MSG_CT_NEW);
> } else if (eventType == OVS_EVENT_CT_DELETE) {
> nlmsgType = (UINT16) (NFNL_SUBSYS_CTNETLINK << 8 | 
> IPCTNL_MSG_CT_DELETE);
>+} else if (eventType == OVS_EVENT_CT_UPDATE) {
>+nlmsgType = (UINT16) (NFNL_SUBSYS_CTNETLINK << 8 | 
>IPCTNL_MSG_CT_UPDATE);
> } else {
> return STATUS_INVALID_PARAMETER;
> }
>diff --git a/datapath-windows/ovsext/Datapath.c 
>b/datapath-windows/ovsext/Datapath.c
>index 83d996e..10412a1 100644
>--- a/datapath-windows/ovsext

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

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 6/14/17, 4:01 PM, "ovs-dev-boun...@openvswitch.org on behalf of Nithin Raju" 
 wrote:

>Couple of minor fixes that got flagged with a static checker.
>
>Signed-off-by: Nithin Raju 
>---
> 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(&natActionInfo.minAddr,
>-   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(&natActionInfo.maxAddr,
>-   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://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=Gcu2sMIlG_kV-8opOt_iKbhfjzkPO9cYR2j-OsbKWtg&s=7_Bz1HQYeFWidKM6e_f97gb2MHM3ySqlpHx02X4XDtY&e=
> 
___
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

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 6/15/17, 12:46 PM, "ovs-dev-boun...@openvswitch.org on behalf of Shashank 
Ram"  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 
>---
> datapath-windows/ovsext/Conntrack.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.h 
>b/datapath-windows/ovsext/Conntrack.h
>index fcdd96e..04ca299 100644
>--- a/datapath-windows/ovsext/Conntrack.h
>+++ b/datapath-windows/ovsext/Conntrack.h
>@@ -69,14 +69,14 @@ typedef struct MD_LABELS {
> struct ovs_key_ct_labels mask;
> } MD_LABELS;
> 
>-typedef enum NAT_ACTION {
>+typedef enum _NAT_ACTION {
> NAT_ACTION_NONE = 0,
> NAT_ACTION_REVERSE = 1 << 0,
> NAT_ACTION_SRC = 1 << 1,
> NAT_ACTION_SRC_PORT = 1 << 2,
> NAT_ACTION_DST = 1 << 3,
> NAT_ACTION_DST_PORT = 1 << 4,
>-};
>+} NAT_ACTION;
> 
> typedef struct _OVS_CT_KEY {
> struct ct_endpoint src;
>-- 
>2.9.3.windows.2
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=3Dz3HHrBXQtG1qmIwlchkCobPqUjawGcRt9P4TMS6MA&s=G14YPFl6TG_Nkp3lTLYzBJsy2SiG9meKRUs8j-taX3w&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] datapath-windows: Zero initialize Conntrack-ICMP entry

[Sairam Venugopal]

Set conntrack-icmp entry to {0}. Add some compile time asserts to ensure
that conn_* struct's first member is OVS_CT_ENTRY.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack-icmp.c  | 3 ++-
 datapath-windows/ovsext/Conntrack-other.c | 1 +
 datapath-windows/ovsext/Conntrack-tcp.c   | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/datapath-windows/ovsext/Conntrack-icmp.c 
b/datapath-windows/ovsext/Conntrack-icmp.c
index b1b6043..4da0665 100644
--- a/datapath-windows/ovsext/Conntrack-icmp.c
+++ b/datapath-windows/ovsext/Conntrack-icmp.c
@@ -27,6 +27,7 @@ struct conn_icmp {
 struct OVS_CT_ENTRY up;
 enum icmp_state state;
 };
+C_ASSERT(offsetof(struct conn_icmp, up) == 0);
 
 static const enum ct_timeout icmp_timeouts[] = {
 [ICMPS_FIRST] = 60 * CT_INTERVAL_SEC,
@@ -78,7 +79,7 @@ OvsConntrackCreateIcmpEntry(UINT64 now)
 if (!conn) {
 return NULL;
 }
-
+conn->up = (OVS_CT_ENTRY) {0};
 conn->state = ICMPS_FIRST;
 
 OvsConntrackUpdateExpiration(&conn->up, now,
diff --git a/datapath-windows/ovsext/Conntrack-other.c 
b/datapath-windows/ovsext/Conntrack-other.c
index 6c68ba8..962cc8a 100644
--- a/datapath-windows/ovsext/Conntrack-other.c
+++ b/datapath-windows/ovsext/Conntrack-other.c
@@ -27,6 +27,7 @@ struct conn_other {
 struct OVS_CT_ENTRY up;
 enum other_state state;
 };
+C_ASSERT(offsetof(struct conn_other, up) == 0);
 
 static const long long other_timeouts[] = {
 [OTHERS_FIRST] = 60 * CT_INTERVAL_SEC,
diff --git a/datapath-windows/ovsext/Conntrack-tcp.c 
b/datapath-windows/ovsext/Conntrack-tcp.c
index f533b93..f8e85a2 100644
--- a/datapath-windows/ovsext/Conntrack-tcp.c
+++ b/datapath-windows/ovsext/Conntrack-tcp.c
@@ -51,6 +51,7 @@ struct conn_tcp {
 struct OVS_CT_ENTRY up;
 struct tcp_peer peer[2];
 };
+C_ASSERT(offsetof(struct conn_tcp, up) == 0);
 
 enum {
 TCPOPT_EOL,
-- 
2.9.0.windows.1

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

[ovs-dev] [PATCH v2] datapath-windows: Add original conntrack tuple to FlowKey

[Sairam Venugopal]

Add the original tuple to Flow Key. In case of ICMP and UDP, default the
parent entry to NULL until related connections is supported.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack.c  | 35 -
 datapath-windows/ovsext/DpInternal.h |  1 +
 datapath-windows/ovsext/Flow.c   | 50 ++--
 3 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index dce0c1b..609ae5a 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -198,7 +198,7 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 }
 
 state |= OVS_CS_F_NEW;
-POVS_CT_ENTRY parentEntry = NULL;
+POVS_CT_ENTRY parentEntry;
 parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
 if (parentEntry != NULL) {
 state |= OVS_CS_F_RELATED;
@@ -209,10 +209,10 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 if (!entry) {
 return NULL;
 }
-/* If this is related entry, then update parent */
-if (parentEntry != NULL) {
-entry->parent = parentEntry;
-}
+
+/* Set parent entry for related FTP connections */
+entry->parent = parentEntry;
+
 OvsCtAddEntry(entry, ctx, currentTime);
 *entryCreated = TRUE;
 }
@@ -235,6 +235,9 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 if (!entry) {
 return NULL;
 }
+
+/* XXX Add support for ICMP-Related */
+entry->parent = NULL;
 OvsCtAddEntry(entry, ctx, currentTime);
 *entryCreated = TRUE;
 }
@@ -250,6 +253,9 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 if (!entry) {
 return NULL;
 }
+
+/* Default UDP related to NULL until TFTP is supported */
+entry->parent = NULL;
 OvsCtAddEntry(entry, ctx, currentTime);
 *entryCreated = TRUE;
 }
@@ -586,8 +592,8 @@ OvsProcessConntrackEntry(PNET_BUFFER_LIST curNbl,
 } else {
 POVS_CT_ENTRY parentEntry;
 parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
+entry->parent = parentEntry;
 if (parentEntry != NULL) {
-entry->parent = parentEntry;
 state |= OVS_CS_F_RELATED;
 }
 }
@@ -702,6 +708,23 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
 }
 }
 
+/* Add original tuple information to flow Key */
+if (entry && entry->key.dl_type == ntohs(ETH_TYPE_IPV4)) {
+OVS_CT_KEY *ctKey;
+if (entry->parent != NULL) {
+POVS_CT_ENTRY parent = entry->parent;
+ctKey = &parent->key;
+} else {
+ctKey = &entry->key;
+}
+
+key->ct.tuple_ipv4.ipv4_src = ctKey->src.addr.ipv4_aligned;
+key->ct.tuple_ipv4.ipv4_dst = ctKey->dst.addr.ipv4_aligned;
+key->ct.tuple_ipv4.src_port = ctKey->src.port;
+key->ct.tuple_ipv4.dst_port = ctKey->dst.port;
+key->ct.tuple_ipv4.ipv4_proto = ctKey->nw_proto;
+}
+
 if (entryCreated && entry) {
 OvsPostCtEventEntry(entry, OVS_EVENT_CT_NEW);
 }
diff --git a/datapath-windows/ovsext/DpInternal.h 
b/datapath-windows/ovsext/DpInternal.h
index 9d1a783..743891c 100644
--- a/datapath-windows/ovsext/DpInternal.h
+++ b/datapath-windows/ovsext/DpInternal.h
@@ -199,6 +199,7 @@ typedef __declspec(align(8)) struct OvsFlowKey {
 UINT32 mark;
 UINT32 state;
 struct ovs_key_ct_labels labels;
+struct ovs_key_ct_tuple_ipv4 tuple_ipv4;
 } ct;/* Connection Tracking Flags */
 } OvsFlowKey;
 
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index 96ff9fa..80f5676 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -180,6 +180,10 @@ const NL_POLICY nlFlowKeyPolicy[] = {
 [OVS_KEY_ATTR_CT_LABELS] = {.type = NL_A_UNSPEC,
 .minLen = sizeof(struct ovs_key_ct_labels),
 .maxLen = sizeof(struct ovs_key_ct_labels),
+.optional = TRUE},
+[OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4] = {.type = NL_A_UNSPEC,
+.minLen = sizeof(struct ovs_key_ct_tuple_ipv4),
+.maxLen = sizeof(struct ovs_key_ct_tuple_ipv4),
 .optional = TRUE}
 };
 const UINT32 nlFlowKeyPolicyLen = ARRAY_SIZE(nlFlowKeyPolicy);
@@ -887,6 +891,12 @@ MapFlowKeyToNlKey(PNL_BUFFER nlBuf,
   

[ovs-dev] [PATCH] datapath-windows: Add original conntrack tuple to FlowKey

[Sairam Venugopal]

Add the original tuple to Flow Key. In case of ICMP and UDP, default the
parent entry to NULL until related connections is supported.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack.c  | 35 -
 datapath-windows/ovsext/DpInternal.h |  1 +
 datapath-windows/ovsext/Flow.c   | 50 ++--
 3 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index dce0c1b..ab5dfad 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -198,7 +198,7 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 }
 
 state |= OVS_CS_F_NEW;
-POVS_CT_ENTRY parentEntry = NULL;
+POVS_CT_ENTRY parentEntry;
 parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
 if (parentEntry != NULL) {
 state |= OVS_CS_F_RELATED;
@@ -209,10 +209,10 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 if (!entry) {
 return NULL;
 }
-/* If this is related entry, then update parent */
-if (parentEntry != NULL) {
-entry->parent = parentEntry;
-}
+
+/* Update the parent entry */
+entry->parent = parentEntry;
+
 OvsCtAddEntry(entry, ctx, currentTime);
 *entryCreated = TRUE;
 }
@@ -235,6 +235,9 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 if (!entry) {
 return NULL;
 }
+
+/* XXX Add support for ICMP-Related */
+entry->parent = NULL;
 OvsCtAddEntry(entry, ctx, currentTime);
 *entryCreated = TRUE;
 }
@@ -250,6 +253,9 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 if (!entry) {
 return NULL;
 }
+
+/* Default this to NULL */
+entry->parent = NULL;
 OvsCtAddEntry(entry, ctx, currentTime);
 *entryCreated = TRUE;
 }
@@ -586,8 +592,8 @@ OvsProcessConntrackEntry(PNET_BUFFER_LIST curNbl,
 } else {
 POVS_CT_ENTRY parentEntry;
 parentEntry = OvsCtRelatedLookup(ctx->key, currentTime);
+entry->parent = parentEntry;
 if (parentEntry != NULL) {
-entry->parent = parentEntry;
 state |= OVS_CS_F_RELATED;
 }
 }
@@ -702,6 +708,23 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
 }
 }
 
+/* Add original tuple information to flow Key */
+if (entry && entry->key.dl_type == ntohs(ETH_TYPE_IPV4)) {
+OVS_CT_KEY *ctKey;
+if (entry->parent != NULL) {
+POVS_CT_ENTRY parent = entry->parent;
+ctKey = &parent->key;
+} else {
+ctKey = &entry->key;
+}
+
+key->ct.tuple_ipv4.ipv4_src = ctKey->src.addr.ipv4_aligned;
+key->ct.tuple_ipv4.ipv4_dst = ctKey->dst.addr.ipv4_aligned;
+key->ct.tuple_ipv4.src_port = ctKey->src.port;
+key->ct.tuple_ipv4.dst_port = ctKey->dst.port;
+key->ct.tuple_ipv4.ipv4_proto = ctKey->nw_proto;
+}
+
 if (entryCreated && entry) {
 OvsPostCtEventEntry(entry, OVS_EVENT_CT_NEW);
 }
diff --git a/datapath-windows/ovsext/DpInternal.h 
b/datapath-windows/ovsext/DpInternal.h
index 9d1a783..743891c 100644
--- a/datapath-windows/ovsext/DpInternal.h
+++ b/datapath-windows/ovsext/DpInternal.h
@@ -199,6 +199,7 @@ typedef __declspec(align(8)) struct OvsFlowKey {
 UINT32 mark;
 UINT32 state;
 struct ovs_key_ct_labels labels;
+struct ovs_key_ct_tuple_ipv4 tuple_ipv4;
 } ct;/* Connection Tracking Flags */
 } OvsFlowKey;
 
diff --git a/datapath-windows/ovsext/Flow.c b/datapath-windows/ovsext/Flow.c
index 96ff9fa..80f5676 100644
--- a/datapath-windows/ovsext/Flow.c
+++ b/datapath-windows/ovsext/Flow.c
@@ -180,6 +180,10 @@ const NL_POLICY nlFlowKeyPolicy[] = {
 [OVS_KEY_ATTR_CT_LABELS] = {.type = NL_A_UNSPEC,
 .minLen = sizeof(struct ovs_key_ct_labels),
 .maxLen = sizeof(struct ovs_key_ct_labels),
+.optional = TRUE},
+[OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4] = {.type = NL_A_UNSPEC,
+.minLen = sizeof(struct ovs_key_ct_tuple_ipv4),
+.maxLen = sizeof(struct ovs_key_ct_tuple_ipv4),
 .optional = TRUE}
 };
 const UINT32 nlFlowKeyPolicyLen = ARRAY_SIZE(nlFlowKeyPolicy);
@@ -887,6 +891,12 @@ MapFlowKeyToNlKey(PNL_BUFFER nlBuf,
 rc = STATUS_UNSUCCESSFUL;
 goto done;
 }
+if (!N

[ovs-dev] [PATCH] ofproto-dpif: Include EthType in ct_orig_tuple feature probe

[Sairam Venugopal]

Set flow->dl_type to either ETH_TYPE_IP or ETH_TYPE_IPV6 when probing for
ct_orig_tuple feature support. This can be expanded later on to check for
both IPv4 and IPv6 support.

Signed-off-by: Sairam Venugopal 
---
 ofproto/ofproto-dpif.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index dc5f004..ba9e1ea 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -1316,7 +1316,7 @@ check_ct_eventmask(struct dpif_backer *backer)
 return !error;
 }
 
-#define CHECK_FEATURE__(NAME, SUPPORT, FIELD, VALUE)\
+#define CHECK_FEATURE__(NAME, SUPPORT, FIELD, VALUE, ETHTYPE)   \
 static bool \
 check_##NAME(struct dpif_backer *backer)\
 {   \
@@ -1333,6 +1333,7 @@ check_##NAME(struct dpif_backer *backer)  
  \
 \
 memset(&flow, 0, sizeof flow);  \
 flow.FIELD = VALUE; \
+flow.dl_type = htons(ETHTYPE);  \
 \
 ofpbuf_use_stack(&key, &keybuf, sizeof keybuf); \
 odp_flow_key_from_flow(&odp_parms, &key);   \
@@ -1347,14 +1348,16 @@ check_##NAME(struct dpif_backer *backer)
\
 \
 return enable;  \
 }
-#define CHECK_FEATURE(FIELD) CHECK_FEATURE__(FIELD, FIELD, FIELD, 1)
+#define CHECK_FEATURE(FIELD) CHECK_FEATURE__(FIELD, FIELD, FIELD, 1, \
+ ETH_TYPE_IP)
 
 CHECK_FEATURE(ct_state)
 CHECK_FEATURE(ct_zone)
 CHECK_FEATURE(ct_mark)
-CHECK_FEATURE__(ct_label, ct_label, ct_label.u64.lo, 1)
-CHECK_FEATURE__(ct_state_nat, ct_state, ct_state, CS_TRACKED|CS_SRC_NAT)
-CHECK_FEATURE__(ct_orig_tuple, ct_orig_tuple, ct_nw_proto, 1)
+CHECK_FEATURE__(ct_label, ct_label, ct_label.u64.lo, 1, ETH_TYPE_IP)
+CHECK_FEATURE__(ct_state_nat, ct_state, ct_state, \
+CS_TRACKED|CS_SRC_NAT, ETH_TYPE_IP)
+CHECK_FEATURE__(ct_orig_tuple, ct_orig_tuple, ct_nw_proto, 1, ETH_TYPE_IP)
 
 #undef CHECK_FEATURE
 #undef CHECK_FEATURE__
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] lib Windows: Use xmalloc instead of malloc

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 5/19/17, 2:38 PM, "ovs-dev-boun...@openvswitch.org on behalf of Shashank 
Ram"  wrote:

>xmalloc checks if the size is valid before allocating
>memory.
>
>Signed-off-by: Shashank Ram 
>---
> lib/netdev-windows.c | 4 ++--
> lib/wmi.c| 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/lib/netdev-windows.c b/lib/netdev-windows.c
>index 375cb32..b4b39e9 100644
>--- a/lib/netdev-windows.c
>+++ b/lib/netdev-windows.c
>@@ -394,7 +394,7 @@ netdev_windows_arp_lookup(const struct netdev *netdev,
> return ENXIO;
> }
>
>-arp_table = (MIB_IPNETTABLE *) malloc(buffer_length);
>+arp_table = (MIB_IPNETTABLE *) xmalloc(buffer_length);
>
> if (arp_table == NULL) {
> VLOG_ERR("Could not allocate memory for all the interfaces");
>@@ -443,7 +443,7 @@ netdev_windows_get_next_hop(const struct in_addr *host,
> return ENXIO;
> }
>
>-all_addr = (IP_ADAPTER_ADDRESSES *) malloc(buffer_length);
>+all_addr = (IP_ADAPTER_ADDRESSES *) xmalloc(buffer_length);
>
> if (all_addr == NULL) {
> VLOG_ERR("Could not allocate memory for all the interfaces");
>diff --git a/lib/wmi.c b/lib/wmi.c
>index dba8022..b560a7e 100644
>--- a/lib/wmi.c
>+++ b/lib/wmi.c
>@@ -406,7 +406,7 @@ delete_wmi_port(char *name)
> wchar_t internal_port_query[WMI_QUERY_COUNT] = L"SELECT * from "
> L"Msvm_EthernetPortAllocationSettingData  WHERE ElementName = \"" ;
>
>-wide_name = malloc((strlen(name) + 1) * sizeof(wchar_t));
>+wide_name = xmalloc((strlen(name) + 1) * sizeof(wchar_t));
> if (wide_name == NULL) {
> VLOG_WARN("Could not allocate memory for wide string");
> retval = false;
>@@ -693,7 +693,7 @@ create_wmi_port(char *name) {
> wchar_t internal_port_query[WMI_QUERY_COUNT] = L"SELECT * FROM "
> L"Msvm_InternalEthernetPort WHERE ElementName = \"";
>
>-wide_name = malloc((strlen(name) + 1) * sizeof(wchar_t));
>+wide_name = xmalloc((strlen(name) + 1) * sizeof(wchar_t));
> if (wide_name == NULL) {
> VLOG_WARN("Could not allocate memory for wide string");
> retval = false;
>--
>2.9.3.windows.2
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=A_SrOn7pygG6mPCwmqq6YGTrmTn8yCfvuSryqv25tqY&s=x4TwpFwUmcevmXKYYFaWo8XUR-0DNGsADZbfW6I_DU4&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v7 3/4] datapath-windows: NAT integration with conntrack

[Sairam Venugopal]

Please find my comments inline.

Thanks,
Sairam




On 5/16/17, 5:34 PM, "Yin Lin"  wrote:

>See inline comments for reply.
>
>-Original Message-
>From: Sairam Venugopal 
>Sent: Tuesday, May 16, 2017 5:09 PM
>To: Yin Lin ; d...@openvswitch.org
>Subject: Re: [ovs-dev] [PATCH v7 3/4] datapath-windows: NAT integration with 
>conntrack
>
>Please find my comments inline.
>
>Thanks,
>Sairam
>
>
>
>
>On 5/9/17, 3:59 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
> wrote:
>
>>This patch integrates NAT module with existing conntrack module. NAT
>>action is now supported.
>>
>>Signed-off-by: Yin Lin 
>>---
>> datapath-windows/automake.mk   |   4 +-
>> datapath-windows/ovsext/Actions.c  | 119 -
>> datapath-windows/ovsext/Actions.h  |  20 
>> datapath-windows/ovsext/Conntrack.c| 187 
>> +
>> datapath-windows/ovsext/Conntrack.h|  25 +++--
>> datapath-windows/ovsext/ovsext.vcxproj |   2 +
>> 6 files changed, 274 insertions(+), 83 deletions(-)
>>
>>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>>index 7177630..f1632cc 100644
>>--- a/datapath-windows/automake.mk
>>+++ b/datapath-windows/automake.mk
>>@@ -16,9 +16,9 @@ EXTRA_DIST += \
>>  datapath-windows/ovsext/Conntrack-icmp.c \
>>  datapath-windows/ovsext/Conntrack-other.c \
>>  datapath-windows/ovsext/Conntrack-related.c \
>>-datapath-windows/ovsext/Conntrack-nat.c \
>>+ datapath-windows/ovsext/Conntrack-nat.c \
>>  datapath-windows/ovsext/Conntrack-tcp.c \
>>-datapath-windows/ovsext/Conntrack-nat.h \
>>+ datapath-windows/ovsext/Conntrack-nat.h \
>>  datapath-windows/ovsext/Conntrack.c \
>>  datapath-windows/ovsext/Conntrack.h \
>>  datapath-windows/ovsext/Datapath.c \
>>diff --git a/datapath-windows/ovsext/Actions.c 
>>b/datapath-windows/ovsext/Actions.c
>>index e2eae9a..a808d2c 100644
>>--- a/datapath-windows/ovsext/Actions.c
>>+++ b/datapath-windows/ovsext/Actions.c
>>@@ -1380,7 +1380,7 @@ PUINT8 OvsGetHeaderBySize(OvsForwardingContext 
>>*ovsFwdCtx,
>>  *  based on the specified key.
>>  
>> *
>>  */
>>-static __inline NDIS_STATUS
>>+NDIS_STATUS
>> OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
>>   const struct ovs_key_udp *udpAttr)
>> {
>>@@ -1427,7 +1427,7 @@ OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
>>  *  based on the specified key.
>>  
>> *
>>  */
>>-static __inline NDIS_STATUS
>>+NDIS_STATUS
>> OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
>>   const struct ovs_key_tcp *tcpAttr)
>> {
>>@@ -1465,12 +1465,125 @@ OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
>> 
>> /*
>>  
>> *
>>+ * OvsUpdateAddressAndPort --
>>+ *  Updates the source/destination IP and port fields in
>>+ *  ovsFwdCtx.curNbl inline based on the specified key.
>>+ 
>>*
>>+ */
>>+NDIS_STATUS
>>+OvsUpdateAddressAndPort(OvsForwardingContext *ovsFwdCtx,
>>+UINT32 newAddr, UINT16 newPort,
>>+BOOLEAN isSource, BOOLEAN isTx)
>>+{
>>+PUINT8 bufferStart;
>>+UINT32 hdrSize;
>>+OVS_PACKET_HDR_INFO *layers = &ovsFwdCtx->layers;
>>+IPHdr *ipHdr;
>>+TCPHdr *tcpHdr = NULL;
>>+UDPHdr *udpHdr = NULL;
>>+UINT32 *addrField = NULL;
>>+UINT16 *portField = NULL;
>>+UINT16 *checkField = NULL;
>>+BOOLEAN l4Offload = FALSE;
>>+NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
>>+
>>+ASSERT(layers->value != 0);
>>+
>>+if (layers->isTcp || layers->isUdp) {
>>+hdrSize = layers->l4Offset +
>>+  layers->isTcp ? sizeof (*tcpHdr) : sizeof (*udpHdr);
>>+} else {
>>+hdrSize = layers->l3Offset + sizeof (*ipHdr);
>>+}
>>+
>>+bufferStart = OvsGetHeaderBySize(ovsFwdCtx, hdrSize);
>>+if (!bufferStart) {
>>+return NDIS_STATUS_RESOURCES;
>>+}
>>+
>>+ipHdr = (IPHdr *)(bufferStart + layers->l3Offset);
>>+
>>+if (layer

Re: [ovs-dev] [PATCH v7 2/4] datapath-windows: Add NAT module in conntrack

[Sairam Venugopal]

Hi Yin,

Thanks for clarifying the comments. I will ack the next version.

@Alin - will you have sometime to review the changes?

Thanks,
Sairam




On 5/16/17, 5:11 PM, "Yin Lin"  wrote:

>Thanks Sai for the review! I fixed most of them and explained the remaining 
>ones in the inline comments.
>
>-Original Message-
>From: Sairam Venugopal 
>Sent: Tuesday, May 16, 2017 4:50 PM
>To: Yin Lin ; d...@openvswitch.org
>Subject: Re: [ovs-dev] [PATCH v7 2/4] datapath-windows: Add NAT module in 
>conntrack
>
>Hi Yin,
>
>Thanks for the patch. Please find my comments inline.
>
>Thanks,
>Sairam
>
>
>
>
>On 5/9/17, 3:59 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
> wrote:
>
>>Signed-off-by: Yin Lin 
>>---
>> datapath-windows/automake.mk|   2 +
>> datapath-windows/ovsext/Conntrack-nat.c | 424 
>> 
>> datapath-windows/ovsext/Conntrack-nat.h |  39 +++
>> 3 files changed, 465 insertions(+)
>> create mode 100644 datapath-windows/ovsext/Conntrack-nat.c
>> create mode 100644 datapath-windows/ovsext/Conntrack-nat.h
>>
>>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>>index 4f7b55a..7177630 100644
>>--- a/datapath-windows/automake.mk
>>+++ b/datapath-windows/automake.mk
>>@@ -16,7 +16,9 @@ EXTRA_DIST += \
>>  datapath-windows/ovsext/Conntrack-icmp.c \
>>  datapath-windows/ovsext/Conntrack-other.c \
>>  datapath-windows/ovsext/Conntrack-related.c \
>>+datapath-windows/ovsext/Conntrack-nat.c \
>>  datapath-windows/ovsext/Conntrack-tcp.c \
>>+datapath-windows/ovsext/Conntrack-nat.h \
>>  datapath-windows/ovsext/Conntrack.c \
>>  datapath-windows/ovsext/Conntrack.h \
>>  datapath-windows/ovsext/Datapath.c \
>>diff --git a/datapath-windows/ovsext/Conntrack-nat.c 
>>b/datapath-windows/ovsext/Conntrack-nat.c
>>new file mode 100644
>>index 000..edf5f8f
>>--- /dev/null
>>+++ b/datapath-windows/ovsext/Conntrack-nat.c
>>@@ -0,0 +1,424 @@
>>+#include "Conntrack-nat.h"
>>+#include "Jhash.h"
>>+
>>+PLIST_ENTRY ovsNatTable = NULL;
>>+PLIST_ENTRY ovsUnNatTable = NULL;
>>+
>>+/*
>>+ *---
>>+ * OvsHashNatKey
>>+ * Hash NAT related fields in a Conntrack key.
>>+ *---
>>+ */
>>+static __inline UINT32
>>+OvsHashNatKey(const OVS_CT_KEY *key)
>>+{
>>+UINT32 hash = 0;
>>+#define HASH_ADD(field) \
>>+hash = OvsJhashBytes(&key->field, sizeof(key->field), hash)
>>+
>>+HASH_ADD(src.addr.ipv4_aligned);
>>+HASH_ADD(dst.addr.ipv4_aligned);
>>+HASH_ADD(src.port);
>>+HASH_ADD(dst.port);
>>+HASH_ADD(zone);
>>+#undef HASH_ADD
>>+return hash;
>>+}
>>+
>>+/*
>>+ *---
>>+ * OvsNatKeyAreSame
>>+ * Compare NAT related fields in a Conntrack key.
>>+ *---
>>+ */
>>+static __inline BOOLEAN
>>+OvsNatKeyAreSame(const OVS_CT_KEY *key1, const OVS_CT_KEY *key2)
>>+{
>>+// XXX: Compare IPv6 key as well
>>+#define FIELD_COMPARE(field) \
>
>[Sai]: Nit: move return statement to next line. 
>[Yin]: This is a MACRO and I don't want to spread it over lines. (Note that I 
>don't even add a semicolon at the end to make it look like a function)
>
>>+if (key1->field != key2->field) return FALSE
>>+
>>+FIELD_COMPARE(src.addr.ipv4_aligned);
>>+FIELD_COMPARE(dst.addr.ipv4_aligned);
>>+FIELD_COMPARE(src.port);
>>+FIELD_COMPARE(dst.port);
>>+FIELD_COMPARE(zone);
>>+return TRUE;
>>+#undef FIELD_COMPARE
>>+}
>>+
>>+/*
>>+ *---
>
>[Sai]: Nit - OvsNatGetBucket
>[Yin]: Fixed
>
>>+ * OvsNaGetBucket
>>+ * Returns the row of NAT table that has the same hash as the given NAT
>>+ * hash key. If isReverse is TRUE, returns the row of reverse NAT table
>>+ * instead.
>>+ *---
>>+ */
>>+static __inline PLIST_ENTRY
>>+OvsNatGetBucket(const OVS_CT_KEY *key, BOOLEAN isReverse)
>>+{
>>+uint32_t hash = OvsHashNatKey(key);
>>+if (isReve

Re: [ovs-dev] [PATCH v7 3/4] datapath-windows: NAT integration with conntrack

[Sairam Venugopal]

Please find my comments inline.

Thanks,
Sairam




On 5/9/17, 3:59 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
 wrote:

>This patch integrates NAT module with existing conntrack module. NAT
>action is now supported.
>
>Signed-off-by: Yin Lin 
>---
> datapath-windows/automake.mk   |   4 +-
> datapath-windows/ovsext/Actions.c  | 119 -
> datapath-windows/ovsext/Actions.h  |  20 
> datapath-windows/ovsext/Conntrack.c| 187 +
> datapath-windows/ovsext/Conntrack.h|  25 +++--
> datapath-windows/ovsext/ovsext.vcxproj |   2 +
> 6 files changed, 274 insertions(+), 83 deletions(-)
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index 7177630..f1632cc 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -16,9 +16,9 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/Conntrack-icmp.c \
>   datapath-windows/ovsext/Conntrack-other.c \
>   datapath-windows/ovsext/Conntrack-related.c \
>-datapath-windows/ovsext/Conntrack-nat.c \
>+  datapath-windows/ovsext/Conntrack-nat.c \
>   datapath-windows/ovsext/Conntrack-tcp.c \
>-datapath-windows/ovsext/Conntrack-nat.h \
>+  datapath-windows/ovsext/Conntrack-nat.h \
>   datapath-windows/ovsext/Conntrack.c \
>   datapath-windows/ovsext/Conntrack.h \
>   datapath-windows/ovsext/Datapath.c \
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index e2eae9a..a808d2c 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -1380,7 +1380,7 @@ PUINT8 OvsGetHeaderBySize(OvsForwardingContext 
>*ovsFwdCtx,
>  *  based on the specified key.
>  *
>  */
>-static __inline NDIS_STATUS
>+NDIS_STATUS
> OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
>   const struct ovs_key_udp *udpAttr)
> {
>@@ -1427,7 +1427,7 @@ OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
>  *  based on the specified key.
>  *
>  */
>-static __inline NDIS_STATUS
>+NDIS_STATUS
> OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
>   const struct ovs_key_tcp *tcpAttr)
> {
>@@ -1465,12 +1465,125 @@ OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
> 
> /*
>  *
>+ * OvsUpdateAddressAndPort --
>+ *  Updates the source/destination IP and port fields in
>+ *  ovsFwdCtx.curNbl inline based on the specified key.
>+ *
>+ */
>+NDIS_STATUS
>+OvsUpdateAddressAndPort(OvsForwardingContext *ovsFwdCtx,
>+UINT32 newAddr, UINT16 newPort,
>+BOOLEAN isSource, BOOLEAN isTx)
>+{
>+PUINT8 bufferStart;
>+UINT32 hdrSize;
>+OVS_PACKET_HDR_INFO *layers = &ovsFwdCtx->layers;
>+IPHdr *ipHdr;
>+TCPHdr *tcpHdr = NULL;
>+UDPHdr *udpHdr = NULL;
>+UINT32 *addrField = NULL;
>+UINT16 *portField = NULL;
>+UINT16 *checkField = NULL;
>+BOOLEAN l4Offload = FALSE;
>+NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
>+
>+ASSERT(layers->value != 0);
>+
>+if (layers->isTcp || layers->isUdp) {
>+hdrSize = layers->l4Offset +
>+  layers->isTcp ? sizeof (*tcpHdr) : sizeof (*udpHdr);
>+} else {
>+hdrSize = layers->l3Offset + sizeof (*ipHdr);
>+}
>+
>+bufferStart = OvsGetHeaderBySize(ovsFwdCtx, hdrSize);
>+if (!bufferStart) {
>+return NDIS_STATUS_RESOURCES;
>+}
>+
>+ipHdr = (IPHdr *)(bufferStart + layers->l3Offset);
>+
>+if (layers->isTcp) {
>+tcpHdr = (TCPHdr *)(bufferStart + layers->l4Offset);
>+} else if (layers->isUdp) {
>+udpHdr = (UDPHdr *)(bufferStart + layers->l4Offset);
>+}
>+
>+csumInfo.Value = NET_BUFFER_LIST_INFO(ovsFwdCtx->curNbl,
>+  TcpIpChecksumNetBufferListInfo);
>+/*
>+ * Adjust the IP header inline as dictated by the action, and also update
>+ * the IP and the TCP checksum for the data modified.
>+ *
>+ * In the future, this could be optimized to make one call to
>+ * ChecksumUpdate32(). Ignoring this for now, since for the most common
>+ * case, we only update the TTL.
>+ */
>+
>+if (isSource) {
>+addrField = &ipHdr->saddr;
>+if (tcpHdr) {
>+portField = &tcpHdr->source;
>+checkField = &tcpHdr->check;
>+l4Offload = isTx ? (BOOLEAN)csumInfo.Transmit.TcpChecksum :
>+((BOOLEAN)csumInfo.Receive.TcpChecksumSucceeded ||
>+ (BOOLEAN)csumInfo.Receive.TcpChecksumFailed);
>+} else if (udpHdr) {
>+portField = &udpHdr->source;
>+checkField = &udpHdr->check;
>

Re: [ovs-dev] [PATCH v7 2/4] datapath-windows: Add NAT module in conntrack

[Sairam Venugopal]

Hi Yin,

Thanks for the patch. Please find my comments inline.

Thanks,
Sairam




On 5/9/17, 3:59 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
 wrote:

>Signed-off-by: Yin Lin 
>---
> datapath-windows/automake.mk|   2 +
> datapath-windows/ovsext/Conntrack-nat.c | 424 
> datapath-windows/ovsext/Conntrack-nat.h |  39 +++
> 3 files changed, 465 insertions(+)
> create mode 100644 datapath-windows/ovsext/Conntrack-nat.c
> create mode 100644 datapath-windows/ovsext/Conntrack-nat.h
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index 4f7b55a..7177630 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -16,7 +16,9 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/Conntrack-icmp.c \
>   datapath-windows/ovsext/Conntrack-other.c \
>   datapath-windows/ovsext/Conntrack-related.c \
>+datapath-windows/ovsext/Conntrack-nat.c \
>   datapath-windows/ovsext/Conntrack-tcp.c \
>+datapath-windows/ovsext/Conntrack-nat.h \
>   datapath-windows/ovsext/Conntrack.c \
>   datapath-windows/ovsext/Conntrack.h \
>   datapath-windows/ovsext/Datapath.c \
>diff --git a/datapath-windows/ovsext/Conntrack-nat.c 
>b/datapath-windows/ovsext/Conntrack-nat.c
>new file mode 100644
>index 000..edf5f8f
>--- /dev/null
>+++ b/datapath-windows/ovsext/Conntrack-nat.c
>@@ -0,0 +1,424 @@
>+#include "Conntrack-nat.h"
>+#include "Jhash.h"
>+
>+PLIST_ENTRY ovsNatTable = NULL;
>+PLIST_ENTRY ovsUnNatTable = NULL;
>+
>+/*
>+ *---
>+ * OvsHashNatKey
>+ * Hash NAT related fields in a Conntrack key.
>+ *---
>+ */
>+static __inline UINT32
>+OvsHashNatKey(const OVS_CT_KEY *key)
>+{
>+UINT32 hash = 0;
>+#define HASH_ADD(field) \
>+hash = OvsJhashBytes(&key->field, sizeof(key->field), hash)
>+
>+HASH_ADD(src.addr.ipv4_aligned);
>+HASH_ADD(dst.addr.ipv4_aligned);
>+HASH_ADD(src.port);
>+HASH_ADD(dst.port);
>+HASH_ADD(zone);
>+#undef HASH_ADD
>+return hash;
>+}
>+
>+/*
>+ *---
>+ * OvsNatKeyAreSame
>+ * Compare NAT related fields in a Conntrack key.
>+ *---
>+ */
>+static __inline BOOLEAN
>+OvsNatKeyAreSame(const OVS_CT_KEY *key1, const OVS_CT_KEY *key2)
>+{
>+// XXX: Compare IPv6 key as well
>+#define FIELD_COMPARE(field) \

[Sai]: Nit: move return statement to next line. 


>+if (key1->field != key2->field) return FALSE
>+
>+FIELD_COMPARE(src.addr.ipv4_aligned);
>+FIELD_COMPARE(dst.addr.ipv4_aligned);
>+FIELD_COMPARE(src.port);
>+FIELD_COMPARE(dst.port);
>+FIELD_COMPARE(zone);
>+return TRUE;
>+#undef FIELD_COMPARE
>+}
>+
>+/*
>+ *---

[Sai]: Nit - OvsNatGetBucket

>+ * OvsNaGetBucket
>+ * Returns the row of NAT table that has the same hash as the given NAT
>+ * hash key. If isReverse is TRUE, returns the row of reverse NAT table
>+ * instead.
>+ *---
>+ */
>+static __inline PLIST_ENTRY
>+OvsNatGetBucket(const OVS_CT_KEY *key, BOOLEAN isReverse)
>+{
>+uint32_t hash = OvsHashNatKey(key);
>+if (isReverse) {
>+return &ovsUnNatTable[hash & NAT_HASH_TABLE_MASK];
>+} else {
>+return &ovsNatTable[hash & NAT_HASH_TABLE_MASK];
>+}
>+}
>+
>+/*
>+ *---
>+ * OvsNatInit
>+ * Initialize NAT related resources.
>+ *---
>+ */
>+NTSTATUS OvsNatInit()
>+{
>+ASSERT(ovsNatTable == NULL);
>+
>+/* Init the Hash Buffer */
>+ovsNatTable = OvsAllocateMemoryWithTag(
>+sizeof(LIST_ENTRY) * NAT_HASH_TABLE_SIZE,
>+OVS_CT_POOL_TAG);
>+if (ovsNatTable == NULL) {
>+goto failNoMem;
>+}
>+
>+ovsUnNatTable = OvsAllocateMemoryWithTag(
>+sizeof(LIST_ENTRY) * NAT_HASH_TABLE_SIZE,
>+OVS_CT_POOL_TAG);
>+if (ovsUnNatTable == NULL) {
>+goto freeNatTable;
>+}
>+
>+for (int i = 0; i < NAT_HASH_TABLE_SIZE; i++) {
>+InitializeListHead(&ovsNatTable[i]);
>+InitializeListHead(&ovsUnNatTable[i]);
>+}
>+return STATUS_SUCCESS;
>+
>+freeNatTable:
>+OvsFreeMemoryWithTag(ovsNatTable, OVS_CT_POOL_TAG);
>+failNoMem:
>+return STATUS_INSUFFICIENT_RESOURCES;
>+}
>+
>+/*
>+ *
>+ * OvsNatFlush
>+ * Flushes out all NAT entries that match the given zone.
>+ *
>+ */
>+VOID OvsNatFlush(UINT16 zone)
>+{
>+PLIST_ENTRY link, ne

Re: [ovs-dev] [PATCH v7 1/4] datapath-windows: Add support for NAT in conntrack

[Sairam Venugopal]

Looks like outlook messed up my formatting.  I had 2 comments in this patch.

The default case statement is missing and 2 other cases aren't handled:
case OVS_NAT_ATTR_UNSPEC: break;
case __OVS_NAT_ATTR_MAX: break;
default: ;

OvsCtExecute_ - parameters exceed the length to almost 87

Thanks,
Sairam

-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
On Behalf Of Yin Lin
Sent: Tuesday, May 9, 2017 4:00 PM
To: d...@openvswitch.org
Cc: Yin Lin 
Subject: [ovs-dev] [PATCH v7 1/4] datapath-windows: Add support for NAT in 
conntrack

From: Anand Kumar 

Add support for parsing netlink attributes related to NAT in conntrack.

Co-Authored-by: Anand Kumar 
Co-Authored-by: Darrell Ball 
Signed-off-by: Yin Lin 
---
 datapath-windows/ovsext/Conntrack.c | 73 -
 datapath-windows/ovsext/Conntrack.h | 17 +
 datapath-windows/ovsext/Flow.c  |  4 +-
 3 files changed, 90 insertions(+), 4 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index dce0c1b..9824368 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -645,7 +645,8 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
   UINT16 zone,
   MD_MARK *mark,
   MD_LABELS *labels,
-  PCHAR helper)
+  PCHAR helper,
+  PNAT_ACTION_INFO natInfo)
 {
 NDIS_STATUS status = NDIS_STATUS_SUCCESS;
 POVS_CT_ENTRY entry = NULL;
@@ -654,6 +655,9 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
 UINT64 currentTime;
 NdisGetCurrentSystemTime((LARGE_INTEGER *) ¤tTime);
 
+/* XXX: Not referenced for now */
+UNREFERENCED_PARAMETER(natInfo);
+
 /* Retrieve the Conntrack Key related fields from packet */
 OvsCtSetupLookupCtx(key, zone, &ctx, curNbl, layers->l4Offset);
 
@@ -730,11 +734,14 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
 MD_MARK *mark = NULL;
 MD_LABELS *labels = NULL;
 PCHAR helper = NULL;
+NAT_ACTION_INFO natActionInfo;
 PNET_BUFFER_LIST curNbl = fwdCtx->curNbl;
 OVS_PACKET_HDR_INFO *layers = &fwdCtx->layers;
 PNET_BUFFER_LIST newNbl = NULL;
+NAT_ACTION_INFO natActionInfo;
 NDIS_STATUS status;
 
+memset(&natActionInfo, 0, sizeof natActionInfo);
 status = OvsDetectCtPacket(fwdCtx, key, &newNbl);
 if (status != NDIS_STATUS_SUCCESS) {
 return status;
@@ -757,6 +764,68 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
 if (ctAttr) {
 labels = NlAttrGet(ctAttr);
 }
+natActionInfo.natAction = NAT_ACTION_NONE;
+ctAttr = NlAttrFindNested(a, OVS_CT_ATTR_NAT);
+if (ctAttr) {
+/* Pares Nested NAT attributes. */
+PNL_ATTR natAttr;
+unsigned int left;
+BOOLEAN hasMinIp = FALSE;
+BOOLEAN hasMinPort = FALSE;
+BOOLEAN hasMaxIp = FALSE;
+BOOLEAN hasMaxPort = FALSE;
+NL_NESTED_FOR_EACH_UNSAFE (natAttr, left, ctAttr) {
+enum ovs_nat_attr sub_type_nest = NlAttrType(natAttr);
+switch(sub_type_nest) {
+case OVS_NAT_ATTR_SRC:
+case OVS_NAT_ATTR_DST:
+natActionInfo.natAction |=
+((sub_type_nest == OVS_NAT_ATTR_SRC)
+? NAT_ACTION_SRC : NAT_ACTION_DST);
+break;
+case OVS_NAT_ATTR_IP_MIN:
+memcpy(&natActionInfo.minAddr,
+   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
+hasMinIp = TRUE;
+break;
+case OVS_NAT_ATTR_IP_MAX:
+memcpy(&natActionInfo.maxAddr,
+   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
+hasMaxIp = TRUE;
+break;
+case OVS_NAT_ATTR_PROTO_MIN:
+natActionInfo.minPort = NlAttrGetU16(natAttr);
+hasMinPort = TRUE;
+break;
+case OVS_NAT_ATTR_PROTO_MAX:
+natActionInfo.maxPort = NlAttrGetU16(natAttr);
+hasMaxPort = TRUE;
+break;
+case OVS_NAT_ATTR_PERSISTENT:
+case OVS_NAT_ATTR_PROTO_HASH:
+case OVS_NAT_ATTR_PROTO_RANDOM:
+break;
+}
+}
+if (natActionInfo.natAction == NAT_ACTION_NONE) {
+natActionInfo.natAction = NAT_ACTION_REVERSE;
+}
+if (hasMinIp && !hasMaxIp) {
+memcpy(&natActionInfo.maxAddr,
+   &natActionInfo.minAddr,
+   sizeof(natActionInfo.maxAddr));
+}
+if (hasMinPort && !hasMaxPort) {
+natActionInfo.maxPort = natActionInfo.minPort;
+}
+if (hasMinPort || hasMaxPort) {
+if (natActionInfo.natAction & NAT_ACTION_SRC) {
+natActionInfo.natAction |= NAT_ACTION_SRC_PORT;
+} else

Re: [ovs-dev] [PATCH v7 1/4] datapath-windows: Add support for NAT in conntrack

[Sairam Venugopal]

Not sure why the "From: Anand Kumar ” shows up in the 
commit description.

Since they are already listed as co-author, it should be safe to remove this.

Acked-by: Sairam Venugopal 






On 5/9/17, 3:59 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
 wrote:

>From: Anand Kumar 
>
>Add support for parsing netlink attributes related to NAT
>in conntrack.
>
>Co-Authored-by: Anand Kumar 
>Co-Authored-by: Darrell Ball 
>Signed-off-by: Yin Lin 
>---
> datapath-windows/ovsext/Conntrack.c | 73 -
> datapath-windows/ovsext/Conntrack.h | 17 +
> datapath-windows/ovsext/Flow.c  |  4 +-
> 3 files changed, 90 insertions(+), 4 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index dce0c1b..9824368 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -645,7 +645,8 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
>   UINT16 zone,
>   MD_MARK *mark,
>   MD_LABELS *labels,
>-  PCHAR helper)
>+  PCHAR helper,
>+  PNAT_ACTION_INFO natInfo)
> {
> NDIS_STATUS status = NDIS_STATUS_SUCCESS;
> POVS_CT_ENTRY entry = NULL;
>@@ -654,6 +655,9 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
> UINT64 currentTime;
> NdisGetCurrentSystemTime((LARGE_INTEGER *) ¤tTime);
> 
>+/* XXX: Not referenced for now */
>+UNREFERENCED_PARAMETER(natInfo);
>+
> /* Retrieve the Conntrack Key related fields from packet */
> OvsCtSetupLookupCtx(key, zone, &ctx, curNbl, layers->l4Offset);
> 
>@@ -730,11 +734,14 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
> MD_MARK *mark = NULL;
> MD_LABELS *labels = NULL;
> PCHAR helper = NULL;
>+NAT_ACTION_INFO natActionInfo;
> PNET_BUFFER_LIST curNbl = fwdCtx->curNbl;
> OVS_PACKET_HDR_INFO *layers = &fwdCtx->layers;
> PNET_BUFFER_LIST newNbl = NULL;
>+NAT_ACTION_INFO natActionInfo;
> NDIS_STATUS status;
> 
>+memset(&natActionInfo, 0, sizeof natActionInfo);
> status = OvsDetectCtPacket(fwdCtx, key, &newNbl);
> if (status != NDIS_STATUS_SUCCESS) {
> return status;
>@@ -757,6 +764,68 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
> if (ctAttr) {
> labels = NlAttrGet(ctAttr);
> }
>+natActionInfo.natAction = NAT_ACTION_NONE;
>+ctAttr = NlAttrFindNested(a, OVS_CT_ATTR_NAT);
>+if (ctAttr) {
>+/* Pares Nested NAT attributes. */
>+PNL_ATTR natAttr;
>+unsigned int left;
>+BOOLEAN hasMinIp = FALSE;
>+BOOLEAN hasMinPort = FALSE;
>+BOOLEAN hasMaxIp = FALSE;
>+BOOLEAN hasMaxPort = FALSE;
>+NL_NESTED_FOR_EACH_UNSAFE (natAttr, left, ctAttr) {
>+enum ovs_nat_attr sub_type_nest = NlAttrType(natAttr);
>+switch(sub_type_nest) {
>+case OVS_NAT_ATTR_SRC:
>+case OVS_NAT_ATTR_DST:
>+natActionInfo.natAction |=
>+((sub_type_nest == OVS_NAT_ATTR_SRC)
>+? NAT_ACTION_SRC : NAT_ACTION_DST);
>+break;
>+case OVS_NAT_ATTR_IP_MIN:
>+memcpy(&natActionInfo.minAddr,
>+   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
>+hasMinIp = TRUE;
>+break;
>+case OVS_NAT_ATTR_IP_MAX:
>+memcpy(&natActionInfo.maxAddr,
>+   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
>+hasMaxIp = TRUE;
>+break;
>+case OVS_NAT_ATTR_PROTO_MIN:
>+natActionInfo.minPort = NlAttrGetU16(natAttr);
>+hasMinPort = TRUE;
>+break;
>+case OVS_NAT_ATTR_PROTO_MAX:
>+natActionInfo.maxPort = NlAttrGetU16(natAttr);
>+hasMaxPort = TRUE;
>+break;
>+case OVS_NAT_ATTR_PERSISTENT:
>+case OVS_NAT_ATTR_PROTO_HASH:
>+case OVS_NAT_ATTR_PROTO_RANDOM:
>+break;
>+}
>+}
>+if (natActionInfo.natAction == NAT_ACTION_NONE) {
>+natActionInfo.natAction = NAT_ACTION_REVERSE;
>+}
>+if (hasMinIp && !hasMaxIp) {
>+memcpy(&natActionInfo.maxAddr,
>+   &natActionInfo.minAddr,
>+   sizeof(natActionInfo.maxAddr));
>+}
>+if (hasMinPort && !hasMaxPort) {
>+natActionInfo.maxPort = natActionInfo.minPort;
>+}

Re: [ovs-dev] [PATCH v6 3/4] datapath-windows: NAT integration with conntrack

[Sairam Venugopal]

Hi Yin,

Thanks for the patches. I had some immediate review comments. 

- OvsUpdateAddressAndPort does not have a return type
- Refrain from changing other code that your patch does not require. Please 
send out separate incremental patch.
- This is the correct way to define static inline functions - "static __inline 
NDIS_STATUS”. Don’t change this.
Update your code to follow this instead.

Please find the other comments inline.

Thanks,
Sairam



On 5/8/17, 3:38 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
 wrote:

>Signed-off-by: Yin Lin 
>---
> datapath-windows/automake.mk   |   4 +-
> datapath-windows/ovsext/Actions.c  | 118 -
> datapath-windows/ovsext/Actions.h  |  20 
> datapath-windows/ovsext/Conntrack.c| 187 +
> datapath-windows/ovsext/Conntrack.h|  25 +++--
> datapath-windows/ovsext/ovsext.vcxproj |   2 +
> 6 files changed, 273 insertions(+), 83 deletions(-)
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index 7177630..f1632cc 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -16,9 +16,9 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/Conntrack-icmp.c \
>   datapath-windows/ovsext/Conntrack-other.c \
>   datapath-windows/ovsext/Conntrack-related.c \
>-datapath-windows/ovsext/Conntrack-nat.c \
>+  datapath-windows/ovsext/Conntrack-nat.c \
>   datapath-windows/ovsext/Conntrack-tcp.c \
>-datapath-windows/ovsext/Conntrack-nat.h \
>+  datapath-windows/ovsext/Conntrack-nat.h \
>   datapath-windows/ovsext/Conntrack.c \
>   datapath-windows/ovsext/Conntrack.h \
>   datapath-windows/ovsext/Datapath.c \
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index e2eae9a..d1938f3 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -1380,7 +1380,7 @@ PUINT8 OvsGetHeaderBySize(OvsForwardingContext 
>*ovsFwdCtx,
>  *  based on the specified key.
>  *
>  */

[Sai]: Please don’t change this. This is the correct - "static __inline 
NDIS_STATUS"
>-static __inline NDIS_STATUS
>+NDIS_STATUS
> OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
>   const struct ovs_key_udp *udpAttr)
> {
>@@ -1427,7 +1427,7 @@ OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
>  *  based on the specified key.
>  *
>  */
>-static __inline NDIS_STATUS
>+NDIS_STATUS

[Sai]: Please don’t change this. This is the correct - "static __inline 
NDIS_STATUS"


> OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
>   const struct ovs_key_tcp *tcpAttr)
> {
>@@ -1465,12 +1465,124 @@ OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
> 
> /*
>  *
>+ * OvsUpdateAddressAndPort --
>+ *  Updates the source/destination IP and port fields in
>+ *  ovsFwdCtx.curNbl inline based on the specified key.
>+ *
>+ */

[Sai]: Missing return type

>+OvsUpdateAddressAndPort(OvsForwardingContext *ovsFwdCtx,
>+UINT32 newAddr, UINT16 newPort,
>+BOOLEAN isSource, BOOLEAN isTx)
>+{
>+PUINT8 bufferStart;
>+UINT32 hdrSize;
>+OVS_PACKET_HDR_INFO *layers = &ovsFwdCtx->layers;
>+IPHdr *ipHdr;
>+TCPHdr *tcpHdr = NULL;
>+UDPHdr *udpHdr = NULL;
>+UINT32 *addrField = NULL;
>+UINT16 *portField = NULL;
>+UINT16 *checkField = NULL;
>+BOOLEAN l4Offload = FALSE;
>+NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
>+
>+ASSERT(layers->value != 0);
>+
>+if (layers->isTcp || layers->isUdp) {
>+hdrSize = layers->l4Offset +
>+  layers->isTcp ? sizeof (*tcpHdr) : sizeof (*udpHdr);
>+} else {
>+hdrSize = layers->l3Offset + sizeof (*ipHdr);
>+}
>+
>+bufferStart = OvsGetHeaderBySize(ovsFwdCtx, hdrSize);
>+if (!bufferStart) {
>+return NDIS_STATUS_RESOURCES;
>+}
>+
>+ipHdr = (IPHdr *)(bufferStart + layers->l3Offset);
>+
>+if (layers->isTcp) {
>+tcpHdr = (TCPHdr *)(bufferStart + layers->l4Offset);
>+} else if (layers->isUdp) {
>+udpHdr = (UDPHdr *)(bufferStart + layers->l4Offset);
>+}
>+
>+csumInfo.Value = NET_BUFFER_LIST_INFO(ovsFwdCtx->curNbl,
>+  TcpIpChecksumNetBufferListInfo);
>+/*
>+ * Adjust the IP header inline as dictated by the action, and also update
>+ * the IP and the TCP checksum for the data modified.
>+ *
>+ * In the future, this could be optimized to make one call to
>+ * ChecksumUpdate32(). Ignoring this for now, since for the most common
>+ * case, we only update the TTL.
>+ */
>+
>+if (isSour

Re: [ovs-dev] [PATCH v6 4/4] Signed-off-by: Alin Gabriel Serdean

[Sairam Venugopal]

Yin,

Can you rebase and rebuild your changes? OvsTcpSegmentNBL arguments have 
changed and this patch breaks compilation.

Can you add commit msgs to your patches? 

This commit title says: "Signed-off-by:Alin Gabriel…” Can you fix this?

Thanks,
Sairam




On 5/8/17, 3:38 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
 wrote:

>From: Alin Gabriel Serdean 
>
>---
> datapath-windows/ovsext/Actions.c | 38 ++
> 1 file changed, 38 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index d1938f3..bb1e6ea 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -1572,6 +1572,44 @@ OvsUpdateAddressAndPort(OvsForwardingContext *ovsFwdCtx,
> }
> *portField = newPort;
> }
>+PNET_BUFFER_LIST curNbl = ovsFwdCtx->curNbl;
>+PNET_BUFFER_LIST newNbl = NULL;
>+if (layers->isTcp) {
>+UINT32 mss = OVSGetTcpMSS(curNbl);
>+if (mss) {
>+OVS_LOG_TRACE("l4Offset %d", layers->l4Offset);
>+newNbl = OvsTcpSegmentNBL(ovsFwdCtx->switchContext, curNbl, 
>layers,
>+  mss, 0);
>+if (newNbl == NULL) {
>+OVS_LOG_ERROR("Unable to segment NBL");
>+return NDIS_STATUS_FAILURE;
>+}
>+/* Clear out LSO flags after this point */
>+NET_BUFFER_LIST_INFO(newNbl, TcpLargeSendNetBufferListInfo) = 0;
>+}
>+}
>+/* If we didn't split the packet above, make a copy now */
>+if (newNbl == NULL) {
>+csumInfo.Value = NET_BUFFER_LIST_INFO(curNbl,
>+  TcpIpChecksumNetBufferListInfo);
>+OvsApplySWChecksumOnNB(layers, curNbl, &csumInfo);
>+}
>+
>+if (newNbl) {
>+curNbl = newNbl;
>+OvsCompleteNBLForwardingCtx(ovsFwdCtx,
>+L"Complete after cloning NBL for 
>encapsulation");
>+OvsInitForwardingCtx(ovsFwdCtx, ovsFwdCtx->switchContext,
>+ newNbl, ovsFwdCtx->srcVportNo, 0,
>+ NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL(newNbl),
>+ ovsFwdCtx->completionList,
>+ &ovsFwdCtx->layers, FALSE);
>+ovsFwdCtx->curNbl = newNbl;
>+}
>+
>+NET_BUFFER_LIST_INFO(curNbl,
>+ TcpIpChecksumNetBufferListInfo) = 0;
>+
> return NDIS_STATUS_SUCCESS;
> }
> 
>-- 
>2.10.2.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3] Windows: Secure the namedpipe implementation

[Sairam Venugopal]

Update the security policies around the creation of the namedpipe. The
current security updates restrict how the namedpipe can be accessed.

- Disable Network access
- Windows Services can access the namedpipe
- Administrators can access the namedpipe

Signed-off-by: Sairam Venugopal 
---
 lib/stream-windows.c | 98 
 1 file changed, 92 insertions(+), 6 deletions(-)

diff --git a/lib/stream-windows.c b/lib/stream-windows.c
index 44b88bf..c5a26c8 100644
--- a/lib/stream-windows.c
+++ b/lib/stream-windows.c
@@ -40,6 +40,9 @@ static void maybe_unlink_and_free(char *path);
 /* Default prefix of a local named pipe. */
 #define LOCAL_PREFIX ".\\pipe\\"
 
+/* Size of the allowed PSIDs for securing Named Pipe. */
+#define ALLOWED_PSIDS_SIZE 2
+
 /* This function has the purpose to remove all the slashes received in s. */
 static char *
 remove_slashes(char *s)
@@ -402,16 +405,99 @@ static HANDLE
 create_pnpipe(char *name)
 {
 SECURITY_ATTRIBUTES sa;
-sa.nLength = sizeof(sa);
-sa.lpSecurityDescriptor = NULL;
+SID_IDENTIFIER_AUTHORITY sia = SECURITY_NT_AUTHORITY;
+DWORD aclSize;
+PSID allowedPsid[ALLOWED_PSIDS_SIZE];
+PSID remoteAccessSid;
+PACL acl = NULL;
+PSECURITY_DESCRIPTOR psd = NULL;
+HANDLE npipe;
+
+/* Disable access over network. */
+if (!AllocateAndInitializeSid(&sia, 1, SECURITY_NETWORK_RID,
+  0, 0, 0, 0, 0, 0, 0, &remoteAccessSid)) {
+VLOG_ERR_RL(&rl, "Error creating Remote Access SID.");
+goto handle_error;
+}
+
+aclSize = sizeof(ACL) + sizeof(ACCESS_DENIED_ACE) +
+  GetLengthSid(remoteAccessSid) - sizeof(DWORD);
+
+/* Allow Windows Services to access the Named Pipe. */
+if (!AllocateAndInitializeSid(&sia, 1, SECURITY_LOCAL_SYSTEM_RID,
+  0, 0, 0, 0, 0, 0, 0, &allowedPsid[0])) {
+VLOG_ERR_RL(&rl, "Error creating Services SID.");
+goto handle_error;
+}
+
+/* Allow Administrators to access the Named Pipe. */
+if (!AllocateAndInitializeSid(&sia, 2, SECURITY_BUILTIN_DOMAIN_RID,
+  DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0,
+  &allowedPsid[1])) {
+VLOG_ERR_RL(&rl, "Error creating Administrator SID.");
+goto handle_error;
+}
+
+for (int i = 0; i < ALLOWED_PSIDS_SIZE; i++) {
+aclSize += sizeof(ACCESS_ALLOWED_ACE) +
+   GetLengthSid(allowedPsid[i]) -
+   sizeof(DWORD);
+}
+
+acl = xmalloc(aclSize);
+if (!InitializeAcl(acl, aclSize, ACL_REVISION)) {
+VLOG_ERR_RL(&rl, "Error initializing ACL.");
+goto handle_error;
+}
+
+/* Add denied ACL. */
+if (!AddAccessDeniedAce(acl, ACL_REVISION,
+GENERIC_ALL, remoteAccessSid)) {
+VLOG_ERR_RL(&rl, "Error adding remote access ACE.");
+goto handle_error;
+}
+
+/* Add allowed ACLs. */
+for (int i = 0; i < ALLOWED_PSIDS_SIZE; i++) {
+if (!AddAccessAllowedAce(acl, ACL_REVISION,
+ GENERIC_ALL, allowedPsid[i])) {
+VLOG_ERR_RL(&rl, "Error adding ACE.");
+goto handle_error;
+}
+}
+
+psd = xmalloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
+if (!InitializeSecurityDescriptor(psd, SECURITY_DESCRIPTOR_REVISION)) {
+VLOG_ERR_RL(&rl, "Error initializing Security Descriptor.");
+goto handle_error;
+}
+
+/* Set DACL. */
+if (!SetSecurityDescriptorDacl(psd, TRUE, acl, FALSE)) {
+VLOG_ERR_RL(&rl, "Error while setting DACL.");
+goto handle_error;
+}
+
+sa.nLength = sizeof sa;
 sa.bInheritHandle = TRUE;
+sa.lpSecurityDescriptor = psd;
+
 if (strlen(name) > 256) {
 VLOG_ERR_RL(&rl, "Named pipe name too long.");
-return INVALID_HANDLE_VALUE;
+goto handle_error;
 }
-return CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
-   PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | PIPE_WAIT,
-   64, BUFSIZE, BUFSIZE, 0, &sa);
+
+npipe = CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
+PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | PIPE_WAIT,
+64, BUFSIZE, BUFSIZE, 0, &sa);
+free(acl);
+free(psd);
+return npipe;
+
+handle_error:
+free(acl);
+free(psd);
+return INVALID_HANDLE_VALUE;
 }
 
 /* Passive named pipe connect.  This function creates a new named pipe and
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH v2] Windows: Secure the namedpipe implementation

[Sairam Venugopal]

Hi Alin,

I think the existing behavior requires an elevated Command Prompt/powershell to 
execute OVS commands. 


Eg: Running 'ovs-appctl list-commands’ on non-Adminsitrator CMD will complain 
that access is denied to the namedpipe.

Are you thinking of other cases where the current user is non-administrator and 
can still access the namedpipe? 

Thanks,
Sairam





On 5/5/17, 4:17 PM, "Alin Serdean"  wrote:

>Hi Sai,
>
>Thanks a lot for the patch!
>
>Could you please add the current user to the accepted list?
>
>We need them for testing and users to be able to run the binaries w/o 
>elevation (i.e. make check on own laptop without elevated prompt).
>
>Let me know if I can help you with that!
>
>Some small nits inlined.
>
>Thanks,
>Alin.
>
>> -Original Message-
>> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
>> boun...@openvswitch.org] On Behalf Of Sairam Venugopal
>> Sent: Friday, May 5, 2017 9:30 PM
>> To: d...@openvswitch.org
>> Subject: [ovs-dev] [PATCH v2] Windows: Secure the namedpipe
>> implementation
>> 
>> Update the security policies around the creation of the namedpipe. The
>> current security updates restrict how the namedpipe can be accessed.
>> 
>> - Disable Network access
>> - Windows Services can access the namedpipe
>> - Administrators can access the namedpipe
>> 
>> Signed-off-by: Sairam Venugopal 
>> ---
>>  lib/stream-windows.c | 91
>> 
>>  1 file changed, 84 insertions(+), 7 deletions(-)
>> 
>> diff --git a/lib/stream-windows.c b/lib/stream-windows.c index
>> 44b88bf..7cc6023 100644
>> --- a/lib/stream-windows.c
>> +++ b/lib/stream-windows.c
>> @@ -40,6 +40,9 @@ static void maybe_unlink_and_free(char *path);
>>  /* Default prefix of a local named pipe. */  #define LOCAL_PREFIX
>> ".\\pipe\\"
>> 
>> +/* Size of the allowed PSIDs for securing Named Pipe. */ #define
>> +ALLOWED_PSIDS_SIZE 2
>> +
>>  /* This function has the purpose to remove all the slashes received in s. */
>> static char *  remove_slashes(char *s) @@ -402,16 +405,90 @@ static
>> HANDLE  create_pnpipe(char *name)  {
>>  SECURITY_ATTRIBUTES sa;
>> -sa.nLength = sizeof(sa);
>> -sa.lpSecurityDescriptor = NULL;
>> +SID_IDENTIFIER_AUTHORITY sia = SECURITY_NT_AUTHORITY;
>> +DWORD aclSize;
>> +PSID allowedPsid[ALLOWED_PSIDS_SIZE];
>> +PSID remoteAccessSid;
>> +PACL acl = NULL;
>> +PSECURITY_DESCRIPTOR psd = NULL;
>> +HANDLE npipe;
>> +
>> +/* Disable access over network. */
>> +if (!AllocateAndInitializeSid(&sia, 1, SECURITY_NETWORK_RID,
>> +  0, 0, 0, 0, 0, 0, 0, &remoteAccessSid)) {
>[Alin Serdean] add print error pls.
>> +goto handle_error;
>> +}
>> +
>> +aclSize = sizeof(ACL) + sizeof(ACCESS_DENIED_ACE) +
>> +  GetLengthSid(remoteAccessSid) - sizeof(DWORD);
>> +
>> +/* Allow Windows Services to access the Named Pipe. */
>> +if (!AllocateAndInitializeSid(&sia, 1, SECURITY_LOCAL_SYSTEM_RID,
>> +  0, 0, 0, 0, 0, 0, 0, &allowedPsid[0])) {
>[Alin Serdean] add print error pls.
>> +goto handle_error;
>> +}
>> +
>> +/* Allow Administrators to access the Named Pipe. */
>> +if (!AllocateAndInitializeSid(&sia, 2, SECURITY_BUILTIN_DOMAIN_RID,
>> +  DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0,
>> +  &allowedPsid[1])) {
>> +return INVALID_HANDLE_VALUE;
>[Alin Serdean] add print error pls.
>[Alin Serdean] goto handle_error ?
>> +}
>> +
>> +for (int i = 0; i < ALLOWED_PSIDS_SIZE; i++) {
>> +aclSize += sizeof(ACCESS_ALLOWED_ACE) +
>> +   GetLengthSid(allowedPsid[i]) -
>> +   sizeof(DWORD);
>> +}
>> +
>> +acl = xmalloc(aclSize);
>> +if (!InitializeAcl(acl, aclSize, ACL_REVISION)) {
>> +goto handle_error;
>> +}
>> +
>> +/* Add denied ACL. */
>> +if (!AddAccessDeniedAce(acl, ACL_REVISION,
>> +GENERIC_ALL, remoteAccessSid)) {
>> +goto handle_error;
>> +}
>> +
>> +/* Add allowed ACLs. */
>> +for (int i = 0; i < 2;i++) {
>[Alin Serdean] i< ALLOWED_PSIDS_SIZE?
>> +if (!AddAccessAllowedAce(acl, ACL_REVISION,
>> +  

Re: [ovs-dev] [PATCH] windows: fix broken build

[Sairam Venugopal]

Thanks for fixing this.

Acked-by: Sairam Venugopal 





On 5/5/17, 1:20 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin Serdean" 
 
wrote:

>The Windows build is failing because EPFNOSUPPORT does not exist.
>
>An equivalent is supplied using the WinSock API: WSAEPFNOSUPPORT.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> include/windows/windefs.h | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/include/windows/windefs.h b/include/windows/windefs.h
>index 5137f07..6ed8d87 100644
>--- a/include/windows/windefs.h
>+++ b/include/windows/windefs.h
>@@ -45,4 +45,6 @@ char *strsep(char **stringp, const char *delim);
> #define srandom srand
> #define random rand
> 
>+#define EPFNOSUPPORT WSAEPFNOSUPPORT
>+
> #endif /* windefs.h */
>-- 
>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&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=I0Ot3GyEy1CNc2-LnNDXV0hFLWzbnTfGr44ezULyoMA&s=plJNu-fqABxTrvJ6tTvhZJV5keUndhqAv4ZApgqYLf4&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Windows: Secure the namedpipe implementation

[Sairam Venugopal]

I have addressed this and the review comments in v2.

Thanks,
Sairam




On 5/4/17, 9:33 PM, "Ben Pfaff"  wrote:

>Usually if we're taking the size of a variable, it makes sense to really
>take the size of that variable, e.g.
>sa.nLength = sizeof sa;
>
>On Fri, May 05, 2017 at 12:40:02AM +, Sairam Venugopal wrote:
>> Hi Ben,
>> 
>> Regarding the usage of sizeof - I think the current implementation is in 
>> line 
>> with the coding style. SECURITY_ATTRIBUTES is a struct and I noticed that we 
>> currently use sizeof with parenthesis while determining the size of 
>> structs/types.
>> 
>> Please correct me if am wrong.
>> 
>> Thanks,
>> Sairam
>> 
>> 
>> 
>> On 5/3/17, 1:05 PM, "Ben Pfaff"  wrote:
>> 
>> >On Wed, May 03, 2017 at 12:22:48PM -0700, Sairam Venugopal wrote:
>> >> Update the security policies around the creation of the namedpipe. The
>> >> current security updates restrict how the namedpipe can be accessed.
>> >> 
>> >> - Disable Network access
>> >> - Windows Services can access the namedpipe
>> >> - Administrators can access the namedpipe
>> >> 
>> >> Signed-off-by: Sairam Venugopal 
>> >
>> >Hi Sairam, thanks for working on making the Windows code more secure.
>> >It's easy to overlook this kind of thing.
>> >
>> >I don't know much about Windows in this area, so I can't review this,
>> >but I have some style requests.
>> >
>> >For the code here, coding-style.rst says:
>> >Try to avoid casts. Don't cast the return value of malloc().
>> >Also, xmalloc() never returns NULL, so you need not check for that:
>> >> +acl = (PACL) xmalloc(aclSize);
>> >> +if (acl == NULL) {
>> >> +return INVALID_HANDLE_VALUE;
>> >> +}
>> >
>> >Here, and various other places, coding-style.rst says:
>> >Comments should be written as full sentences that start with a
>> >capital letter and end with a period. Put two spaces between
>> >sentences.
>> >> +/* Add denied ACL */
>> >> +if (!AddAccessDeniedAce(acl, ACL_REVISION,
>> >> +GENERIC_ALL, remoteAccessSid)) {
>> >> +goto handle_error;
>> >> +}
>> >
>> >Unnecessary cast:
>> >> +psd = (PSECURITY_DESCRIPTOR) xmalloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
>> >> +if (!InitializeSecurityDescriptor(psd, 
>> >> SECURITY_DESCRIPTOR_REVISION)) {
>> >> +goto handle_error;
>> >> +}
>> >> +
>> >> +/* Set DACL */
>> >> +if (!SetSecurityDescriptorDacl(psd, TRUE, acl, FALSE)) {
>> >> +goto handle_error;
>> >> +}
>> >
>> >Regarding "sizeof", coding-style.rst says:
>> >The "sizeof" operator is unique among C operators in that it accepts
>> >two very different kinds of operands: an expression or a type. In
>> >general, prefer to specify an expression, e.g. ``int *x =
>> >xmalloc(sizeof *\ x);``. When the operand of sizeof is an
>> >expression, there is no need to parenthesize that operand, and
>> >please don't.
>> >> +sa.nLength = sizeof(SECURITY_ATTRIBUTES);
>> >>  sa.bInheritHandle = TRUE;
>> >> +sa.lpSecurityDescriptor = psd;
>> >> +
>> >>  if (strlen(name) > 256) {
>> >> -VLOG_ERR_RL(&rl, "Named pipe name too long.");
>> >> -return INVALID_HANDLE_VALUE;
>> >> +goto handle_error;
>> >> +}
>> >> +
>> >> +npipe = CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | 
>> >> FILE_FLAG_OVERLAPPED,
>> >> +PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | 
>> >> PIPE_WAIT,
>> >> +64, BUFSIZE, BUFSIZE, 0, &sa);
>> >> +free(acl);
>> >> +free(psd);
>> >> +return npipe;
>> >> +handle_error:
>> >
>> >Regarding free(), coding-style.rst says:
>> >Functions that destroy an instance of a dynamically-allocated type
>> >should accept and ignore a null pointer argument. Code that calls
>> >such a function (including the C standard library function
>> >``free()``) should omit a null-pointer check. We find that this
>> >usually makes code easier to read.
>> >> +if (acl != NULL) {
>> >> +free(acl);
>> >> +}
>> >> +if (psd != NULL) {
>> >> +free(psd);
>> >>  }
>> >> -return CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | 
>> >> FILE_FLAG_OVERLAPPED,
>> >> -   PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | 
>> >> PIPE_WAIT,
>> >> -   64, BUFSIZE, BUFSIZE, 0, &sa);
>> >> +return INVALID_HANDLE_VALUE;
>> >>  }
>> >
>> >Thanks again for making OVS more secure!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] Windows: Secure the namedpipe implementation

[Sairam Venugopal]

Update the security policies around the creation of the namedpipe. The
current security updates restrict how the namedpipe can be accessed.

- Disable Network access
- Windows Services can access the namedpipe
- Administrators can access the namedpipe

Signed-off-by: Sairam Venugopal 
---
 lib/stream-windows.c | 91 
 1 file changed, 84 insertions(+), 7 deletions(-)

diff --git a/lib/stream-windows.c b/lib/stream-windows.c
index 44b88bf..7cc6023 100644
--- a/lib/stream-windows.c
+++ b/lib/stream-windows.c
@@ -40,6 +40,9 @@ static void maybe_unlink_and_free(char *path);
 /* Default prefix of a local named pipe. */
 #define LOCAL_PREFIX ".\\pipe\\"
 
+/* Size of the allowed PSIDs for securing Named Pipe. */
+#define ALLOWED_PSIDS_SIZE 2
+
 /* This function has the purpose to remove all the slashes received in s. */
 static char *
 remove_slashes(char *s)
@@ -402,16 +405,90 @@ static HANDLE
 create_pnpipe(char *name)
 {
 SECURITY_ATTRIBUTES sa;
-sa.nLength = sizeof(sa);
-sa.lpSecurityDescriptor = NULL;
+SID_IDENTIFIER_AUTHORITY sia = SECURITY_NT_AUTHORITY;
+DWORD aclSize;
+PSID allowedPsid[ALLOWED_PSIDS_SIZE];
+PSID remoteAccessSid;
+PACL acl = NULL;
+PSECURITY_DESCRIPTOR psd = NULL;
+HANDLE npipe;
+
+/* Disable access over network. */
+if (!AllocateAndInitializeSid(&sia, 1, SECURITY_NETWORK_RID,
+  0, 0, 0, 0, 0, 0, 0, &remoteAccessSid)) {
+goto handle_error;
+}
+
+aclSize = sizeof(ACL) + sizeof(ACCESS_DENIED_ACE) +
+  GetLengthSid(remoteAccessSid) - sizeof(DWORD);
+
+/* Allow Windows Services to access the Named Pipe. */
+if (!AllocateAndInitializeSid(&sia, 1, SECURITY_LOCAL_SYSTEM_RID,
+  0, 0, 0, 0, 0, 0, 0, &allowedPsid[0])) {
+goto handle_error;
+}
+
+/* Allow Administrators to access the Named Pipe. */
+if (!AllocateAndInitializeSid(&sia, 2, SECURITY_BUILTIN_DOMAIN_RID,
+  DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0,
+  &allowedPsid[1])) {
+return INVALID_HANDLE_VALUE;
+}
+
+for (int i = 0; i < ALLOWED_PSIDS_SIZE; i++) {
+aclSize += sizeof(ACCESS_ALLOWED_ACE) +
+   GetLengthSid(allowedPsid[i]) -
+   sizeof(DWORD);
+}
+
+acl = xmalloc(aclSize);
+if (!InitializeAcl(acl, aclSize, ACL_REVISION)) {
+goto handle_error;
+}
+
+/* Add denied ACL. */
+if (!AddAccessDeniedAce(acl, ACL_REVISION,
+GENERIC_ALL, remoteAccessSid)) {
+goto handle_error;
+}
+
+/* Add allowed ACLs. */
+for (int i = 0; i < 2;i++) {
+if (!AddAccessAllowedAce(acl, ACL_REVISION,
+ GENERIC_ALL, allowedPsid[i])) {
+goto handle_error;
+}
+}
+
+psd = xmalloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
+if (!InitializeSecurityDescriptor(psd, SECURITY_DESCRIPTOR_REVISION)) {
+goto handle_error;
+}
+
+/* Set DACL. */
+if (!SetSecurityDescriptorDacl(psd, TRUE, acl, FALSE)) {
+goto handle_error;
+}
+
+sa.nLength = sizeof sa;
 sa.bInheritHandle = TRUE;
+sa.lpSecurityDescriptor = psd;
+
 if (strlen(name) > 256) {
-VLOG_ERR_RL(&rl, "Named pipe name too long.");
-return INVALID_HANDLE_VALUE;
+goto handle_error;
 }
-return CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
-   PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | PIPE_WAIT,
-   64, BUFSIZE, BUFSIZE, 0, &sa);
+
+npipe = CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
+PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | PIPE_WAIT,
+64, BUFSIZE, BUFSIZE, 0, &sa);
+free(acl);
+free(psd);
+return npipe;
+
+handle_error:
+free(acl);
+free(psd);
+return INVALID_HANDLE_VALUE;
 }
 
 /* Passive named pipe connect.  This function creates a new named pipe and
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] Windows: Secure the namedpipe implementation

[Sairam Venugopal]

Hi Ben,

Thanks for taking the time to review this. I will address the coding style 
changes 
along with other potential comments in the next version.

Thanks,
Sairam



On 5/3/17, 1:05 PM, "Ben Pfaff"  wrote:

>On Wed, May 03, 2017 at 12:22:48PM -0700, Sairam Venugopal wrote:
>> Update the security policies around the creation of the namedpipe. The
>> current security updates restrict how the namedpipe can be accessed.
>> 
>> - Disable Network access
>> - Windows Services can access the namedpipe
>> - Administrators can access the namedpipe
>> 
>> Signed-off-by: Sairam Venugopal 
>
>Hi Sairam, thanks for working on making the Windows code more secure.
>It's easy to overlook this kind of thing.
>
>I don't know much about Windows in this area, so I can't review this,
>but I have some style requests.
>
>For the code here, coding-style.rst says:
>Try to avoid casts. Don't cast the return value of malloc().
>Also, xmalloc() never returns NULL, so you need not check for that:
>> +acl = (PACL) xmalloc(aclSize);
>> +if (acl == NULL) {
>> +return INVALID_HANDLE_VALUE;
>> +}
>
>Here, and various other places, coding-style.rst says:
>Comments should be written as full sentences that start with a
>capital letter and end with a period. Put two spaces between
>sentences.
>> +/* Add denied ACL */
>> +if (!AddAccessDeniedAce(acl, ACL_REVISION,
>> +GENERIC_ALL, remoteAccessSid)) {
>> +goto handle_error;
>> +}
>
>Unnecessary cast:
>> +psd = (PSECURITY_DESCRIPTOR) xmalloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
>> +if (!InitializeSecurityDescriptor(psd, SECURITY_DESCRIPTOR_REVISION)) {
>> +goto handle_error;
>> +}
>> +
>> +/* Set DACL */
>> +if (!SetSecurityDescriptorDacl(psd, TRUE, acl, FALSE)) {
>> +goto handle_error;
>> +}
>
>Regarding "sizeof", coding-style.rst says:
>The "sizeof" operator is unique among C operators in that it accepts
>two very different kinds of operands: an expression or a type. In
>general, prefer to specify an expression, e.g. ``int *x =
>xmalloc(sizeof *\ x);``. When the operand of sizeof is an
>expression, there is no need to parenthesize that operand, and
>please don't.
>> +sa.nLength = sizeof(SECURITY_ATTRIBUTES);
>>  sa.bInheritHandle = TRUE;
>> +sa.lpSecurityDescriptor = psd;
>> +
>>  if (strlen(name) > 256) {
>> -VLOG_ERR_RL(&rl, "Named pipe name too long.");
>> -return INVALID_HANDLE_VALUE;
>> +goto handle_error;
>> +}
>> +
>> +npipe = CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
>> +PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | 
>> PIPE_WAIT,
>> +64, BUFSIZE, BUFSIZE, 0, &sa);
>> +free(acl);
>> +free(psd);
>> +return npipe;
>> +handle_error:
>
>Regarding free(), coding-style.rst says:
>Functions that destroy an instance of a dynamically-allocated type
>should accept and ignore a null pointer argument. Code that calls
>such a function (including the C standard library function
>``free()``) should omit a null-pointer check. We find that this
>usually makes code easier to read.
>> +if (acl != NULL) {
>> +free(acl);
>> +}
>> +if (psd != NULL) {
>> +free(psd);
>>  }
>> -return CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
>> -   PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | 
>> PIPE_WAIT,
>> -   64, BUFSIZE, BUFSIZE, 0, &sa);
>> +return INVALID_HANDLE_VALUE;
>>  }
>
>Thanks again for making OVS more secure!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Windows: Secure the namedpipe implementation

[Sairam Venugopal]

Update the security policies around the creation of the namedpipe. The
current security updates restrict how the namedpipe can be accessed.

- Disable Network access
- Windows Services can access the namedpipe
- Administrators can access the namedpipe

Signed-off-by: Sairam Venugopal 
---
 lib/stream-windows.c | 99 
 1 file changed, 92 insertions(+), 7 deletions(-)

diff --git a/lib/stream-windows.c b/lib/stream-windows.c
index 44b88bf..d3bc337 100644
--- a/lib/stream-windows.c
+++ b/lib/stream-windows.c
@@ -40,6 +40,9 @@ static void maybe_unlink_and_free(char *path);
 /* Default prefix of a local named pipe. */
 #define LOCAL_PREFIX ".\\pipe\\"
 
+/* Size of the allowed PSIDs for securing Named Pipe */
+#define ALLOWED_PSIDS_SIZE 2
+
 /* This function has the purpose to remove all the slashes received in s. */
 static char *
 remove_slashes(char *s)
@@ -402,16 +405,98 @@ static HANDLE
 create_pnpipe(char *name)
 {
 SECURITY_ATTRIBUTES sa;
-sa.nLength = sizeof(sa);
-sa.lpSecurityDescriptor = NULL;
+SID_IDENTIFIER_AUTHORITY sia = SECURITY_NT_AUTHORITY;
+DWORD aclSize = sizeof(ACL);
+PSID allowedPsid[ALLOWED_PSIDS_SIZE];
+PSID remoteAccessSid;
+PACL acl = NULL;
+PSECURITY_DESCRIPTOR psd = NULL;
+HANDLE npipe;
+
+/* Disable access over network */
+if (!AllocateAndInitializeSid(&sia, 1, SECURITY_NETWORK_RID,
+  0, 0, 0, 0, 0, 0, 0, &remoteAccessSid)) {
+goto handle_error;
+}
+
+aclSize += sizeof(ACCESS_DENIED_ACE) +
+   GetLengthSid(remoteAccessSid) -
+   sizeof(DWORD);
+
+/* Allow Windows Services to access the Named Pipe */
+if (!AllocateAndInitializeSid(&sia, 1, SECURITY_LOCAL_SYSTEM_RID,
+  0, 0, 0, 0, 0, 0, 0, &allowedPsid[0])) {
+goto handle_error;
+}
+
+/* Allow Administrators to access the Named Pipe */
+if (!AllocateAndInitializeSid(&sia, 2, SECURITY_BUILTIN_DOMAIN_RID,
+  DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0,
+  &allowedPsid[1])) {
+return INVALID_HANDLE_VALUE;
+}
+
+for (int i = 0; i < ALLOWED_PSIDS_SIZE; i++) {
+aclSize += sizeof(ACCESS_ALLOWED_ACE) +
+   GetLengthSid(allowedPsid[i]) -
+   sizeof(DWORD);
+}
+
+acl = (PACL) xmalloc(aclSize);
+if (acl == NULL) {
+return INVALID_HANDLE_VALUE;
+}
+
+if (!InitializeAcl(acl, aclSize, ACL_REVISION)) {
+goto handle_error;
+}
+
+/* Add denied ACL */
+if (!AddAccessDeniedAce(acl, ACL_REVISION,
+GENERIC_ALL, remoteAccessSid)) {
+goto handle_error;
+}
+
+/* Add allowed ACLs */
+for (int i = 0; i < 2;i++) {
+if (!AddAccessAllowedAce(acl, ACL_REVISION,
+ GENERIC_ALL, allowedPsid[i])) {
+goto handle_error;
+}
+}
+
+psd = (PSECURITY_DESCRIPTOR) xmalloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
+if (!InitializeSecurityDescriptor(psd, SECURITY_DESCRIPTOR_REVISION)) {
+goto handle_error;
+}
+
+/* Set DACL */
+if (!SetSecurityDescriptorDacl(psd, TRUE, acl, FALSE)) {
+goto handle_error;
+}
+
+sa.nLength = sizeof(SECURITY_ATTRIBUTES);
 sa.bInheritHandle = TRUE;
+sa.lpSecurityDescriptor = psd;
+
 if (strlen(name) > 256) {
-VLOG_ERR_RL(&rl, "Named pipe name too long.");
-return INVALID_HANDLE_VALUE;
+goto handle_error;
+}
+
+npipe = CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
+PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | PIPE_WAIT,
+64, BUFSIZE, BUFSIZE, 0, &sa);
+free(acl);
+free(psd);
+return npipe;
+handle_error:
+if (acl != NULL) {
+free(acl);
+}
+if (psd != NULL) {
+free(psd);
 }
-return CreateNamedPipe(name, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
-   PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE | PIPE_WAIT,
-   64, BUFSIZE, BUFSIZE, 0, &sa);
+return INVALID_HANDLE_VALUE;
 }
 
 /* Passive named pipe connect.  This function creates a new named pipe and
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Add missing IPCT_LABEL.

[Sairam Venugopal]

Thanks for adding this in.

Acked-by: Sairam Venugopal 





On 4/19/17, 7:01 PM, "ovs-dev-boun...@openvswitch.org on behalf of Jarno 
Rajahalme"  wrote:

>Add the missing enum definition for IPCT_LABEL.
>
>Signed-off-by: Jarno Rajahalme 
>---
> datapath-windows/include/OvsDpInterfaceCtExt.h | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/datapath-windows/include/OvsDpInterfaceCtExt.h 
>b/datapath-windows/include/OvsDpInterfaceCtExt.h
>index 2795edc..3b94778 100644
>--- a/datapath-windows/include/OvsDpInterfaceCtExt.h
>+++ b/datapath-windows/include/OvsDpInterfaceCtExt.h
>@@ -132,6 +132,7 @@ enum ip_conntrack_events {
> IPCT_MARK,
> IPCT_NATSEQADJ,
> IPCT_SECMARK,
>+IPCT_LABEL,
> };
> 
> enum ip_conntrack_expect_events {
>-- 
>2.1.4
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=R8iw4Jr-HMBdatGO514ei63gCELrhnMK2QS9dEZUYCA&s=IjblaY4BjRXCwAXsMU3BHL3ShZjfcICvbBGlg1afGfY&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 5/5] datapath-windows: Fragment NBL based on MRU size

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 3/24/17, 1:51 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>This patch adds support for Fragmenting NBL based on the MRU value.
>MRU value is updated only for Ipv4 fragments, if it is non zero, then
>fragment the NBL and send out the new NBL to the vnic.
>
>Signed-off-by: Anand Kumar 
>---
>v5->v6: No Change
>v4->v5:
>   - Use MRU information in the _OVS_BUFFER_CONTEXT to fragment NBL.
>v3->v4: No Change
>v2->v3:
>   - Updated log message
>v1->v2: No change
>---
> datapath-windows/ovsext/Actions.c | 27 +++
> 1 file changed, 27 insertions(+)
>
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index cbc7640..a68679c 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -34,6 +34,7 @@
> #include "Vport.h"
> #include "Vxlan.h"
> #include "Geneve.h"
>+#include "IpFragment.h"
> 
> #ifdef OVS_DBG_MOD
> #undef OVS_DBG_MOD
>@@ -864,6 +865,8 @@ OvsOutputForwardingCtx(OvsForwardingContext *ovsFwdCtx)
> NDIS_STATUS status = STATUS_SUCCESS;
> POVS_SWITCH_CONTEXT switchContext = ovsFwdCtx->switchContext;
> PCWSTR dropReason;
>+PNET_BUFFER_LIST fragNbl = NULL;
>+POVS_BUFFER_CONTEXT ctx;
> 
> /*
>  * Handle the case where the some of the destination ports are tunneled
>@@ -909,6 +912,30 @@ OvsOutputForwardingCtx(OvsForwardingContext *ovsFwdCtx)
> goto dropit;
> }
> 
>+ctx = 
>(POVS_BUFFER_CONTEXT)NET_BUFFER_LIST_CONTEXT_DATA_START(ovsFwdCtx->curNbl);
>+if (ctx->mru != 0) {
>+/* Fragment nbl based on mru. If it returns NULL then the original
>+ * reassembled NBL is sent out to the VIF which will be dropped if
>+ * the packet size is more than VIF MTU.
>+ */
>+fragNbl = OvsFragmentNBL(ovsFwdCtx->switchContext,
>+ ovsFwdCtx->curNbl,
>+ &(ovsFwdCtx->layers),
>+ ctx->mru, 0, TRUE);
>+if (fragNbl != NULL) {
>+OvsCompleteNBLForwardingCtx(ovsFwdCtx,
>+L"Dropped since fragmenting NBL");
>+status = OvsInitForwardingCtx(ovsFwdCtx,
>+  ovsFwdCtx->switchContext,
>+  fragNbl,
>+  ovsFwdCtx->srcVportNo,
>+  ovsFwdCtx->sendFlags,
>+  
>NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL(fragNbl),
>+  ovsFwdCtx->completionList,
>+  &ovsFwdCtx->layers, FALSE);
>+}
>+}
>+
> OvsSendNBLIngress(ovsFwdCtx->switchContext, ovsFwdCtx->curNbl,
>   ovsFwdCtx->sendFlags);
> /* End this pipeline by resetting the corresponding context. */
>-- 
>2.9.3.windows.1
>
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=3sl4LJX8-HSAc_mfofbqDS1UYgla5hIj4zVdVv8Mz5c&s=CuBYGxQI9b-Q-vjVq6DY8KAqOu1TllZ5TWdmnea67go&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 4/5] datapath-windows: Updated OvsTcpSegmentNBL to handle IP fragments.

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 3/24/17, 1:51 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>With this patch, OvsTcpSegmentNBL not only supports fragmenting NBL
>to TCP segments but also Ipv4 fragments.
>
>To reflect the new changes, renamed function name from OvsTcpSegmentNBL
>to OvsFragmentNBL and created a wrapper for OvsTcpSegmentNBL.
>
>Signed-off-by: Anand Kumar 
>---
>v5->v6: No Change
>v4->v5: Changed a variable mss to fragmentSize.
>v3->v4: No Change
>v2->v3:
>   - Updated log message and function summary
>v1->v2:
>   - Fix compile error for release mode.
>---
> datapath-windows/ovsext/BufferMgmt.c | 194 +--
> datapath-windows/ovsext/BufferMgmt.h |  10 +-
> datapath-windows/ovsext/Geneve.c |   2 +-
> datapath-windows/ovsext/Gre.c|   2 +-
> datapath-windows/ovsext/Stt.c|   2 +-
> datapath-windows/ovsext/User.c   |   2 +-
> datapath-windows/ovsext/Vxlan.c  |   2 +-
> 7 files changed, 152 insertions(+), 62 deletions(-)
>
>diff --git a/datapath-windows/ovsext/BufferMgmt.c 
>b/datapath-windows/ovsext/BufferMgmt.c
>index d99052d..0011c10 100644
>--- a/datapath-windows/ovsext/BufferMgmt.c
>+++ b/datapath-windows/ovsext/BufferMgmt.c
>@@ -1084,6 +1084,31 @@ nblcopy_error:
> return NULL;
> }
> 
>+NDIS_STATUS
>+GetIpHeaderInfo(PNET_BUFFER_LIST curNbl,
>+UINT32 *hdrSize)
>+{
>+CHAR *ethBuf[sizeof(EthHdr)];
>+EthHdr *eth;
>+IPHdr *ipHdr;
>+PNET_BUFFER curNb;
>+
>+curNb = NET_BUFFER_LIST_FIRST_NB(curNbl);
>+ASSERT(NET_BUFFER_NEXT_NB(curNb) == NULL);
>+
>+eth = (EthHdr *)NdisGetDataBuffer(curNb, ETH_HEADER_LENGTH,
>+  (PVOID)ðBuf, 1, 0);
>+if (eth == NULL) {
>+return NDIS_STATUS_INVALID_PACKET;
>+}
>+ipHdr = (IPHdr *)((PCHAR)eth + ETH_HEADER_LENGTH);
>+if (ipHdr == NULL) {
>+return NDIS_STATUS_INVALID_PACKET;
>+}
>+*hdrSize = (UINT32)(ETH_HEADER_LENGTH + (ipHdr->ihl * 4));
>+return NDIS_STATUS_SUCCESS;
>+}
>+
> /*
>  * --
>  * GetSegmentHeaderInfo
>@@ -1113,15 +1138,16 @@ GetSegmentHeaderInfo(PNET_BUFFER_LIST nbl,
> 
> /*
>  * --
>- * FixSegmentHeader
>+ * FixPacketHeader
>  *
>- *Fix IP length, IP checksum, TCP sequence number and TCP checksum
>- *in the segment.
>+ *Fix IP length, Offset, IP checksum, TCP sequence number and TCP checksum
>+ *in the netbuffer if applicable.
>  * --
>  */
> static NDIS_STATUS
>-FixSegmentHeader(PNET_BUFFER nb, UINT16 segmentSize, UINT32 seqNumber,
>- BOOLEAN lastPacket, UINT16 packetCounter)
>+FixPacketHeader(PNET_BUFFER nb, UINT16 segmentSize, UINT32 seqNumber,
>+BOOLEAN lastPacket, UINT16 packetCounter, UINT16 offset,
>+BOOLEAN isFragment)
> {
> EthHdr *dstEth = NULL;
> TCPHdr *dstTCP = NULL;
>@@ -1140,41 +1166,55 @@ FixSegmentHeader(PNET_BUFFER nb, UINT16 segmentSize, 
>UINT32 seqNumber,
> case ETH_TYPE_IPV4_NBO:
> {
> IPHdr *dstIP = NULL;
>-
>-ASSERT((INT)MmGetMdlByteCount(mdl) - NET_BUFFER_CURRENT_MDL_OFFSET(nb)
>+if (!isFragment) {
>+ASSERT((INT)MmGetMdlByteCount(mdl) - 
>NET_BUFFER_CURRENT_MDL_OFFSET(nb)
> >= sizeof(EthHdr) + sizeof(IPHdr) + sizeof(TCPHdr));
>-dstIP = (IPHdr *)((PCHAR)dstEth + sizeof(*dstEth));
>-dstTCP = (TCPHdr *)((PCHAR)dstIP + dstIP->ihl * 4);
>-ASSERT((INT)MmGetMdlByteCount(mdl) - NET_BUFFER_CURRENT_MDL_OFFSET(nb)
>+dstIP = (IPHdr *)((PCHAR)dstEth + sizeof(*dstEth));
>+dstTCP = (TCPHdr *)((PCHAR)dstIP + dstIP->ihl * 4);
>+ASSERT((INT)MmGetMdlByteCount(mdl) - 
>NET_BUFFER_CURRENT_MDL_OFFSET(nb)
> >= sizeof(EthHdr) + dstIP->ihl * 4 + TCP_HDR_LEN(dstTCP));
> 
>-/* Fix IP length and checksum */
>-ASSERT(dstIP->protocol == IPPROTO_TCP);
>-dstIP->tot_len = htons(segmentSize + dstIP->ihl * 4 + 
>TCP_HDR_LEN(dstTCP));
>-dstIP->id += packetCounter;
>+/* Fix IP length and checksum */
>+ASSERT(dstIP->protocol == IPPROTO_TCP);
>+dstIP->tot_len = htons(segmentSize + dstIP->ihl * 4 + 
>TCP_HDR_LEN(dstTCP));
>+dstIP->id += packetCounter;
>+dstTCP->seq = htonl(seqNumber);
>+
>+/*
>+ * Set the TCP

Re: [ovs-dev] [PATCH v6 3/5] datapath-windows: Retain MRU value in the _OVS_BUFFER_CONTEXT.

[Sairam Venugopal]

Thanks for incorporating this change.

Acked-by: Sairam Venugopal 





On 3/24/17, 1:51 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>This patch introduces a new field MRU(Maximum Recieved Unit) in the
>_OVS_BUFFER_CONTEXT and it is used only for Ip Fragments to retain MRU for
>the reassembled IP datagram when the packet is forwarded to userspace.
>
>Signed-off-by: Anand Kumar 
>---
>v5->v6: No Change
>v4->v5:
>   - Refactored the patch as MRU field is removed form 
> ovsForwardingContext.
>   - Added MRU field in _OVS_BUFFER_CONTEXT.
>   - Updated commit message.
>v3->v4: No Change
>v2->v3: No change
>v1->v2: No change
>---
> datapath-windows/ovsext/BufferMgmt.c |  1 +
> datapath-windows/ovsext/BufferMgmt.h |  1 +
> datapath-windows/ovsext/DpInternal.h |  2 +-
> datapath-windows/ovsext/IpFragment.c |  2 ++
> datapath-windows/ovsext/User.c   | 20 +++-
> 5 files changed, 24 insertions(+), 2 deletions(-)
>
>diff --git a/datapath-windows/ovsext/BufferMgmt.c 
>b/datapath-windows/ovsext/BufferMgmt.c
>index 6027c35..d99052d 100644
>--- a/datapath-windows/ovsext/BufferMgmt.c
>+++ b/datapath-windows/ovsext/BufferMgmt.c
>@@ -266,6 +266,7 @@ OvsInitNBLContext(POVS_BUFFER_CONTEXT ctx,
> ctx->flags = flags;
> ctx->srcPortNo = srcPortNo;
> ctx->origDataLength = origDataLength;
>+ctx->mru = 0;
> }
> 
> 
>diff --git a/datapath-windows/ovsext/BufferMgmt.h 
>b/datapath-windows/ovsext/BufferMgmt.h
>index 11a05b2..77b2854 100644
>--- a/datapath-windows/ovsext/BufferMgmt.h
>+++ b/datapath-windows/ovsext/BufferMgmt.h
>@@ -58,6 +58,7 @@ typedef union _OVS_BUFFER_CONTEXT {
> UINT32 origDataLength;
> UINT32 dataOffsetDelta;
> };
>+UINT16 mru;
> };
> 
> UINT64 value[MEM_ALIGN_SIZE(16) >> 3];
>diff --git a/datapath-windows/ovsext/DpInternal.h 
>b/datapath-windows/ovsext/DpInternal.h
>index f62fc55..9d1a783 100644
>--- a/datapath-windows/ovsext/DpInternal.h
>+++ b/datapath-windows/ovsext/DpInternal.h
>@@ -298,7 +298,7 @@ typedef struct _OVS_PACKET_INFO {
> typedef struct OvsPacketExecute {
>uint32_t dpNo;
>uint32_t inPort;
>-
>+   uint16 mru;
>uint32_t packetLen;
>uint32_t actionsLen;
>PNL_MSG_HDR nlMsgHdr;
>diff --git a/datapath-windows/ovsext/IpFragment.c 
>b/datapath-windows/ovsext/IpFragment.c
>index 37abcd8..b0294ce 100644
>--- a/datapath-windows/ovsext/IpFragment.c
>+++ b/datapath-windows/ovsext/IpFragment.c
>@@ -208,6 +208,8 @@ OvsIpv4Reassemble(POVS_SWITCH_CONTEXT switchContext,
> OvsCompleteNBL(switchContext, *curNbl, TRUE);
> }
> /* Store mru in the ovs buffer context. */
>+ctx = (POVS_BUFFER_CONTEXT)NET_BUFFER_LIST_CONTEXT_DATA_START(*newNbl);
>+ctx->mru = entry->mru;
> *curNbl = *newNbl;
> return status;
> }
>diff --git a/datapath-windows/ovsext/User.c b/datapath-windows/ovsext/User.c
>index c7ac284..3154640 100644
>--- a/datapath-windows/ovsext/User.c
>+++ b/datapath-windows/ovsext/User.c
>@@ -283,7 +283,8 @@ OvsNlExecuteCmdHandler(POVS_USER_PARAMS_CONTEXT 
>usrParamsCtx,
> [OVS_PACKET_ATTR_ACTIONS] = {.type = NL_A_UNSPEC, .optional = FALSE},
> [OVS_PACKET_ATTR_USERDATA] = {.type = NL_A_UNSPEC, .optional = TRUE},
> [OVS_PACKET_ATTR_EGRESS_TUN_KEY] = {.type = NL_A_UNSPEC,
>-.optional = TRUE}
>+.optional = TRUE},
>+[OVS_PACKET_ATTR_MRU] = { .type = NL_A_U16, .optional = TRUE }
> };
> 
> RtlZeroMemory(&execute, sizeof(OvsPacketExecute));
>@@ -381,6 +382,10 @@ _MapNlAttrToOvsPktExec(PNL_MSG_HDR nlMsgHdr, PNL_ATTR 
>*nlAttrs,
> ASSERT(keyAttrs[OVS_KEY_ATTR_IN_PORT]);
> execute->inPort = NlAttrGetU32(keyAttrs[OVS_KEY_ATTR_IN_PORT]);
> execute->keyAttrs = keyAttrs;
>+
>+if (nlAttrs[OVS_PACKET_ATTR_MRU]) {
>+execute->mru = NlAttrGetU16(nlAttrs[OVS_PACKET_ATTR_MRU]);
>+}
> }
> 
> NTSTATUS
>@@ -397,6 +402,7 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
> POVS_VPORT_ENTRYvport = NULL;
> PNL_ATTR tunnelAttrs[__OVS_TUNNEL_KEY_ATTR_MAX];
> OvsFlowKey tempTunKey = {0};
>+POVS_BUFFER_CONTEXT ctx;
> 
> if (execute->packetLen == 0) {
> status = STATUS_INVALID_PARAMETER;
>@@ -459,6 +465,9 @@ OvsExecuteDpIoctl(OvsPacketExecute *execute)
> ndisStatus = OvsExtractFlow(pNbl, execute->inPort, &key, &layers,
>  tempTunKey.tunKey.dst == 0 ? NULL : &tempTunKey.tunKey);
> 
>+ctx = (POVS_BUFFER_CONTEXT)NET_BUFFER_LIST_CONTEXT_DA

Re: [ovs-dev] [PATCH v6 2/5] datapath-windows: Added Ipv4 fragments support in Conntrack

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 3/24/17, 1:51 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>This patch adds support for tracking Ipv4 fragments in conntrack module.
>Individual fragments are not tracked and are consumed by the
>fragmentation/reassembly. Only the reassembled Ipv4 datagram is tracked and
>treated as a single ct entry.
>
>Signed-off-by: Anand Kumar 
>---
>v5->v6: No Change
>v4->v5:
>   - Removed MRU argument from function declarations as MRU is now retained
>   in _OVS_BUFFER_CONTEXT.
>v3->v4: No Change
>v2->v3:
>   - Updated log messages and fixed alignment.
>v1->v2: No change
>---
> datapath-windows/ovsext/Actions.c   | 13 +
> datapath-windows/ovsext/Conntrack.c | 35 ++-
> datapath-windows/ovsext/Conntrack.h |  6 +-
> 3 files changed, 40 insertions(+), 14 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Actions.c 
>b/datapath-windows/ovsext/Actions.c
>index 46f84bc..cbc7640 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -2032,11 +2032,16 @@ OvsDoExecuteActions(POVS_SWITCH_CONTEXT switchContext,
> }
> }
> 
>-status = OvsExecuteConntrackAction(ovsFwdCtx.curNbl, layers,
>-   key, (const PNL_ATTR)a);
>+status = OvsExecuteConntrackAction(switchContext, 
>&ovsFwdCtx.curNbl,
>+   ovsFwdCtx.completionList,
>+   
>ovsFwdCtx.fwdDetail->SourcePortId,
>+   layers, key, (const 
>PNL_ATTR)a);
> if (status != NDIS_STATUS_SUCCESS) {
>-OVS_LOG_ERROR("CT Action failed");
>-dropReason = L"OVS-conntrack action failed";
>+/* Pending NBLs are consumed by Defragmentation. */
>+if (status != NDIS_STATUS_PENDING) {
>+OVS_LOG_ERROR("CT Action failed");
>+dropReason = L"OVS-conntrack action failed";
>+}
> goto dropit;
> }
> break;
>diff --git a/datapath-windows/ovsext/Conntrack.c 
>b/datapath-windows/ovsext/Conntrack.c
>index 35ab7a1..ea3c111 100644
>--- a/datapath-windows/ovsext/Conntrack.c
>+++ b/datapath-windows/ovsext/Conntrack.c
>@@ -15,6 +15,7 @@
>  */
> 
> #include "Conntrack.h"
>+#include "IpFragment.h"
> #include "Jhash.h"
> #include "PacketParser.h"
> #include "Event.h"
>@@ -317,13 +318,23 @@ OvsCtEntryExpired(POVS_CT_ENTRY entry)
> }
> 
> static __inline NDIS_STATUS
>-OvsDetectCtPacket(OvsFlowKey *key)
>+OvsDetectCtPacket(POVS_SWITCH_CONTEXT switchContext,
>+  PNET_BUFFER_LIST *curNbl,
>+  OvsCompletionList *completionList,
>+  NDIS_SWITCH_PORT_ID sourcePort,
>+  OvsFlowKey *key,
>+  PNET_BUFFER_LIST *newNbl)
> {
> /* Currently we support only Unfragmented TCP packets */
> switch (ntohs(key->l2.dlType)) {
> case ETH_TYPE_IPV4:
> if (key->ipKey.nwFrag != OVS_FRAG_TYPE_NONE) {
>-return NDIS_STATUS_NOT_SUPPORTED;
>+return OvsProcessIpv4Fragment(switchContext,
>+  curNbl,
>+  completionList,
>+  sourcePort,
>+  key->tunKey.tunnelId,
>+  newNbl);
> }
> if (key->ipKey.nwProto == IPPROTO_TCP
> || key->ipKey.nwProto == IPPROTO_UDP
>@@ -706,11 +717,16 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
> /*
>  *---
>  * OvsExecuteConntrackAction
>- * Executes Conntrack actions XXX - Add more
>+ * Executes Conntrack actions
>+ * For the Ipv4 fragments, consume the orginal fragment NBL
>+ * XXX - Add more
>  *---
>  */
> NDIS_STATUS
>-OvsExecuteConntrackAction(PNET_BUFFER_LIST curNbl,
>+OvsExecuteConntrackAction(POVS_SWITCH_CONTEXT switchContext,
>+  PNET_BUFFER_LIST *curNbl,
>+  OvsCompletionList *completionList,
>+  NDIS_SWITCH_PORT_ID sourcePort,
>   OVS_PACKET_HDR_INFO *layers,
>   OvsFlowKey *key,
>  

Re: [ovs-dev] [PATCH v6 1/5] datapath-windows: Added a new file to support Ipv4 fragments.

[Sairam Venugopal]

Thanks for the patches!

Acked-by: Sairam Venugopal 






On 3/24/17, 1:51 PM, "ovs-dev-boun...@openvswitch.org on behalf of Anand Kumar" 
 wrote:

>This patch adds functionalities to support IPv4 fragments, which will be
>used by Conntrack module.
>
>Added a new structure to hold the Ipv4 fragments and a hash table to
>hold Ipv4 datagram entries. Also added a clean up thread that runs
>every minute to delete the expired IPv4 datagram entries.
>
>The individual fragments are ignored by the conntrack. Once all the
>fragments are recieved, a new NBL is created out of the reassembled
>fragments and conntrack executes actions on the new NBL.
>
>Created new APIs OvsProcessIpv4Fragment() to process individual fragments,
>OvsIpv4Reassemble() to reassemble Ipv4 fragments.
>
>Signed-off-by: Anand Kumar 
>---
>v5->v6: No Change
>v4->v5:
>  - Modified Patch 3 to retain MRU in _OVS_BUFFER_CONTEXT instead of
>   using it in ovsForwardingContext with minor changes in rest of the
>   patches.
>v3->v4:
>  - Rebase
>  - Acquire read lock for read operations.
>v2->v3:
>  - using spinlock instead of RW lock.
>  - updated log messages, summary, fixed alignment issues.
>v1->v2:
>  - Patch 4 updated to make it compile for release mode.
>---
> datapath-windows/automake.mk   |   2 +
> datapath-windows/ovsext/Debug.h|   3 +-
> datapath-windows/ovsext/IpFragment.c   | 500 +
> datapath-windows/ovsext/IpFragment.h   |  73 +
> datapath-windows/ovsext/Switch.c   |   9 +
> datapath-windows/ovsext/ovsext.vcxproj |   2 +
> 6 files changed, 588 insertions(+), 1 deletion(-)
> create mode 100644 datapath-windows/ovsext/IpFragment.c
> create mode 100644 datapath-windows/ovsext/IpFragment.h
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index 53983ae..4f7b55a 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -32,6 +32,8 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/Flow.h \
>   datapath-windows/ovsext/Gre.h \
>   datapath-windows/ovsext/Gre.c \
>+  datapath-windows/ovsext/IpFragment.c \
>+  datapath-windows/ovsext/IpFragment.h \
>   datapath-windows/ovsext/IpHelper.c \
>   datapath-windows/ovsext/IpHelper.h \
>   datapath-windows/ovsext/Jhash.c \
>diff --git a/datapath-windows/ovsext/Debug.h b/datapath-windows/ovsext/Debug.h
>index cae6ac9..6de1812 100644
>--- a/datapath-windows/ovsext/Debug.h
>+++ b/datapath-windows/ovsext/Debug.h
>@@ -42,8 +42,9 @@
> #define OVS_DBG_STT  BIT32(22)
> #define OVS_DBG_CONTRK   BIT32(23)
> #define OVS_DBG_GENEVE   BIT32(24)
>+#define OVS_DBG_IPFRAG   BIT32(25)
> 
>-#define OVS_DBG_LAST 24  /* Set this to the last defined module number. */
>+#define OVS_DBG_LAST 25  /* Set this to the last defined module number. */
> /* Please add above OVS_DBG_LAST. */
> 
> #define OVS_DBG_ERRORDPFLTR_ERROR_LEVEL
>diff --git a/datapath-windows/ovsext/IpFragment.c 
>b/datapath-windows/ovsext/IpFragment.c
>new file mode 100644
>index 000..37abcd8
>--- /dev/null
>+++ b/datapath-windows/ovsext/IpFragment.c
>@@ -0,0 +1,500 @@
>+/*
>+ * Copyright (c) 2017 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_licenses_LICENSE-2D2.0&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=1abLNFAEjs9Cscb3AJMpOuBIqOdZ-_J4Gaaxv_J69Uc&s=8iji8m6jUpxnBC2ddLAT_24ix4jr_EMbFXX31y-p3h4&e=
> 
>+ *
>+ * 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.
>+ */
>+
>+#include "Conntrack.h"
>+#include "Debug.h"
>+#include "IpFragment.h"
>+#include "Jhash.h"
>+#include "Offload.h"
>+#include "PacketParser.h"
>+
>+#ifdef OVS_DBG_MOD
>+#undef OVS_DBG_MOD
>+#endif
>+#define OVS_DBG_MOD OVS_DBG_IPFRAG
>+
>+/* Function declarations */
>+static VOID OvsIpFragmentEntryCleaner(PVOID data);
>+static VOID OvsIpFragmentEntryDelete(POVS_IPFRAG_ENTRY entry);
>+
>+/* Global and static variables */
>+static OVS_IPFRAG_THREAD_CTX ipFragThreadCtx;
>+static PNDIS_RW_LOCK_EX ovsIpFragmentHashLockObj;
>+stat

Re: [ovs-dev] [PATCH 2/3 v2] datapath-windows: Add NAT module in conntrack

[Sairam Venugopal]

Hi Yin,

Thanks for sending over the patch. While it looks good for the most part, there 
are certain indentations that need fixing. I will send those out separately.

I see that you have allocated - ovsNatLock and have added in stubs for flush 
and cleanup similar to Conntrack.c. 

However, I don’t see you taking out the lock for accessing the NAT tables. How 
are you verifying thread-safety here?

Thanks,
Sairam




On 3/22/17, 3:11 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yin Lin" 
 wrote:

>Signed-off-by: Yin Lin 
>
>Issue: #
>Change-Id: I6f37360c36525548b343f0016304015fec8aba7d
>---
> datapath-windows/automake.mk|   2 +
> datapath-windows/ovsext/Conntrack-nat.c | 437 
> datapath-windows/ovsext/Conntrack-nat.h |  39 +++
> 3 files changed, 478 insertions(+)
> create mode 100644 datapath-windows/ovsext/Conntrack-nat.c
> create mode 100644 datapath-windows/ovsext/Conntrack-nat.h
>
>diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
>index 53983ae..296e785 100644
>--- a/datapath-windows/automake.mk
>+++ b/datapath-windows/automake.mk
>@@ -16,7 +16,9 @@ EXTRA_DIST += \
>   datapath-windows/ovsext/Conntrack-icmp.c \
>   datapath-windows/ovsext/Conntrack-other.c \
>   datapath-windows/ovsext/Conntrack-related.c \
>+datapath-windows/ovsext/Conntrack-nat.c \
>   datapath-windows/ovsext/Conntrack-tcp.c \
>+datapath-windows/ovsext/Conntrack-nat.h \
>   datapath-windows/ovsext/Conntrack.c \
>   datapath-windows/ovsext/Conntrack.h \
>   datapath-windows/ovsext/Datapath.c \
>diff --git a/datapath-windows/ovsext/Conntrack-nat.c 
>b/datapath-windows/ovsext/Conntrack-nat.c
>new file mode 100644
>index 000..4930694
>--- /dev/null
>+++ b/datapath-windows/ovsext/Conntrack-nat.c
>@@ -0,0 +1,437 @@
>+#include "Conntrack-nat.h"
>+#include "Jhash.h"
>+
>+PLIST_ENTRY ovsNatTable = NULL;
>+PLIST_ENTRY ovsUnNatTable = NULL;
>+static PNDIS_RW_LOCK_EX ovsNatLock;
>+
>+/*
>+ *---
>+ * OvsHashNatKey
>+ * Hash NAT related fields in a Conntrack key.
>+ *---
>+ */
>+static __inline UINT32
>+OvsHashNatKey(const OVS_CT_KEY *key)
>+{
>+UINT32 hash = 0;
>+#define HASH_ADD(field) \
>+hash = OvsJhashBytes(&key->field, sizeof(key->field), hash)
>+
>+HASH_ADD(src.addr.ipv4_aligned);
>+HASH_ADD(dst.addr.ipv4_aligned);
>+HASH_ADD(src.port);
>+HASH_ADD(dst.port);
>+HASH_ADD(zone);
>+#undef HASH_ADD
>+return hash;
>+}
>+
>+/*
>+ *---
>+ * OvsNatKeyAreSame
>+ * Compare NAT related fields in a Conntrack key.
>+ *---
>+ */
>+static __inline BOOLEAN
>+OvsNatKeyAreSame(const OVS_CT_KEY *key1, const OVS_CT_KEY *key2)
>+{
>+// XXX: Compare IPv6 key as well
>+#define FIELD_COMPARE(field) \
>+if (key1->field != key2->field) return FALSE
>+
>+FIELD_COMPARE(src.addr.ipv4_aligned);
>+FIELD_COMPARE(dst.addr.ipv4_aligned);
>+FIELD_COMPARE(src.port);
>+FIELD_COMPARE(dst.port);
>+FIELD_COMPARE(zone);
>+return TRUE;
>+#undef FIELD_COMPARE
>+}
>+
>+/*
>+ *---
>+ * OvsNaGetBucket
>+ * Returns the row of NAT table that has the same hash as the given NAT
>+ * hash key. If isReverse is TRUE, returns the row of reverse NAT table
>+ * instead.
>+ *---
>+ */
>+static __inline PLIST_ENTRY
>+OvsNatGetBucket(const OVS_CT_KEY *key, BOOLEAN isReverse)
>+{
>+uint32_t hash = OvsHashNatKey(key);
>+if (isReverse) {
>+return &ovsUnNatTable[hash & NAT_HASH_TABLE_MASK];
>+} else {
>+return &ovsNatTable[hash & NAT_HASH_TABLE_MASK];
>+}
>+}
>+
>+/*
>+ *---
>+ * OvsNatInit
>+ * Initialize NAT related resources.
>+ *---
>+ */
>+NTSTATUS OvsNatInit(POVS_SWITCH_CONTEXT context)
>+{
>+ASSERT(ovsNatTable == NULL);
>+
>+/* Init the sync-lock */
>+ovsNatLock = NdisAllocateRWLock(context->NdisFilterHandle);
>+if (ovsNatLock == NULL) {
>+goto failNoMem;
>+}
>+
>+/* Init the Hash Buffer */
>+ovsNatTable = OvsAllocateMemoryWithTag(
>+sizeof(LIST_ENTRY) * NAT_HASH_TABLE_SIZE,
>+OVS_CT_POOL_TAG);
>+if (ovsNatTable == NULL) {
>+goto freeNatLock;
>+}
>+
>+ovsUnNatTable = OvsAllocateMemoryWithTag(
>+sizeof(LIST_ENTRY) * NAT_HASH_TABLE_SIZE,
>+OVS_CT_POOL_TAG);
>+if (ovsUnNatTable == NULL) {
>+goto freeNatTable;
>+}
>+
>+for (int i = 0; i < NAT_HASH_TABLE_SIZE; i++) {
>+InitializeListHead(&ovsN

[ovs-dev] [PATCH] datapath-windows: Add support for OVS_CT_ATTR_FORCE_COMMIT

[Sairam Venugopal]

Add support for handling OVS_CT_ATTR_FORCE_COMMIT in Conntrack action.
When this flag is specified, it implicitly means commit and deletes
entries in the reverse direction.

Signed-off-by: Sairam Venugopal 
---
 datapath-windows/ovsext/Conntrack.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 9f41861..35ab7a1 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -633,6 +633,7 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
   OvsFlowKey *key,
   OVS_PACKET_HDR_INFO *layers,
   BOOLEAN commit,
+  BOOLEAN force,
   UINT16 zone,
   MD_MARK *mark,
   MD_LABELS *labels,
@@ -653,6 +654,13 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
 /* Lookup Conntrack entries for a matching entry */
 entry = OvsCtLookup(&ctx);
 BOOLEAN entryCreated = FALSE;
+
+/* Delete entry in reverse direction if 'force' is specified */
+if (entry && force && ctx.reply) {
+OvsCtEntryDelete(entry);
+entry = NULL;
+}
+
 if (!entry) {
 /* If no matching entry was found, create one and add New state */
 entry = OvsCtEntryCreate(curNbl, key->ipKey.nwProto,
@@ -709,6 +717,7 @@ OvsExecuteConntrackAction(PNET_BUFFER_LIST curNbl,
 {
 PNL_ATTR ctAttr;
 BOOLEAN commit = FALSE;
+BOOLEAN force = FALSE;
 UINT16 zone = 0;
 MD_MARK *mark = NULL;
 MD_LABELS *labels = NULL;
@@ -721,6 +730,7 @@ OvsExecuteConntrackAction(PNET_BUFFER_LIST curNbl,
 return status;
 }
 
+/* XXX Convert this to NL_ATTR_FOR_EACH */
 ctAttr = NlAttrFindNested(a, OVS_CT_ATTR_ZONE);
 if (ctAttr) {
 zone = NlAttrGetU16(ctAttr);
@@ -748,9 +758,15 @@ OvsExecuteConntrackAction(PNET_BUFFER_LIST curNbl,
 return NDIS_STATUS_NOT_SUPPORTED;
 }
 }
+ctAttr = NlAttrFindNested(a, OVS_CT_ATTR_FORCE_COMMIT);
+if (ctAttr) {
+force = TRUE;
+/* Force implicitly means commit */
+commit = TRUE;
+}
 
-status = OvsCtExecute_(curNbl, key, layers,
-   commit, zone, mark, labels, helper);
+status = OvsCtExecute_(curNbl, key, layers, commit, force,
+   zone, mark, labels, helper);
 return status;
 }
 
-- 
2.9.0.windows.1

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

Re: [ovs-dev] [PATCH] datapath-windows: Trigger conntrack event after setting mark and label

[Sairam Venugopal]

Hi Shashank,

Can you explain this? The intent of the patch is not to confirm if an entry 
exists. Instead it is to track if an entry is created as part of the current CT 
action.

Not all CT actions trigger an Entry Creation. If an entry is created, then we 
need to delay the event generation until Mark and Label are present.

Thanks,
Sairam

From: Shashank Ram
Date: Thursday, March 2, 2017 at 2:05 PM
To: Sairam Venugopal, "d...@openvswitch.org<mailto:d...@openvswitch.org>"
Subject: Re: [ovs-dev] [PATCH] datapath-windows: Trigger conntrack event after 
setting mark and label


Thanks Sai for the change.


I was wondering if you could add a helper function to lookup the OVS_CT_ENTRY 
that got added to the OvsConntrackKeyLookupCtx list, instead of passing a 
boolean around to functions.

i.e replace "entryCreated" with "IsEntryCreated()".


Thanks,

Shashank


From: ovs-dev-boun...@openvswitch.org<mailto:ovs-dev-boun...@openvswitch.org> 
mailto:ovs-dev-boun...@openvswitch.org>> on 
behalf of Sairam Venugopal mailto:vsai...@vmware.com>>
Sent: Thursday, March 2, 2017 1:41:03 PM
To: d...@openvswitch.org<mailto:d...@openvswitch.org>
Subject: [ovs-dev] [PATCH] datapath-windows: Trigger conntrack event after 
setting mark and label

New Conntrack Entry event should be triggered after setting the mark and
label fields. The current RW lock implementation prevents Event Handler
from reading the entry until mark/label is set.

Fixing the workflow to trigger the event after setting mark/label.

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

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index d1be480..9f41861 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -168,7 +168,7 @@ OvsCtAddEntry(POVS_CT_ENTRY entry, OvsConntrackKeyLookupCtx 
*ctx, UINT64 now)
 entry->timestampStart = now;
 InsertHeadList(&ovsConntrackTable[ctx->hash & CT_HASH_TABLE_MASK],
&entry->link);
-OvsPostCtEventEntry(entry, OVS_EVENT_CT_NEW);
+
 ctTotalEntries++;
 }

@@ -179,9 +179,11 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
  OvsConntrackKeyLookupCtx *ctx,
  OvsFlowKey *key,
  BOOLEAN commit,
- UINT64 currentTime)
+ UINT64 currentTime,
+ BOOLEAN *entryCreated)
 {
 POVS_CT_ENTRY entry = NULL;
+*entryCreated = FALSE;
 UINT32 state = 0;
 switch (ipProto)
 {
@@ -211,6 +213,7 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 entry->parent = parentEntry;
 }
 OvsCtAddEntry(entry, ctx, currentTime);
+*entryCreated = TRUE;
 }

 OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
@@ -232,6 +235,7 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 return NULL;
 }
 OvsCtAddEntry(entry, ctx, currentTime);
+*entryCreated = TRUE;
 }

 OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
@@ -246,6 +250,7 @@ OvsCtEntryCreate(PNET_BUFFER_LIST curNbl,
 return NULL;
 }
 OvsCtAddEntry(entry, ctx, currentTime);
+*entryCreated = TRUE;
 }

 OvsCtUpdateFlowKey(key, state, ctx->key.zone, 0, NULL);
@@ -525,10 +530,12 @@ OvsProcessConntrackEntry(PNET_BUFFER_LIST curNbl,
  OvsFlowKey *key,
  UINT16 zone,
  BOOLEAN commit,
- UINT64 currentTime)
+ UINT64 currentTime,
+ BOOLEAN *entryCreated)
 {
 POVS_CT_ENTRY entry = ctx->entry;
 UINT32 state = 0;
+*entryCreated = FALSE;

 /* If an entry was found, update the state based on TCP flags */
 if (ctx->related) {
@@ -555,7 +562,8 @@ OvsProcessConntrackEntry(PNET_BUFFER_LIST curNbl,
 OvsCtEntryDelete(ctx->entry);
 ctx->entry = NULL;
 entry = OvsCtEntryCreate(curNbl, key->ipKey.nwProto, l4Offset,
- ctx, key, commit, currentTime);
+ ctx, key, commit, currentTime,
+ entryCreated);
 if (!entry) {
 return NULL;
 }
@@ -644,17 +652,19 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,

 /* Lookup Conntrack entries for a matching entry */
 entry = OvsCtLookup(&ctx);
-
+BOOLEAN entryCreated = FALSE;
 if (!entry) {
 /* If no matching entry was found, create one and add New state */

Re: [ovs-dev] [PATCH 07/10] windows: add include to stream-windows.c

[Sairam Venugopal]

Acked-by: Sairam Venugopal 






On 2/5/17, 8:41 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin Serdean" 
 
wrote:

>fatal_signal_unlink_file_now is used but the header for it is missing in
>the include section.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> lib/stream-windows.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/lib/stream-windows.c b/lib/stream-windows.c
>index 1950014..44b88bf 100644
>--- a/lib/stream-windows.c
>+++ b/lib/stream-windows.c
>@@ -1,5 +1,5 @@
> /*
>- * Copyright (c) 2016 Cloudbase Solutions Srl
>+ * Copyright (c) 2016, 2017 Cloudbase Solutions Srl
>  *
>  * Licensed under the Apache License, Version 2.0 (the "License");
>  * you may not use this file except in compliance with the License.
>@@ -22,6 +22,7 @@
> #include 
> #include "poll-loop.h"
> #include "dirs.h"
>+#include "fatal-signal.h"
> #include "util.h"
> #include "stream-provider.h"
> #include "openvswitch/vlog.h"
>-- 
>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&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=EMvAFL6hi4dJTHjZN0D_bsrzIyU7Z0yKkVrFcCmEYac&s=YxdZd27GFcaY5WwD71S8a3ZVYchl2CtEGh1nJOlJcys&e=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev