Hello,
it seems prudent to cherry-pick
commit 41a50d621a321b4c15273cc1b5ed41437f4acdfb
Author: Alexander Drozdov <al.drozdov@xxxxxxxxx>
Date: Tue Feb 24 08:18:28 2015 +0300
af_packet: don't pass empty blocks for PACKET_V3
Before da413eec729d ("packet: Fixed TPACKET V3 to signal poll when block is
closed rather than every packet") poll listening for an af_packet socket was
not signaled if there was no packets to process. After the patch poll is
signaled evety time when block retire timer expires. That happens because
af_packet closes the current block on timeout even if the block is empty.
Passing empty blocks to the user not only wastes CPU but also wastes ring
buffer space increasing probability of packets dropping on small timeouts.
to the stable kernels 3.2, 3.4 (still alive?), 3.16 and 3.18 - since
without that one the softflowd program may stall for a long time,
details below.
However according to the description it might be a idea to pick the
commit referred there as well. Honestly, I don't feel competent enough
to judge this and therefore ask for your expertise.
The problem seen in userland is as follows: The softflowd application
uses poll() in the main loop¹ to learn about updates from two sources:
The usual pcap handle, and a local socket to receive control messages
using the "softflowctl" program.
If the interface softflowd listens on has no traffic at all, the
pcap_dispatch() call does not return, making any access using
softflowctl stall. Also, "kill -9" is required to stop the softflowd
process.
This problem does not exist with newer kernels, reverse bisect led to
the above commit.
How to repeat:
# modprobe dummy numdummies=1
# ip link set up dev dummy0
# softflowd -d -i dummy0 -c /tmp/softflowd.ctl
In a second terminal:
# softflowctl -c /tmp/softflow.ctl statistics
After a few seconds of softflowd running, this command will stall -
until there's *any* traffic on dummy0 like "ping6 ff02::1%dummy0".
Related: It seems 3.2 and 3.4 have a performance issue in the above
softflowd scenario: There is a ksoftirqd process at around 50% CPU
usage. An additional reverse bisect led to 47aa8b6cbc and cherry-picking
that one indeed ends it. But that's for another day.
Christoph
¹ https://sources.debian.net/src/softflowd/0.9.9-3/softflowd.c/#L1897