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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCBBFC636D4 for ; Tue, 31 Jan 2023 21:11:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232097AbjAaVLF (ORCPT ); Tue, 31 Jan 2023 16:11:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231731AbjAaVLE (ORCPT ); Tue, 31 Jan 2023 16:11:04 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12A9C53E70; Tue, 31 Jan 2023 13:11:03 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id gr7so20907064ejb.5; Tue, 31 Jan 2023 13:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mZ+EfdGoneEgPdpzwa991bp+XLQi7R5BmAQzM+ojBhM=; b=b3T4Qclicuupe7pt2buXAQXzJQiuekMXFfFlKeaWTj6LqlDBWF0oqshDFKAYCKnoSf J90hg4LIaqs5uPiG9qnHxTOGLXaOpNvzjLRvXcKWrCq3XzKNic5cnR+g31clFP/90ktt emyPXZfO/bu0cmaBk/AxxsOxlwO630Fx+s3NH3+rPuTSnO9zyfvo3P4oKUJMFZXwhfYb E9HhMIog6Gi1nKBgHsLqKoiMjJSLW26BMtr3nsXOsIc2XlIHObbDL/CN0WfIpmMACqJQ b8iMGM3EK3WAX7J7pbn9ybLBtM+2Qu42qiHE3e7RVJsM2Flj4b0QDlaYGVEIGbZ4O/LI yJTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mZ+EfdGoneEgPdpzwa991bp+XLQi7R5BmAQzM+ojBhM=; b=xIEKNQpLC9JG6ksNLJ2nHt5inBeYe6U65SYRXSt9MloMwmjXVPns0BGYKcjJe/zdEX WZgGJh9xL9dGqNWrzCy/UPnWxaFNFbkOz3YnD0YATHu+mX3ENAF5aAt4WmbJcbjtGYWV HJifNKsmMGGUCBkCOgdDSgbaOjg0SHz9XIrjfGcZyTM5mB6Hur4w2UaJqjKafWhp/lSQ pJZ+AIipxs9IunWL4Q7FC4BRuilM/T+2W7V9MO2ipNcZr/fuJ6OkSA0bmJppyxPF9xie Z0PHl8JXZN7rYdZ/PjfdRwRAV7IAFoUgsle/3wq9CXvWVxjK2PEe3mpMOuszkL6tzKjD dIeQ== X-Gm-Message-State: AFqh2krrnzKReJW6NXZmRDwKg4gGZh516TIFoB+43VPjWABMsHeCPTrd uuHHF9wMh58IeuBAHdADHSnlZEGReT2+ztIq4lLOEUH9 X-Google-Smtp-Source: AMrXdXtIiK2uDbrQWfFeTSFwHnPvVhv1FJ3p78bPbh6GTN5FGoPjS+ke7sjaQoZyStRGBGdcUQwyykSvMPGS+cKyTtI= X-Received: by 2002:a17:906:7ac2:b0:86e:429b:6a20 with SMTP id k2-20020a1709067ac200b0086e429b6a20mr9169550ejo.247.1675199461331; Tue, 31 Jan 2023 13:11:01 -0800 (PST) MIME-Version: 1.0 References: <20230127191703.3864860-1-joannelkoong@gmail.com> <20230127191703.3864860-4-joannelkoong@gmail.com> <5715ea83-c4aa-c884-ab95-3d5e630cad05@linux.dev> <20230130223141.r24nlg2jp5byvuph@macbook-pro-6.dhcp.thefacebook.com> In-Reply-To: From: Alexei Starovoitov Date: Tue, 31 Jan 2023 13:10:49 -0800 Message-ID: Subject: Re: [PATCH v9 bpf-next 3/5] bpf: Add skb dynptrs To: Joanne Koong Cc: Andrii Nakryiko , Martin KaFai Lau , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Alexei Starovoitov , Network Development , Kumar Kartikeya Dwivedi , Kernel Team , bpf Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jan 31, 2023 at 12:48 PM Joanne Koong wrote: > > > > > > > > p = bpf_dynptr_slice(dp, off, 16, buf); > > > > if (p == NULL) { > > > > /* out of range */ > > > > } else { > > > > /* work with p directly */ > > > > } > > > > > > > > /* if we wrote something to p and it was copied to buffer, write it back */ > > > > if (p == buf) { > > > > bpf_dynptr_write(dp, buf, 16); > > > > } > > > > > > > > > > > > We'll just need to teach verifier to make sure that buf is at least 16 > > > > byte long. > > > > > > I'm confused what the benefit of passing in the buffer is. If it's to > > > avoid the uncloning, this will still need to happen if the user writes > > > back the data to the skb (which will be the majority of cases). If > > > it's to avoid uncloning if the user only reads the data of a writable > > > prog, then we could add logic in the verifier so that we don't pull > > > the data in this case; the uncloning might still happen regardless if > > > another part of the program does a direct write. If the benefit is to > > > avoid needing to pull the data, then can't the user just use > > > bpf_dynptr_read, which takes in a buffer? > > > > There is no unclone and there is no pull in xdp. > > The main idea of this semantics of bpf_dynptr_slice is to make it > > work the same way on skb and xdp for _read_ case. > > Writes are going to be different between skb and xdp anyway. > > In some rare cases the writes can be the same for skb and xdp > > with this bpf_dynptr_slice + bpf_dynptr_write logic, > > but that's a minor feature addition of the api. > > bpf_dynptr_read works the same way on skb and xdp. bpf_dynptr_read > takes in a buffer as well, so what is the added benefit of > bpf_dynptr_slice? That it doesn't copy most of the time.