Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751686AbcLEL5d (ORCPT ); Mon, 5 Dec 2016 06:57:33 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:42952 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751244AbcLEL44 (ORCPT ); Mon, 5 Dec 2016 06:56:56 -0500 Date: Mon, 5 Dec 2016 12:56:53 +0100 From: Pavel Machek To: Giuseppe CAVALLARO Cc: David Miller , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses. Message-ID: <20161205115653.GB16126@amd> References: <20161123105125.GA26394@amd> <20161124085506.GA25007@amd> <20161124.110416.198867271899443489.davem@davemloft.net> <20161124212540.GA24796@amd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2318 Lines: 68 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > the idea behind the TX mitigation is to mix the interrupt and > timer and this approach gave us real benefit in terms > of performances and CPU usage (especially on SH4-200/SH4-300 platforms > based). > In the ring, some descriptors can raise the irq (according to a > threshold) and set the IC bit. In this path, the NAPI poll will be > scheduled. > But there is a timer that can run (and we experimented that no high > resolution is needed) to clear the tx resources. I'm sorry, but it is just broken. It could have never worked. If it appered it did, you did not test it right. First, low-res timers have resolution down to one per second (see David's email). It is not acceptable to delay transmits for 40msec, and certainly not acceptable to delay them for 1000msec. Second, the logic is wrong: if (likely(priv->tx_coal_frames > priv->tx_count_frames)) mod_timer(&priv->txtimer, STMMAC_COAL_TIMER(priv->tx_coal_timer)); else { priv->tx_count_frames =3D 0; priv->hw->desc->set_tx_ic(desc); priv->xstats.tx_set_ic_bit++; } =09 doing tx_clean() after set number of packets, or set time after the first packet is transmitted would make sense. But that's not what the code does. As long as packets are being transmitted, you move the timer into the future.. so that finally you run out of the place, then wait for timer (!) and only then you do the cleaning. Third, times are wrong by order of magnitude. AFAICT cleaning should be at around 5msec at 100mbit speeds, and at around .5msec at gigabit. You have 40msec there. (Perhaps that is not too important if the logic is fixed, as described above). Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhFVgUACgkQMOfwapXb+vJKZgCdECNN7YJBvAXv1wznGamW4big S8MAn3zN6E3SmiqupnSbGwj4tcKVXbnH =68Ny -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm--