netdev - automatically decrease sender throughput when network traffic is heavy?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 21 Apr 2011 14:50:00 +0800
From:	zhou rui <zhourui.cn@...il.com>
To:	netdev@...r.kernel.org
Subject: automatically decrease sender throughput when network traffic is heavy?

hi
meet a strange situation:

usually throughput between sender(tcpreplay)  ->  receiver(my app) is
about 800~900Mbps(different machine,1G nic)

my kernel module will do a complicated work when it receive a packet,
I register a hook func like this:

 prot_hook.func = my_packet_rcv;
 prot_hook.type = htons(ETH_P_ALL);
 dev_add_pack(&prot_hook);

I suppose the nic driver will drop packets when traffic is heavy,
however, surprised that the sender throught is dreased to 500-600Mbps
why? what happened?

top - 14:00:46 up 5 days, 23:25,  3 users,  load average: 1.20, 0.44, 0.64
Tasks: 126 total,   5 running, 121 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.9%us,  8.9%sy,  0.0%ni, 76.5%id,  0.0%wa,  0.0%hi, 12.6%si,  0.0%st
Mem:     16077M total,     3427M used,    12650M free,       87M buffers
Swap:     2055M total,        0M used,     2055M free,      850M cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   25 root      20   0     0    0    0 R   98  0.0  10:33.29 ksoftirqd/6


the kernel is 2.6.36.4-0.7-default #5 SMP Thu Apr 14 15:37:53 SGT 2011
x86_64 x86_64 x86_64 GNU/Linux

before that same test was done on kernel 2.6.16 and no this problem seen

thanks
rui
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html