lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f8440be16d88634c31f1e817d5b63ad9.squirrel@www.liukuma.net>
Date:	Thu, 23 Dec 2010 12:50:57 +0200
From:	"juice" <juice@...gman.org>
To:	"Jon Zhou" <Jon.Zhou@...u.com>,
	"Eric Dumazet" <eric.dumazet@...il.com>,
	"Stephen Hemminger" <shemminger@...tta.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Using ethernet device as efficient small packet generator

>
> Ethtool -S "My intel x520 10G nic" will show there are 8 rx/tx queues
>
> I just made 5M pps with 64 bytes packet according to link given by eric
> Dumazet.
> (connect the 2 ports with each other of the NIC, XEON E5540,kernel
> 2.6.32,set irq affinity, Noted that I have an abnormal ksoftirqd/2 which
> occupy 30%cpu even at idle state, so the result still has space to
> improve)
>
> At another old kernel(2.6.16) with tg3 and bnx2 1G NIC,XEON E5450, I only
> got 490K pps(it is about 300Mbps,30% GE), I think the reason is multiqueue
> unsupported in this kernel.
>
> I will do a test with 1Gb nic on the new kernel later.
>

Which do you suppose is the reason for poor performance on my setup,
is it lack of multiqueue HW in the GE NIC's I am using or is it lack
of multiqueue support in the kernel (2.6.32) that I am using?

Is multiqueue really necessary to achieve the full 1GE saturation, or
is it only needed on 10GE NIC's?

As I understand multiqueue is useful only if there are lots of CPU cores
to run, each handling one queue.

The application I am thinking of, preloading a packet sequence into
kernel from userland application and then starting to send from buffer
propably does not benefit so much from many cores, it would be enough
that one CPU would handle the sending and other core(s) would handle
other tasks.

Yours, Jussi Ohenoja


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