|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Yet one more reason that confirms what Alon said. And now what Pat said.
The worst case odd byte fragment length is as arbitrary as now (no constraint).
Example – odd byte nnn first fragment + 64 byte last fragment.
So any constraint does not make the odd byte alignment cases go away.
Confirming what Alon said. Early on, we discussed having an alignment requirement like 32 bit-alignment. I don't recall any time discussing an alignment as long as 64-bytes. The longest I recall considering was 4-byte or maybe 8-byte.
During development of the standard, we came to the conclusion that the additional delay in waiting to suspend was undesirable and that the burden on the receiving MAC wasn't worth requiring more than byte alignment. If a MAC has a wide internal path, then it could hold onto the non-path multiple bytes received at the end of a non-final fragment until the next fragment arrives and provides the bytes to get to a multiple. For example, if a MAC has an 8-byte wide data path and gets a first fragment of 513 bytes, it has received 64 * 8 + 1 bytes. It can hold onto the 1 byte and send it to the data path when the next fragment has provided 7 more bytes.
We didn't receive any ballot comments that objected to this.
On Mon, Apr 17, 2017 at 6:33 AM, Beaudoin, Denis <dbeaudoin@xxxxxx> wrote:
From our IET standard, it seems that we could fragment a packet say at 513 bytes as long as we have a final frag of 64 bytes.
That is because we meet the minimum non-final fragment size, say 256, nothing requires the fragment length to be 32 bit aligned.
Was that the intent?
I thought it was originally required to be 64 byte aligned so MAC that use wide internal paths do not have to byte swizzle, but that is not actually specified.
Is this tested?