[ovs-dev] Design notes for provisioning Netlink interface from the OVS Windows driver (Switch extension)
sghinet at cloudbasesolutions.com
Wed Aug 13 15:35:33 UTC 2014
It might be a bit of misunderstanding on what one or another is trying to say :)
I meant concurrency such as:
thread1: flow dump start
thread1: flow dump next
thread2: datapath dump start
thread2: datapath dump next
thread1: flow dump next
This would require, as I see, the buffer to be associated with the FILE_OBJECT ptr, or else thread2 might accidentally read from flow dump's buffer instead of datapath's.
[QUOTE]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?[/QUOTE]
From: Nithin Raju [nithin at vmware.com]
Sent: Wednesday, August 13, 2014 6:08 PM
To: Samuel Ghinet
Cc: Eitan Eliahu; Alin Serdean; dev at openvswitch.org; Rajiv Krishnamurthy; Ben Pfaff; Kaushik Guha; Ben Pfaff; Justin Pettit; Ankur Sharma; Linda Sun; Keith Amidon
Subject: Re: Design notes for provisioning Netlink interface from the OVS Windows driver (Switch extension)
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