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