vr(4) performance
Pyun YongHyeon
pyunyh at gmail.com
Fri Nov 3 00:30:38 UTC 2006
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
More information about the freebsd-hackers
mailing list