> > On Wed, 6 Nov 2013, Nebojša Ćosić wrote: > > > You can try with this patch. I am quite sure that same problem > > > persists on all newer kernels (I am using 2.6.33), but never had a > > > time to create simple test to prove it. > > > > I'm looking forward to your detailed analysis .... > > > > > Index: net/sched/sch_generic.c > > > =================================================================== > > > --- net/sched/sch_generic.c (revision 1709) > > > +++ net/sched/sch_generic.c (revision 1710) > > > @@ -120,16 +120,18 @@ > > > int ret = NETDEV_TX_BUSY; > > > > > > /* And release qdisc */ > > > - spin_unlock(root_lock); > > > +/* spin_unlock(root_lock); > > > > > > HARD_TX_LOCK(dev, txq); > > > +*/ > > > > Do you really think this locking scheme is just for fun? > > qdisk_lock, i.e. root_lock and the netif_tx_lock are mutually > > exclusive for a reason. Reading the documentation and > > comments of code is optional, right? > > > > > > > When transmit queue is empty, thread wanting to send a message > > > > > comes directly to sch_direct_xmit, without changing context. It > > > > > then releases spin lock, and than takes another. So far so good. > > > > > If this starting thread is of lower priority, it can be > > preempted > > > > > by another thread, while still being in dev_hard_start_xmit > > > > > function This thread will check if HARD_TX_LOCK is > > taken, and if > > > > > so, go on and queue its own message. If there are > > enough higher > > > > > priority tasks, tx can be stalled indefinitely. [..] > > > > Utter nonsense. > > In my situation if a first thread is preempted in dev_hard_start_xmit, then a second > thread which transmits over the same interface sees a none empty queue and > just enqueue the skb in the queue. No transmit (HARD_TX_LOCK) is necessary > because the first thread is already working on the queue. Please correct me if I'm > not right. > For my case the first thread does normal SSH communication and the second > thread does real-time UDP communication. This results in a priority inversion for > the transmission of skb's over the same network interface. > Is there any chance to get rid of this priority inversion? Maybe with priority qdisc? And this is precisely what this hack is trying to work around. Original thread was a call for a discussion in order to find real solution to the problem. New messages arriving to the queue should somehow raise priority of thread sitting in dev_hard_start_xmit according to their own thread priority. Or can priority of a thread currently in dev_hard_start_xmit temporarily be raised to some configurable value. This hack is effectively shutting down queuing of skbs, and instead forces queuing of threads. > > > The code (sch_direct_xmit) you are modifying is called from > > exactly two places: > > > > 1) __dev_xmit_skb > > > > 2) __qdisc_run() > > > > Which in turn two call sites: > > > > 1) __dev_xmit_skb() either directly or via qdisc_run() > > > > 2) net_tx_action() which is the NET_TX softirq action > > > > None of those calls does a trylock on the xmit lock. So what > > the heck are you talking about? > > > > Thanks, > > > > tglx > > regards, gerhard-- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Pozdrav, Nebojša -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
