Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757787Ab1CBDKG (ORCPT ); Tue, 1 Mar 2011 22:10:06 -0500 Received: from swm.pp.se ([212.247.200.143]:38509 "EHLO uplift.swm.pp.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757736Ab1CBDKE (ORCPT ); Tue, 1 Mar 2011 22:10:04 -0500 Date: Wed, 2 Mar 2011 04:10:02 +0100 (CET) From: Mikael Abrahamsson To: Eric Dumazet cc: Albert Cahalan , David Miller , johnwheffner@gmail.com, linville@tuxdriver.com, jussi.kivilinna@mbnet.fi, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: txqueuelen has wrong units; should be time In-Reply-To: <1298964381.2676.58.camel@edumazet-laptop> Message-ID: References: <20110228165501.GC2515@tuxdriver.com> <20110228.201852.193726064.davem@davemloft.net> <1298964381.2676.58.camel@edumazet-laptop> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2108 Lines: 46 On Tue, 1 Mar 2011, Eric Dumazet wrote: > We should allow some trafic spikes, or many applications will stop > working. Unless all applications are fixed, we are stuck. > > Only if the queue stay loaded a long time (yet another parameter) we can > try to drop packets. Are we talking forwarding of packets or originating them ourselves, or trying to use the same mechanism for both? In the case of routing a packet, I envision a WRED kind of behaviour is the most efficient. "QoS: Time-Based Thresholds for WRED and Queue Limit for the Cisco 12000 Series Router" You can set the drop probabilites in milliseconds. Unfortunately ECN isn't supported on this platform but on other platforms it can be configured and used instead of WRED dropping packets. For the case when we're ourselves originating the traffic (for instance to a wifi card with varying speed and jitter due to retransmits on the wifi layer), I think it's taking the too easy way out to use the same mechanisms (dropping packets or marking ECN for our own originated packets seems really weird), here we should be able to pushback information to the applications somehow and do prioritization between flows since we're sitting on all information ourselves including the application. For this case, I think there is something to be learnt from: Here you have the IP part and the ATM part, and you can limit the number of cells/packets sent to the ATM hardware at any given time (this queue is FIFO so no AQM when the packet has been sent here). We need the same here, to properly keep latency down and make AQM work, the hardware FIFO queue needs to be kept low. -- Mikael Abrahamsson email: swmike@swm.pp.se -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/