Nithin, 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] Yes. Sam ________________________________________ From: Nithin Raju [nit...@vmware.com] Sent: Wednesday, August 13, 2014 6:08 PM To: Samuel Ghinet Cc: Eitan Eliahu; Alin Serdean; dev@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 <sghi...@cloudbasesolutions.com> wrote: > [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" Samuel, 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? thanks, Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
