datapath-windows: Removed memory barrier and master lock

There is no need to enforce Netlink serialization on transactions
sent from userspace. The access to the driver's shared resources
is synchronized anyway. Thus I have removed the master lock.

I also removed the memory barrier from filter dispatch routine. A
memory barrier is already in place in OvsReleaseSwitchContext
function, due to the use of InterlockedCompareExchange function.

Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>

1 files changed, 0 insertions, 14 deletions

diff --git a/datapath-windows/ovsext/Datapath.h b/datapath-windows/ovsext/Datapath.h
index dbc9dea58..2c61d8217 100644
--- a/datapath-windows/ovsext/Datapath.h
+++ b/datapath-windows/ovsext/Datapath.h
@@ -52,20 +52,6 @@ typedef struct _OVS_OPEN_INSTANCE {
     POVS_USER_PACKET_QUEUE packetQueue;
     UINT32 pid;
 
-    /*
-     * On platforms that support netlink natively, there's generally some form of
-     * serialization between concurrent calls to netlink sockets. However, OVS
-     * userspace guarantees that a given netlink handle is not concurrently used.
-     * Despite this, we do want to have some basic checks in the kernel to make
-     * sure that things don't break if there are concurrent calls.
-     *
-     * This is generally not an issue since kernel data structure access should
-     * be sychronized anyway. Only reason to have this safeguared is to protect
-     * the state in "state-aware" read calls which rely on previous state. This
-     * restriction might go away as the userspace code gets implemented.
-     */
-     INT inUse;
-
     struct {
         POVS_MESSAGE ovsMsg;    /* OVS message passed during dump start. */
         UINT32 index[2];        /* markers to continue dump from. One or more