From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 14:19:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5BA4C995 for ; Sat, 19 Jan 2013 14:19:45 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm19-vm0.bullet.mail.ne1.yahoo.com (nm19-vm0.bullet.mail.ne1.yahoo.com [98.138.91.59]) by mx1.freebsd.org (Postfix) with ESMTP id DD489DCF for ; Sat, 19 Jan 2013 14:19:44 +0000 (UTC) Received: from [98.138.90.57] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 14:17:45 -0000 Received: from [98.138.88.238] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 14:17:45 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 19 Jan 2013 14:17:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 932085.74043.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 61296 invoked by uid 60001); 19 Jan 2013 14:17:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358605065; bh=ANS+Z4Gx/scgL9OgW2IJM3ERYIHfafNUhrf2/2F+qBU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kdqNvJk3K/CI+5psdYyQyqBCRXotqaFpC0wy7qOXyN53pVHM+hEIgZlJNorAAGU2+LE5qZxai18sBgyc1OA+rpLAPjJRgkAz9CPa/Boh8bTO/5M6I+jg30T0MgclkusvqK8+Ra25UZgU8yY9SRF7Us06sNQ5/U2jEZjxaw+Fu7g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n7Ao8scAHB446i2nVbrVUT9eBfnOVmG0z69fZK1bT1oihmpK/51m1in8UZNCYUYnwDIyhytpMi9bEsX/902sZGi/ja/k23jp8od9PVRHqyZywORxKBszdomQJxDru0WbseaLmLFGyDmleFLreCaRV9xG+jJ9+aDmbDTAOHx/zXM=; X-YMail-OSG: j2OVnJ4VM1kPB_tugAR94AETFkpkX2YLVviUeSQNDLIt6kx ztqVQUxgX0v0cffHWbOeZ8COw6moyHZmESUQI5_RiG3kHsRxEkiB_EKQGW6Q hvZ1OHN0ojkJuT1lBsA_V8vhWh1IdbVGA_NACJOGVexGbSWYn3zIxuH3eCJN tS1HrekDlBhyk07mQacLvYpi9YTyDs8ZoeiFlUJ7YeMCDdCf0bYTqGbyfu1W 1B0ktsn59G_eTtXypTT8Niv1o07f0L1XKTbf0Ca8Qt69j7ZOG.XAn7owTydT 9mxWwddzaxkbZPYce7RJR8Y_nw4P0rm_R.ZQ37y4lRIkJu1QyxsgioMzOAEr 6uvM8OqW3x5h0v7OR.RMaEus80asKZXVXSbegjcObwmtlT2Mv93.Kb8iT7Vw O4vkjiQ6x2L7YERUr7w7SCLQkQdqQXGZyKR7LVbsbzjcsE.mVm0W1NF4nRQk TRowSzjdyJHHGrb2hfhAdkEtYhR7tf.mTDymkixA3iOtyExxu1s7rawIv_ta FhnYF2mMyuGzonXg6DKHPkacNrMTi Received: from [174.48.128.27] by web121604.mail.ne1.yahoo.com via HTTP; Sat, 19 Jan 2013 06:17:45 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gRnJpLCAxLzE4LzEzLCBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4gd3JvdGU6Cgo.IEZyb206IEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPgo.IFN1YmplY3Q6IFJlOiB0d28gcHJvYmxlbXMgaW4gZGV2L2UxMDAwL2lmX2xlbS5jOjpsZW1faGFuZGxlX3J4dHgoKQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.Cj4gQ2M6IGZyZWVic2QtbmV0QGZyZWVic2Qub3JnLCAiTHVpZ2kgUml6em8iIDxyaXp6b0BpZXQudW5pcGkuaXQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358605065.60481.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Sat, 19 Jan 2013 06:17:45 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Luigi Rizzo 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: Sat, 19 Jan 2013 14:19:45 -0000 --- On Fri, 1/18/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org, "Luigi Rizzo" > Date: Friday, January 18, 2013, 3:09 PM > On 18 January 2013 06:30, Barney > Cordoba > wrote: > > > I don't see the distinction between the rx thread > getting re-scheduled > > "immediately" vs introducing another thread. In fact > you increase missed > > interrupts by this method. The entire point of > interrupt moderation is > > to tune the intervals where a driver is processed. > > The problem with interrupt moderation combined with > enabling/disabling > interrupts is that if you get it even slightly wrong, > you won't run the packet processing thread(s) until the next > interrupt > occurs - even if something is in the queue. Which is the point of interrupt moderation. Your argument is that "I only want 6000 interrupts per second, but I'm willing to launch N tasks that have the exact same processing load where N <= 20". So you're willing to have 120000 interrupts/task_queues per second (its only possible to get about 2000pps in 1/6000th of a second on a gigabit link unless you're fielding runts). This all comes down, again, to tuning. Luigi's example would result in 39 tasks being queued to process his 3900 backup with a process limit of 100. This would bypass the "next interrupt" by a wide margin. Is the point of moderation to not have the network task take over your system? If you don't care, then why not just set moderation to 20Kpps? The "work" should be the amount of time you're willing to process packets within the interrupt moderation window. The settings go hand in hand. I'm not saying that the task_queue idea is wrong; however in Luigi's example it will cause substantially more overhead by launching too many tasks. Unless you're still running a 700Mhz P3 100 is way too low for a workload limit. It's just arbitrarily silly. BC