Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
On Mon, 7 Jul 2008, Robert Watson wrote:
On Mon, 7 Jul 2008, Bruce Evans wrote:
(1) sendto() to a specific address and port on a socket that has been
bound to
INADDR_ANY and a specific port.
(2) sendto() on a specific address and port on a socket that has been
bound to
a specific IP address (not INADDR_ANY) and a specific port.
(3) send() on a socket that has been connect()'d to a specific IP address
and
a specific port, and bound to INADDR_ANY and a specific port.
(4) send() on a socket that has been connect()'d to a specific IP address
and a specific port, and bound to a specific IP address (not
INADDR_ANY)
and a specific port.
The last of these should really be quite a bit faster than the first of
these, but I'd be interested in seeing specific measurements for each if
that's possible!
Not sure if I understand networking well enough to set these up quickly.
Does netrate use one of (3) or (4) now?
(3) and (4) are effectively the same thing, I think, since connect(2) should
force the selection of a source IP address, but I think it's not a bad idea
to confirm that. :-)
The structure of the desired micro-benchmark here is basically:
...
I hacked netblast.c to do this:
% --- /usr/src/tools/tools/netrate/netblast/netblast.c Fri Dec 16 17:02:44 2005
% +++ netblast.cMon Jul 14 21:26:52 2008
% @@ -44,9 +44,11 @@
% {
%
% - fprintf(stderr, "netblast [ip] [port] [payloadsize] [duration]\n");
% - exit(-1);
% + fprintf(stderr, "netblast ip port payloadsize duration bind connect\n");
% + exit(1);
% }
%
% +static int gconnected;
% static int global_stop_flag;
% +static struct sockaddr_in *gsin;
%
% static void
% @@ -116,6 +118,13 @@
% counter++;
% }
% - if (send(s, packet, packet_len, 0) < 0)
% + if (gconnected && send(s, packet, packet_len, 0) < 0) {
% send_errors++;
% + usleep(1000);
% + }
% + if (!gconnected && sendto(s, packet, packet_len, 0,
% + (struct sockaddr *)gsin, sizeof(*gsin)) < 0) {
% + send_errors++;
% + usleep(1000);
% + }
% send_calls++;
% }
% @@ -146,9 +155,10 @@
% struct sockaddr_in sin;
% char *dummy, *packet;
% - int s;
% + int bind_desired, connect_desired, s;
%
% - if (argc != 5)
% + if (argc != 7)
% usage();
%
% + gsin = &sin;
% bzero(&sin, sizeof(sin));
% sin.sin_len = sizeof(sin);
% @@ -176,4 +186,7 @@
% usage();
%
% + bind_desired = (strcmp(argv[5], "b") == 0);
% + connect_desired = (strcmp(argv[6], "c") == 0);
% +
% packet = malloc(payloadsize);
% if (packet == NULL) {
% @@ -189,7 +202,19 @@
% }
%
% - if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) {
% - perror("connect");
% - return (-1);
% + if (bind_desired) {
% + struct sockaddr_in osin;
% +
% + osin = sin;
% + if (inet_aton("0", &sin.sin_addr) == 0)
% + perror("inet_aton(0)");
% + if (bind(s, (struct sockaddr *)&sin, sizeof(sin)) < 0)
% + err(-1, "bind");
% + sin = osin;
% + }
% +
% + if (connect_desired) {
% + if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0)
% + err(-1, "connect");
% + gconnected = 1;
% }
%
This also fixes some bugs in usage() (bogus [] around non-optional args and
bogus exit code) and adds a sleep after send failure. Without the sleep,
netblast distorts the measurements by taking 100% CPU. This depends on
kernel queues having enough buffering to not run dry during the sleep
time (rounded up to a tick boundary). I use ifq_maxlen =
DRIVER_TX_RING_CNT + imax(2 * tick / 4, 1) = 10512 for DRIVER = bge
and HZ = 100. This is actually wrong now. The magic 2 is to round up to
a tick boundary and the magic 4 is for bge taking a minimum of 4 usec per
packet on old hadware, but bge actually takes about 1.5 usec on the test
hardware and I'd like it to take 0.66 usec. The queues rarely run dry in
practice, but running dry just a few times for a few msec each would
explain some anomalies. Old SGI ttcp uses a select timeout of 18 msec here.
nttcp and netsend use more sophisticated methods that don't work unless HZ
is too small. It's just impossible for a program to schedule its sleeps
with a fine enough resolution to ensure waking up before the queue runs
dry, unless HZ is too small or the queue is too large. select() for
writing doesn't work for the queue part of socket i/o.
Results:
~5.2 sendto (1): 630 kpps 98% CPU 11 cm/p (cache misses/packet (min))
-cur sendto: 590 kpps 100% CPU 10 cm/p (July 8 -current)
(2): no significant difference - see below
~5.2 send (3): 620 kpps 75% CPU 9.5 cm/p
-cur send:
Re: BPF problems on FreeBSD 7.0
Robin Sommer wrote: Hi all, we're seeing some strange effects with our libpcap-based application (the Bro network intrusion detection system) on a FreeBSD 7-RELEASE system. As the application has always been running fine on 6.x, we're wondering whether this might be triggered by any of the changes that went into 7. ... I'm wondering whether anybody here has seen something similar or might have an idea where to start looking for the cause. Any ideas? One place to start might be: netstat -B output in 7.x (I *think* this got MFCed), this will let us see what the drop count is for the Bro process, and what the flags are for the open BPF descriptors in the system. I'm not hot on current BPF internals, but I hazard a guess this is related to BPF descriptor buffering -- an area where there have been changes, some of which I've eyeballed. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's the deal with hardware checksum and net.inet.udp.checksum?
A, thanks, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
igb doesn't compile in STABLE?
Howdy, As of today, this afternoon, I see the following: linking kernel.debug e1000_api.o(.text+0xad9): In function `e1000_setup_init_funcs': ../../../dev/em/e1000_api.c:343: undefined reference to `e1000_init_function_pointers_80003es2lan' e1000_api.o(.text+0xae8):../../../dev/em/e1000_api.c:340: undefined reference to `e1000_init_function_pointers_82571' e1000_api.o(.text+0xafa):../../../dev/em/e1000_api.c:334: undefined reference to `e1000_init_function_pointers_82541' e1000_api.o(.text+0xb0c):../../../dev/em/e1000_api.c:328: undefined reference to `e1000_init_function_pointers_82540' e1000_api.o(.text+0xb1e):../../../dev/em/e1000_api.c:321: undefined reference to `e1000_init_function_pointers_82543' e1000_api.o(.text+0xb30):../../../dev/em/e1000_api.c:316: undefined reference to `e1000_init_function_pointers_82542' e1000_ich8lan.o(.text+0x98c): In function `e1000_valid_nvm_bank_detect_ich8lan': ../../../dev/em/e1000_ich8lan.c:1032: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xc32): In function `e1000_acquire_swflag_ich8lan': ../../../dev/em/e1000_ich8lan.c:424: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xc6e):../../../dev/em/e1000_ich8lan.c:426: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xc9d):../../../dev/em/e1000_ich8lan.c:422: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xced):../../../dev/em/e1000_ich8lan.c:436: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0x16bf):../../../dev/em/e1000_ich8lan.c:2700: more undefined references to `e1000_translate_register_82542' follow *** Error code 1 Thoughts? Later, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: igb doesn't compile in STABLE?
Just guessing, did someone change conf/files maybe?? Jack On Mon, Jul 14, 2008 at 2:44 PM, <[EMAIL PROTECTED]> wrote: > Howdy, > > As of today, this afternoon, I see the following: > > linking kernel.debug > e1000_api.o(.text+0xad9): In function `e1000_setup_init_funcs': > ../../../dev/em/e1000_api.c:343: undefined reference to > `e1000_init_function_pointers_80003es2lan' > e1000_api.o(.text+0xae8):../../../dev/em/e1000_api.c:340: undefined reference > to `e1000_init_function_pointers_82571' > e1000_api.o(.text+0xafa):../../../dev/em/e1000_api.c:334: undefined reference > to `e1000_init_function_pointers_82541' > e1000_api.o(.text+0xb0c):../../../dev/em/e1000_api.c:328: undefined reference > to `e1000_init_function_pointers_82540' > e1000_api.o(.text+0xb1e):../../../dev/em/e1000_api.c:321: undefined reference > to `e1000_init_function_pointers_82543' > e1000_api.o(.text+0xb30):../../../dev/em/e1000_api.c:316: undefined reference > to `e1000_init_function_pointers_82542' > e1000_ich8lan.o(.text+0x98c): In function > `e1000_valid_nvm_bank_detect_ich8lan': > ../../../dev/em/e1000_ich8lan.c:1032: undefined reference to > `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xc32): In function `e1000_acquire_swflag_ich8lan': > ../../../dev/em/e1000_ich8lan.c:424: undefined reference to > `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xc6e):../../../dev/em/e1000_ich8lan.c:426: undefined > reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xc9d):../../../dev/em/e1000_ich8lan.c:422: undefined > reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xced):../../../dev/em/e1000_ich8lan.c:436: undefined > reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0x16bf):../../../dev/em/e1000_ich8lan.c:2700: more > undefined references to `e1000_translate_register_82542' follow > *** Error code 1 > > > Thoughts? > > Later, > George > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
