On 06/13/2016 03:20 PM, Erik Hugne wrote: > > > On Jun 13, 2016 20:29, "Jon Maloy" <ma...@donjonn.com > <mailto:ma...@donjonn.com>> wrote: > > I already thought about that, and checked the implementation of > > skb_dequeue(). As I suspected it unconditionally grabs the queue lock > > before checking if there is anything to return. We don't want that on > > the critical data path. > > > > What i suggested is no different than your patch from a queue locking > point of view. > It definitely is. When checking for !skb_queue_empty() the only thing done is a comparison between the list->next pointer and the list pointer itself, i.e., the lock is not taken. Since this condition almost never is true, we can skip over the content of the if clause and continue the loop directly.
If we do as you suggest, the lock will be grabbed and all interrupts will be disabled at least once even when the list is empty. > > Only the extra length check is removed. > > Did you perhaps intend to use __skb_dequeue()? > No, that cannot be used here, since we may have an interrupt feeding the queue while we are emptying it. ///jon > //E > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
