Acquiring a spin lock raises the IRQL to DISPATCH_LEVEL. But
in many places of the code, while holding a spin lock, there
are useless checks for the current IRQL against DISPATCH_LEVEL.
Also, the dispatch flag is not correctly set when calling
NdisAcquireRWLockXXX() functions, which causes an extra
> > -ASSERT(KeGetCurrentIrql() == DISPATCH_LEVEL);
> > OvsAcquireDatapathRead(datapath, &dpLockState, dispatch);
>
> We can pass NDIS_RWL_AT_DISPATCH_LEVEL instead of 'dispatch', and let the
> ASSERT be.
>
> SV: Here, I will leave the use of the 'dispatch' variable, due to
Hi Nithin,
Thanks for your review. Please see my comments inline.
-Original Message-
From: Nithin Raju [mailto:nit...@vmware.com]
Sent: Wednesday, October 1, 2014 8:55 PM
To: Sorin Vinturis
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH] datapath-windows: Incorrect assumption of
hi Sorin,
I had minor comments. Pls. see inline.
> #define NETLINK_FAMILY_NAME_LEN 48
>
> +#ifndef IFNAMSIZ
> +#define IFNAMSIZ 16
> +#endif
This is defined in OvsDpInterface.h. We can avoid an extra definition. See
commit - f92156ae2c86cf1b7c2076f2bca88b6fa10ec632.
> +
>
> /*
> * Netlink me
Acquiring a spin lock raises the IRQL level to DISPATCH_LEVEL.
But in many places of the code, while holding a spin lock, there
are useless checks for the current IRQL against DISPATCH_LEVEL.
Also, the dispatch flag is not correctly set when calling
NdisAcquireRWLockXXX() functions, which causes an
