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 <l...@freebsd.org> 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. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
