|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Thank you all for the quick response.
The original question came in from our industrial team.
My response was that I did not see any alignment constraint in the standard.
I do remember talking about alignment, but did not require it for our solution.
Denis Beaudoin DMTS Texas Instruments dbeaudoin@xxxxxx W: 214-479-4287 M: 214-475-9193
From: Pat Thaler [mailto:pat.thaler@xxxxxxxxxxxx]
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?