Subject: Re: IPv6 Options alignment and padding problem //RE: [2nd] Working Group Last Call for draft-ietf-6man-mtu-option-06

From: [email-masked]
Date: Wed, 1 Sep 2021 14:04:39 +0200

Tom,

> The reason for the convention to align fields to their natural
> alignment is to make it easy on host CPUs when accessing the fields.
> Most modern CPU architectures can handle unaligned accesses
> efficiently, however there are still architectures in deployment, such
> as Sparc, that take a software trap on unaligned accesses-- very
> costly for performance. While it's good practice to try to align
> individual fields, IMO it is still quite important to ensure that
> various headers are aligned to at least 32 bits, lest some
> implementations would have serious performance issues processing a
> whole bunch of unaligned protocol fields.

The platforms I work on provide no guarantee that a NIC will DMA a frame buffer in a way that ensures the L3 header is aligned.
Variable length L2 headers and tunnels. Unless you explicitly copy the packet headers I am not sure what implementations can assume packet headers aligned at 64 bits.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 1 Sep 2021 08:14:16 -0400

On Wed, Sep 1, 2021, 8:04 AM <[email-masked]> wrote:

> The platforms I work on provide no guarantee that a NIC will DMA a frame
> buffer in a way that ensures the L3 header is aligned.
>

Hi Ole,

What platform and NIC is that? The way this is done in Linux is to provide
a NIC with receive buffers that are offset by two to account for 12+2 byte
Ethernet header. AFAIK this technique generally works across all NICs to
maintain L3 alignment. Encapsulated Ethernet where alignment is messed up
for the embedded L3 is what was unpleasant for Sparc (doesn't handle
unaligned fields well).

Tom

Tom

Variable length L2 headers and tunnels. Unless you explicitly copy the
> packet headers I am not sure what implementations can assume packet headers
> aligned at 64 bits.
>
> Cheers,
> Ole
>

---

From: [email-masked]
Date: Wed, 1 Sep 2021 15:07:47 +0200

Tom,

> What platform and NIC is that? The way this is done in Linux is to provide a NIC with receive buffers that are offset by two to account for 12+2 byte Ethernet header. AFAIK this technique generally works across all NICs to maintain L3 alignment. Encapsulated Ethernet where alignment is messed up for the embedded L3 is what was unpleasant for Sparc (doesn't handle unaligned fields well).

That scheme wouldn't work with QinQ would it?

Cheers,
Ole