Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3780924imm; Mon, 30 Jul 2018 03:26:51 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcIZjbfEKfyXgDPIDEtGV36eEoiS+ydIi2DymEhFM032pHsarqlxCRiH0yG2qzrl7D+S+Dw X-Received: by 2002:a17:902:bf06:: with SMTP id bi6-v6mr15967718plb.76.1532946411074; Mon, 30 Jul 2018 03:26:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532946411; cv=none; d=google.com; s=arc-20160816; b=HQEEfNTDH4zOAqvUpMvRbuO5wtABL3U8MxY33uS61nyBvwLD+7wNPiOXkV6MbPdXOQ qE/lFnePjgu9Z4qcZpeLNer6DrEaKfDYCW7GRddxmxCZvTHbDaaFII7eIlvRD4ZjNz9t Nne90tYYgaw+NByDgNZtsKkA1GwiHvJ1AKyFd+u6ErmyN53WhQi5dptySrRPzjCZPWrx g3XRzJysU7hPZkbD4dlMC50W6AVL9LE5S0uJk+Hw2AVyx948+NSr2S+yJaLDAEhtKo/S KTu89EZoks/CYC0oOPK51fLpIWjKYQSOw8mmXAmSSlKX+5vI8rRCz/IcZoMLn0QO5mOs h75g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=s98cEbqjck5ZS5q001Lr4VnobCe12eb1wWoPFiXxR1A=; b=RdFXIX3lnsMy3HAqL/0WoJkjQF4Kwn3XQRgMr7AkrgTldYe6i87MoVLwPhjvGnrSqZ YUtjw9/+IJbCo55GLlvDSp076YfHaR6XlLFp29MYHKT/o6I0MsCbZHQiErk8q8rnbafQ lRDl70E+weUbL+eoGhg5YHqmoQCEQ365CwBGFgVoXi+1NJVotMupKii7sIk8XnCKcpje IyhPZ8VG53Kc+2EO+Ix48MJA6eQPIjD2nBWim5hn80Mwa9NCrnHs2VEuNZTddct7gUa7 iGD4m9L8SPjAQD9G04tkTeUDPw/8jpbFn+8WOXk3cHHs5VAAiJUhsJ4sIxWVOrmacAEo atrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vNJzEmHt; 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 n64-v6si11001239pgn.247.2018.07.30.03.26.37; Mon, 30 Jul 2018 03:26:51 -0700 (PDT) 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=vNJzEmHt; 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 S1727463AbeG3MAF (ORCPT + 99 others); Mon, 30 Jul 2018 08:00:05 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:37609 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726667AbeG3MAD (ORCPT ); Mon, 30 Jul 2018 08:00:03 -0400 Received: by mail-it0-f67.google.com with SMTP id h20-v6so16082896itf.2 for ; Mon, 30 Jul 2018 03:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s98cEbqjck5ZS5q001Lr4VnobCe12eb1wWoPFiXxR1A=; b=vNJzEmHteDbo257iV4fH769nCcciAr96oxT7a/FmQAp/YqhUOxvqDSorNRvBhoaXk7 d1xFMeJjb5ImX18SZt0LqLhkDs7/C2JzUzZSKYQDBUts1/YJzJTXIjnDXcv2eHDhCjHO bfxxZanCYaY1RLmV6NxWphMlpLs33hhpcj8I6GYLqorz9n39kIhtns9S2RjyhG3AW0fQ sk1TnVh3OePNJCAFSvKBA6E7bWry9uZBCcnrVfK+POBLKZ6HuSDwycxfhO/W64tA1A/4 gLtXgJLdtFeM/CP3Wc0lDqrA+Vf4hkfAYqYjbuX+OJrkzztJSNtSi6DNtvjKv0XdeMTp RT0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s98cEbqjck5ZS5q001Lr4VnobCe12eb1wWoPFiXxR1A=; b=Q8ZYvk+47xn0LHDdjXqkbACac9ksmkZlaoj0RMw+Yt3dQF4UA3Ww7p+ApkAoMtwYj5 +c5VRYTQijK72VpSdezjwf/Kyy8M0O50MSbAp7QLiifOYt/9nW77R4wYCiJOGhDOVWsW JuaEg65way0ZGOjD648n2J/RHuQ8gI4mHg7wey9QtipRBluQ/G6lgOVEDK2ZyHC3Unhr RW11eHFOa2XdpG4Pjsks0cbsRZdu52TfFKYywlRnQukka52nGcEx0W52xTyoHEeDXgRN /VphpMp4INeOWQw8Ome2sktM3xUOB5LeiyaF/oAHc/WUN24gbNqO0gPiMYU16QfN537n dUtw== X-Gm-Message-State: AOUpUlEchx2THqcO7rgm9GOYwB0ij4tfEM1IpTP7APJzKvvzcQDTNTfD wcmvzXT7V9IMx2n2AUHd2zEo7hIpsu3doKcGBkBj+g== X-Received: by 2002:a02:6c45:: with SMTP id w66-v6mr15900521jab.87.1532946343914; Mon, 30 Jul 2018 03:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:ba01:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 03:25:43 -0700 (PDT) In-Reply-To: References: <20180729205835.34850-1-dancol@google.com> From: Daniel Colascione Date: Mon, 30 Jul 2018 03:25:43 -0700 Message-ID: Subject: Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command To: Daniel Borkmann Cc: Joel Fernandes , linux-kernel , Tim Murray , netdev , Alexei Starovoitov , Lorenzo Colitti , Chenbo Feng , Mathieu Desnoyers , Alexei Starovoitov 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 On Mon, Jul 30, 2018 at 3:04 AM, Daniel Borkmann wrote: > Hmm, I don't think such UAPI as above is future-proof. In case we would want > a similar mechanism in future for other maps, we would need a whole new bpf > command or reuse BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES as a workaround though > the underlying map may not even be a map-to-map. Additionally, we don't have > any map object at hand in the above, so we couldn't make any finer grained > decisions either. Something like below would be more suitable and leaves room > for extending this further in future. YAGNI. Your proposed mechanism doesn't add anything under the current implementation. It's also not clear how a map-specific synchronization command is supposed to work in cases where we swap multiple map references. Do we synchronize_rcu multiple times? Why would we impose that inefficiency just for the sake of some non-specific future extensibility? Add some kind of batching layer? The current approach works for the anticipated use cases. While my preference is not to talk about map-to-maps at all in the user API and instead spec the thing as talking about map references in general, I'd rather have something that talks about references-to-maps-acquired-from-maps than this interface.