BPF List
 help / color / mirror / Atom feed
From: Dave Thaler <dthaler1968@googlemail.com>
To: "'Éric Vyncke'" <evyncke@cisco.com>
Cc: <draft-ietf-bpf-isa@ietf.org>, <bpf-chairs@ietf.org>,
	<bpf@ietf.org>, <void@manifault.com>, <bpf@vger.kernel.org>
Subject: Éric Vyncke's feedback on byteswap functions
Date: Thu, 20 Jun 2024 12:59:37 -0700	[thread overview]
Message-ID: <1b3701dac34c$6337e7f0$29a7b7d0$@gmail.com> (raw)
In-Reply-To: <171811793126.62184.9537540105321678706@ietfa.amsl.com>

É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


WARNING: multiple messages have this Message-ID (diff)
From: Dave Thaler <dthaler1968=40googlemail.com@dmarc.ietf.org>
To: "'Éric Vyncke'" <evyncke@cisco.com>
Cc: draft-ietf-bpf-isa@ietf.org, bpf-chairs@ietf.org, bpf@ietf.org,
	void@manifault.com, bpf@vger.kernel.org
Subject: [Bpf] Éric Vyncke's feedback on byteswap functions
Date: Thu, 20 Jun 2024 12:59:37 -0700	[thread overview]
Message-ID: <1b3701dac34c$6337e7f0$29a7b7d0$@gmail.com> (raw)
Message-ID: <20240620195937.Rt-U3dq1XfxxZ4ZlKDzjYJsg6T-yBt7wIiudqqEj-Yg@z> (raw)
In-Reply-To: <171811793126.62184.9537540105321678706@ietfa.amsl.com>

É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

  parent reply	other threads:[~2024-06-20 19:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <171811793126.62184.9537540105321678706@ietfa.amsl.com>
2024-06-20 19:58 ` BPF/eBPF non-acronym feedback from Gunter Van de Velde and Éric Vyncke Dave Thaler
2024-06-20 19:58   ` [Bpf] " Dave Thaler
2024-06-21 14:47   ` [Bpf] " Eric Vyncke (evyncke)
2024-06-20 19:59 ` Dave Thaler [this message]
2024-06-20 19:59   ` [Bpf] Éric Vyncke's feedback on byteswap functions Dave Thaler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='1b3701dac34c$6337e7f0$29a7b7d0$@gmail.com' \
    --to=dthaler1968@googlemail.com \
    --cc=bpf-chairs@ietf.org \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=draft-ietf-bpf-isa@ietf.org \
    --cc=evyncke@cisco.com \
    --cc=void@manifault.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox