From owner-freebsd-net@FreeBSD.ORG Wed Oct 30 22:23:40 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02707F4A for ; Wed, 30 Oct 2013 22:23:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64118288C for ; Wed, 30 Oct 2013 22:23:38 +0000 (UTC) Received: (qmail 64385 invoked from network); 30 Oct 2013 22:53:56 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Oct 2013 22:53:56 -0000 Message-ID: <527186D3.7090307@freebsd.org> Date: Wed, 30 Oct 2013 23:23:15 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [long] Network stack -> NIC flow (was Re: MQ Patch.) References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <52701D8B.8050907@freebsd.org> <527022AC.4030502@FreeBSD.org> <527027CE.5040806@freebsd.org> <5270309E.5090403@FreeBSD.org> <5270462B.8050305@freebsd.org> <20131030050056.GA84368@onelab2.iet.unipi.it> <52717A62.7040600@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Navdeep Parhar , Randall Stewart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:23:40 -0000 On 30.10.2013 22:53, Adrian Chadd wrote: > On 30 October 2013 14:30, Andre Oppermann wrote: > >> As default setup and when running a server no QoS will be active >> or inserted. No or only very small software queues exist to handle >> concurrency (except for ieee80211 to do sophisticated frame management >> inside *if_txframe). Whenever the DMA ring is full there is no point >> in queuing up more packets. Instead the socket buffers act as buffers >> and also ensure flow control and backpressure up to userspace to limit >> kernel memory usage from double and triple buffering. > > .. and what about for LAN<->WAN traffic, where there's no socket buffers? When the DMA ring is full (in case of a deep ring, or the software queue for small DMA rings) additional packets get dropped as it is today. Instead of tail dropping an active queue management algorithm like RED may be used. The is no point in ultra deep buffering ending up in tens or hundreds of milliseconds (see bufferbloat). If there is more egress traffic destined for an interface than it can handle there is no way to avoid packet drops. It's actually a good thing because for TCP packet drops are the primary feedback for its sending behavior. -- Andre