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
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