From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 05:20:23 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 2BF7216A407 for ; Thu, 26 Oct 2006 05:20:23 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9FF843D58 for ; Thu, 26 Oct 2006 05:20:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9Q5IQXk095238; Wed, 25 Oct 2006 23:18:32 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <45404522.6000001@samsco.org> Date: Wed, 25 Oct 2006 23:18:26 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Jack Vogel References: <200610251818.k9PIIe7p062530@ambrisko.com> <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> <454009DF.5000704@samsco.org> <2a41acea0610252211w262e95c4k32e80d729475c0b9@mail.gmail.com> In-Reply-To: <2a41acea0610252211w262e95c4k32e80d729475c0b9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.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:20:23 -0000 Jack Vogel wrote: > 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 Yes, that's almost exactly what was there! It was #ifndef NO_EM_FASTINTR Anywho...