On Sun 2016-12-11 14:31:13, David Miller wrote: > From: Pavel Machek <pa...@ucw.cz> > Date: Sun, 11 Dec 2016 20:07:50 +0100 > > > David, ping? Can I get you to apply this one? > > > > As you noticed, tx coalescing is completely broken in that driver, and > > not easy to repair. This is simplest way to disable it. It can still > > be re-enabled from userspace, so code can be fixed in future. > > Sorry I'm not applying this, I want you and the driver maintainer > to reach a real solution.
This is what you said about this driver:
# > 4.9-rc6 still has the delays. With the
# >
# > #define STMMAC_COAL_TX_TIMER 1000
# > #define STMMAC_TX_MAX_FRAMES 2
# >
# > settings, delays go away, and driver still works. (It fails fairly
# > fast in 4.4). Good news. But the question still is: what is going on
# > there?
#
# 256 packets looks way too large for being a trigger for aborting the
# TX coalescing timer.
#
# Looking more deeply into this, the driver is using non-highres timers
# to implement the TX coalescing. This simply cannot work.
#
# 1 HZ, which is the lowest granularity of non-highres timers in the
# kernel, is variable as well as already too large of a delay for
# effective TX coalescing.
#
# I seriously think that the TX coalescing support should be ripped out
# or disabled entirely until it is implemented properly in this driver.
I'm doing just that -- disabling it entirely until it is done
properly.
Unfortunately, maintainer does not think delays are huge problem. So I
need your help here.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
