Re: [Bpf] BPF ISA conformance groups

dthaler1968@googlemail.com Tue, 23 January 2024 23:29 UTC

Return-Path: <dthaler1968@googlemail.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 A425DC14CF09 for <bpf@ietfa.amsl.com>; Tue, 23 Jan 2024 15:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.855
X-Spam-Level:
X-Spam-Status: No, score=-6.855 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_ENVFROM_END_DIGIT=0.25, 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=googlemail.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 dh7Sa7I8y6kn for <bpf@ietfa.amsl.com>; Tue, 23 Jan 2024 15:29:46 -0800 (PST)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 27FE5C14F6E9 for <bpf@ietf.org>; Tue, 23 Jan 2024 15:29:46 -0800 (PST)
Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-290483f8c7bso3679273a91.3 for <bpf@ietf.org>; Tue, 23 Jan 2024 15:29:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1706052585; x=1706657385; darn=ietf.org; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=Uxp7csI7GVkKVo3iyFT9bVz+XlkrKNjW2GUNPvl/QNw=; b=BR2BFK5s+p9KLJkifNIbOTTLzKpvB/wux5/EgCr23ppfqokdl9mFEiT/t3s8BhFMxo thC53sLVJAe7FcIMrxOd609a8G97dzitP/A34u9fmBWVh5TNrV30trS5YthgOkF/aTfC uGoR/93NTOAV/JVWP3nTPjfYLyJlYEpYbpJFhBknBSMsd630/q4W9ncmtuyUaAz0nJEH MtxMLergayshR4ecb+JSoAXiZEeOx6NgZvqiOjnKrubRZ94gxM8CJT/YGuuk3GrqVqgW 5cHfuog3vlJS1U9pp5MUEKTZP9BHBJT9RFDs6yk+wq4OBeGrBIe/nACwzWC0uio+MWFg drJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706052585; x=1706657385; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Uxp7csI7GVkKVo3iyFT9bVz+XlkrKNjW2GUNPvl/QNw=; b=STBTDcrVM22ocGI8rz1oLFXDbbO4rxnv5qdObtg6sh4SLeai/o6MYLRBGdeNFjbUyJ PX83Eq8BQNulIpTedpeiGDouQiMoLr6xPPTd51g0yctGctF/WWXntvbMKQpZ4gYYOlUd j0ttX3R4oN+BOG8a4y66fyauHd/IaiH1TrCzajZfxf5OBC5l1BIcYf6+zB32P6FmInP6 r4UKJzaEI6dNo5O9zFQDcNWzkhgrvKdeFFlgECZRDgEO8gKf7KjOUwus0skVr+p/2E+5 dyKRZXba21i9Wizp10E0Pysa5AkmrUIvE5XgKIyrL2U8pAFU9VaBe+j7gEGiBXsJPJG/ g6aQ==
X-Gm-Message-State: AOJu0YyGtfL1Iaj8ihbbKQyyTnwoyzUw9f02B1qB/h0dT1pd3IesrU71 9Mmxv0AHeTqK91qZigLbXjn+EGII7YOIHnL4fY+jljLqP9v41kay
X-Google-Smtp-Source: AGHT+IEGvt/yImDo8Ob1k0Z4lY994xLw3f+pk6Sv7zqAkcyFvFUUx3Hd7wrrrOUxBx08cxEdejrjvQ==
X-Received: by 2002:a17:90a:f614:b0:290:6c4:ad45 with SMTP id bw20-20020a17090af61400b0029006c4ad45mr3688918pjb.39.1706052584666; Tue, 23 Jan 2024 15:29:44 -0800 (PST)
Received: from ArmidaleLaptop (c-67-170-74-237.hsd1.wa.comcast.net. [67.170.74.237]) by smtp.gmail.com with ESMTPSA id nc15-20020a17090b37cf00b0028feef1f7adsm12227727pjb.50.2024.01.23.15.29.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2024 15:29:44 -0800 (PST)
From: dthaler1968@googlemail.com
X-Google-Original-From: <dthaler1968@gmail.com>
To: 'David Vernet' <void@manifault.com>, "'Jose E. Marchesi'" <jose.marchesi@oracle.com>
Cc: 'Alexei Starovoitov' <alexei.starovoitov@gmail.com>, 'Christoph Hellwig' <hch@infradead.org>, bpf@ietf.org, 'bpf' <bpf@vger.kernel.org>, 'Jakub Kicinski' <kuba@kernel.org>, david.faust@oracle.com
References: <20231214174437.GA2853@maniforge> <ZXvkS4qmRMZqlWhA@infradead.org> <CAADnVQ+ExRC_RavN_sbuOmuwyP6+HKnV9bFjJOseORBaVw0Jcg@mail.gmail.com> <09dc01da32a6$99c97e50$cd5c7af0$@gmail.com> <CAADnVQ+Kb20aUZdcqSh5eF-_dzpHWcpjAtYpLgg5Fqog=g7hpA@mail.gmail.com> <ZYPiq6ijLaMl/QD8@infradead.org> <20240105220711.GA1001999@maniforge> <ZZwcC7nZiZ+OV1ST@infradead.org> <CAADnVQLMo0M675T89gu9v_wSR+GbQmu4ajWjwgWK9aCNkJPsaQ@mail.gmail.com> <874jfm68ok.fsf@oracle.com> <20240123213948.GA221862@maniforge>
In-Reply-To: <20240123213948.GA221862@maniforge>
Date: Tue, 23 Jan 2024 15:29:41 -0800
Message-ID: <1f8301da4e54$0b0ad690$212083b0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQClir6lI1sScEFfIiSZU+wYPRcfRwJboihlAe8iqfAB/zVPlgJHtDdIAuBp+8cCBQmzlAH9CezDAX+HGP0B/YYFwQJ+11wssqYPW3A=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/bpf/ako8ucDfE6AbPMkHyY8DzAMzhHI>
Subject: Re: [Bpf] BPF ISA conformance groups
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: Tue, 23 Jan 2024 23:29:50 -0000

> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Tuesday, January 23, 2024 1:40 PM
> To: Jose E. Marchesi <jose.marchesi@oracle.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>; Christoph Hellwig
> <hch@infradead.org>; Dave Thaler <dthaler1968@googlemail.com>;
> bpf@ietf.org; bpf <bpf@vger.kernel.org>; Jakub Kicinski <kuba@kernel.org>;
> david.faust@oracle.com
> Subject: Re: [Bpf] BPF ISA conformance groups
> 
> On Tue, Jan 09, 2024 at 12:35:39PM +0100, Jose E. Marchesi wrote:
> >
> > > On Mon, Jan 8, 2024 at 8:00 AM Christoph Hellwig <hch@infradead.org>
> wrote:
> > >>
> > >> On Fri, Jan 05, 2024 at 04:07:11PM -0600, David Vernet wrote:
> > >> >
> > >> > So how do we want to move forward here? It sounds like we're
> > >> > leaning toward's Alexei's proposal of having:
> > >> >
> > >> > - Base Integer Instruction Set, 32-bit
> > >> > - Base Integer Instruction Set, 64-bit
> > >> > - Integer Multiplication and Division
> > >> > - Atomic Instructions
> > >>
> > >> As in the 64-bit integer set would be an add-on to the first one
> > >> which is the core set?  In that case that's fine with me, but the
> > >> above wording is a bit suboptimal.
> > >
> > > yes.
> > > Here is how I was thinking about the grouping:
> > > 32-bit set: all 32-bit instructions those with BPF_ALU and BPF_JMP32
> > > and load/store.
> > >
> > > 64-bit set: above plus BPF_ALU64 and BPF_JMP.
> > >
> > > The idea is to allow for clean 32-bit HW offloads.
> > > We can introduce a compiler flag that will only use such
> > > instructions and will error when 64-bit math is needed.
> > > Details need to be thought through, of course.
> > > Right now I'm not sure whether we need to reduce sizeof(void*) to 4
> > > in such a case or normal 8 will still work, but from ISA perspective
> > > everything is ready. 32-bit subregisters fit well.
> > > The compiler work plus additional verifier smartness is needed, but
> > > the end result should be very nice.
> > > Offload of bpf programs into 32-bit embedded devices will be possible.
> >
> > This is very interesting.
> this is necessarily something we need to figure out now. Hopefully this is all
> stuff we can iron out once we start to really sink our teeth into the ABI doc.

"Integer Multiplication and Division" in this thread doesn't seem to separate
between 32-bit vs 64-bit.  Is the proposal that multiplication/division is ok
to require 64-bit operations?  I had expected one rationale for the 32bit
multiplication/division instructions is to accommodate 32-bit-only
implementations.   So should we have separate groups for 32-bit vs
64-bit for the multiplication/division instructions?

Similar question goes for the atomic instructions, i.e., should we
have separate conformance groups for 32-bit vs 64-bit atomics? 

Dave