Re: [Bpf] Review of draft-thaler-bpf-isa-01

Alexei Starovoitov <alexei.starovoitov@gmail.com> Fri, 28 July 2023 00:56 UTC

Return-Path: <alexei.starovoitov@gmail.com>
X-Original-To: bpf@ietfa.amsl.com
Delivered-To: bpf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0AEC151709 for <bpf@ietfa.amsl.com>; Thu, 27 Jul 2023 17:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdfc6KT27ABO for <bpf@ietfa.amsl.com>; Thu, 27 Jul 2023 17:56:07 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2D6C151066 for <bpf@ietf.org>; Thu, 27 Jul 2023 17:56:07 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2b9cdbf682eso4866851fa.2 for <bpf@ietf.org>; Thu, 27 Jul 2023 17:56:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690505765; x=1691110565; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tVVw9V6+eXMOzrYrZNj/SaWARDVdKVJviBLcx53P3ZQ=; b=dMNXoWyVBnPDl67ZivzX2VxwxYcYXIq9KlAxmVZA80nQm4okJonRgaMrA8V/2NBPzk mHCpq5fkQDfIqcI3Cq697fRDSSB5NIvvB/5/dSV3tjKjqTvLCAXUUx8bXoFyal9mkpB6 //oCKHZkHc5sIWxp5nVOL3BoY9kxmUDLcZd4jeNJ/sm8WPri9gBLeoe4BpB5OKmdyrja VehpGJvV8oZcR6VrZz4oZak5aawtdnM1/rbcTdzHUikzvqzWphpsFMHfDV431k24iOgy T9cScWlpCyes8nvMd+d+3Wd9TXltyxpMhzOIzDtm2jhYGtBP0BO+EUfNr/VkTw50FGgQ gT1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690505765; x=1691110565; h=content-transfer-encoding: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=tVVw9V6+eXMOzrYrZNj/SaWARDVdKVJviBLcx53P3ZQ=; b=jmfabwc/nxVPqN0fwJAbyEX5ty4DQi3FP9b32Wqwu6o3Co86ybiT3V3uYNVKUoE+Hd qwzD+JkPWmX/rAQtWbWyHyf9YKwe2nEpIRCB/mHvz/HEzkSeHlogaW4hg8bic1Qovkuz ODT/iGBMu4x5HMRLUlI4oUef6B79tHgQWmJ9UbGfNrgnA6KJ0Y+57Top6wWpFaE2ye2h lte3zGEMBg91WBIg3KuH/B4esp4Y+0gr3spNIs+wG3n3a4cLr1GOO9ym0AKWyKMT+d+P 3T4zh71ljjmscHay14A8TBxHzFYanQtUY7xjgup92cvYL1F7ztsWXkhQBwsPuyt20mN4 X5zQ==
X-Gm-Message-State: ABy/qLYibBRNacUFQ758wUM/KlZygWoSPQaFbK1brwtEpw7tspBtTuNu UlDfxFLrtaCqT89yPcNbuVe5QFwPguEmYMAgtSI=
X-Google-Smtp-Source: APBJJlEXq2/6tNRsFubcck+VptVVbUngHYk+ZDxKWI6bIwM9a1UKEQdvvWeQh1G1/6r+nfRBZ9gMu6l5DMGhOpJ8oK8=
X-Received: by 2002:a2e:8e93:0:b0:2b5:7a87:a85a with SMTP id z19-20020a2e8e93000000b002b57a87a85amr519609ljk.13.1690505764821; Thu, 27 Jul 2023 17:56:04 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0ckZO+b5bRgMZhOvx+Jn-sa0g8cBD+ug1CJEdtYxSm_hgA@mail.gmail.com> <PH7PR21MB3878D8DCEF24A5F8E52BA59DA303A@PH7PR21MB3878.namprd21.prod.outlook.com> <CAADnVQJ1fKXcsTXdCijwQzf0OVF0md-ATN5RbB3g10geyofNzA@mail.gmail.com> <CACsn0cmf22zEN9AduiRiFnQ7XhY1ABRL=SwAwmmFgxJvVZAOsg@mail.gmail.com>
In-Reply-To: <CACsn0cmf22zEN9AduiRiFnQ7XhY1ABRL=SwAwmmFgxJvVZAOsg@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Thu, 27 Jul 2023 17:55:53 -0700
Message-ID: <CAADnVQ+O0CZQ1-5+dBiPWgZig3MVRX92PWPwNCrL7rG+4Xrbag@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Dave Thaler <dthaler@microsoft.com>, "bpf@ietf.org" <bpf@ietf.org>, bpf <bpf@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/bpf/JuA030SmDR_XAEr0vw7M8vK76A0>
Subject: Re: [Bpf] Review of draft-thaler-bpf-isa-01
X-BeenThere: bpf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion of BPF/eBPF standardization efforts within the IETF <bpf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bpf>, <mailto:bpf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bpf/>
List-Post: <mailto:bpf@ietf.org>
List-Help: <mailto:bpf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bpf>, <mailto:bpf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jul 2023 00:56:11 -0000

