Re: r8169 rx_missed increasing in bursts (regression)

[Timo Teras <timo.teras@iki.fi>]

On Wed, 9 Jan 2013 19:14:56 +0200 Timo Teras <timo.teras@iki.fi> wrote:

> It seems that the rx_missed is not directly related to traffic amount.
> At times the box is handling easily 10000+ pps, while packet loss can
> happen at other times on 4000-8000pps levels.
> 
> Generally time_squeeze does not happen, and the box is at 20-30%
> softirq. Some times time_squeeze bumps up with one (within a one
> second interval) or two and packet loss does not happen.
> 
> When rx_missed is getting bumped, time_squeeze goes up with 1-3, and
> rx_missed goes up with 50-1000 packets. Usually around 200 packets. (1
> second sampling period)
> 
> I did find a strong correlation that rx_misses happen usually when the
> box has dropped a packet due to iptables DROP/REJECT rule, or some
> other reason (e.g. I'm seeing once in a while dmesg contain:
> "nf_ct_sip: dropping packet").
> 
> Any ideas why a netfilter packet drop might cause netdevice rx to
> stall long enough to saturate the hardware receive queue?

Ok, found the main culprit. Embarassingly, there was LOG targets, which
wound up writing to ttyS0. That apparently is synchronous operation, so
the printk's made the napi poller choke whenever packets got dropped.

However, I do still observe minor packet drops on specific loads.
Increasing the rx fifo size helped noticeably, but even at 512 it still
does some drops. Seems that Realtek's r8168 driver has rx fifo size of
1024.

Would it be feasible to make the fifo size a module parameter, or
somehow autotuned according to available system memory?

I also noticed that since recent commits, the dirty_rx is always
identical cur_rx. Basically, dirty_rx can be just removed. Should I
send a patch for this?

 - Timo