Software receive packet steering can use smp cpu all Performance.

this is the patch file:
http://lwn.net/Articles/361440/
http://lwn.net/Articles/363339/

can't be add in routeros 4.4?

wow! sweeeet =) MT staff, what do you say? =) v5?

those are some impressive pps benchmarks!

this only benefits dualcore CPU's that have shared cache. we don't add unfinished patches, when this will be a part of the kernel, and we upgrade RouterOS to that kernel, then you will have it

in simple language: still only v5 or v6 =)

rps: Receive Packet Steering already Merge in kernel next git.
so if use kernel 2.6.35 will have best network capabilities on smp cpu.

http://git.kernel.org/?p=linux/kernel/g ... b625c2fcad

huh =(

v5 uses 2.6.32.5 =( maybe it's possible to switch to 2.6.35 before the first beta? %)

UPD: but... isn't it introduces some problems with parallel shaping?

Linux 2.6.35 has been released on 1 Aug, 2010.

1. Prominent features (the cool stuff)
1.1. Transparent spreading of incoming network traffic load across CPUs
Recommended LWN articles: "Receive packet steering" and "Receive flow steering"
Network cards have improved the bandwidth to the point where it's hard for a single modern CPU to keep up. Two new features contributed by Google aim to spread the load of network handling across the CPUs available in the system: Receive Packet Steering (RPS) and Receive Flow Steering (RFS).
RPS distributes the load of received packet processing across multiple CPUs. This solution allows protocol processing (e.g. IP and TCP) to be performed on packets in parallel (contrary to the previous code). For each device (or each receive queue in a multi-queue device) a hashing of the packet header is used to index into a mask of CPUs (which can be configured manually in /sys/class/net/<device>/queues/rx-<n>/rps_cpus) and decide which CPU will be used to process a packet. But there're also some heuristics provided by the RFS side of this feature. Instead of randomly choosing the CPU from a hash, RFS tries to use the CPU where the application running the recvmsg() syscall is running or has run in the past, to improve cache utilization. Hardware hashing is used if available. This feature effectively emulates what a multi-queue NIC can provide, but instead it is implement in software and for all kind of network hardware, including single queue cards and not excluding multiqueue cards.
Benchmarks of 500 instances of netperf TCP_RR test with 1 byte request and response show the potential benefit of this feature, a e1000e network card on 8 core Intel server goes from 104K tps at 30% CPU usage, to 303K tps at 61% CPU usage when using RPS+RFS. A RPC test which is similar in structure to the netperf RR test with 100 threads on each host, but doing more work in userspace that netperf, goes from 103K tps at 48% of CPU utilization to 223K at 73% CPU utilization and much lower latency.
Code: (commit 1, 2, 3)

Simple question . v5 or v6 ?

Take a look at this address http://www.linuxinsider.com/rsstory/70537.html . More excited after reading .

In his announcement of the release, Linux creator Linus Torvalds referred readers to the Kernel Newbies site for a full description of its features.
Tripled Performance

The addition of RPS and RFS technology "effectively emulates what a multiqueue NIC can provide, but instead it is implemented in software and for all kind of network hardware, including single queue cards and not excluding multiqueue cards," Kernel Newbies explained.

A benchmark test, in fact, recently showed how an eight-core Intel (Nasdaq: INTC) CPU-based server with an Intel e1000e network adapter went from 104K tps at about 30 percent CPU usage to 303K tps at 61 percent CPU usage when using RPS and RFS.

In other words, the technology almost tripled performance while doubling overall system utilization, Charles King, principal analyst at Pund-IT, told LinuxInsider.

"The context for this is that the industry and businesses are firmly moving into a world where multicore technology is the processor technology of choice across the x86 world -- it doesn't matter if you're using Intel or AMD," King explained.

we will try to make it into v5, but if kernel upgrade turns out to be more difficult than thought, then only in v6

new kernel 2.6.35 Stable
Include RPS 、RFS


Strongly recommended to upgrade ！！！！

please! made that in v5!! we need to reach a milion pps

yes. we will

first update kernel 2.6.35
Second Improve Max entries to 500k

yes. we will

you rocks!!

yes. we will

Thanks

thanks mikrotik!!!!



kernel updated and *) added support for RPS (Receive Packet Steering) on multicore systems!!

COOOOOOOOOOOOOOOL!!!

kernel 2.6.37:
xps: Transmit Packet Steering
http://git.kernel.org/?p=linux/kernel/g ... 8ef1176d4f
This patch implements transmit packet steering (XPS) for multiqueue
devices. XPS selects a transmit queue during packet transmission based
on configuration. This is done by mapping the CPU transmitting the
packet to a queue. This is the transmit side analogue to RPS-- where
RPS is selecting a CPU based on receive queue, XPS selects a queue
based on the CPU (previously there was an XPS patch from Eric
Dumazet, but that might more appropriately be called transmit completion
steering).

Each transmit queue can be associated with a number of CPUs which will
use the queue to send packets. This is configured as a CPU mask on a
per queue basis in:

/sys/class/net/eth<n>/queues/tx-<n>/xps_cpus

The mappings are stored per device in an inverted data structure that
maps CPUs to queues. In the netdevice structure this is an array of
num_possible_cpu structures where each structure holds and array of
queue_indexes for queues which that CPU can use.

The benefits of XPS are improved locality in the per queue data
structures. Also, transmit completions are more likely to be done
nearer to the sending thread, so this should promote locality back
to the socket on free (e.g. UDP). The benefits of XPS are dependent on
cache hierarchy, application load, and other factors. XPS would
nominally be configured so that a queue would only be shared by CPUs
which are sharing a cache, the degenerative configuration woud be that
each CPU has it's own queue.

Below are some benchmark results which show the potential benfit of
this patch. The netperf test has 500 instances of netperf TCP_RR test
with 1 byte req. and resp.

bnx2x on 16 core AMD
XPS (16 queues, 1 TX queue per CPU) 1234K at 100% CPU
No XPS (16 queues) 996K at 100% CPU