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
next prev 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