From patchwork Thu May 17 14:28:06 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mathieu Xhonneux X-Patchwork-Id: 915400 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="nyJMcP41"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40mrFC2kSTz9s0y for ; Thu, 17 May 2018 22:28:31 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751438AbeEQM22 (ORCPT ); Thu, 17 May 2018 08:28:28 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:35560 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061AbeEQM21 (ORCPT ); Thu, 17 May 2018 08:28:27 -0400 Received: by mail-wm0-f68.google.com with SMTP id o78-v6so8821975wmg.0 for ; Thu, 17 May 2018 05:28:26 -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:mime-version :content-transfer-encoding; bh=mkIFPii5ezo+7ZYP0gLVT9vs9QDuB7G/mKW1m/tTtiY=; b=nyJMcP41eK3W8zxd+wntR7/GNWM8dt4qSG9fFoFl4VqrItvoZoKy+XSftVIOtzMedh B1oClNvUH8FbxVZKB32XuqCGYuEadKtWQLIIyrN+l5H4AOAryuXPsvnBYUh59cKcVfOF VdwNppCzwmrGQNA3F+Ql7Mpvil45dQwUTNrpk1AJePvaGWhq5xpolhenLzibUteWheyz 0temIljiRUMFQ5yymZ0x4PKK1JCDq3jxjzZa3QKjhJp66GpPXBMGkQkhPYDe2JMYR2V2 GNMKjQRD65mgd0erg9RNcFxGvrZhJM65s2rnntSgusMhhBmBuPl/3S10MhxFF1FJLV+W LMtw== 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:mime-version :content-transfer-encoding; bh=mkIFPii5ezo+7ZYP0gLVT9vs9QDuB7G/mKW1m/tTtiY=; b=mnyPGqtvXiSEcu5XpkY9PjW0wAYOopo3L6cwjeXPQCDx+cLKW7D1f4UKFMNk+2RxKu kY17d/D72olKfqYymM0FAvjZU9387yPdh/IdZDqnrW7o/CoHtz93pn8ejFGwoNiL5+rt ktJMjpo34apQlmGAPywuWnCnbtF76DgFDKBz6hYoWr9BQ5n9ye6Qd+nmL0VYF1cYybmS UT6j1aqyFp7Yd8J2XqjINphN0QPkVQUAJtLMdYBvFmo1sV2ZewDuPiZ7zmeMd60IkdfG d5HMeWvwEiE/h403Y0IMmcLn86xKe1s8u5QrpPuq5rPlHWW9CxasuIpyW8Vs+d3+ZkyF 0W3A== X-Gm-Message-State: ALKqPwe3f3r4J+8UWX/AvHNpj8jUaHvvPw3DXiXhv+aGECoUZtMmW7Dq zXfHkSLlJX1lGkf9CK1BezP+Ww== X-Google-Smtp-Source: AB8JxZoCCWd76Fn2sb4uncnl9QJyOitpjV+G1Vk01ZgcddyVgX/IN6ftvLD2Ibqk6ikUNAKEPTcTNw== X-Received: by 2002:a50:860f:: with SMTP id o15-v6mr6734649edo.243.1526560105807; Thu, 17 May 2018 05:28:25 -0700 (PDT) Received: from trondheim.voo.be ([2a02:2788:7d4:17f1:3322:3b09:5c0a:74bb]) by smtp.googlemail.com with ESMTPSA id y7-v6sm2421934edq.8.2018.05.17.05.28.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 05:28:25 -0700 (PDT) From: Mathieu Xhonneux To: netdev@vger.kernel.org Cc: daniel@iogearbox.net, dlebrun@google.com, alexei.starovoitov@gmail.com Subject: [PATCH bpf-next v6 0/6] ipv6: sr: introduce seg6local End.BPF action Date: Thu, 17 May 2018 15:28:06 +0100 Message-Id: X-Mailer: git-send-email 2.16.1 MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org As of Linux 4.14, it is possible to define advanced local processing for IPv6 packets with a Segment Routing Header through the seg6local LWT infrastructure. This LWT implements the network programming principles defined in the IETF “SRv6 Network Programming” draft. The implemented operations are generic, and it would be very interesting to be able to implement user-specific seg6local actions, without having to modify the kernel directly. To do so, this patchset adds an End.BPF action to seg6local, powered by some specific Segment Routing-related helpers, which provide SR functionalities that can be applied on the packet. This BPF hook would then allow to implement specific actions at native kernel speed such as OAM features, advanced SR SDN policies, SRv6 actions like Segment Routing Header (SRH) encapsulation depending on the content of the packet, etc. This patchset is divided in 6 patches, whose main features are : - A new seg6local action End.BPF with the corresponding new BPF program type BPF_PROG_TYPE_LWT_SEG6LOCAL. Such attached BPF program can be passed to the LWT seg6local through netlink, the same way as the LWT BPF hook operates. - 3 new BPF helpers for the seg6local BPF hook, allowing to edit/grow/ shrink a SRH and apply on a packet some of the generic SRv6 actions. - 1 new BPF helper for the LWT BPF IN hook, allowing to add a SRH through encapsulation (via IPv6 encapsulation or inlining if the packet contains already an IPv6 header). As this patchset adds a new LWT BPF hook, I took into account the result of the discussions when the LWT BPF infrastructure got merged. Hence, the seg6local BPF hook doesn’t allow write access to skb->data directly, only the SRH can be modified through specific helpers, which ensures that the integrity of the packet is maintained. More details are available in the related patches messages. The performances of this BPF hook have been assessed with the BPF JIT enabled on a Intel Xeon X3440 processors with 4 cores and 8 threads clocked at 2.53 GHz. No throughput losses are noted with the seg6local BPF hook when the BPF program does nothing (440kpps). Adding a 8-bytes TLV (1 call each to bpf_lwt_seg6_adjust_srh and bpf_lwt_seg6_store_bytes) drops the throughput to 410kpps, and inlining a SRH via bpf_lwt_seg6_action drops the throughput to 420kpps. All throughputs are stable. ------- v2: move the SRH integrity state from skb->cb to a per-cpu buffer v3: - document helpers in man-page style - fix kbuild bugs - un-break BPF LWT out hook - bpf_push_seg6_encap is now static - preempt_enable is now called when the packet is dropped in input_action_end_bpf v4: fix kbuild bugs when CONFIG_IPV6=m v5: fix kbuild sparse warnings when CONFIG_IPV6=m v6: fix skb pointers-related bugs in helpers Thanks. Mathieu Xhonneux (6): ipv6: sr: make seg6.h includable without IPv6 ipv6: sr: export function lookup_nexthop bpf: Add IPv6 Segment Routing helpers bpf: Split lwt inout verifier structures ipv6: sr: Add seg6local action End.BPF selftests/bpf: test for seg6local End.BPF action include/linux/bpf_types.h | 5 +- include/net/seg6.h | 7 +- include/net/seg6_local.h | 32 ++ include/uapi/linux/bpf.h | 97 ++++- include/uapi/linux/seg6_local.h | 3 + kernel/bpf/verifier.c | 1 + net/core/filter.c | 393 ++++++++++++++++--- net/ipv6/Kconfig | 5 + net/ipv6/seg6_local.c | 180 ++++++++- tools/include/uapi/linux/bpf.h | 97 ++++- tools/lib/bpf/libbpf.c | 1 + tools/testing/selftests/bpf/Makefile | 6 +- tools/testing/selftests/bpf/bpf_helpers.h | 12 + tools/testing/selftests/bpf/test_lwt_seg6local.c | 438 ++++++++++++++++++++++ tools/testing/selftests/bpf/test_lwt_seg6local.sh | 140 +++++++ 15 files changed, 1344 insertions(+), 73 deletions(-) create mode 100644 include/net/seg6_local.h create mode 100644 tools/testing/selftests/bpf/test_lwt_seg6local.c create mode 100755 tools/testing/selftests/bpf/test_lwt_seg6local.sh