From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 01:35:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6493D106566C; Fri, 31 Aug 2012 01:35:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 25B7E8FC0A; Fri, 31 Aug 2012 01:35:39 +0000 (UTC) Received: by dadr6 with SMTP id r6so1577098dad.13 for ; Thu, 30 Aug 2012 18:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=EpyrkZMAnPQZF/evt+51EJkC3aypkM3HnBVKwCi24LI=; b=S21hxC+wSldLKVeTInUfnEpGlY7tc0rYtXBa0VR5OaOS6+m61npOe8TUz1Ev1IQx4A CkSaHEnoe6Cm82zqV8iiNCWVIU0BtBxY3wsHhbpWgCqhlXyOCviiTh9u+G/LIW5UPJVZ syDDorGNftOZOJZQFbYKney1uWe4Lzukx4JLk5tTXtKhYVYbC+2q65Q0FwyO/CC+mboR BrlKFD3B7Ren2XjR1Pgs/MtB0EVMpuJ7Czymd3Sne73v4srBQAdDQE0EIz3Z0tY4idve uKq8zl+Dex9u21yUWcKWVux+LZHz7UdRVfzfKilgrhFU3+KlRLRnpmae/V6p2ovVqWNb KenA== Received: by 10.68.130.65 with SMTP id oc1mr14526095pbb.29.1346376933566; Thu, 30 Aug 2012 18:35:33 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id pk9sm2512892pbb.4.2012.08.30.18.35.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2012 18:35:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 31 Aug 2012 10:35:24 -0700 From: YongHyeon PYUN Date: Fri, 31 Aug 2012 10:35:24 -0700 To: Adam Vande More Message-ID: <20120831173524.GA3208@michelle.cdnetworks.com> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, lev@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 01:35:40 -0000 On Thu, Aug 30, 2012 at 03:32:25PM -0500, Adam Vande More wrote: > On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov wrote: > > > Hello, Ian. > > You wrote 30 августа 2012 г., 10:23:56: > > > > >> Yep, I'll collapse my two-rule chains in one rule. > > IS> I guess if the issue persists, we may need to see more of your ruleset. > > Not a problem at all, here it is: > > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > > Yep. I didn't see it. My question is, really: why vr1 (my physical > > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > > is only 40mbit/s down and about 20mbit/s up (with many connections)? > > > Have you taken this into account from vr(4)? > > BUGS > The vr driver always copies transmit mbuf chains into longword-aligned > buffers prior to transmission in order to pacify the Rhine chips. If > buffers are not aligned correctly, the chip will round the supplied > buffer address and begin DMAing from the wrong location. This buffer > copying impairs transmit performance on slower systems but cannot be > avoided. On faster machines (e.g. a Pentium II), the performance > impact > is much less noticeable. I'm not sure what controller is used in Geode LX but newer vr(4) controllers such as VT6105/VT6105M do not have such DMA alignment limitation of TX buffer. vr(4) selectively enables software workaround based on controller revision. Manual software padding for short frames(< 60 bytes) is still required for all VIA fast ethernet controllers though. vr_attach() will show what quirks are activated so you would be able to tell whether your controller has TX DMA buffer alignment limitation or not.