From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 3 00:30:38 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FE8416A4AB for ; Fri, 3 Nov 2006 00:30:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D822A43D45 for ; Fri, 3 Nov 2006 00:30:37 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so247140wxd for ; Thu, 02 Nov 2006 16:30:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=WVdYFYJKEKfKzE2TxYJ3mHzu+NCDa9jsWXkdh0hrrYOVc+2gru4yOM1tZvVDnmQ54UvD0n/I1CSdtvzvTX6nMQ7oQ/0STS0MtL2MU3rFTZWVICxbZTpZq9oqOUmX9PtEDQrsduFQGEfQ58l0zjzGPE3eXAI3S60irmvuDNEG6S4= Received: by 10.70.75.14 with SMTP id x14mr1922574wxa.1162513836807; Thu, 02 Nov 2006 16:30:36 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id i19sm183057wxd.2006.11.02.16.30.35; Thu, 02 Nov 2006 16:30:36 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kA30XDuY069619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Nov 2006 09:33:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kA30XB1I069618; Fri, 3 Nov 2006 09:33:11 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 3 Nov 2006 09:33:11 +0900 From: Pyun YongHyeon To: Sam Leffler Message-ID: <20061103003311.GD69214@cdnetworks.co.kr> References: <9ab217670611021511l3120d58bhd0b61bf44f8ecc87@mail.gmail.com> <454A7EF2.5090201@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <454A7EF2.5090201@errno.com> User-Agent: Mutt/1.4.2.1i Cc: hackers@freebsd.org, "Devon H. O'Dell" Subject: Re: vr(4) performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 00:30:38 -0000 On Thu, Nov 02, 2006 at 03:27:46PM -0800, Sam Leffler wrote: > Devon H. O'Dell wrote: > > Hey all, > > > > So, vr(4) kind of sucks, and it seems like this is mostly due to the > > fact that we call m_defrag() on every mbuf that we send through it. > > This seems to really screw performance on outgoing packets (something > > like 33% the output efficiency of fxp(4), if I'm understanding this > > all correctly). > > > > I'm sort of wondering if anybody has attempted to address this before > > and if there's a way to possibly mitigate this behavior. I know Bill > > Paul's comments say ``Unfortunately, FreeBSD FreeBSD doesn't guarantee > > that mbufs will be filled in starting at longword boundaries, so we > > have to do a buffer copy before transmission.'' -- since it's been a > > long day, and I'm about to go home to grab a pizza and stop thinking > > about code, would anybody mind offering suggestions as to either: > > > > a) Pros and cons of guaranteeing that they're filled in aligned (and > > possibly hints on doing it), or > > b) Possible workarounds / hacks to do this faster for vr(4) > > > > Any input is appreciated! (Except ``vr(4) is lol'') > > m_defrag is ~10x slower than it needs to be. I proposed changes to > address this a while back but eventually gave up and put driver-specific > code in ath. You can look there or I can send you some patches to > m_defrag to try out in vr. > Because the purpose of m_defrag(9) in vr(4) is to guarantee longword aligned mbufs I'm not sure ath_defrag can be used here. If memory serve me right ath_defrag would not change the first mbuf address in a chain. If the first mbuf is not aligned on longword boundary it wouldn't work I guess. Of course we can check the first mbuf in the chain before calling super-fast ath_defrag, I guess. -- Regards, Pyun YongHyeon