From patchwork Sun Nov 5 03:22:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christina Jacob X-Patchwork-Id: 834242 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@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; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="HZA4ALvB"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3yV1H95bldz9t39 for ; Sun, 5 Nov 2017 14:23:17 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751940AbdKEDWn (ORCPT ); Sat, 4 Nov 2017 23:22:43 -0400 Received: from mail-pg0-f48.google.com ([74.125.83.48]:51018 "EHLO mail-pg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751619AbdKEDWl (ORCPT ); Sat, 4 Nov 2017 23:22:41 -0400 Received: by mail-pg0-f48.google.com with SMTP id y5so5607571pgq.7; Sat, 04 Nov 2017 20:22:40 -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=ZBFBO+nYYanRZ54818Y2Ord68WG7H5hpOzIHMuFjGhY=; b=HZA4ALvBpZaiIOtbcoCP+LdIdHqw/KmKpNzr209ottJyRtFykxor22y3Pd7ivhbuFG 5gjKIjvR3w0qB7zWgY1q32Hp5DF2oJVPS8E0g3n/Xy6X2VNtdfTPSLspa1IpxHoxUTy1 dPimxWZ7mvfNYL+WGIn5m2QgLoID6utL7+o+OyaSOZBUucP563BuTJjxNOLSyYtslxo7 m73lAlhxuYxBMPErtWtOIfUvakCpoyPLmcM8S8yfLZE/1yvzBfNIZCBmLhPTYJGBQqFR YwWI7ij+cGh4BIKx/hAUpPGj6ybuznJKMTGRqNBq117PdnrAllq2z/0BYRr4ygphq1ut vPoQ== 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=ZBFBO+nYYanRZ54818Y2Ord68WG7H5hpOzIHMuFjGhY=; b=tjLiZXe3dPIfTIapA5lUpc53CT33XIH+k6TLh+2DDsnR+ichsVuIAhWYXhd6YuvBdO jJDIJ73P78rxH9TrvLaIpkR0sC1/K2+oOwP9de9Vnvss/ZIK2bqxzS9wvapGnQrSYYwq 78RWKHZRmQDQEGv3RnmQOLwz8anSQs14Gy8gdtdEvJqoupKxwLNavccx10pjJL77CWMN 6xTZIQMBl9b8Rtkyb8uhhDB5nFFr0k2m3j6083JfgaifVGaKzLS+0tyuc/Fbj05y1cT6 pjivuYlXd0PGEOIIGUhYD6zUGSdFppjLPQ7Q/SG/Z7Xwxpz64Ih9Qp27kuGw6INklX0B O0jA== X-Gm-Message-State: AMCzsaU7niTTBDcLEXaUoyu/ECGEfKk3HO1eRVAljBFN0cTI9uMtvDky 0PiphnB+fI4P4hGVQYKpg8+bQiNF X-Google-Smtp-Source: ABhQp+TltnL+55BFRQSyoHPvfFOrLtpKGRPJurZ/o516aTVsmG81A+8xzmBz5hLurM72Swe0R2rHOA== X-Received: by 10.84.236.12 with SMTP id q12mr11013123plk.314.1509852160265; Sat, 04 Nov 2017 20:22:40 -0700 (PDT) Received: from cavium-Inspiron-7520.caveonetworks.com ([111.93.218.67]) by smtp.gmail.com with ESMTPSA id q13sm21058415pfi.166.2017.11.04.20.22.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Nov 2017 20:22:39 -0700 (PDT) From: Christina Jacob To: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, brouer@redhat.com, Sunil.Goutham@cavium.com, Christina.Jacob@cavium.com Subject: [PATCH v4 0/1] XDP program for ip forward Date: Sun, 5 Nov 2017 08:52:29 +0530 Message-Id: <1509852150-1466-1-git-send-email-christina.jacob.koikara@gmail.com> X-Mailer: git-send-email 2.7.4 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Christina Jacob The patch below implements port to port forwarding through route table and arp table lookup for ipv4 packets using bpf_redirect helper function and lpm_trie map. This has an improved performance over the normal kernel stack ip forward. Implementation details. ----------------------- The program uses one map each for arp table, route table and packet count. The number of entries the program can process is limited by the size of the map used. In the xdp_router_ipv4_user.c, initially, the routing table is read and is stored in an lpm trie map. The arp table is read and stored in an array map There are two netlink sockets that listens to any change in the route table and arp table. There are two types of changes to the route table. 1.New The new entries are added to the lpm_trie with proper key and prefix length If there is a another entry in the route table with a different metric(only metric is considered). Then the values are compared and the one with lowest metric is added to the node. 2.Deletion On deletion from the route table, The particular node is removed and the entire route table is again read to check if there is another entry with a different metric. This implementation depends on bpf: Implement map_delete_elem for BPF_MAP_TYPE_LPM_TRIE which is not yet upstreamed. There are two types of changes to the route table 1.New The new arp entries are added in the in the array map directly with the ip address as the key and the destination mac address as the value. 2.Delete The entry corresponding to the particular ip is deleted from the arp table map. Another map is maintained for entries in the route table having 32 bit mask. such entries can have a corresponding arp entry which if stored together with the route entry in an array map and can be accessed in O(1) time. Eliminating the trie lookup and arp lookup. In the xdp_router_ipv4_kern.c, The array map for the 32 bit mask entries checked to see if there is a key that exactly matches with the destination ip. If it has a non zero destination mac entry then the xdp data is updated accordingly Otherwise a proper route and arp table lookup is done using the lpm_trie and the arp table array map. Usage: as ./xdp_router_ipv4 -S (-S for generic xdp implementation ifindex- the index of the interface to which the xdp program has to be attached.) in 4.14-rc3 kernel. Changes from v1 to v2 --------------------- * As suggested by Jesper Dangaard Brouer 1. Changed the program name to list xdp_router_ipv4 2. Changed the commandline arguments from ifindex list to interface name Usage : ./xdp_router_ipv4 [-S] -S for generic xdp implementation -interface name list is the list of interfaces to which the xdp program should attach to * As suggested by Daniel Borkmann 1. Using __builin_memcpy to update source and destination mac in the bpf kernel program. 2. Started using __be32 in the kernel program to be inline with the data type used in user program 3. Rectified few style issues. * Corrected the copyright issue pointed out by David Ahern * Fixed the bug: The already attached interfaces are not detached from the xdp program if the program fails to attach to an interface later in the list. Changes from v2 to v3 --------------------- * As pointed out by Jesper Dangaard Brouer 1. Changed the program name in the cover letter. 2. Changed variable declararions to follow Reverse-xmas tree rule. 3. Reduced the nesting in code for readability. 4. Fixed bug: incorrect mac address being set for source and destination mac. 5. Fixed comment style. * As suggested by Stephen Hemminger Changed all the bzeros' to memset. * As suggested by David Laight removed the signed remainders calculation. * As suggested by Stephen Hemminger and David Daney 1. Added checks for the ioctl return value. 2. Changed data types to be64 to be sure about the size of the data type. 3. Verified byte order. Using the mac address from ioctl in network byte order. not casting to to long data type anymore. 4. Fixed returning address of local variable. Changes from v3 to v4 --------------------- * As suggested by Jesper, 1. Removed redundant typecastings. 2. Modified program to use bpf_redirect_map for better performance. 3. Changed program name in the code as well. Christina Jacob (1): xdp: Sample xdp program implementing ip forward samples/bpf/Makefile | 4 + samples/bpf/xdp_router_ipv4_kern.c | 186 +++++++++++ samples/bpf/xdp_router_ipv4_user.c | 659 +++++++++++++++++++++++++++++++++++++ 3 files changed, 849 insertions(+) create mode 100644 samples/bpf/xdp_router_ipv4_kern.c create mode 100644 samples/bpf/xdp_router_ipv4_user.c