From patchwork Sun Jun 10 16:02:08 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Toshiaki Makita X-Patchwork-Id: 927378 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="heLWsLIl"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 413gs40HmBz9rvt for ; Mon, 11 Jun 2018 02:02:32 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932137AbeFJQC0 (ORCPT ); Sun, 10 Jun 2018 12:02:26 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:38854 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753435AbeFJQCZ (ORCPT ); Sun, 10 Jun 2018 12:02:25 -0400 Received: by mail-pl0-f68.google.com with SMTP id b14-v6so10925670pls.5 for ; Sun, 10 Jun 2018 09:02:25 -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=ho+rEJBAhFKOecvPXrog0VHoZfSkd7gtNGACzuIleu8=; b=heLWsLIlsOj4CwLgVZkd9IEwUIVdBTUtgV8R6y42yY7ndxi+4zhjgyXA8dfQ6kGidE 4lneaQKe47LAN3TYcOaFDWc6toetoLpnoRq45yVN/1x4coqx/lZl3joHVPkOn/y21LH7 6p0Hl/V4ZJulAVBvmrnOiW817TNWPwXxz1gPPWgu0/qzSEoaKNS27VTItkjxI41x2ySt 25gKEIizsjvHdU0L0FmDDcPITFTY8dH4Dv2vvw8g7FYaLDnVEHRSpiVBBuzJwXp9/PIR EwWnWr4yB0Zx0BKEaxXaXo4CeaQA3+lStTMhx2dfCDVPxy2qQaAK8D3aZo0n0gqDTgmP o+4g== 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=ho+rEJBAhFKOecvPXrog0VHoZfSkd7gtNGACzuIleu8=; b=uBfoSRuHjunmpJzESPNTqQ1jPGlY2g6wVVoxL5HxjrLpktvcCqXHgxstChJUgiAfj4 td6EsjHX0bHk1bR70lxbpjwXylBUAaSOEIwVEqABoaWzwjp1PPBnm4kSzGRskjRRD6SN /TscuGB91HTs71CixPDNGqbJQzjBaH5+7LzbTWcvCmbkrq+wqga7OiIrGEnXVeC6CJMA yoaM9PB2ttSDE5PzWnEt5viR+bx/KgMh70EfNZBGev/z5xWYEG8QQtb8cLR6+9DVWugT CCzGDj8Vj9nBzPh2+8q21jSd+gbjIuW1ZR6+3g1UWZ3Cb8Xgm/dbTMRlpp3rAl5pDtrD O4Kg== X-Gm-Message-State: APt69E0MKcHHBFToksS1IEw6pMoLvZO0+Evf3ESwCmgSxF5mtVotQ4A0 kN3vbfVHe/GPXFCbSJB+iDTM0A== X-Google-Smtp-Source: ADUXVKI6EAVWk977Zf5y0QnObZlil/ssIuUb1djKmSxYiEV17pwdzwNEOhTXrryAPqQ6uinXxpOiYA== X-Received: by 2002:a17:902:9b92:: with SMTP id y18-v6mr14783643plp.57.1528646545030; Sun, 10 Jun 2018 09:02:25 -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 o87-v6sm56068211pfa.106.2018.06.10.09.02.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 10 Jun 2018 09:02:24 -0700 (PDT) From: Toshiaki Makita To: netdev@vger.kernel.org Cc: Toshiaki Makita , Jesper Dangaard Brouer , Alexei Starovoitov , Daniel Borkmann Subject: [PATCH RFC v2 0/9] veth: Driver XDP Date: Mon, 11 Jun 2018 01:02:08 +0900 Message-Id: <20180610160217.3146-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. The envisioned use cases are: * 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. With single core and simple XDP programs which only redirect and drop packets, I got 10.5 Mpps redirect/drop rate with i40e 25G NIC + veth. XXV710 (i40e) --- (XDP redirect) --> veth===veth (XDP drop) 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. This patchset is based on top of net-next commit 75d4e704fa8d (netdev-FAQ: clarify DaveM's position for stable backports). Any feedback is welcome. Thanks! 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). Toshiaki Makita (9): net: Export skb_headers_offset_update veth: Add driver XDP veth: Avoid drops by oversized packets when XDP is enabled veth: Add another napi ring for ndo_xdp_xmit and handle xdp_frames 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 veth: Bulk skb xmit for XDP path drivers/net/veth.c | 734 ++++++++++++++++++++++++++++++++++++++++++++++++- include/linux/filter.h | 16 ++ include/linux/skbuff.h | 1 + include/net/xdp.h | 4 + net/core/filter.c | 11 +- net/core/skbuff.c | 3 +- net/core/xdp.c | 6 +- 7 files changed, 753 insertions(+), 22 deletions(-)