From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 00:36:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4FB016A403 for ; Thu, 26 Oct 2006 00:36:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3527743D7E for ; Thu, 26 Oct 2006 00:36:21 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so205111pyc for ; Wed, 25 Oct 2006 17:36:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=clt8ZS9iA6coE+qCVDF1s2IN7S1Jgjr7QUlNg9aRoeEVjGaDKa/gq0B45b+8KSflxEWZq7qxeYQqJlShEgc5vUL3e3dHgafCzabOgTaXhEmuFJkQY9ceCgjpH40pRaoY7rSpWRFguum0C4lfv4unH22/iHT2tnAd4aVeoa7Z+go= Received: by 10.35.121.12 with SMTP id y12mr2146309pym; Wed, 25 Oct 2006 17:36:17 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Wed, 25 Oct 2006 17:36:17 -0700 (PDT) Message-ID: <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> Date: Wed, 25 Oct 2006 17:36:17 -0700 From: "Jack Vogel" To: "Doug Ambrisko" In-Reply-To: <200610251818.k9PIIe7p062530@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200610251818.k9PIIe7p062530@ambrisko.com> Cc: freebsd-net , Scott Long , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 00:36:25 -0000 On 10/25/06, Doug Ambrisko wrote: > 3) In em_process_receive_interrupts/em_rxeof always decrement > the count on every run through the loop. If you notice > count is an is an int that starts at the passed in value > of -1. It then count-- until count==0. Doing -1, -2, -3 > takes awhile until the int rolls over to 0. Passing 100 > limits it more :-) So this can run 3 * 100 versuses > infinite * int roll over assuming we don't skip a count--. Been chatting with Jesse Brandeburg (one of our senior Linux guys) about receive side cleaning. Gave me a number of things to think about. First off, this change you mention is problematic. The reason it doesnt increment every time thru the while loop is its meant as a packet counter, NOT a descriptor counter. If we just fix this number at 100, and have it only counting descriptors you could get all but the EOP descriptor of a packet and then exit without finishing it and calling the stack, not a good tactic. Having a limited count is still a good idea, but I think we still want to base it on packets and not just descriptors. Jesse also talked about their experience with the Linux driver, deciding where to update the RDT, my current code doesnt do it til after the whole while loop is completed (havent looked at CURRENT again today yet), Jesse suggested doing it but not EVERY pass in the loop, maybe making it mod the number of rx descriptors. Having that AND a fixed limit on the number of total packets cleaned in a pass might be good. I was also thinking, maybe having the taskqueue code be selectable, but not just a POLL vs TASKQUEUE, rather keep a legacy intr option which has a POLL option within it. My motivation for doing that is I can take the TASKQUEUE code into the Intel code base, but make it backward compatible, the default would have it optioned off. Jack