topic Re: About ethtool statistics in Firewall and Security Management

About ethtool statistics

ykpark — Fri, 12 Aug 2022 10:39:25 GMT

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

Re: About ethtool statistics

Chris_Atkinson — Fri, 12 Aug 2022 09:52:44 GMT

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

Re: About ethtool statistics

Hasnain_Ansari — Fri, 12 Aug 2022 10:04:16 GMT

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

Re: About ethtool statistics

Chris_Atkinson — Fri, 12 Aug 2022 10:26:31 GMT

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

Re: About ethtool statistics

Hasnain_Ansari — Fri, 12 Aug 2022 10:39:57 GMT

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.

Re: About ethtool statistics

the_rock — Fri, 12 Aug 2022 12:25:27 GMT

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

Re: About ethtool statistics

Timothy_Hall — Fri, 12 Aug 2022 12:35:07 GMT

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