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

[Dave Thaler <[e-mail]>]

Alexei Starovoitov <[e-mail]> wrote: 
> On Tue, Aug 1, 2023 at 6:55 PM Dave Thaler <[e-mail]>
> wrote:
[...]
>  I interpreted this as saying no one cared about having the IANA
> considerations section in a separate file there.  But we confirm consensus on
> the list, so it's fine to revisit now if there are good reasons to do so.
> 
> I think IANA consideration section is orthogonal to giant opcode table.

It's not orthogonal, such a table is a required part of the IANA Considerations
section.  See https://www.rfc-editor.org/rfc/rfc8126#section-2.2
(specifically the "Initial assignments and reservations").

> They're related, but don't have to be together in one .rst file.

True.

> I think it's cleaner to have separate instruction-set-opcode.rst

Sure.

> We also went back and forth during the meeting whether hierarchy of tables
> is prefered or one table.

During the meeting, no one argued for one table (other than me saying 
if no one has a preference, I'll leave it the way it is), and several people
argued for multiple tables so I took that as potential consensus for multiple
tables.  But again, we confirm consensus on the list so if anyone here has a
reason why one table or multiple tables are technically better, please speak up.

> Currently you have one table and it actually looks
> very readable. My preference would be to keep it this way and carry over to
> IANA eventually as one table.

Personally, I agree that I find one table more readable.  But it sounded like
others in the meeting found multiple tables more readable.

Comparing slides 8 and 9 from the meeting, at https://datatracker.ietf.org/meeting/117/materials/slides-117-bpf-isa-extension-policy-03
folks will notice that on slide 9 in the multiple tables example, I omitted columns from the opcode table other than the single key field (opcode, src, or whatever depending on the
table) and the description.  Thus for say opcode 0x17 (dst -= imm) the one table
version shows src 0x0 and imm any, whereas the multiple tables one doesn't.
Perhaps it could, but one thing I like about the single table version is that as currently
depicted, opcode 0x17 with src != 0x0 is currently undefined (i.e., available for later use),
whereas the multiple table version with a single key field depicts it as defined as "dst -= imm" with English text in the body of the doc that says src must be zero.

Thus the single table version that presents src as a key field unless it contains "any"
means there's plenty of instruction space left unallocated.  Anyone who actually wants
to disallow any future instructions from ever using opcode 0x17 with src != 0x0 might
prefer the multiple tables (i.e., without src as a key field).  But to me, this could
potentially be a technical argument for keeping one table.

Dave