netsniff-ng.git - A high-performance Linux networking toolkit

Age	Commit message (Collapse)	Author	Files	Lines
2015-07-30	sock: Don't panic() when sysctl_set_int fails	Tobias Klauser	1	-1/+2
	Instead print an error message including some more details. netsniff-ng should still remain funcional without the socket sysctl values being set. Suggested-by: Vadim Kochan <vadim4j@gmail.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
2015-07-20	sock: Use sysctl helpers to access /proc/sys/ params	Vadim Kochan	1	-32/+9
	Use helpers from sysctl.c module to set sock memory params via /proc/sys/net/core. Signed-off-by: Vadim Kochan <vadim4j@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2015-06-18	sock: Add dgram socket creation.	Daniel Borkmann	1	-0/+21
	LINKTYPE_LINUX_SLL needs datagram packet sockets. We'll need this function at a later point in time. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2015-05-06	sock: Fix capturing extra packets from other dev	Vadim Kochan	1	-10/+1
	Create PF_PACKET socket with proto=0 which does not setup packet handler and will not capture packets until bind() will be invoked. Also replaced pf_tx_socket by pf_socket as these funcs became the same, as proto arg is set to 0. Suggested-by: Daniel Borkmann <borkmann@iogearbox.net> Signed-off-by: Vadim Kochan <vadim4j@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
2015-01-11	sock: Add cause message in case of error	Vadim Kochan	1	-9/+9
	Add error messages which explain the cause of error state of the socket functions, so it makes message like: $ ./netsniff-ng/netsniff-ng -i wlp3s0 Creation of PF socket failed: Operation not permitted more understandable. Signed-off-by: Vadim Kochan <vadim4j@gmail.com> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
2014-09-09	sock: Error out if setting of the system socket memory fails	Tobias Klauser	1	-1/+2
	Currently we ignore the return value of the write() calls to /proc/sys/net/core/{r,w}mem_{default,max} in set_system_socket_mem(). Better check the return value and notify the user about it. This also fixes a clang compiler warning about a variable explicitely assigned to itself. Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
2013-12-12	trafgen: take advantage of PACKET_QDISC_BYPASS sock option	Jesper Dangaard Brouer	1	-0/+18
	Since Linux 3.14, the kernel supports a socket option PACKET_QDISC_BYPASS, which trafgen enables by default. That allow us to bypass the kernels normal qdisc (traffic control) layer. An option -q, --qdisc-path is added to allow enabling the qdisc path explicity, useful for testing purposes. This will be avail in kernels >= 3.14 via commit d346a3fae3 (packet: introduce PACKET_QDISC_BYPASS socket option). Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
2013-12-11	trafgen: speedup TX only path by avoiding kernel packet_rcv() call	Jesper Dangaard Brouer	1	-0/+10
	The tool trafgen is used in a pktgen style transmit only scenario. We discovered a performance bottleneck in the kernel, when running trafgen, where the kernel stalled on a lock in packet_rcv(). This call is unnecessary for trafgen given its transmit only nature. This packet_rcv() call can, easily be avoided by instructing the RAW/PF_PACKET socket, to not listen to any protocols (by passing protocol argument zero, when creating the socket). The performance gain is huge, increasing performance from approx max 2Mpps to 12Mpps, basically causing trafgen to scale with the number of CPUs. Following tests were run on a 2xCPU E5-2650 with Intel 10Gbit/s ixgbe: Trafgen using sendto() syscall via parameter -t0: * # CPUs -- with -- without packet_rcv() call * 1 CPU == 1,232,244 -- 1,236,144 pkts/sec * 2 CPUs == 1,592,720 -- 2,593,620 pkts/sec * 3 CPUs == 1,635,623 -- 3,692,216 pkts/sec * 4 CPUs == 1,567,768 -- 4,102,866 pkts/sec * 5 CPUs == 1,700,270 -- 5,151,489 pkts/sec * 6 CPUs == 1,762,392 -- 6,124,512 pkts/sec * 7 CPUs == 1,850,139 -- 7,120,496 pkts/sec * 8 CPUs == 1,770,909 -- 8,058,710 pkts/sec * 9 CPUs == 1,721,072 -- 8,963,192 pkts/sec * 10 CPUs == 1,359,157 -- 9,584,535 pkts/sec * 11 CPUs == 1,175,520 -- 10,498,038 pkts/sec * 12 CPUs == 1,075,867 -- 11,189,292 pkts/sec * 13 CPUs == 1,012,602 -- 12,048,836 pkts/sec * [...] * 20 CPUs == 1,030,446 -- 11,202,449 pkts/sec Trafgen using mmap() TX tpacket_v2 (default) * # CPUs -- with -- without packet_rcv() call * 1 CPU == 920,682 -- 927,984 pkts/sec * 2 CPUs == 1,607,940 -- 2,061,406 pkts/sec * 3 CPUs == 1,668,488 -- 2,979,463 pkts/sec * 4 CPUs == 1,423,066 -- 3,169,565 pkts/sec * 5 CPUs == 1,507,708 -- 3,910,756 pkts/sec * 6 CPUs == 1,555,616 -- 4,625,844 pkts/sec * 7 CPUs == 1,560,961 -- 5,298,441 pkts/sec * 8 CPUs == 1,596,092 -- 6,000,465 pkts/sec * 9 CPUs == 1,575,139 -- 6,722,130 pkts/sec * 10 CPUs == 1,311,676 -- 7,114,202 pkts/sec * 11 CPUs == 1,157,650 -- 7,859,399 pkts/sec * 12 CPUs == 1,060,366 -- 8,491,004 pkts/sec * 13 CPUs == 1,012,956 -- 9,269,761 pkts/sec * [...] * 20 CPUs == 955,716 -- 8,653,947 pkts/sec It is fairly strange that the mmap() version runs slower than the sendto() version. This is likely another performance problem related to mmap() which seems worth fixing. Note, that the mmap() version speed can be improved by reducing the default --ring-size to around 1-2 MiB. But this does not fix general trend with mmap() performance. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
2013-06-14	sock: Check return value of setsockopt() in set_tcp_nodelay()	Tobias Klauser	1	-2/+5
	Check the return value of setsockopt() and panic in case it is not 0, as in the other setsockopt() wrapper functions. This issue was discovered by the Coverity scanner. Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
2013-06-04	sock: add socket management functions	Daniel Borkmann	1	-0/+176
	Remove them from xutils, and add them to socket management. Signed-off-by: Daniel Borkmann <dborkman@redhat.com>