From owner-freebsd-current Fri Mar 7 12:57:36 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5959B37B405 for ; Fri, 7 Mar 2003 12:57:34 -0800 (PST) Received: from mail.flugsvamp.com (ts46-01-qdr3643.mdfrd.or.charter.com [68.118.36.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB55943F85 for ; Fri, 7 Mar 2003 12:57:32 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by mail.flugsvamp.com (8.12.6/8.12.6) id h27Kv5FZ074080; Fri, 7 Mar 2003 14:57:05 -0600 (CST) (envelope-from jlemon) Date: Fri, 7 Mar 2003 14:57:05 -0600 (CST) From: Jonathan Lemon Message-Id: <200303072057.h27Kv5FZ074080@mail.flugsvamp.com> To: tlambert2@mindspring.com, current@freebsd.org Subject: Re: mbuf cache X-Newsgroups: local.mail.freebsd-current In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article you write: >Petri Helenius wrote: >> > There's probably a tightloop of frees going on somewhere. It's tough >> > for me to analyze this as I cannot reproduce it. Have you tried >> > running your tests over loopback to see if the same thing happens? >> >> What is the definition of "tightloop"? The received packet mbufs are freed >> when the packets get processed/discarded which happens once for >> a packet. The received packet rate is 50000-150000 packets per second. >> > >> > If so, and it does, can you please explain how to exactly replicate >> > the test? >> >> Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable >> promisc and monitor so it drops the packets after interrupt processing. >> The overhead beyond that is neglible compared to mb_free. > >Ah. You are receiver livelocked. Try enabling polling; it will >help up to the first stall barrier (NETISR not getting a chance >to run protocol processing to completion because of interrupt >overhead); there are two other stall barriers after that, and >another in user space is possible depending on whether the >application layer is request/response. Actually, in -current, we now have a sysctl (net.isr.enable) that will switch the netisr from queuing into a direct dispatch mechanism. In other words, the packet is pushed all the way through the TCP stack to the socket buffer by the network card's interrupt. You can toggle it on and off at runtime, so you can play with it and see if there is any difference. My initial performance tests showed it to be a wash, but ttcp testing today shows it gives a 30% performance boost when run over a gigabit link. YMMV, I guess. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message