From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 05:11:35 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 786C116A40F for ; Thu, 26 Oct 2006 05:11:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9164243D49 for ; Thu, 26 Oct 2006 05:11:34 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so243054pyc for ; Wed, 25 Oct 2006 22:11:34 -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=kEeS21RaZZGBv1lQHrx+X4gaFWss5CIvmmNzbWlD0hHoGsKoG9I9tZ0hX+RjVRKgqL9Qt3zcWKoayu4+ReZvUs+rH+UUCXwemO9JUMp2fByLmorxoSsy+kSFHUpKHjcK0fMqow6HfZtxQGZE9PHb3Zr0Kudj1F9ozpQJZn+k4JQ= Received: by 10.35.78.13 with SMTP id f13mr2626112pyl; Wed, 25 Oct 2006 22:11:34 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Wed, 25 Oct 2006 22:11:33 -0700 (PDT) Message-ID: <2a41acea0610252211w262e95c4k32e80d729475c0b9@mail.gmail.com> Date: Wed, 25 Oct 2006 22:11:33 -0700 From: "Jack Vogel" To: "Scott Long" In-Reply-To: <454009DF.5000704@samsco.org> 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> <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> <454009DF.5000704@samsco.org> Cc: freebsd-net , 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 05:11:35 -0000 On 10/25/06, Scott Long wrote: > Jack Vogel wrote: > > 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. > > Good idea. Though for 1518 byte frames, I think you'll only have one > descriptor per packet. Definitely need to do the right thing for jumbo > frames, though. > > > > > 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 > > I had it that way initially, and I think you commented that it was ugly > ;-) Naaahhhh, couldnt be, I'd never do anything like that :) OHHHH, I know what you're talking about. When I first started this job a year ago the driver was just PEPPERED with all these #if _FreeBSD_Version < BladdyFoo or something like that. I think the Intel code base was even worse cuz Tony was trying to make a single source base for 4.X and 5.X at that point. It was a major pain to look at that code :) What I'm talking about is a simple #ifdef EM_FASTINTR or something like that, no defines that remind me of POSIX header files please :) Jack