On Feb 16, 2016, at 7:50 PM, IWAMOTO Toshihiro <[email protected]> wrote: > With a software switch such as openvswitch, PacketIn events may not > happen.
That's true; that can *also* be the case with a hardware switch, though. > And even with your situation, in a interval where there's no pending > PacketIn event, processing of other high priority events can be > delayed up to 5 seconds with your code. > OK. Your argument, then, is that the wait-until-timeout on an empty PacketIn queue delays processing of higher priority events that may arrive during the wait. That's a fair critique; I need to think about how best to address it. > I think you can increase the queue size to reduce such priority > inversions, or independent semaphores can be used to limit the number > of low priority events in the queue. Actually - that idea may be the closest to a solution. How about a single priority queue, of size n, with 3 semaphores of size n/3? Events are inserted into the queue, in priority order, and consume an appropriate semaphore entry upon insertion. Events are removed from the queue in priority order, and increment the appropriate semaphore upon removal. In that way, there should be no delay in awaiting events, and insertion into the priority queue will not be subject to priority inversion. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
