2018-02-07 18:59 GMT+01:00 Tom Herbert <t...@herbertland.com>: > On Wed, Jan 31, 2018 at 5:53 AM, Björn Töpel <bjorn.to...@gmail.com> wrote: [...] >> >> Below are the results in Mpps of the I40E NIC benchmark runs for 64 >> byte packets, generated by commercial packet generator HW that is >> generating packets at full 40 Gbit/s line rate. >> >> XDP baseline numbers without this RFC: >> xdp_rxq_info --action XDP_DROP 31.3 Mpps >> xdp_rxq_info --action XDP_TX 16.7 Mpps >> >> XDP performance with this RFC i.e. with the buffer allocator: >> XDP_DROP 21.0 Mpps >> XDP_TX 11.9 Mpps >> >> AF_PACKET V4 performance from previous RFC on 4.14-rc7: >> Benchmark V2 V3 V4 V4+ZC >> rxdrop 0.67 0.73 0.74 33.7 >> txpush 0.98 0.98 0.91 19.6 >> l2fwd 0.66 0.71 0.67 15.5 >> >> AF_XDP performance: >> Benchmark XDP_SKB XDP_DRV XDP_DRV_ZC (all in Mpps) >> rxdrop 3.3 11.6 16.9 >> txpush 2.2 NA* 21.8 >> l2fwd 1.7 NA* 10.4 >> > Hi Bjorn, > > This is very impressive work, thank you for contributing it! >
Thank you for looking at it! :-) > For these benchmarks how are the AF_PACKET and AF_XDP numbers to be > compared. For instance is rxdpop comparable to XDP_DROP and > "xdp_rxq_info --action XDP_DROP"? Given your explanation below, I > believe they are, but it might be better to make that clear up front. > Ah, yeah, that was a bit confusing: "xdp_rxq_info --action XDP_DROP" is doing an XDP_DROP (no buffer touching) and should be compared to "XDP_DROP". I meant to write "xdp_rxq_info --action XDP_DROP" instead of "XDP_DROP" for the second case. So, what this shows is that the buffer allocation scheme in the patch set (buff_pool) has a pretty hard performance regression (21.0 vs 31.3) on the regular XDP (and skb!) path. Not acceptable. "rxdrop" from AF_PACKET V4 should be compared to "rxdrop" from AF_XDP. This is dropping a packet in user space, whereas the former is dropping a packet in XDP/kernel space. Less confusing? Björn
