<html>
<head>
<base href="https://bugs.dpdk.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8" class="bz_new_table">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - rte_ipv6_hdr.version is encoded in the wrong byte on little-endian platforms"
href="https://bugs.dpdk.org/show_bug.cgi?id=1679">1679</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>rte_ipv6_hdr.version is encoded in the wrong byte on little-endian platforms
</td>
</tr>
<tr>
<th>Product</th>
<td>DPDK
</td>
</tr>
<tr>
<th>Version</th>
<td>24.11
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>Normal
</td>
</tr>
<tr>
<th>Component</th>
<td>core
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dev@dpdk.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>maxime@leroys.fr
</td>
</tr>
<tr>
<th>Target Milestone</th>
<td>---
</td>
</tr></table>
<p>
<div class="bz_comment_block">
<pre class="bz_comment_text">Created <span class=""><a href="attachment.cgi?id=304" name="attach_304" title="patch to reproduce the issue with testpmd">attachment 304</a> <a href="attachment.cgi?id=304&action=edit" title="patch to reproduce the issue with testpmd">[details]</a></span>
patch to reproduce the issue with testpmd
When setting the version field in a struct rte_ipv6_hdr, the compiler-generated
code stores the value in the wrong byte of the vtc_flow field on little-endian
architectures such as x86_64. As a result, the encoded IPv6 version value is
not in the expected network byte order, and version checks (such as
rte_ipv6_check_version()) fail.
I encountered this issue while writing new unit tests for the DPDK Grout
project, which exposed the incorrect version encoding. The issue is
reproducible with GCC 13 and 14 and Clang 15, 16, and 18 on Ubuntu 24.04
(x86_64), but it does not reproduce on ARM.
Example output with the patch provided:
$ ./build/app/dpdk-testpmd
version is bad
0 0 0 60
This suggests that 0x60 (i.e., version = 6) is incorrectly stored in the 4th
byte of vtc_flow (i.e., ((uint8_t *)&vtc_flow)[3]), whereas the 1st byte ([0],
the MSB in network byte order) should hold the version field.
Assembly dump with objdump:
memset(&ip, 0, sizeof(ip));
movzbl -0x9d(%rbp), %eax ; β accesses byte offset +3 from ip
and $0xf, %eax
or $0x60, %eax
mov %al, -0x9d(%rbp) ; β stores version into 4th byte
If ip is located at -0xa0(%rbp), then the offset -0x9d(%rbp) corresponds to
byte 3 (i.e., ip + 3).
But the version field should be encoded in the first byte (ip + 0) to follow
network byte order.
This problem appears since we added bitfield for the version field in
rte_ipv6_hdr in : <a href="https://git.dpdk.org/dpdk/commit/?id=cba27998dc8">https://git.dpdk.org/dpdk/commit/?id=cba27998dc8</a>
The behavior of bitfield layout in C is implementation-defined, as stated in
WG14/N1256 (C99 draft standard), section 6.7.2.1, paragraphs 10 and 11:
βThe order of allocation of bit-fields within a unit (high-order to
low-order or low-order to high-order) is implementation-defined.β
Grout PR demonstrating the issue:
- <a href="https://github.com/DPDK/grout/pull/189">https://github.com/DPDK/grout/pull/189</a>
</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
<link itemprop="url" href="https://bugs.dpdk.org/show_bug.cgi?id=1679">
<meta itemprop="name" content="View bug">
</div>
<meta itemprop="description" content="Bugzilla bug update notification">
</div>
</body>
</html>