On Thu, Apr 03, 2014 at 05:47:04PM -0700, Pravin Shelar wrote: > On Thu, Apr 3, 2014 at 2:41 PM, Ben Pfaff <b...@nicira.com> wrote: > > 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.
Thanks. > > 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. OK. > > 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. OK. We don't have to have it immediately, but I want to encourage thinking about it. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
