On 9/20/2016 11:38 AM, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 10:55 AM, Joe Touch <to...@isi.edu> wrote:
>> On 9/20/2016 10:47 AM, Tom Herbert wrote:
>>> On Tue, Sep 20, 2016 at 10:35 AM, Joe Touch <to...@isi.edu> 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.
It is, and something that handles Ethernet messages should already know
what to do here.
So if it already expects to shift the packet over as it copies it in,
then you've just defeated that. The same is true for non-IP inside
Ethernet, which might have its own padding to re-align its contents.
I.e., if it's ethernet, treat it as ethernet. That's what an L2 tunnel
nvo3 mailing list