On Thu, 2014-03-06 at 21:48 +0000, Zoltan Kiss wrote:Performance team made a lot of measurements, I've added Marcus to comment on that.
>A long known problem of the upstream netback implementation that on the TXDo you have any other numbers? e.g. for a modern Intel or AMD system? A
>path (from guest to Dom0) it copies the whole packet from guest memory into
>Dom0. That simply became a bottleneck with 10Gb NICs, and generally it's a
>huge perfomance penalty. The classic kernel version of netback used grant
>mapping, and to get notified when the page can be unmapped, it used page
>destructors. Unfortunately that destructor is not an upstreamable solution.
>Ian Campbell's skb fragment destructor patch series [1] tried to solve this
>problem, however it seems to be very invasive on the network stack's code,
>and therefore haven't progressed very well.
>This patch series use SKBTX_DEV_ZEROCOPY flags to tell the stack it needs to
>know when the skb is freed up. That is the way KVM solved the same problem,
>and based on my initial tests it can do the same for us. Avoiding the extra
>copy boosted up TX throughput from 6.8 Gbps to 7.9 (I used a slower AMD
>Interlagos box, both Dom0 and guest on upstream kernel, on the same NUMA node,
>running iperf 2.0.5, and the remote end was a bare metal box on the same 10Gb
>switch)
slower box is likely to make the difference between copy and map larger,
whereas modern Intel for example is supposed to be very good at copying.
I've checked that back in November:
>Based on my investigations the packet get only copied if it is delivered toNumbers?
>Dom0 IP stack through deliver_skb, which is due to this [2] patch. This affects
>DomU->Dom0 IP traffic and when Dom0 does routing/NAT for the guest. That's a bit
>unfortunate, but luckily it doesn't cause a major regression for this usecase.