no rx_missed_errors counter in i40e interface?

[Daniel_]

I tried to analyse our system (16200, R80.40) for RX-DROPs. Timothy suggested in "Check Point Firewall
Performance Optimization" book to take a look for rx_missed_errors in "ethtool -S <interface>".

On a i40e we don't have a counter for rx_missed_errors. On igb interfaces it's available on the same system.

How can I verify that a ring buffer slot was not available to receive a frame on a i40e interface?

Thanks!

[Timothy_Hall]

The relevant counter probably has something like "fifo" or even "buffer" (maybe rx_out_of_buffer?) in it, but this varies wildly for every driver.  Please post the output of ethtool -S for the relevant interface and I should be able to find it.  Keep in mind though that starting in Gaia 3.10 not every RX-DRP is necessarily a buffering miss, and could instead be "trash traffic" such as unknown EtherTypes and invalid VLAN tags.  sk166424: Number of RX packet drops on interfaces increases on a Security Gateway R80.30 and higher ...

[Daniel_]

Thanks for your answer. I attached ethtool -S. Looks like it's rx_dropped but with a gap between ip link show and ethtool....

# ip -s link show eth2-03 ; ethtool -S eth2-03 |grep rx_dropped
18: eth2-03: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond2 state UP mode DEFAULT qlen 1000
    link/ether de:ad:be:ef:de:ad brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    5483651403100933 7555221204989 39      250173841 0       4169914178
    TX: bytes  packets  errors  dropped carrier collsns
    5322039635704921 6727811742195 0       0       0       0
     rx_dropped: 248075911

[Timothy_Hall]

Looks like it is rx_dropped, assuming all of those are legit ring buffer drops the overall drop rate is a miniscule 0.0033% which is well beyond the 0.1% target.  You can use sar -n EDEV if you are curious to see if these increments are happening constantly or in clumps.  If RX-DRPs are incrementing slowly and constantly that generally means it is trash traffic, but this trash traffic normally does not increment any counters under ethtool -S at all.

Does the RX-DRP value shown by netstat -ni exactly follow rx-dropped? 

[Daniel_]

---

@Timothy_Hall wrote:

Does the RX-DRP value shown by netstat -ni exactly follow rx-dropped? 

---

Looks like it different.

Tested quick and dirty with

# while :; do date; netstat -ni | grep eth2-03 | awk '{print $6 " netstat -ni"}'; ethtool -S eth2-03 |grep -E '[^.]rx_dropped' | awk '{ print $2 " ethtool -S"}'; sleep 1; done
Thu Dec 7 08:04:19 CET 2023
250233343 netstat -ni
248130440 ethtool -S
Thu Dec 7 08:04:20 CET 2023
250233343 netstat -ni
248130440 ethtool -S
Thu Dec 7 08:04:21 CET 2023
250233343 netstat -ni
248130440 ethtool -S
Thu Dec 7 08:04:22 CET 2023
250233344 netstat -ni
248130440 ethtool -S
Thu Dec 7 08:04:23 CET 2023
250233344 netstat -ni
248130440 ethtool -S
Thu Dec 7 08:04:24 CET 2023
250233344 netstat -ni
248130440 ethtool -S
Thu Dec 7 08:04:25 CET 2023
250233344 netstat -ni
248130440 ethtool -S
Thu Dec 7 08:04:26 CET 2023
250233344 netstat -ni
248130440 ethtool -S

[Timothy_Hall · Accepted solution]

Right, for your outputs I would interpret the 248,130,440 reported by ethtool as legit ring buffer drops, while anything above that is trash traffic (2,102,904 delta for your last data set).  The fact that RX-DRP is still incrementing but nothing is advancing under ethtool indicates a constant stream of trash traffic (undesirable EtherTypes like IPv6 or improperly pruned VLAN tags).  Legit ring buffer drops tend to come in clumps and not slowly accumulate.

[Daniel_]

---

@Timothy_Hall wrote:

The fact that RX-DRP is still incrementing but nothing is advancing under ethtool indicates a constant stream of trash traffic (undesirable EtherTypes like IPv6 or improperly pruned VLAN tags). 

---

Full ACK. I also saw it's incremented exactly every 30 seconds.

Thanks for your help!