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

Alexei Starovoitov <alexei.starovoitov@gmail.com> Fri, 28 July 2023 01:06 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 F1351C151990 for <bpf@ietfa.amsl.com>; Thu, 27 Jul 2023 18:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 TqPXIkTU0PdP for <bpf@ietfa.amsl.com>; Thu, 27 Jul 2023 18:06:43 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 40B08C151982 for <bpf@ietf.org>; Thu, 27 Jul 2023 18:05:58 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2b93fba1f62so24503421fa.1 for <bpf@ietf.org>; Thu, 27 Jul 2023 18:05:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690506356; x=1691111156; 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=uRvF7S6BCKQOHpa/hnG8yDSBjnyYzzktXP0BSYr1PV4=; b=eCnXOAzpwp4vq7NmQJ5aKaCKwOGzi6EApZnV9f7A86ZKFNq40vhQgT/66eiKnFv22+ HZlGeUvJ6/Mw1vTJUqsUlBkLjKorQRdWWFmzkmopxFxQice31QEvq+QaBJX48PRzG6PG Zb7m9KgvWP/g+TaS78Conpa9t0BHj+H9/EdR4LKxpQoAxHn/2q8XWwiZItD6m/TegOwe gJvie7dbISxrnniLEXMAMN2t8fEbeHjRbbdKniiHTdLipPyTS3r8uawkg19h+8drz/cJ KPzcJLlGMNf2yO42CV28ZvassA6jtDc2Ct68wuW7KRwbF2bBcVMJGi4DbV5v/1glzu3N dJiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690506356; x=1691111156; 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=uRvF7S6BCKQOHpa/hnG8yDSBjnyYzzktXP0BSYr1PV4=; b=LDXAmf1N3Ej4JZ6MlfpAWrJdPCLS63I6qLd/a4D/NGWpT1o0I4dtV8/1hxwm5BDWSh LRSpOCgrgCTuQ6xxqzpL+MSyTGsZ7mnREQ6sxBTXdCFd1NNzlOlkzehYFU3PtYwfzjMb rTTnG4LAar4TBAsc9Li8L7hP43f1Yief9tmNf7AMkIk6ehgnwHwNVo3kW3OziDrLQPdZ b6IqyvLHF7Wct/VSaMtGjgmB+sa0gwxlTtXoRyLhlVph+pa18Kmk3k0p1fnXc78yltSl n3ogTAqPvxdzikGwpJFv7JGujh/aBsFU+saXl6uvxgZB/FCT5BwsBNM/Rrx0GqpF3Gf+ JG3g==
X-Gm-Message-State: ABy/qLZPQ479fEFTEBppAxl0bM0fCoEKvfA8KI1HhF/yTSQU7T7KNONK 8GNHhuBhNd9wNgJmuRyb+V4K5j1ZF5ydq57PA+Y=
X-Google-Smtp-Source: APBJJlFpsa9S+MbwDuUpA001xWkpqg8vP9isN2mtCBJKVJix7GUmVZtCItBEoyaul1kXK9WPf7t8cs95jF+g0y69LkE=
X-Received: by 2002:a2e:9b8b:0:b0:2b7:117:e54 with SMTP id z11-20020a2e9b8b000000b002b701170e54mr579538lji.4.1690506355615; Thu, 27 Jul 2023 18:05:55 -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> <CADx9qWi+VQ=do+_Bsd8W4Yc-S1LekVq7Hp4bfD3nz0YP47Sqgg@mail.gmail.com>
In-Reply-To: <CADx9qWi+VQ=do+_Bsd8W4Yc-S1LekVq7Hp4bfD3nz0YP47Sqgg@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Thu, 27 Jul 2023 18:05:44 -0700
Message-ID: <CAADnVQ+5d8ztfFLraWnZKszAX23Z-12=pHjJfufNbd3qzWVNsQ@mail.gmail.com>
To: Will Hawkins <hawkinsw@obs.cr>
Cc: Watson Ladd <watsonbladd@gmail.com>, 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/dDzJ-CYLMDxdi2hQamYDfPWJt0g>
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 01:06:48 -0000

On Wed, Jul 26, 2023 at 12:16 PM Will Hawkins <hawkinsw@obs.cr> wrote:
>
> On Tue, Jul 25, 2023 at 2:37 PM 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.
>
> Hello! Based on Watson's post, I have done some research and would
> potentially like to offer a path forward. There are several different
> ways that ISAs specify the semantics of their operations:
>
> 1. Intel has a section in their manual that describes the pseudocode
> they use to specify their ISA: Section 3.1.1.9 of The Intel® 64 and
> IA-32 Architectures Software Developer’s Manual at
> https://cdrdv2.intel.com/v1/dl/getContent/671199
> 2. ARM has an equivalent for their variety of pseudocode: Chapter J1
> of Arm Architecture Reference Manual for A-profile architecture at
> https://developer.arm.com/documentation/ddi0487/latest/
> 3. Sail "is a language for describing the instruction-set architecture
> (ISA) semantics of processors."
> (https://www.cl.cam.ac.uk/~pes20/sail/)
>
> Given the commercial nature of (1) and (2), perhaps Sail is a way to
> proceed. If people are interested, I would be happy to lead an effort
> to encode the eBPF ISA semantics in Sail (or find someone who already
> has) and incorporate them in the draft.

imo Sail is too researchy to have practical use.
Looking at arm64 or x86 Sail description I really don't see how
it would map to an IETF standard.
It's done in a "sail" language that people need to learn first to be
able to read it.
Say we had bpf.sail somewhere on github. What value does it bring to
BPF ISA standard? I don't see an immediate benefit to standardization.
There could be other use cases, no doubt, but standardization is our goal.

As far as 1 and 2. Intel and Arm use their own pseudocode, so they had
to add a paragraph to describe it. We are using C to describe BPF ISA
semantics. I don't think we need to explain C in the BPF ISA doc.
The only exception is "s>=", but it is explained in the doc already.