From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 153AEC28CC5 for ; Wed, 5 Jun 2019 15:42:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DC72A2075B for ; Wed, 5 Jun 2019 15:42:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="P0Kv1alh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728436AbfFEPmv (ORCPT ); Wed, 5 Jun 2019 11:42:51 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:41776 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728228AbfFEPmu (ORCPT ); Wed, 5 Jun 2019 11:42:50 -0400 Received: by mail-pf1-f194.google.com with SMTP id q17so15063323pfq.8 for ; Wed, 05 Jun 2019 08:42:50 -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:in-reply-to:references :mime-version:content-transfer-encoding; bh=rjlv+ApWLX3HTsuf1Vi48F2A2yBt/brxhNfn4nOtyNs=; b=P0Kv1alhEKK5pUGiSSWhrYnZOyP8CZpF1MrHuS38MumUOEfwxizgmblN1WWbtF+RDM MFER8JTpetmZTQNlN2uWWrDMv1sYafcpIuoZnEJ8YTDdI7CnE8wn4fOul4+klLnB01AP RaptjBunVnkad3N77o2KsdgT7duzrZK6+CU4bfBv7SPkG61tmq7I7NGEzLxqHeyCE7VY s6rf2ygG7THD5okIk+JMlv2F79LWr1mzojeuhXsyuS/qfvhcsAPNh2q8hLv39y4plzPQ tckUWGmCF5Miopov3AWK0mQzi6JEL1Uwh7BaH8lRBFL3VHufQCQ2zxapCZXEGHBP3exf etfg== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=rjlv+ApWLX3HTsuf1Vi48F2A2yBt/brxhNfn4nOtyNs=; b=R8YE8EzEVR1/HGKr+RnPQm7uemHKFkQFDCM0TvmbRbFc4pwslB8M0n/Dcj9fsBHxb9 Efh8rpMj+FG3XlK8KAMwbq7t3/yYw8LTffNBQvyjjY8u/+RWTa9KSln3KpKf4Li9iNpQ aFj2dyhu9tRuj8qZ/o748bztHI3+vhiFveT4FBuEgafUPNhmYra8sYzUhpjGq49cauax dAsjKZpQafckWKAf1i6l3uA5DSippMM3QiIbX0/fwaOZ/zSi480ixZExV1tIhaSn14Qx 0Og/F/Q+pnp36nu0hShNgx+Kmo07VoZop/O9kRJNJBaLnHnQcdFJ4dpX2EqtxEBw0rRT ctqA== X-Gm-Message-State: APjAAAVNGj8ZQwSA6Rsj47REjExfOZoDi4g1q7+2gQgV3g803j7zBKWE iMVDFI+brGyvLt9FvtCxzMw= X-Google-Smtp-Source: APXvYqw7i+u7ZpF+0NY6r/2rqh6IrZu9/6YzdPDia7Me7D75SWI0p/7ubTffE3OUSX09pdYxz8ke0w== X-Received: by 2002:a17:90a:d151:: with SMTP id t17mr31703159pjw.60.1559749370111; Wed, 05 Jun 2019 08:42:50 -0700 (PDT) Received: from [172.20.85.241] ([2620:10d:c090:180::1:bf6]) by smtp.gmail.com with ESMTPSA id i22sm21047495pfa.127.2019.06.05.08.42.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2019 08:42:49 -0700 (PDT) From: "Jonathan Lemon" To: "=?utf-8?b?QmrDtnJuIFTDtnBlbA==?=" Cc: "Martin Lau" , "Jesper Dangaard Brouer" , netdev@vger.kernel.org, "Kernel Team" , bjorn.topel@intel.com, magnus.karlsson@intel.com, ast@kernel.org, daniel@iogearbox.net Subject: Re: [PATCH v4 bpf-next 1/2] bpf: Allow bpf_map_lookup_elem() on an xskmap Date: Wed, 05 Jun 2019 08:42:48 -0700 X-Mailer: MailMate (1.12.5r5635) Message-ID: <1E4A2FA7-E759-450A-8979-F7CCD7F653C4@gmail.com> In-Reply-To: References: <20190603163852.2535150-1-jonathan.lemon@gmail.com> <20190603163852.2535150-2-jonathan.lemon@gmail.com> <20190604184306.362d9d8e@carbon> <87399C88-4388-4857-AD77-E98527DEFDA4@gmail.com> <20190604181202.bose7inhbhfgb2rc@kafai-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 5 Jun 2019, at 1:45, Björn Töpel wrote: > On Tue, 4 Jun 2019 at 20:13, Martin Lau wrote: >> >> On Tue, Jun 04, 2019 at 10:25:23AM -0700, Jonathan Lemon wrote: >>> On 4 Jun 2019, at 9:43, Jesper Dangaard Brouer wrote: >>> >>>> On Mon, 3 Jun 2019 09:38:51 -0700 >>>> Jonathan Lemon wrote: >>>> >>>>> Currently, the AF_XDP code uses a separate map in order to >>>>> determine if an xsk is bound to a queue. Instead of doing this, >>>>> have bpf_map_lookup_elem() return the queue_id, as a way of >>>>> indicating that there is a valid entry at the map index. >>>> >>>> Just a reminder, that once we choose a return value, there the >>>> queue_id, then it basically becomes UAPI, and we cannot change it. >>> >>> Yes - Alexei initially wanted to return the sk_cookie instead, but >>> that's 64 bits and opens up a whole other can of worms. >>> >>> >>>> Can we somehow use BTF to allow us to extend this later? >>>> >>>> I was also going to point out that, you cannot return a direct pointer >>>> to queue_id, as BPF-prog side can modify this... but Daniel already >>>> pointed this out. >>> >>> So, I see three solutions here (for this and Toke's patchset also, >>> which is encountering the same problem). >>> >>> 1) add a scratch register (Toke's approach) >>> 2) add a PTR_TO_, which has the access checked. This is the most >>> flexible approach, but does seem a bit overkill at the moment. >> I think it would be nice and more extensible to have PTR_TO_xxx. >> It could start with the existing PTR_TO_SOCKET >> >> or starting with a new PTR_TO_XDP_SOCK from the beginning is also fine. >> > > Doesn't the PTR_TO_SOCKET path involve taking a ref and mandating > sk_release() from the fast path? :-( AF_XDP sockets are created with SOCK_RCU_FREE, and used under rcu, so I don't think that they need to be refcounted. bpf_sk_release is a NOP in the RCU_FREE case. -- Jonathan