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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.