On Tue, Jul 25, 2023 at 11:37 AM Watson Ladd <watsonbladd@gmail.com> wrote:
>
> On Tue, Jul 25, 2023 at 9:15 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Jul 25, 2023 at 7:03 AM Dave Thaler <dthaler@microsoft.com> wrote:
> > >
> > > I am forwarding the email below (after converting HTML to plain text)
> > > to the mailto:bpf@vger.kernel.org list so replies can go to both lists.
> > >
> > > Please use this one for any replies.
> > >
> > > Thanks,
> > > Dave
> > >
> > > > From: Bpf <bpf-bounces@ietf.org> On Behalf Of Watson Ladd
> > > > Sent: Monday, July 24, 2023 10:05 PM
> > > > To: bpf@ietf.org
> > > > Subject: [Bpf] Review of draft-thaler-bpf-isa-01
> > > >
> > > > Dear BPF wg,
> > > >
> > > > I took a look at the draft and think it has some issues, unsurprisingly at this stage. One is
> > > > the specification seems to use an underspecified C pseudo code for operations vs
> > > > defining them mathematically.
> >
> > Hi Watson,
> >
> > This is not "underspecified C" pseudo code.
> > This is assembly syntax parsed and emitted by GCC, LLVM, gas, Linux Kernel, etc.
>
> I don't see a reference to any description of that in section 4.1.
> It's possible I've overlooked this, and if people think this style of
> definition is good enough that works for me. But I found table 4
> pretty scanty on what exactly happens.

Could you please be specific which instruction in table 4 is not obvious?

> >
> > > > The good news is I think this is very fixable although tedious.
> > > >
> > > > The other thornier issues are memory model etc. But the overall structure seems good
> > > > and the document overall makes sense.
> >
> > What do you mean by "memory model" ?
> > Do you see a reference to it ? Please be specific.
>
> No, and that's the problem. Section 5.2 talks about atomic operations.
> I'd expect that to be paired with a description of barriers so that
> these work, or a big warning about when you need to use them.

That's a good suggestion.
A warning paragraph that BPF ISA does not have barrier instructions
is necessary.

> For
> clarity I'm pretty unfamiliar with bpf as a technology, and it's
> possible that with more knowledge this would make sense. On looking
> back on that I don't even know if the memory space is flat, or
> segmented: can I access maps through a value set to dst+offset, or
> must I always used index? I'm just very confused.

flat vs segmented is an orthogonal topic.
We definitely need to cover it in the architecture doc.
BPF WG charter requires us to produce it as Informational doc eventually.

As far as memory model BPF adopts LKMM (Linux Kernel Memory Model).
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0124r7.html

We can add a reference to it from BPF ISA doc, but since
there are no barrier instructions at the moment the memory model
statement would be premature.
The work on "BPF Memory Model" have been ongoing for quite some time.
For example see:
https://lpc.events/event/11/contributions/941/attachments/859/1667/bpf-memory-model.2020.09.22a.pdf

BPF Memory Model is certainly an important topic, but out of scope for ISA.