On 9/20/2016 10:29 AM, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 10:07 AM, Joe Touch <to...@isi.edu> wrote:
>> Hi, Tom,
>> On 9/20/2016 9:13 AM, Tom Herbert wrote:
>>> ...
>>> For new encapsulation protocols please consider the effects of IP
>>> header alignment in the presence of Ethernet encapsulation. Defining
>>> Ethernet encapsulation with the two byte padding like in ETHERIP may
>>> help a lot to make implementation of Ethernet encapsulation feasible
>>> on CPU HW.
>> IMO, alignment needs to be handled within each encapsulation layer
>> independently. I don't think it's useful to expect new encapsulation
>> layers to have to make sure every layer of an encapsulated packet is
>> aligned - just the first one ought to be sufficient. The rest is the
>> responsibility of whomever added the other layers already in place.
>> So yes, it's useful to make sure the encapsulated packet starts on a
>> boundary that is 4-byte aligned, but the rest *needs to be* someone
>> else's problem.
> It's the Ethernet payload that we need to be four byte aligned not the
> Ethernet header. Just aligning Ethernet header to four bytes is not
> useful; that means the Ethernet payload, e.g. an IP packet, won't have
> four byte alignment and hence the misery of trying to process the
> packet. For the cost of two bytes ETHERIP gets things right in this
> regard!
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. Aligning the IP header de-aligns the
Ethernet one. Again, if you're encapsulating ethernet, then that is what
you should align to.


nvo3 mailing list

Reply via email to