From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Laight Subject: RE: [PATCH] net: mvneta: fix handling of the Tx descriptor counter Date: Mon, 20 Nov 2017 14:58:57 +0000 Message-ID: <293edadc5ed14687b388c88802798dd8@AcuMS.aculab.com> References: <20171108165835.13453-1-simon.guinot@sequanux.org> <20171111.184504.2151388779461931723.davem@davemloft.net> <20171113145115.GM18407@kw.sim.vm.gnt> <20171113.235414.987480304119622711.davem@davemloft.net> <20171113153614.GN18407@kw.sim.vm.gnt> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT Cc: "thomas.petazzoni@free-electrons.com" , "netdev@vger.kernel.org" , "musv@gmx.de" , "andreas.tobler@cloudguard.ch" , "gregory.clement@free-electrons.com" , "antoine.tenart@free-electrons.com" , "mw@semihalf.com" , "stable@vger.kernel.org" To: 'Simon Guinot' , David Miller Return-path: Received: from smtp-out6.electric.net ([192.162.217.184]:56421 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751155AbdKTO6l (ORCPT ); Mon, 20 Nov 2017 09:58:41 -0500 In-Reply-To: <20171113153614.GN18407@kw.sim.vm.gnt> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: From: Simon Guinot > Sent: 13 November 2017 15:36 > To: David Miller > Cc: thomas.petazzoni@free-electrons.com; netdev@vger.kernel.org; musv@gmx.de; > andreas.tobler@cloudguard.ch; gregory.clement@free-electrons.com; antoine.tenart@free-electrons.com; > mw@semihalf.com; stable@vger.kernel.org > Subject: Re: [PATCH] net: mvneta: fix handling of the Tx descriptor counter > > On Mon, Nov 13, 2017 at 11:54:14PM +0900, David Miller wrote: > > From: Simon Guinot > > Date: Mon, 13 Nov 2017 15:51:15 +0100 > > > > > IIUC the driver stops the queue if a threshold of 316 Tx descriptors is > > > reached (default and worst value). > > > > That's a lot of latency. > > OK, then I'll keep the "tx_pending > 255" flushing condition. But note > there is no other software mechanism to limit the Tx latency inside the > mvneta driver. Should we add something ? And is that not rather the job > of the network stack to keep track of the latency and to limit the txq > size ? This is 'first packet transmit latency'. If the 'doorbell write' is just a PCIe write then, on most systems, that is cheap and pipelined/posted. I'd almost be surprised if you see any 'improvement' from not doing it every packet. The overall tx queue size is a different issue - usually needs limiting by BQL if TSO is done. David