Traffic into lo vs eth, why might I be seeing only half the traffic on lo compared to eth?

Question

I am forwarding traffic to ports on eth0 and lo.

For the same traffic at the same ports and different ports, when I do a tcpdump and count the packets, for time t, I only see about half the number of packets on the loopback, lo, compared with the eth0.

I have tried this on different port numbers, with different traffic rates, and the number of packets on lo is always about half that of eth0.

Is there anything inherently different between the lo, and eth interfaces that would account for this?

---

Update: I am using the IP address of the loopback to send the traffic, and this is the same on all devices. Is it possible that my packets are just being split between two devices, and their loopback port?

---

Update 2: So what I see from the tcpdump is that for the eth0 100% of the packets are received by the filter and captured. But at the lo, only 50% of the packets received by the filter are processed. I've only been counting captured packets, not all those received by the filter.

But why is the lo only capturing 50% of the packets?

Answer 1

Here's an example of what you'd get for your interfaces:

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether be:1a:e0:7d:22:6e brd ff:ff:ff:ff:ff:ff link-netns test

While MTU of eth0 is only 1500, MTU of lo is 65536. That means if you stream over TCP some contents, you need way less packets over lo than over eth0 for the same total data size.

The exact behaviour of data coalescing depends on multiple factors and on some TCP options. For example the use of TCP_CORK would favorise this behaviour while the use of TCP_NODELAY would avoid this behaviour (by disabling Nagle's algorithm).