Date: Wed, 25 Oct 2006 17:36:17 -0700 From: "Jack Vogel" <jfvogel@gmail.com> To: "Doug Ambrisko" <ambrisko@ambrisko.com> Cc: freebsd-net <freebsd-net@freebsd.org>, Scott Long <scottl@samsco.org>, John Polstra <jdp@polstra.com> Subject: Re: em network issues Message-ID: <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> In-Reply-To: <200610251818.k9PIIe7p062530@ambrisko.com> References: <XFMail.20061019152433.jdp@polstra.com> <200610251818.k9PIIe7p062530@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/25/06, Doug Ambrisko <ambrisko@ambrisko.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea0610251736n16cc4188h489f6d953130f91a>