At Mon, 15 Feb 2016 03:42:36 +0000, Victor Orlikowski wrote: > > > > > On Feb 14, 2016, at 9:54 PM, IWAMOTO Toshihiro <[email protected]> > > wrote: > <snip/> > > > I think you can use eventlet.queue.PriorityQueue instead of these 3 > > queues. (see below) > > > > Let us have: > > > > self.events = hub.PriorityQueue(128) > > > > No, this will not work. > If the priority queue becomes full, lower priority items blocked awaiting > insertion ahead of higher priority items into the single queue *will* cause a > priority inversion. > > You *need* 3 queues, for the three different types of items, if you wish to > avoid priority inversion as a result of blocking awaiting insertion. > > > > > And a single semaphore would do, if needed at all. > > > > Again - I can *assure* you, there is a bug in eventlet queues, that > *requires* the semaphore. > Under heavy load, there are missed wakeups. > > <snip/> > >> + if ev is None: > >> + try: > >> + ev, state = > >> self.pi_events.get(timeout=self._event_get_timeout) > > > > > > This will harm responsiveness. > > > > In my testing, it does not. > Responsiveness (to PacketIn events) would *only* be harmed in the case where > events other than PacketIn *greatly* outnumber the number of PacketIn events. > In my experience, PacketIns *tend* to outnumber all other events, when they > are being used by the controller application. > > If it is the timeout that you are concerned about - the timeout is only > awaited *if* there are no PacketIn events present. The hub is free to > schedule other greenlets during this time, and the arrival of a PacketIn > event in the queue before the end of the timeout will result in the greenlet > being unblocked.
With a software switch such as openvswitch, PacketIn events may not happen. 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. > Please explain the basis for your assertion that this will "harm > responsiveness," and I will gladly explain my logic for why it will not. > > I emphatically do *not* agree, however, with the use of a single > PriorityQueue. > Priority inversion *will* result, as soon as the number of events being > processed exceeds the capacity of the queue. 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. -- IWAMOTO Toshihiro ------------------------------------------------------------------------------ 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
