Date: Wed, 25 Feb 2009 18:39:40 +0800 From: Siquijor Philips <siquijorphilips@gmail.com> To: Eugene Grosbein <eugen@kuzbass.ru> Cc: freebsd-net@freebsd.org Subject: Re: Questions on processing smaller frame size Message-ID: <a27b90e40902250239x414d3fa7l12d291d278162377@mail.gmail.com> In-Reply-To: <20090225075310.GA85904@svzserv.kemerovo.su> References: <a27b90e40902242314w12c15fddma43e1cd5afec8938@mail.gmail.com> <20090225075310.GA85904@svzserv.kemerovo.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Eugene, > 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. > All the test scenarios here are bombarded with 1-Gig of network traffic. When packet drops due to high pps rate, meaning to say that the current FreeBSD system can't still handle this kind of situation with high packet rate? Or just it depends on your hardware? I just can't imagine that with 2x quad-core system processing on high packet rate, average CPU utilization consumes a total of 98%. > 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 - Maybe there's a way we can optimize this, but just don't know how and what particular component to optimize? > I've profiled kernel with DTrace. It seems it spends many cycles > inside inlined mtx_lock/mtx_unlock functions. I would like to assume this is also what had happened to my Chelsio NIC. But I might be wrong here, so if someone is familiar with what's going on, then your idea is highly appreciated. I used to install Dtrace but got no luck with installation. My em(4) driver is statically > compiled into the kernel so mtx_lock/mtx_unload are inlined assembler ops. > The same is true with my cxgb(4) driver, statically compiled in the kernel. Regards, Siquijor
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a27b90e40902250239x414d3fa7l12d291d278162377>