[ovs-dev] Design notes for provisioning Netlink interface from the OVS Windows driver (Switch extension)
nithin at vmware.com
Wed Aug 13 15:08:09 UTC 2014
On Aug 13, 2014, at 7:05 AM, Samuel Ghinet <sghinet at cloudbasesolutions.com>
> [QUOTE]The driver does not care about multiple threads concurrently executing dump as any DeviceIOContol will be self-contained. Also, the user mode implementation guarantees that there are no simultaneous dumps for a given socket.[/QUOTE]
> Regarding "DeviceIOContol will be self-contained", I think it is quite clear that DeviceIoControl is not quite self-contained for dumps - in the meaning that you need to preserve the buffer you read from, until you read it whole.
> But, the second sentence gave the answer: "the user mode implementation guarantees that there are no simultaneous dumps for a given socket"
Usermode guarantees that there are no concurrent accesses to a netlink socket. Even if there is concurrent access, platforms that support netlink natively have some mechanism of serializing the calls before they reach the kernel driver. On Windows, we'll put in safeguards in the kernel to make sure that there are no concurrent calls. In reality, we don't need these safeguards if we can make sure that each "DeviceIOContol will be self-contained", ie. it does not rely on previous state thus avoiding a race to update the previous state. But "making sure that DeviceIOContol will be self-contained" will depend a lot of how the userspace code is written as well.
So, we are looking to having a discussion about the actual implementation (in userspace) based on the design guideline Eitan has sent out. Does this make sense?
More information about the dev