From patchwork Sun Jul 22 15:13:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Toshiaki Makita X-Patchwork-Id: 947474 Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="VI3sddBQ"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41YSn15Z1vz9s3N for ; Mon, 23 Jul 2018 01:13:25 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729698AbeGVQKT (ORCPT ); Sun, 22 Jul 2018 12:10:19 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:44806 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728506AbeGVQKT (ORCPT ); Sun, 22 Jul 2018 12:10:19 -0400 Received: by mail-pg1-f193.google.com with SMTP id r1-v6so10418040pgp.11 for ; Sun, 22 Jul 2018 08:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=+XrIckoVowPsIBtvSLYoW9+oDTv5C4CNHjj7VjebQ7c=; b=VI3sddBQ66DPIkKdXGjVJmGx5C7z98bFeUcEbqxzscxAtoAZ9eUdAprSZA/YaLTe3/ CVaVIxSH1dYBtp7LrUU+fVU2A7buUKKrBiYDc2cobyeeBYQ+//HBdn88zj4pq83Hll6W fCbuxhphyUFrzLrgZdAsxhJWubHbStvmXdLQ1vn0J3gghePMhaywJ8wmbwfNKyfQnRc7 w8C7NZfUOvbW4kMuqnnc7u6ly4U7C0lmjxhSTP8yPE0MwG3vemc8In+axfJaNJYfOmxd QueZT8UA7NhB0CmUfQIRuw+kbwGvExoNrw2ccrHENQIiDa0lsP8IZl9G44NAIzeHyiC1 n5ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=+XrIckoVowPsIBtvSLYoW9+oDTv5C4CNHjj7VjebQ7c=; b=SC/fYPnX0yb3TvsnRp9tOiNEhmg3vKWXvNgnQrmJXDc09SKlHo67Bk7/taYQ9tzU9f YZ94J+VvyiNgfLkDjAoXsNkY4RJa279ytaDPXtdmYcRUoN8ePeaqjcRiS8mfcQknsXTo 8LeiLeru1Vl11wJ4bvrqj/o6tSeG1BzRA9eLl/Gec9QM0fWtnJXQEqqGnf0HZecmqkkt oM++R5HwYXZyUKGuEsIbfPolqVr9wTYJDPPulRZePdceq95pXGejxwzXdt8n6v7LZfs7 VPVfQ5wc3rCZb5YtZPfNDqwS3LkNmK+a2GuSrTEXdspwbxQs9aRmfuNy5f/Pm4Zcfwzw JKFQ== X-Gm-Message-State: AOUpUlFQyu9uLQhmPAb/xR5Z0mFhSPXWBz1l5qJacjX5QF3BcI4Vc5Bl Hba9sSZbiCwGG4TKGXyXCfj2HUS5 X-Google-Smtp-Source: AAOMgpemkaO8sau7bHtkIJssrjct1WHbsmOnG7gJY0IzmkAH4ITfjY3sHfNnb2KFCxYNtTh69cWZTQ== X-Received: by 2002:a62:5984:: with SMTP id k4-v6mr9650949pfj.116.1532272399061; Sun, 22 Jul 2018 08:13:19 -0700 (PDT) Received: from localhost.localdomain (i153-145-22-9.s42.a013.ap.plala.or.jp. [153.145.22.9]) by smtp.gmail.com with ESMTPSA id v6-v6sm12092940pfa.28.2018.07.22.08.13.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 22 Jul 2018 08:13:18 -0700 (PDT) From: Toshiaki Makita To: netdev@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann Cc: Toshiaki Makita , Jesper Dangaard Brouer Subject: [PATCH v3 bpf-next 0/8] veth: Driver XDP Date: Mon, 23 Jul 2018 00:13:00 +0900 Message-Id: <20180722151308.5480-1-toshiaki.makita1@gmail.com> X-Mailer: git-send-email 2.14.3 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Toshiaki Makita This patch set introduces driver XDP for veth. Basically this is used in conjunction with redirect action of another XDP program. NIC -----------> veth===veth (XDP) (redirect) (XDP) In this case xdp_frame can be forwarded to the peer veth without modification, so we can expect far better performance than generic XDP. Envisioned use-cases -------------------- * Container managed XDP program Container host redirects frames to containers by XDP redirect action, and privileged containers can deploy their own XDP programs. * XDP program cascading Two or more XDP programs can be called for each packet by redirecting xdp frames to veth. * Internal interface for an XDP bridge When using XDP redirection to create a virtual bridge, veth can be used to create an internal interface for the bridge. Implementation -------------- This changeset is making use of NAPI to implement ndo_xdp_xmit and XDP_TX/REDIRECT. This is mainly because XDP heavily relies on NAPI context. - patch 1: Export a function needed for veth XDP. - patch 2-3: Basic implementation of veth XDP. - patch 4-5: Add ndo_xdp_xmit. - patch 6-7: Add XDP_TX and XDP_REDIRECT. - patch 8: Performance optimization for multi-queue env. Tests and performance numbers ----------------------------- Tested with a simple XDP program which only redirects packets between NIC and veth. I used i40e 25G NIC (XXV710) for the physical NIC. The server has 20 of Xeon Silver 2.20 GHz cores. pktgen --(wire)--> XXV710 (i40e) <--(XDP redirect)--> veth===veth (XDP) The rightmost veth loads XDP progs and just does DROP or TX. The number of packets is measured in the XDP progs. The leftmost pktgen sends packets at 37.1 Mpps (almost 25G wire speed). veth XDP action Flows Mpps ================================ DROP 1 10.6 DROP 2 21.2 DROP 100 36.0 TX 1 5.0 TX 2 10.0 TX 100 31.0 I also measured netperf TCP_STREAM but was not so great performance due to lack of tx/rx checksum offload and TSO, etc. netperf <--(wire)--> XXV710 (i40e) <--(XDP redirect)--> veth===veth (XDP PASS) Direction Flows Gbps ============================== external->veth 1 20.8 external->veth 2 23.5 external->veth 100 23.6 veth->external 1 9.0 veth->external 2 17.8 veth->external 100 22.9 Also tested doing ifup/down or load/unload a XDP program repeatedly during processing XDP packets in order to check if enabling/disabling NAPI is working as expected, and found no problems. Note: This patchset depends on commit d8d7218ad842 ("xdp: XDP_REDIRECT should check IFF_UP and MTU") which is currently in DaveM's net-next tree. v3: - Drop skb bulk xmit patch since it makes little performance difference. The hotspot in TCP skb xmit at this point is checksum computation in skb_segment and packet copy on XDP_REDIRECT due to cloned/nonlinear skb. - Fix race on closing device. - Add extack messages in ndo_bpf. v2: - Squash NAPI patch with "Add driver XDP" patch. - Remove conversion from xdp_frame to skb when NAPI is not enabled. - Introduce per-queue XDP ring (patch 8). - Introduce bulk skb xmit when XDP is enabled on the peer (patch 9). Signed-off-by: Toshiaki Makita Toshiaki Makita (8): net: Export skb_headers_offset_update veth: Add driver XDP veth: Avoid drops by oversized packets when XDP is enabled veth: Handle xdp_frames in xdp napi ring veth: Add ndo_xdp_xmit xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info veth: Add XDP TX and REDIRECT veth: Support per queue XDP ring drivers/net/veth.c | 735 ++++++++++++++++++++++++++++++++++++++++++++++++- include/linux/skbuff.h | 1 + include/net/xdp.h | 4 + net/core/skbuff.c | 3 +- net/core/xdp.c | 6 +- 5 files changed, 737 insertions(+), 12 deletions(-)