BPF/eBPF non-acronym feedback from Gunter Van de Velde and Éric Vyncke

BPF/eBPF non-acronym feedback from Gunter Van de Velde and Éric Vyncke

[Dave Thaler]

Gunter Van de Velde, RTG AD, wrote:
> > 12 eBPF (which is no longer an acronym for anything), also commonly
>
> I assumed that 'e' was for 'extended' and that BPF stands for 'BSD Packet
> Filter' originally described and specified in a paper titled "The BSD
> Packet Filter: A New Architecture for User-level Packet Capture" by
> Steven McCanne and Van Jacobson, presented at the 1993 Winter
> USENIX Conference. This paper introduced the BPF architecture, which
> was designed for efficient packet filtering and capture.
>
> Hence a bit surprised why the first words of the first line in
> the first paragraph of the draft abstract suggest that its
> not an acronym?

Éric Vyncke wrote: 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bpf-isa-03: Yes
> 
> When responding, please keep the subject line intact and reply to all email addresses
> included in the To and CC lines. (Feel free to cut this introductory paragraph,
> however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bpf-isa/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Nice document, easy to read and understand and the shepherd's write-up
> companion is also clear.
> 
> Just two COMMENTs (no need to reply, but replies will be appreciated):
> 
> 1) like Gunter, having an expansion to "eBPF is related or is the successor of
> extended Berkeley Packet Filter" would comfort the readers about what they are
> reading.

The existing text is derived from what is at https://ebpf.io/what-is-ebpf/
and a much longer exposition would be more appropriate for a different document on the WG charter ("[I] an architecture and framework document").

However, https://ebpf.io/what-is-ebpf/#what-do-ebpf-and-bpf-stand-for does have the FAQ answer for "What do eBPF and BPF stand for?":

> BPF originally stood for Berkeley Packet Filter, but now that eBPF
> (extended BPF) can do so much more than packet filtering, the acronym
> no longer makes sense. eBPF is now considered a standalone term that
> doesn’t stand for anything. In the Linux source code, the term BPF
> persists, and in tooling and in documentation, the terms BPF and eBPF
> are generally used interchangeably. The original BPF is sometimes
> referred to as cBPF (classic BPF) to distinguish it from eBPF.

That paragraph, or some variation of it, would in my opinion be appropriate
in the architecture/ framework document, but do we really want it in *every*
other document from the WG?  That would seem needlessly redundant to me.

There are plenty of examples in the world of things that started as acronyms
and no longer stand for anything and so are not expanded (AT&T,
NPR, CBS, 3M, SOS, etc.)   See
http://blog.writeathome.com/index.php/2013/10/12-initials-that-stand-for-nothing/
for one of many articles with a list of such terms, but web searches will turn
up plenty of other references.

Trying to explain in every news article that uses
one of those terms what it originally stood for but doesn't any more, doesn't
seem particularly helpful to me and certainly isn't commonly done.

Dave

[Bpf] BPF/eBPF non-acronym feedback from Gunter Van de Velde and Éric Vyncke

[Dave Thaler]

Gunter Van de Velde, RTG AD, wrote:
> > 12 eBPF (which is no longer an acronym for anything), also commonly
>
> I assumed that 'e' was for 'extended' and that BPF stands for 'BSD Packet
> Filter' originally described and specified in a paper titled "The BSD
> Packet Filter: A New Architecture for User-level Packet Capture" by
> Steven McCanne and Van Jacobson, presented at the 1993 Winter
> USENIX Conference. This paper introduced the BPF architecture, which
> was designed for efficient packet filtering and capture.
>
> Hence a bit surprised why the first words of the first line in
> the first paragraph of the draft abstract suggest that its
> not an acronym?

Éric Vyncke wrote: 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bpf-isa-03: Yes
> 
> When responding, please keep the subject line intact and reply to all email addresses
> included in the To and CC lines. (Feel free to cut this introductory paragraph,
> however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bpf-isa/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Nice document, easy to read and understand and the shepherd's write-up
> companion is also clear.
> 
> Just two COMMENTs (no need to reply, but replies will be appreciated):
> 
> 1) like Gunter, having an expansion to "eBPF is related or is the successor of
> extended Berkeley Packet Filter" would comfort the readers about what they are
> reading.

