Re: Explaining RX-stages for XDP


Jesper Dangaard Brouer
 

On Tue, 27 Sep 2016 19:12:44 -0700 Alexei Starovoitov <alexei.starovoitov@...> wrote:

On Tue, Sep 27, 2016 at 11:32:37AM +0200, Jesper Dangaard Brouer wrote:

Let me try in a calm way (not like [1]) to explain how I imagine that
the XDP processing RX-stage should be implemented. As I've pointed out
before[2], I'm proposing splitting up the driver into RX-stages. This
is a mental-model change, I hope you can follow my "inception" attempt.

The basic concept behind this idea is, if the RX-ring contains
multiple "ready" packets, then the kernel was too slow, processing
incoming packets. Thus, switch into more efficient mode, which is a
"packet-vector" mode.

Today, our XDP micro-benchmarks looks amazing, and they are! But once
real-life intermixed traffic is used, then we loose the XDP I-cache
benefit. XDP is meant for DoS protection, and an attacker can easily
construct intermixed traffic. Why not fix this architecturally?

Most importantly concept: If XDP return XDP_PASS, do NOT pass the
packet up the network stack immediately (that would flush I-cache).
Instead store the packet for the next RX-stage. Basically splitting
the packet-vector into two packet-vectors, one for network-stack and
one for XDP. Thus, intermixed XDP vs. netstack not longer have effect
on XDP performance.

The reason for also creating an XDP packet-vector, is to move the
XDP_TX transmit code out of the XDP processing stage (and future
features). This maximize I-cache availability to the eBPF program,
and make eBPF performance more uniform across drivers.


Inception:
* Instead of individual packets, see it as a RX packet-vector.
* XDP should be seen as a stage *before* the network stack gets called.

If your mind can handle it: I'm NOT proposing a RX-vector of 64-packets.
I actually want N-packet per vector (8-16). As the NIC HW RX process
runs concurrently, and by the time it takes to process N-packets, more
packets have had a chance to arrive in the RX-ring queue.
Sounds like what Edward was proposing earlier with building
link list of skbs and passing further into stack?
Or the idea is different ?
The idea is quite different. It has nothing to do with Edward's
proposal[3]. The RX packet-vector is simply an array, either of pointers
or index numbers (into the RX-ring). The needed changes are completely
contained inside the driver.


As far as intermixed XDP vs stack traffic, I think for DoS case the
traffic patterns are binary. Either all of it is good or under attack
most of the traffic is bad, so makes sense to optimize for these two.
50/50 case I think is artificial and not worth optimizing for.
Sorry, but I feel you have completely misunderstood the concept of my
idea. It does not matter what traffic pattern you believe or don't
believe in, it is irrelevant. The fact is that intermixed traffic is
possible with the current solution. The core of my idea is to remove
the possibility for this intermixed traffic to occur, simply by seeing
XDP as a RX-stage before the stack.


For all good traffic whether xdp is there or not shouldn't matter
for this N-vector optimization. Whether it's a batch of 8, 16 or 64,
either via link-list or array, it should probably be a generic
mechanism independent of any xdp stuff.
I also feel you have misunderstood the N-vector "optimization".
But, yes, this introduction of RX-stages is independent of XDP.

The RX-stages is a generic change to the drivers programming model.


[...]
I think existing mlx4+xdp is already optimized for 'mostly attack' traffic
and performs pretty well, since imo 'all drop' benchmark is accurate.
The "all drop" benchmark is as artificial as it gets. It think Eric
agrees.

My idea is confining the XDP_DROP part to a RX-stage _before_ the
netstack. Then, the "all drop" benchmark number will get a little more
trustworthy.


Optimizing xdp for 'mostly good' traffic is indeed a challange.
We'd need all the tricks to make it as good as normal skb-based traffic.

I haven't seen any tests yet comparing xdp with 'return XDP_PASS' program
vs no xdp at all running netperf tcp/udp in user space. It shouldn't
be too far off.
Well, I did post numbers to the list with a 'return XDP_PASS' program[4]:
https://mid.mail-archive.com/netdev@vger.kernel.org/msg122350.html

Wake-up and smell the coffee, please revise your assumptions:
* It showed that the performance reduction is 25.98%!!!
(AB comparison dropping packets in iptables raw)

Conclusion: These measurements confirm that we need a page recycle
facility for the drivers before switching to order-0 allocations.

I did the same kind of experiment with mlx5. Where I change the memory
model to order-0 pages, and then I implemented page_pool on top. (Below
number are before I implemented the DMA part of page_pool, which do
work now).

page_pool work
- iptables-raw-drop: driver mlx5
* 4,487,518 pps - baseline-before => 100.0%
* 3,624,237 pps - mlx5 order0-patch => - 19.2% (slower)
* 4,806,142 pps - PoC page_pool patch => +7.1% (faster)

This Prove-of-Concept page_pool patch show that it is worth doing, as
the end result is a 7% performance improvement. It also show page
recycling is definitely needed, as this also show that the cost
switching to order-0 is approx 212 cycles on this machine.

(1/4487518-1/3624237)*10^9* 4GHz = -212.32 cycles (cost change to order-0)
(1/4806142-1/3624237)*10^9* 4GHz = -271.41 cycles (gain of recycling)

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer

[1] https://mid.mail-archive.com/netdev@vger.kernel.org/msg127043.html
[2] http://lists.openwall.net/netdev/2016/01/15/51
[3] http://lists.openwall.net/netdev/2016/04/19/89
[4] https://mid.mail-archive.com/netdev@vger.kernel.org/msg122350.html

Join iovisor-dev@lists.iovisor.org to automatically receive all group messages.