About ethtool statistics

[ykpark]

Dear all,

I have a question about ethtool statistics.

Below are the ethtool stats from Security Gateway.

The value of rx_long_byte_count continues to increase.

I want to know what these counts mean and what problems may arise.

Thanks

[Chris_Atkinson]

Believe it's a somewhat redundant counter covered by rx_bytes (third row from the top).

Whereas if it were rx_long_length_errors then you'd be looking at a potential MTU issue (refer: sk115357).

[_CP_Firewall]

Seems like connected interface is getting jumbo-frame packets (A packet size more than 1500-1522 bytes) and if MTU is not set accordingly then these packets will keep dropping until the MTU is not properly configured to accept the jumbo-frames.
I don't think it's going to create an issue but it's wasting the resources.

Regards,
Hasnain Ansari

[Chris_Atkinson]

This is incorrect in my opinion, you'll note the count of rx_bytes & rx_long_byte_count is the same value.

[_CP_Firewall]

As per my understanding rx_bytes is the total (good data/frames) received at the interface and rx_long_byte_count means count of jumbo frame that hit at this interface.
Why these 2 things are showing same value ? Any difference ?
Correct me if i missed something.

[the_rock]

I tend to agree with your assessment, as I had seen this before and thats exactly what the issue was.

[Timothy_Hall · Accepted solution]

No, rx_long_length_errors indicate the receipt of an overly large frame in excess of the MTU (this used to be called a "jabber" long ago, along with "runts" for frames that were too short) but it is 0 in this case.  I'm not completely sure what rx_long_byte_count is trying to indicate, but it always seems to match rx_bytes precisely on every system I've seen.  Unfortunately these counter names are not standardized between NIC vendors and can mean just about anything.

If I had to take a wild guess, perhaps rx_bytes indicates the number of payload/data (i.e. non-header) bytes received at the hardware NIC level off the wire, while rx_long_byte_count reports the number of payload/data bytes that actually made it up into the receive socket buffer (referenced by a ring buffer descriptor), after the DMA transfer from the NIC hardware buffer into Gaia's memory.  Perhaps "long" in this context indicates a frame that has a nonzero number of payload/data bytes. 

Obviously these two counter values should always match, and if they don't that indicates some kind of bug in the NIC driver or SoftIRQ routine that a coder would need to address.  Just a guess though...