Date: Wed, 25 Feb 2009 14:53:10 +0700 From: Eugene Grosbein <eugen@kuzbass.ru> To: Siquijor Philips <siquijorphilips@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Questions on processing smaller frame size Message-ID: <20090225075310.GA85904@svzserv.kemerovo.su> In-Reply-To: <a27b90e40902242314w12c15fddma43e1cd5afec8938@mail.gmail.com> References: <a27b90e40902242314w12c15fddma43e1cd5afec8938@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 25, 2009 at 03:14:11PM +0800, Siquijor Philips wrote: > Can someone explain why FreeBSD network throughput (both incoming and > outgoing traffic) decreases when smaller frame size being processed? > With smaller frame size, corresponding packet rate (packet/sec or pps) > increases and experiencing dropped packets. What causes dropping of > packets with small frame size? Traffic bandwidth does not matter (or much less), PPS rate matters. Packets drop due to high pps rate. Higher packet size, lesser pps saturates link and pps just can't grow high. It can with smaller packets. I've tried to make FreeBSD 7.1 act as packet generator with Intel dualcore 2.8Ghz processor and onboard gigabit ethernet em0 using ng_source(4) low-overhead packet emitter. And it can't saturate gigabit link with UDP packets (64 bytes payload, 130 bytes at wire - including inter-packet gaps, FCSs etc.) It takes all CPU cycles of one 2.8Ghz core to send 750Kpps - I've profiled kernel with DTrace. It seems it spends many cycles inside inlined mtx_lock/mtx_unlock functions. My em(4) driver is statically compiled into the kernel so mtx_lock/mtx_unload are inlined assembler ops. Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090225075310.GA85904>