From patchwork Tue Apr 24 14:39:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Toshiaki Makita X-Patchwork-Id: 903533 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="LJLyJ0SG"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40VmFF2mJgz9ry1 for ; Wed, 25 Apr 2018 00:39:45 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754058AbeDXOjn (ORCPT ); Tue, 24 Apr 2018 10:39:43 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:39312 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753690AbeDXOjl (ORCPT ); Tue, 24 Apr 2018 10:39:41 -0400 Received: by mail-pf0-f194.google.com with SMTP id z9so12440437pfe.6 for ; Tue, 24 Apr 2018 07:39:41 -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=pG5kIAdxqav6Y4O7j37NHO8yb/1AnuZgiR9FcwTHNlw=; b=LJLyJ0SGpn3zFNJxt1VgJtfpQVwxMM4QwMJk1i1i2oMQ2zifMYWbpVKlXkOvPDfsMO gVef4D+wKtTat/e5I9El14/jKyprsFeXmFZZjRHAXhwVynsMs4FJPDL9/6J2+XGMH8mr U5LPjZlF0soAjKl79B1iw5EjLb0nrq20MBrs/+gMO03HDgS7nQEAevGxpuEnpx8Ypryd ZHUKP8SeE+AyEv9Tr8diL0XjUWWtOJ1Yvo1TdO7T5UaRvNPTRXJdyR44V2V7XaUxfy5M W6fcsh4QYOxztAWAKj2geJQ3sHAAEN0OB7NFTYiZu+1sUSLUWbxN5TpgcXBeuPXc57sq /l4g== 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=pG5kIAdxqav6Y4O7j37NHO8yb/1AnuZgiR9FcwTHNlw=; b=B63B6kJxRy+020yt/gW4VlI3zu9dbFfuZeovw/BxkzO8Sol9ZBofcaJRq0Bm4FCHc9 /h0jKZgK7jR5gwWoXZrlofrkff3ezllkfHU/30ar7OkAXea+dtnIKJwFP2kM0Bn6ZTlS DyHUGWOzPbPik0//km3di9klOKP6jq/vVZJPm3XDnuS/MlWRN0GEcWWIxHwmW78WakFp /a0j9/BZwnOG9ray0amh8gUYSFuPGhGs07dNrCv4b+dvEDS5qrlGRmqMiuFCbouqwJ53 MYp0Bap+lV6GVBAKk/8Cgb9uHGHzg/MHNPoEa2rUKERjIJmvqut8nybRWrTEexappSU/ jJwQ== X-Gm-Message-State: ALQs6tDKaTW/02Kod8K/BQBsHhu4HZz6b4Up+xKvawRpNHccin0uV3kr eXaoaOiH68J1f7ew7p0TFfMJ/+pTCIA= X-Google-Smtp-Source: AB8JxZq5LDfTQWS1i3nj8C2clPTq29VULGx6HZzWRB28eWGG6PuVjUn1loy+XnFqDQpCebc2CVVfHQ== X-Received: by 10.98.74.80 with SMTP id x77mr4713034pfa.142.1524580780722; Tue, 24 Apr 2018 07:39:40 -0700 (PDT) Received: from localhost.localdomain (i121-115-166-6.s42.a013.ap.plala.or.jp. [121.115.166.6]) by smtp.gmail.com with ESMTPSA id o64sm28179970pfb.62.2018.04.24.07.39.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Apr 2018 07:39:40 -0700 (PDT) From: Toshiaki Makita To: netdev@vger.kernel.org Cc: Toshiaki Makita Subject: [PATCH RFC 0/9] veth: Driver XDP Date: Tue, 24 Apr 2018 23:39:14 +0900 Message-Id: <20180424143923.26519-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 I wanted to avoid stack inflation by recursive calling of XDP programs. As an RFC this has not implemented recently introduced xdp_adjust_tail and based on top of Jesper's redirect memory return API patch set (684009d4fdaf). Any feedback is welcome. Thanks! Toshiaki Makita (9): net: Export skb_headers_offset_update and skb_copy_header veth: Add driver XDP veth: Avoid drops by oversized packets when XDP is enabled veth: Use NAPI for XDP veth: Handle xdp_frame in xdp napi ring veth: Add ndo_xdp_xmit veth: Add XDP TX and REDIRECT veth: Avoid per-packet spinlock of XDP napi ring on dequeueing veth: Avoid per-packet spinlock of XDP napi ring on enqueueing drivers/net/veth.c | 688 +++++++++++++++++++++++++++++++++++++++++++++++-- include/linux/filter.h | 16 ++ include/linux/skbuff.h | 2 + net/core/filter.c | 11 +- net/core/skbuff.c | 12 +- 5 files changed, 699 insertions(+), 30 deletions(-)