On Wed, 2016-11-30 at 23:30 +0100, Jesper Dangaard Brouer wrote: > On Wed, 30 Nov 2016 11:30:00 -0800 > Eric Dumazet <eric.duma...@gmail.com> wrote: > > > On Wed, 2016-11-30 at 20:17 +0100, Jesper Dangaard Brouer wrote: > > > > > Don't take is as critique Eric. I was hoping your patch would have > > > solved this issue of being sensitive to TX completion adjustments. You > > > usually have good solutions for difficult issues. I basically rejected > > > Achiad's approach/patch because it was too sensitive to these kind of > > > adjustments. > > > > Well, this patch can hurt latencies, because a doorbell can be delayed, > > and softirqs can be delayed by many hundred of usec in some cases. > > > > I would not enable this behavior by default. > > What about another scheme, where dev_hard_start_xmit() can return an > indication that driver choose not to flush (based on TX queue depth), > and there by requesting stack to call flush at a later point. > > Would that introduce less latency issues?
Again, how is it going to change anything when your netperf UDP sends one packet at a time ? qdisc gets one packet , dequeue it immediately. No pressure. -> doorbell will be sent as before. Some TX producers do not even use a qdisc to begin with. Please think of a solution that does not involve qdisc layer at all.
