Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 02 Nov 2006 15:27:46 -0800
From:      Sam Leffler <sam@errno.com>
To:        "Devon H. O'Dell" <devon.odell@gmail.com>
Cc:        hackers@freebsd.org
Subject:   Re: vr(4) performance
Message-ID:  <454A7EF2.5090201@errno.com>
In-Reply-To: <9ab217670611021511l3120d58bhd0b61bf44f8ecc87@mail.gmail.com>
References:  <9ab217670611021511l3120d58bhd0b61bf44f8ecc87@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?454A7EF2.5090201>