Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1541244ybx; Thu, 7 Nov 2019 13:22:28 -0800 (PST) X-Google-Smtp-Source: APXvYqzgvB0alYJJODQl4T41WuZqKrHZgVfh3i/VPZwcF5qrlL6Cyzo43zCNNB9WSCOHrkU253KM X-Received: by 2002:a50:ac2c:: with SMTP id v41mr6158067edc.11.1573161748407; Thu, 07 Nov 2019 13:22:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573161748; cv=none; d=google.com; s=arc-20160816; b=p2ZYjL/gWNl7jxtwVtuNlbfjV9AChK/eeOSK2hwyTkqgX9MUnc/FHRVN+XHBR9fEtF zEdroJve9ymciLfU5A/jr/3m16iDBdNZCeDXN1GIxUuoKUEga36HiJHOOhxFntz8fmRi /33Kg0DqoveAgCBRx1wbCvodWMjdWk2ySeoe59a4NnuSynUib6F5Xl3bHIKbprkuT5l8 rmXd8lRwY83OYiASkdubQCcdazZGsVzK7g3QlXg+sPKMemys4ykv3sNbvkpJAVI2qYYy MFwbQvHQmm8exIohrLEue7AzZl3mUC+Kqmo5m6xHQseIXCE1nUfWgms7gOM9wquq06TX 102Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:mime-version :message-id:date:dkim-signature; bh=6u+JVwA832DZQxhqfbOLyuFUBvBp6cNKT0wKluwBqRo=; b=Q+KZ+dsJB6EuF8aQ5U2pL24GvPTjTDUUGbX/FuquWKpEw7rXbA34wOgRo21yZ2cLT2 FT8jbt78WssVyoNecq2L4W8RxhmiaEbMwzIlSUIBFw2GiJVe/jAxkOWcYojfeNU1Emqf F2WPzzfF/SmRCV0jZI/1b5eQan9XAeFrdkn7UVKaX3Ch/lMulBYByEvI/YhjVO1qtAkT w84MLNYMeQpLI1zw15HP+DI8GQ6lDXXU1wOrxkKS4etT9mgj5BD1hmrwNMBTdBxSVJ0f UxqZm4HboOSoXl+uwt86Il5djTY6N9vQuHO7bXmdEDDgNU1u5Xjn0I/AWOxaJ8jr6Po1 l6+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=lEBiQrXr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b49si2199377eda.312.2019.11.07.13.22.03; Thu, 07 Nov 2019 13:22:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=lEBiQrXr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726809AbfKGVVC (ORCPT + 99 others); Thu, 7 Nov 2019 16:21:02 -0500 Received: from mail-vk1-f201.google.com ([209.85.221.201]:44024 "EHLO mail-vk1-f201.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726793AbfKGVVA (ORCPT ); Thu, 7 Nov 2019 16:21:00 -0500 Received: by mail-vk1-f201.google.com with SMTP id k127so1707003vka.10 for ; Thu, 07 Nov 2019 13:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=6u+JVwA832DZQxhqfbOLyuFUBvBp6cNKT0wKluwBqRo=; b=lEBiQrXrWG2wgDQ5zKGOW/z/xlj8J49kypK3w0hinwPeCT677Eg7dvxvkhFgzLrVqp S++7WbHgea82mstavCEFzyAMWY2wuwq8Gerfc6BtUeAYtbIRoNAQRmlMIlYfTHwz7oKj KEqkrXA7ENGPmHoLzYoeQsjdWmgeezFvZWulnoQQvenVlih4e3cFhM06gBQhN7u8Ct/c ApHxqmKj8SoZKcMNLlIfyG6E1KlG42g+IqSSbvwQGSrrpxeCZEs8ICdFG5Umpkqyzwx7 z2KtetpehWpXXq2oXZktoFUXD3+AfQW2EySMRbXSOosav1cNFn9Nko7ktJP3P63PHCm9 4q8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=6u+JVwA832DZQxhqfbOLyuFUBvBp6cNKT0wKluwBqRo=; b=RLl1us5ekyK+1pBAM+8mECItQtcM0amN610YMid3fRk8cx39BoVVgWpSlfA7sTAkaq dPLS1Yl6/OxQqn5jqFSVGkbb74JdM5gVII2NhbCZhRFD3VKsUvFP+EbBPWHEiV1L/Y+F NX38Xgyu+yQYfg+uZYYms+brqikemkaxqEs+Lo2XZ6WDgfzdVbITh3f5hLgvAaWq3nDY t9O6IGBEwYwmex3XwPThB3JtteIoEcykMsDZThj6YLv7+Haq8r6SncWQIRoO3HB9h/Cy sWEGaG02eSByOTvzkhb/Xky/H3S64nwcCEPCQ5QRw4Y6aNDMRjAboE3aLGcsm5r23zp6 baDw== X-Gm-Message-State: APjAAAVUs9Vw7fHet8avGnP6P7JXYhBbWasfqihFimRDn6zvMjO7ZtBL x4wJ5MpgeVHrYOtT2rjaJfP4WTGic6AT X-Received: by 2002:ac5:c7b1:: with SMTP id d17mr1927609vkn.90.1573161657334; Thu, 07 Nov 2019 13:20:57 -0800 (PST) Date: Thu, 7 Nov 2019 13:20:20 -0800 Message-Id: <20191107212023.171208-1-brianvv@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.24.0.432.g9d3f5f5b63-goog Subject: [RFC bpf-next 0/3] bpf: adding map batch processing support From: Brian Vazquez To: Brian Vazquez , Alexei Starovoitov , Daniel Borkmann , "David S . Miller" Cc: Stanislav Fomichev , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Brian Vazquez , Yonghong Song , Petar Penkov , Willem de Bruijn Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a follow up in the effort to batch bpf map operations to reduce the syscall overhead with the map_ops. I initially proposed the idea and the discussion is here: https://lore.kernel.org/bpf/20190724165803.87470-1-brianvv@google.com/ Yonghong talked at the LPC about this and also proposed and idea that handles the special weird case of hashtables by doing traversing using the buckets as a reference instead of a key. Discussion is here: https://lore.kernel.org/bpf/20190906225434.3635421-1-yhs@fb.com/ This RFC proposes a way to extend batch operations for more data structures by creating generic batch functions that can be used instead of implementing the operations for each individual data structure, reducing the code that needs to be maintained. The series contains the patches used in Yonghong's RFC and the patch that adds the generic implementation of the operations plus some testing with pcpu hashmaps and arrays. Note that pcpu hashmap shouldn't use the generic implementation and it either should have its own implementation or share the one introduced by Yonghong, I added that just as an example to show that the generic implementation can be easily added to a data structure. What I want to achieve with this RFC is to collect early feedback and see if there's any major concern about this before I move forward. I do plan to better separate this into different patches and explain them properly in the commit messages. Current known issues where I would like to discuss are the followings: - Because Yonghong's UAPI definition was done specifically for iterating buckets, the batch field is u64 and is treated as an u64 instead of an opaque pointer, this won't work for other data structures that are going to use a key as a batch token with a size greater than 64. Although I think at this point the only key that couldn't be treated as a u64 is the key of a hashmap, and the hashmap won't use the generic interface. - Not all the data structures use delete (because it's not a valid operation) i.e. arrays. So maybe lookup_and_delete_batch command is not needed and we can handle that operation with a lookup_batch and a flag. - For delete_batch (not just the lookup_and_delete_batch). Is this operation really needed? If so, shouldn't it be better if the behaviour is delete the keys provided? I did that with my generic implementation but Yonghong's delete_batch for a hashmap deletes buckets. Brian Vazquez (1): bpf: add generic batch support Yonghong Song (2): bpf: adding map batch processing support tools/bpf: test bpf_map_lookup_and_delete_batch() include/linux/bpf.h | 21 + include/uapi/linux/bpf.h | 22 + kernel/bpf/arraymap.c | 4 + kernel/bpf/hashtab.c | 331 ++++++++++ kernel/bpf/syscall.c | 573 ++++++++++++++---- tools/include/uapi/linux/bpf.h | 22 + tools/lib/bpf/bpf.c | 59 ++ tools/lib/bpf/bpf.h | 13 + tools/lib/bpf/libbpf.map | 4 + .../map_tests/map_lookup_and_delete_batch.c | 245 ++++++++ .../map_lookup_and_delete_batch_array.c | 118 ++++ 11 files changed, 1292 insertions(+), 120 deletions(-) create mode 100644 tools/testing/selftests/bpf/map_tests/map_lookup_and_delete_batch.c create mode 100644 tools/testing/selftests/bpf/map_tests/map_lookup_and_delete_batch_array.c -- 2.24.0.432.g9d3f5f5b63-goog