On Thu, Apr 3, 2014 at 2:41 PM, Ben Pfaff <b...@nicira.com> wrote: > On Thu, Mar 27, 2014 at 09:44:18AM -0700, Pravin wrote: >> This patch does not change any functionality. >> >> Signed-off-by: Pravin B Shelar <pshe...@nicira.com> > > I don't like seeing this as a global variable. Can it be per-datapath > (probably set using a new provider callback function)? > There can be only one definition of this callback thats why I defined it as global. I am fine defining it as member of dpif.
> Did you look for races as ofprotos and datapaths are created and > destroyed? Before this series, an ofproto upcall thread could only > process a packet when it was in a state where it expected it, and it > is not obvious at a glance that this is still true when a callback can > be issued asynchronously at any moment. > dpif-netdev checks for callback data pointer if that is set then only it can call the callback function. so I think it is safe. > In the short term, while we're developing the DPDK code, I think that > having an alternate interface like this to packet misses is OK. But > in the long term, I don't really like having two different interfaces > to the same functionality, that is, two ways to get misses and other > packets from a dpif to the code that consumes it. Do you think that > it will be possible to use callbacks exclusively, instead of sometimes > callbacks and sometimes queues, and then delete the bits of the > interface that support queuing? At this point of time dpif-linux and dpif-netdev have very different requirements for miss handling. dpif-linux need to batch upcalls as much as possible to efficiently lookup, execute and install flow. for dpif-netdev we just need lookup flow. Let me think if there is way to unify miss-call handling. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
