Re: [Rtg-dt-encap-considerations] [nvo3] Alignment and Ethernet encapsulation

[Tom Herbert <[e-mail]>]

On Tue, Sep 20, 2016 at 10:55 AM, Joe Touch <[e-mail]> wrote:
>
>
> On 9/20/2016 10:47 AM, Tom Herbert wrote:
>> On Tue, Sep 20, 2016 at 10:35 AM, Joe Touch <[e-mail]> wrote:
>>> ...
>>> If you've been handed Ethernet to encapsulate, then that is the header
>>> whose alignment you should be optimizing.
>>>
>>> As you point out, you can't align both IP and Ethernet to 4-byte
>>> boundaries at the same time.
>> You can if you insert a two byte pad before the encapsulated Ethernet
>> header like ETHERIP (RFC3378 does).
>
> You CAN do a lot of things, but you shouldn't.
>
> If you're handed ethernet to encapsulate, then THAT is the header whose
> access should be aligned.
>
> You have no business ASSUMING that you need to optimize for IP header
> access. All you're doing is messing up the ethernet access.
>
Sorry, but I disagree with that statement. Keeping IP headers aligned
for stack processing is a HUGE concern in real implementation.
Probably every device driver on the planet will put in a two byte pad
in receiver buffers to ensure that the Ethernet payload (and hence IP
header, EHs, TCP headers, etc.). We need two byte alignment of
Ethernet headers, and four byte alignment on IP protocols. If we don't
have this a lot of things will break (as VXLAN is currently broken on
SPARC)! Maybe in theory alignment is no longer considered an issue and
is just a historical footnote, but on real devices in deployment today
unaligned protocol headers still can be problematic.

Tom


> Frankly, anything that already parses Ethernet then IP ought to be able
> to efficiently handle the difference in the two alignments - and you
> might be messing THAT up.
>
> RFC3378 defines a header used for ETHERIP; that header may or may not be
> relevant to other ethernet-in-X encapsulations. The field needed to be
> there for versioning and was expanded from 8 to 16 bits, which certainly
> helps align the *ethernet* header that comes after it compared to the
> earlier use of an 8-bit field. There's no mention of aligning for the
> purposes of accessing the IP header, which again, I disagree with.
>
> Joe
>
>