The existing text is derived from what is at https://ebpf.io/what-is-ebpf/
and a much longer exposition would be more appropriate for a different document on the WG charter ("[I] an architecture and framework document").

However, https://ebpf.io/what-is-ebpf/#what-do-ebpf-and-bpf-stand-for does have the FAQ answer for "What do eBPF and BPF stand for?":

> BPF originally stood for Berkeley Packet Filter, but now that eBPF
> (extended BPF) can do so much more than packet filtering, the acronym
> no longer makes sense. eBPF is now considered a standalone term that
> doesn’t stand for anything. In the Linux source code, the term BPF
> persists, and in tooling and in documentation, the terms BPF and eBPF
> are generally used interchangeably. The original BPF is sometimes
> referred to as cBPF (classic BPF) to distinguish it from eBPF.

That paragraph, or some variation of it, would in my opinion be appropriate
in the architecture/ framework document, but do we really want it in *every*
other document from the WG?  That would seem needlessly redundant to me.

There are plenty of examples in the world of things that started as acronyms
and no longer stand for anything and so are not expanded (AT&T,
NPR, CBS, 3M, SOS, etc.)   See
http://blog.writeathome.com/index.php/2013/10/12-initials-that-stand-for-nothing/
for one of many articles with a list of such terms, but web searches will turn
up plenty of other references.

Trying to explain in every news article that uses
one of those terms what it originally stood for but doesn't any more, doesn't
seem particularly helpful to me and certainly isn't commonly done.

Dave

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

[Bpf] Re: BPF/eBPF non-acronym feedback from Gunter Van de Velde and Éric Vyncke

[Eric Vyncke (evyncke)]

