As far as I can tell the ethernet fcs is included in the 64 minimum packet size, so I would guess:
64 + 4 + 4 = mpu 72 B
rx-fcs is off [fixed] in ethtool so I can't verify this on my Linksys WRT3200ACM.
According to
https://en.wikipedia.org/wiki/Ethernet_frame
the frame check sequence lives inside the 64 byte ethernet MPU, it is only the preamble, the start of frame delimiter and the inter-frame-gap that fall outside that 64 byte minimum for an ethernet mpu of:
64 + 7 + 1 + 12 = 84B
or
64 + 7 + 1 + 12 = 84B
Looking at the wikipedia article also indicates that VLAN tags also lives inside the mpu...
I've read that articles a few times over. I trust most of the article except it's wikipedia, and I don't take it's info as the holy grail without verification 
. It seems odd that the vlan tag would be included as well, as that's an option and not all boards support 802.1Q.
Have a look at http://www.moduletek.com/Download/IEEE-Standard-for-Ethernet.pdf page 73"
4.2.3.3 Minimum frame size
InterPacket
The CSMA/CD Media Access mechanism requires that a minimum frame length of minFrameSize bits be transmitted. If frameSize is less than minFrameSize, then the CSMA/CD MAC sublayer shall append extra bits in units of octets (Pad), after the end of the MAC Client Data field but prior to calculating and appending the FCS (if not provided by the MAC client). The number of extra bits shall be sufficient to ensure that the frame, from the DA field through the FCS field inclusive, is at least minFrameSize bits. If the FCS is (optionally) provided by the MAC client, the Pad shall also be provided by the MAC client. The content of the Pad is unspecified.
To me this seems to indicate that the VLAN tag should be inside the minFrameSize. This makes sense considering the rationale for a min frame size in ethernet: the min frame size makes sure that any veridical transmit will take a minimum amount of time on the medium. Instead of filling this up with padding octets one might as well put the 4 byte VLAN tag inside it.
https://en.wikipedia.org/wiki/Ping_(networking_utility) No mention of 802.1Q / VLAN / PVID as far as I can tell.
A basic ICMP packet is [64b]
IPv4 Hdr 20
ICMP Hdr 8
ICMP Payload:
PTI (Payload Type Identifier) 3b + PFI (Payload FCS Indicator) 1b + EXI (Extension Header Identifier) 4b + UPI (User Payload Identifier) 8b +tHEC (type Header Error Check) 2b =18
Source 6b
Dest 6b
Ethernet type II 2b
FCS 4
Edit
The FCS is optional, so it is padded using 0's or ASCII depending on the source you reference.
These happen on the ethernet layer, so on a link using VLAN tags ICMP packet will also carry vlan tags....
As far as I can tell the ethernet FCS is not optional, as ethernet uses the FCS to detect broken packets...
Good Catch, the Payload FCS is optional.
I still disagree, as I don't see the vlan tag being inserted into the 64b but added as the additional 4b on top e.g. 64b+4b=68b. UNLESS the Payload FCS could be substituted with a vlan tag to squeeze that in.
Nah, ethernet minFrameSize padding only comes into play if the accountable payload size is smaller than minFrameSize, if the payload is larger minFrameSize/mpu become irrelevant.
The algorithm works approximately like this:
get the packet length from the skb, add the configured per packet overhead to get the effective packetsize, if and only if this sum is smaller than sqm's MPU then set packetsize = MPU.
So in the likely case that effective packetsize >= mpu nothing needs to be done.
I just wanted to drop in and say a big thank you to @ldir – been following your work with dscpmark/act_ctinfo. (Thought it better to post in this thread rather than the lengthy DSCP one...)
Used this from your exp branch alongside building master with the kmod enabled.
Formerly just ran with piece_of_cake.qos – now running ctinfo_4layercake.qos; though I modified it to get rid of the hard-coding parts and only kept the dynamic parts.
When I used to run layer_cake.qos in the past, "Bulk" traffic wouldn't ever have any packets in the statistic. I can see your logic for classifying Bulk is somewhere along the lines of:
DURUP=30
DURDN=30
CONNBDN=$(( ${DOWNLINK} * 1000 * ${DURDN} / 8 ))
CONNBUP=$(( ${UPLINK} * 1000 * ${DURUP} / 8 ))
Thanks for this!
1 Like
so the ethernet header, fcs, vlan tag are all included in the mpu. What about the 4bytes of ptm?
These come on top of the ethernet data from destination MAC to FCS.
still 64 or 68?
VDSL2/PTM should be configured with a tcMPU of 68, 64 for the full ethernet mpu (where the padding lives between payload and FCS) plus four for PTM's:
1 Byte Start of Frame (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS)
Good Deal. I did notice that there is a disparity between setting mpu on egress and ingress. I'm not at home right now but cake has 64 for one side and 68 for the other for some reason under tc stats.
DISREGARD! I guess this was fixed after v18.06.4
is it still working?
I'm no longer using VDSL2 as I moved, and now using Docsis 3.1