datapath-windows: Removed memory barrier and master lock
authorSorin Vinturis <svinturis@cloudbasesolutions.com>
Wed, 27 May 2015 17:08:00 +0000 (17:08 +0000)
committerBen Pfaff <blp@nicira.com>
Wed, 27 May 2015 19:46:05 +0000 (12:46 -0700)
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>
datapath-windows/ovsext/Datapath.c
datapath-windows/ovsext/Datapath.h

index 185bfb5..b5832de 100644 (file)
@@ -726,12 +726,6 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
         goto exit;
     }
 
-    /* Concurrent netlink operations are not supported. */
-    if (InterlockedCompareExchange((LONG volatile *)&instance->inUse, 1, 0)) {
-        status = STATUS_RESOURCE_IN_USE;
-        goto done;
-    }
-
     /*
      * Validate the input/output buffer arguments depending on the type of the
      * operation.
@@ -921,9 +915,6 @@ done:
     OvsReleaseSwitchContext(gOvsSwitchContext);
 
 exit:
-    KeMemoryBarrier();
-    instance->inUse = 0;
-
     /* Should not complete a pending IRP unless proceesing is completed. */
     if (status == STATUS_PENDING) {
         /* STATUS_PENDING is returned by the NL handler when the request is
index dbc9dea..2c61d82 100644 (file)
@@ -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