[-- Attachment #1.1: Type: text/plain, Size: 4418 bytes --]

Dave

I knew the story but thanks for the added pieces of information.

As you wrote, this may be useful to include this I-D is linked to the eBPF that you know and love. Especially for this ISA draft, the first one, as it is the first time IETF does some eBPF standardization.

Of course, if this I-D is followed by more in the coming years, there will be less need to add this short explanation.

Regards

-éric

From: Dave Thaler <dthaler1968@googlemail.com>
Date: Thursday, 20 June 2024 at 21:58
To: Eric Vyncke (evyncke) <evyncke@cisco.com>, gunter.van_de_velde@nokia.com <gunter.van_de_velde@nokia.com>
Cc: draft-ietf-bpf-isa@ietf.org <draft-ietf-bpf-isa@ietf.org>, bpf-chairs@ietf.org <bpf-chairs@ietf.org>, bpf@ietf.org <bpf@ietf.org>, void@manifault.com <void@manifault.com>, bpf@vger.kernel.org <bpf@vger.kernel.org>
Subject: BPF/eBPF non-acronym feedback from Gunter Van de Velde and Éric Vyncke
Gunter Van de Velde, RTG AD, wrote:
> > 12 eBPF (which is no longer an acronym for anything), also commonly
>
> I assumed that 'e' was for 'extended' and that BPF stands for 'BSD Packet
> Filter' originally described and specified in a paper titled "The BSD
> Packet Filter: A New Architecture for User-level Packet Capture" by
> Steven McCanne and Van Jacobson, presented at the 1993 Winter
> USENIX Conference. This paper introduced the BPF architecture, which
> was designed for efficient packet filtering and capture.
>
> Hence a bit surprised why the first words of the first line in
> the first paragraph of the draft abstract suggest that its
> not an acronym?

Éric Vyncke wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bpf-isa-03: Yes
>
> When responding, please keep the subject line intact and reply to all email addresses
> included in the To and CC lines. (Feel free to cut this introductory paragraph,
> however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bpf-isa/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Nice document, easy to read and understand and the shepherd's write-up
> companion is also clear.
>
> Just two COMMENTs (no need to reply, but replies will be appreciated):
>
> 1) like Gunter, having an expansion to "eBPF is related or is the successor of
> extended Berkeley Packet Filter" would comfort the readers about what they are
> reading.

The existing text is derived from what is at https://ebpf.io/what-is-ebpf/
and a much longer exposition would be more appropriate for a different document on the WG charter ("[I] an architecture and framework document").

However, https://ebpf.io/what-is-ebpf/#what-do-ebpf-and-bpf-stand-for does have the FAQ answer for "What do eBPF and BPF stand for?":

> BPF originally stood for Berkeley Packet Filter, but now that eBPF
> (extended BPF) can do so much more than packet filtering, the acronym
> no longer makes sense. eBPF is now considered a standalone term that
> doesn’t stand for anything. In the Linux source code, the term BPF
> persists, and in tooling and in documentation, the terms BPF and eBPF
> are generally used interchangeably. The original BPF is sometimes
> referred to as cBPF (classic BPF) to distinguish it from eBPF.

That paragraph, or some variation of it, would in my opinion be appropriate
in the architecture/ framework document, but do we really want it in *every*
other document from the WG?  That would seem needlessly redundant to me.

There are plenty of examples in the world of things that started as acronyms
and no longer stand for anything and so are not expanded (AT&T,
NPR, CBS, 3M, SOS, etc.)   See
http://blog.writeathome.com/index.php/2013/10/12-initials-that-stand-for-nothing/
for one of many articles with a list of such terms, but web searches will turn
up plenty of other references.

Trying to explain in every news article that uses
one of those terms what it originally stood for but doesn't any more, doesn't
seem particularly helpful to me and certainly isn't commonly done.

Dave

[-- Attachment #1.2: Type: text/html, Size: 8596 bytes --]

[-- Attachment #2: Type: text/plain, Size: 88 bytes --]

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

Éric Vyncke's feedback on byteswap functions

[Dave Thaler]

Éric Vyncke wrote: 
> 2) I find puzzling the absence of betoh16() in the presence of htobe16()
> functions.

Since the implementation is identical, I believe it wouldn't make sense to
use up another instruction with the same implementation.  

Table 6 in section 4.2 uses the direction-agnostic description for TO_BE of
"convert between host byte order and big endian" which I think is good.
But then it says:

> {END, TO_BE, ALU} with 'imm' = 16/32/64 means:
>
> dst = htobe16(dst)
> dst = htobe32(dst)
> dst = htobe64(dst)

Where section 2.2 confusingly defines it as direction-specific as you noted:

> htobe16: Takes an unsigned 16-bit number in host-endian format and
> returns the equivalent number as an unsigned 16-bit number in big-endian format.

Whereas bswap16 is direction agnostic:
> bswap16: Takes an unsigned 16-bit number in either big- or little-endian format
> and returns the equivalent number with the same bit width but opposite endianness.

I think the right way to address your comment is to change 2.2 and perhaps
the function name to be direction agnostic and match the description in table 6.
For example:

* bebswap16: Takes an unsigned 16-bit number and converts it between host byte
order and big endian.  That is, on a big-endian platform the value is left unchanged
and on a little-endian platform the behavior is the same as bswap16.

Dave

[Bpf] Éric Vyncke's feedback on byteswap functions

[Dave Thaler]

Éric Vyncke wrote: 
> 2) I find puzzling the absence of betoh16() in the presence of htobe16()
> functions.

Since the implementation is identical, I believe it wouldn't make sense to
use up another instruction with the same implementation.  

Table 6 in section 4.2 uses the direction-agnostic description for TO_BE of
"convert between host byte order and big endian" which I think is good.
But then it says:

> {END, TO_BE, ALU} with 'imm' = 16/32/64 means:
>
> dst = htobe16(dst)
> dst = htobe32(dst)
> dst = htobe64(dst)

Where section 2.2 confusingly defines it as direction-specific as you noted:

> htobe16: Takes an unsigned 16-bit number in host-endian format and
> returns the equivalent number as an unsigned 16-bit number in big-endian format.

Whereas bswap16 is direction agnostic:
> bswap16: Takes an unsigned 16-bit number in either big- or little-endian format
> and returns the equivalent number with the same bit width but opposite endianness.

I think the right way to address your comment is to change 2.2 and perhaps
the function name to be direction agnostic and match the description in table 6.
For example:

* bebswap16: Takes an unsigned 16-bit number and converts it between host byte
order and big endian.  That is, on a big-endian platform the value is left unchanged
and on a little-endian platform the behavior is the same as bswap16.

Dave

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org