From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 6E77367B83 for ; Thu, 17 Aug 2006 09:48:28 +1000 (EST) Subject: Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch. From: Benjamin Herrenschmidt To: Linas Vepstas In-Reply-To: <20060811170813.GJ10638@austin.ibm.com> References: <20060811170337.GH10638@austin.ibm.com> <20060811170813.GJ10638@austin.ibm.com> Content-Type: text/plain Date: Thu, 17 Aug 2006 01:43:40 +0200 Message-Id: <1155771820.11312.116.camel@localhost.localdomain> Mime-Version: 1.0 Cc: Arnd Bergmann , netdev@vger.kernel.org, James K Lewis , linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Jens Osterkamp List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2006-08-11 at 12:08 -0500, Linas Vepstas wrote: > > Implement basic low-watermark support for the transmit queue. > > The basic idea of a low-watermark interrupt is as follows. > The device driver queues up a bunch of packets for the hardware > to transmit, and then kicks he hardware to get it started. > As the hardware drains the queue of pending, untransmitted > packets, the device driver will want to know when the queue > is almost empty, so that it can queue some more packets. > > This is accomplished by setting the DESCR_TXDESFLG flag in > one of the packets. When the hardware sees this flag, it will > interrupt the device driver. Because this flag is on a fixed > packet, rather than at fixed location in the queue, the > code below needs to move the flag as more packets are > queued up. This implementation attempts to keep te flag > at about 3/4's of the way into the queue. > > This patch boosts driver performance from about > 300-400Mbps for 1500 byte packets, to about 710-740Mbps. Sounds good (without actually looking at the code though :), that was a long required improvement to that driver. Also, we should probably look into using NAPI polling for tx completion queue as well, no ? Cheers, Ben.