From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e Date: Wed, 06 Jun 2012 11:23:32 -0700 (PDT) Message-ID: <20120606.112332.885204082939531665.davem@davemloft.net> References: <20120606092635.00003b61@unknown> <20120607021937.a5638bfd.shimoda.hiroaki@gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: shimoda.hiroaki@gmail.com, jesse.brandeburg@intel.com, eric.dumazet@gmail.com, denys@visp.net.lb, netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net, jeffrey.t.kirsher@intel.com To: therbert@google.com Return-path: Received: from shards.monkeyblade.net ([149.20.54.216]:38096 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753118Ab2FFSXd (ORCPT ); Wed, 6 Jun 2012 14:23:33 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: From: Tom Herbert Date: Wed, 6 Jun 2012 11:21:40 -0700 > I'm not exactly sure what the exact effect of WTHRESH is here. Does > the device coalesce 5 completions regardless of size? Would the > problem be avoided if bql limit_min were MTU, or could same issue be > hit with larger that 64 byte packets? The problem is that no TX completions are signalled happen until at least WTHRESH are pending. BQL is the least of the problems generated by this kind of behavior. All drivers must TX complete in a small, finite, amount of time so it is absolutely illegal to have the behavior that WRTHRESH > 1 gives.