This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

am335x: high load broadcast reception issue with recent kernels

We experience massive problems, when putting am335x based devices into
high broadcast load environment (customer reports). To reproduce the
issue we've written following Python script

#!/usr/bin/python
# Send UDP broadcast packets

myport = 50000

import sys, time
from socket import *

if len(sys.argv) == 2:
    myport = int(sys.argv[1])

s = socket(AF_INET, SOCK_DGRAM)
s.bind(('192.168.254.36', 0))
s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)

while 1:
    #data = repr(time.time()) + '\n'
    data = "a"
    s.sendto(data, ('<broadcast>', myport))
    time.sleep(0.0001)

Just running this script on a host machine and invoking "top" on the
am335x machine results in sirq showing about 90% for 600MHz CPU and
3.18.x kernel. Below example of idle "top" output for the reference:

Mem: 13432K used, 217844K free, 64K shrd, 652K buff, 4956K cached
CPU:   0% usr   0% sys   0% nic  99% idle   0% io   0% irq   0% sirq

I have tried following kernels on the am335x-evmsk to reproduce this behavior on your reference platform:

sirq load for different kernels
Kernel sirq load
3.2.0+ 2-3%
3.14.48 (origin/ti-linux-3.14.y) 50%
4.1.2 (vanilla kernel) 40-45%

Recent kernels were compiled with omap2plus_defconfig. OS is not listening for these broadcasts explicitly: 

# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
netstat: /proc/net/tcp6: No such file or directory
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 3 [ ] DGRAM 4177 /dev/log
unix 2 [ ] DGRAM 4181

How do I get sirq load down to 2-3% as was the case by the old 3.2 kernel as the system cannot perform well under this load in such environments?

Regards,

rfc2217