From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 00:39:58 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4794B6 for ; Sun, 4 Nov 2012 00:39:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5F58FC14 for ; Sun, 4 Nov 2012 00:39:57 +0000 (UTC) Received: (qmail 37294 invoked from network); 4 Nov 2012 02:15:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Nov 2012 02:15:52 -0000 Message-ID: <5095B953.9060301@freebsd.org> Date: Sun, 04 Nov 2012 01:39:47 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Fabian Keil Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> In-Reply-To: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 00:39:59 -0000 Hello Fabian, thank you for the bug report. Please try the attached patch which should fix the issue you observed. -- Andre Index: tcp_input.c =================================================================== --- tcp_input.c (revision 242494) +++ tcp_input.c (working copy) @@ -2650,10 +2652,12 @@ SOCKBUF_LOCK(&so->so_snd); if (acked > so->so_snd.sb_cc) { + tp->snd_wnd -= so->so_snd.sb_cc; sbdrop_locked(&so->so_snd, (int)so->so_snd.sb_cc); ourfinisacked = 1; } else { sbdrop_locked(&so->so_snd, acked); + tp->snd_wnd -= acked; ourfinisacked = 0; } /* NB: sowwakeup_locked() does an implicit unlock. */ From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 02:40:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCCC3E93 for ; Sun, 4 Nov 2012 02:40:16 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id B35108FC0C for ; Sun, 4 Nov 2012 02:40:16 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id qA42eDqm044840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 19:40:14 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Proposal for changes to network device drivers and network stack (RFC) From: Marcel Moolenaar In-Reply-To: <570F1A37-38F0-41CF-91C7-B6047AA79E97@neville-neil.com> Date: Sat, 3 Nov 2012 19:40:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3465231B-CEC2-4FC1-92EF-95C535EFCBED@xcllnt.net> References: <570F1A37-38F0-41CF-91C7-B6047AA79E97@neville-neil.com> To: George Neville-Neil X-Mailer: Apple Mail (2.1499) Cc: "freebsd-net@freebsd.org" , Anuranjan Shukla X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 02:40:17 -0000 On Sep 5, 2012, at 1:16 PM, George Neville-Neil = wrote: > One more note. Can you break the patches down into more bite sized = pieces? They're hard > to review as is. Following up finally. Let's focus on the device driver interface. I renamed the interface implementation from mumble_ddi.h to if_device.[ch] and put a diff here: http://people.freebsd.org/~marcel/Juniper/if_device.diff To see how it's used and/or how it changes a device driver, look at a diff to if_em.c here: http://people.freebsd.org/~marcel/Juniper/if_em.diff Some notes: 1. Yes, there needs a license at the top. It's 2-clause BSD 2. The function pointers are macros right now. I think it's better to have an ops structure and a single function to set the ops than a bunch of accessors to set functions. 3. The code needs to be tidied up. What I'd like to see is a discussion on the functions themselves. They're the result of looking at a single driver (or maybe 2 drivers), and as such may not be perfectly generic or logical. As said before: we'd like to focus on an ABI-stable interface, but a one based on macros should also be possible. Sorry for the delay, --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 06:28:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2EF9735E for ; Sun, 4 Nov 2012 06:28:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 01AD78FC08 for ; Sun, 4 Nov 2012 06:28:57 +0000 (UTC) Received: from [10.0.1.30] (adsl-70-231-139-202.dsl.snfc21.sbcglobal.net [70.231.139.202]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id qA46SnXa051620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 23:28:50 -0700 (PDT) (envelope-from julian@elischer.org) References: <570F1A37-38F0-41CF-91C7-B6047AA79E97@neville-neil.com> <3465231B-CEC2-4FC1-92EF-95C535EFCBED@xcllnt.net> In-Reply-To: <3465231B-CEC2-4FC1-92EF-95C535EFCBED@xcllnt.net> Mime-Version: 1.0 (1.0) Message-Id: <24AEFB78-C46F-4837-81E1-01250CA8666E@elischer.org> X-Mailer: iPad Mail (9B206) From: Julian Main Subject: Re: Proposal for changes to network device drivers and network stack (RFC) Date: Sat, 3 Nov 2012 23:28:44 -0700 To: Marcel Moolenaar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Anuranjan Shukla X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 06:28:58 -0000 > > > I renamed the interface implementation from mumble_ddi.h to > if_device.[ch] and put a diff here: > http://people.freebsd.org/~marcel/Juniper/if_device.diff Looks reasonable to me. Gives some protection from API change But to really make use of this you could have driver specific methods... > > To see how it's used and/or how it changes a device driver, look > at a diff to if_em.c here: > http://people.freebsd.org/~marcel/Juniper/if_em.diff > > Some notes: > 1. Yes, there needs a license at the top. It's 2-clause BSD > 2. The function pointers are macros right now. I think it's > better to have an ops structure and a single function to > set the ops than a bunch of accessors to set functions. > 3. The code needs to be tidied up. > > What I'd like to see is a discussion on the functions themselves. > They're the result of looking at a single driver (or maybe 2 > drivers), and as such may not be perfectly generic or logical. > > As said before: we'd like to focus on an ABI-stable interface, > but a one based on macros should also be possible. > > Sorry for the delay, > > -- > Marcel Moolenaar > marcel@xcllnt.net > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 12:38:02 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A8C3EA2; Sun, 4 Nov 2012 12:38:02 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by mx1.freebsd.org (Postfix) with ESMTP id 358C58FC12; Sun, 4 Nov 2012 12:38:01 +0000 (UTC) Received: from [87.79.249.200] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TUzN2-0001Bs-BX; Sun, 04 Nov 2012 13:32:08 +0100 Date: Sun, 4 Nov 2012 13:29:57 +0100 From: Fabian Keil To: Andre Oppermann Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] Message-ID: <20121104132957.3965dc99@fabiankeil.de> In-Reply-To: <5095B953.9060301@freebsd.org> References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/U7yRATJNVg8ppN5zBQ6++t4"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:38:02 -0000 --Sig_/U7yRATJNVg8ppN5zBQ6++t4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > thank you for the bug report. Please try the attached patch > which should fix the issue you observed. Thanks for the patch, Andre. It seems to make the transfers 100% reliably again, but they are frequently very slow: fk@r500 ~ $i=3D1; while curl -o /dev/zero 'http://127.0.0.1:81/90k-file'; d= o echo $i; ((i=3D$i+1)); done % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 100 90000 100 90000 0 0 8670 0 0:00:10 0:00:10 --:--:-- 2= 057 1 % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 100 90000 100 90000 0 0 8821 0 0:00:10 0:00:10 --:--:-- 2= 057 2 % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 100 90000 100 90000 0 0 8821 0 0:00:10 0:00:10 --:--:-- 2= 057 3 % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 100 90000 100 90000 0 0 33.0M 0 --:--:-- --:--:-- --:--:-- 42= .9M 4 % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 100 90000 100 90000 0 0 32.5M 0 --:--:-- --:--:-- --:--:-- 85= .8M Looks like this is caused by occasional 5 second pauses between packets after the client's TCP window update: 13:04:40.424942 IP (tos 0x0, ttl 64, id 11449, offset 0, flags [DF], proto = TCP (6), length 60) 127.0.0.1.63441 > 127.0.0.1.81: Flags [S], seq 1083421426, win 65535, o= ptions [mss 16344,nop,wscale 6,sackOK,TS val 2526577688 ecr 0], length 0 13:04:40.425039 IP (tos 0x0, ttl 64, id 11450, offset 0, flags [DF], proto = TCP (6), length 60) 127.0.0.1.81 > 127.0.0.1.63441: Flags [S.], seq 1708634234, ack 1083421= 427, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 3536938095 ec= r 2526577688], length 0 13:04:40.425090 IP (tos 0x0, ttl 64, id 11451, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.63441 > 127.0.0.1.81: Flags [.], seq 1, ack 1, win 1275, opti= ons [nop,nop,TS val 2526577688 ecr 3536938095], length 0 13:04:40.425984 IP (tos 0x0, ttl 64, id 11452, offset 0, flags [DF], proto = TCP (6), length 205) 127.0.0.1.63441 > 127.0.0.1.81: Flags [P.], seq 1:154, ack 1, win 1275,= options [nop,nop,TS val 2526577689 ecr 3536938095], length 153 13:04:40.426320 IP (tos 0x0, ttl 64, id 11453, offset 0, flags [DF], proto = TCP (6), length 16384) 127.0.0.1.81 > 127.0.0.1.63441: Flags [.], seq 1:16333, ack 154, win 12= 75, options [nop,nop,TS val 3536938096 ecr 2526577689], length 16332 [...] 13:04:40.447030 IP (tos 0x0, ttl 64, id 11473, offset 0, flags [DF], proto = TCP (6), length 16384) 127.0.0.1.81 > 127.0.0.1.58989: Flags [.], seq 1:16333, ack 154, win 12= 75, options [nop,nop,TS val 831837815 ecr 2625389072], length 16332 13:04:40.447110 IP (tos 0x0, ttl 64, id 11474, offset 0, flags [DF], proto = TCP (6), length 16384) 127.0.0.1.81 > 127.0.0.1.58989: Flags [.], seq 16333:32665, ack 154, wi= n 1275, options [nop,nop,TS val 831837815 ecr 2625389072], length 16332 13:04:40.447152 IP (tos 0x0, ttl 64, id 11475, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.58989 > 127.0.0.1.81: Flags [.], seq 154, ack 32665, win 897,= options [nop,nop,TS val 2625389073 ecr 831837815], length 0 13:04:40.447222 IP (tos 0x0, ttl 64, id 11476, offset 0, flags [DF], proto = TCP (6), length 16384) 127.0.0.1.81 > 127.0.0.1.58989: Flags [P.], seq 32665:48997, ack 154, w= in 1275, options [nop,nop,TS val 831837815 ecr 2625389073], length 16332 13:04:40.447271 IP (tos 0x0, ttl 64, id 11477, offset 0, flags [DF], proto = TCP (6), length 16384) 127.0.0.1.81 > 127.0.0.1.58989: Flags [.], seq 48997:65329, ack 154, wi= n 1275, options [nop,nop,TS val 831837815 ecr 2625389073], length 16332 13:04:40.447333 IP (tos 0x0, ttl 64, id 11478, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.58989 > 127.0.0.1.81: Flags [.], seq 154, ack 65329, win 511,= options [nop,nop,TS val 2625389074 ecr 831837815], length 0 13:04:40.447597 IP (tos 0x0, ttl 64, id 11479, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.58989 > 127.0.0.1.81: Flags [.], seq 154, ack 65329, win 1023= , options [nop,nop,TS val 2625389074 ecr 831837815], length 0 13:04:45.447389 IP (tos 0x0, ttl 64, id 11481, offset 0, flags [DF], proto = TCP (6), length 16324) 127.0.0.1.81 > 127.0.0.1.58989: Flags [.], seq 65329:81601, ack 154, wi= n 1275, options [nop,nop,TS val 831842816 ecr 2625389074], length 16272 13:04:45.547335 IP (tos 0x0, ttl 64, id 11482, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.58989 > 127.0.0.1.81: Flags [.], seq 154, ack 81601, win 1275= , options [nop,nop,TS val 2625394174 ecr 831842816], length 0 13:04:50.547368 IP (tos 0x0, ttl 64, id 11483, offset 0, flags [DF], proto = TCP (6), length 53) 127.0.0.1.81 > 127.0.0.1.58989: Flags [.], seq 81601:81602, ack 154, wi= n 1275, options [nop,nop,TS val 831847916 ecr 2625394174], length 1 13:04:50.647331 IP (tos 0x0, ttl 64, id 11484, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.58989 > 127.0.0.1.81: Flags [.], seq 154, ack 81602, win 1275= , options [nop,nop,TS val 2625399274 ecr 831847916], length 0 13:04:50.647389 IP (tos 0x0, ttl 64, id 11485, offset 0, flags [DF], proto = TCP (6), length 8691) 127.0.0.1.81 > 127.0.0.1.58989: Flags [P.], seq 81602:90241, ack 154, w= in 1275, options [nop,nop,TS val 831848016 ecr 2625399274], length 8639 13:04:50.647859 IP (tos 0x0, ttl 64, id 11486, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.58989 > 127.0.0.1.81: Flags [F.], seq 154, ack 90241, win 127= 5, options [nop,nop,TS val 2625399274 ecr 831848016], length 0 13:04:50.647916 IP (tos 0x0, ttl 64, id 11487, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.81 > 127.0.0.1.58989: Flags [.], seq 90241, ack 155, win 1275= , options [nop,nop,TS val 831848016 ecr 2625399274], length 0 13:04:50.648018 IP (tos 0x0, ttl 64, id 11488, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.81 > 127.0.0.1.58989: Flags [F.], seq 90241, ack 155, win 127= 5, options [nop,nop,TS val 831848016 ecr 2625399274], length 0 13:04:50.648078 IP (tos 0x0, ttl 64, id 11489, offset 0, flags [DF], proto = TCP (6), length 52) 127.0.0.1.58989 > 127.0.0.1.81: Flags [.], seq 155, ack 90242, win 1275= , options [nop,nop,TS val 2625399274 ecr 831848016], length 0 Fabian --Sig_/U7yRATJNVg8ppN5zBQ6++t4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCWX8gACgkQBYqIVf93VJ3YpACdEtIYqj3buLuaMK4PkGl24Qes 3g0AmgNgbgvbgiClielh755bSR7P3OLE =RN8o -----END PGP SIGNATURE----- --Sig_/U7yRATJNVg8ppN5zBQ6++t4-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 19:49:34 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7625B217 for ; Sun, 4 Nov 2012 19:49:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CC65C8FC0A for ; Sun, 4 Nov 2012 19:49:33 +0000 (UTC) Received: (qmail 42163 invoked from network); 4 Nov 2012 21:25:19 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Nov 2012 21:25:19 -0000 Message-ID: <5096C6CA.4090306@freebsd.org> Date: Sun, 04 Nov 2012 20:49:30 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Fabian Keil , null@pozo.com Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> In-Reply-To: <20121104132957.3965dc99@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:49:34 -0000 On 04.11.2012 13:29, Fabian Keil wrote: > Andre Oppermann wrote: > >> thank you for the bug report. Please try the attached patch >> which should fix the issue you observed. > > Thanks for the patch, Andre. > > It seems to make the transfers 100% reliably again, > but they are frequently very slow: > > fk@r500 ~ $i=1; while curl -o /dev/zero 'http://127.0.0.1:81/90k-file'; do echo $i; ((i=$i+1)); done > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 8670 0 0:00:10 0:00:10 --:--:-- 2057 > 1 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 8821 0 0:00:10 0:00:10 --:--:-- 2057 > 2 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 8821 0 0:00:10 0:00:10 --:--:-- 2057 > 3 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 33.0M 0 --:--:-- --:--:-- --:--:-- 42.9M > 4 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 32.5M 0 --:--:-- --:--:-- --:--:-- 85.8M > > Looks like this is caused by occasional 5 second pauses > between packets after the client's TCP window update: Fabian, Manfred, The patch I sent was not correct. Please try this new attached patch instead. -- Andre Index: netinet/tcp_output.c =================================================================== --- netinet/tcp_output.c (revision 242577) +++ netinet/tcp_output.c (working copy) @@ -228,7 +228,7 @@ tso = 0; mtu = 0; off = tp->snd_nxt - tp->snd_una; - sendwin = min(tp->snd_wnd, tp->snd_cwnd); + sendwin = ulmax(ulmin(tp->snd_wnd - off, tp->snd_cwnd), 0); flags = tcp_outflags[tp->t_state]; /* @@ -249,7 +249,7 @@ (p = tcp_sack_output(tp, &sack_bytes_rxmt))) { long cwin; - cwin = min(tp->snd_wnd, tp->snd_cwnd) - sack_bytes_rxmt; + cwin = ulmin(tp->snd_wnd - off, tp->snd_cwnd) - sack_bytes_rxmt; if (cwin < 0) cwin = 0; /* Do not retransmit SACK segments beyond snd_recover */ @@ -355,7 +355,7 @@ * sending new data, having retransmitted all the * data possible in the scoreboard. */ - len = ((long)ulmin(so->so_snd.sb_cc, tp->snd_wnd) + len = ((long)ulmin(so->so_snd.sb_cc, tp->snd_wnd - off) - off); /* * Don't remove this (len > 0) check ! From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 21:55:31 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E73C3705; Sun, 4 Nov 2012 21:55:31 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by mx1.freebsd.org (Postfix) with ESMTP id 56C208FC0C; Sun, 4 Nov 2012 21:55:30 +0000 (UTC) Received: from [78.35.133.171] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TV89c-0008EY-Qx; Sun, 04 Nov 2012 22:54:52 +0100 Date: Sun, 4 Nov 2012 22:52:26 +0100 From: Fabian Keil To: Andre Oppermann Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] Message-ID: <20121104225226.500507a3@fabiankeil.de> In-Reply-To: <5096C6CA.4090306@freebsd.org> References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> <5096C6CA.4090306@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ImanUpxKjV_MSJJzuDjb3mG"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-net@FreeBSD.org, null@pozo.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 21:55:32 -0000 --Sig_/ImanUpxKjV_MSJJzuDjb3mG Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > On 04.11.2012 13:29, Fabian Keil wrote: > > Andre Oppermann wrote: > > > >> thank you for the bug report. Please try the attached patch > >> which should fix the issue you observed. > > > > Thanks for the patch, Andre. > > > > It seems to make the transfers 100% reliably again, > > but they are frequently very slow: =20 > The patch I sent was not correct. Please try this new attached patch > instead. This seems to fix the issue for connections between curl and gatling, I'm still frequently seeing problems with curl and Privoxy, though: fk@r500 ~ $echo $http_proxy http://10.0.0.1:8118/ fk@r500 ~ $i=3D1; while curl -o /dev/zero 'http://127.0.0.1:81/90k-file'; d= o echo $i; ((i=3D$i+1)); done % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 100 90000 100 90000 0 0 364k 0 --:--:-- --:--:-- --:--:-- 3= 66k 1 % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 100 90000 100 90000 0 0 799k 0 --:--:-- --:--:-- --:--:-- 8= 06k 2 % Total % Received % Xferd Average Speed Time Time Time Cur= rent Dload Upload Total Spent Left Spe= ed 99 90000 99 89742 0 0 363k 0 --:--:-- --:--:-- --:--:-- 3= 65k curl: (18) transfer closed with 258 bytes remaining to read In this cases Privoxy wrote most of the response body in chunks of 4999 bytes, near the end of the transfer write() returned -1: 22:34:01.342943 IP (tos 0x0, ttl 64, id 31042, offset 0, flags [DF], proto = TCP (6), length 60) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [S], seq 815402461, win 65535, op= tions [mss 16344,nop,wscale 6,sackOK,TS val 1684019208 ecr 0], length 0 22:34:01.343041 IP (tos 0x0, ttl 64, id 31043, offset 0, flags [DF], proto = TCP (6), length 60) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [S.], seq 4122285051, ack 8154024= 62, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 3752298629 ecr= 1684019208], length 0 22:34:01.343093 IP (tos 0x0, ttl 64, id 31044, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 1, ack 1, win 1275, opti= ons [nop,nop,TS val 1684019208 ecr 3752298629], length 0 22:34:01.343970 IP (tos 0x0, ttl 64, id 31045, offset 0, flags [DF], proto = TCP (6), length 254) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [P.], seq 1:203, ack 1, win 1275,= options [nop,nop,TS val 1684019209 ecr 3752298629], length 202 22:34:01.353719 IP (tos 0x0, ttl 64, id 31057, offset 0, flags [DF], proto = TCP (6), length 322) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [P.], seq 1:271, ack 203, win 127= 5, options [nop,nop,TS val 3752298640 ecr 1684019209], length 270 22:34:01.353883 IP (tos 0x0, ttl 64, id 31058, offset 0, flags [DF], proto = TCP (6), length 16384) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 271:16603, ack 203, win = 1275, options [nop,nop,TS val 3752298640 ecr 1684019209], length 16332 22:34:01.353925 IP (tos 0x0, ttl 64, id 31059, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 16603, win 1020= , options [nop,nop,TS val 1684019219 ecr 3752298640], length 0 22:34:01.353983 IP (tos 0x0, ttl 64, id 31060, offset 0, flags [DF], proto = TCP (6), length 3476) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [P.], seq 16603:20027, ack 203, w= in 1275, options [nop,nop,TS val 3752298640 ecr 1684019219], length 3424 22:34:01.354103 IP (tos 0x0, ttl 64, id 31062, offset 0, flags [DF], proto = TCP (6), length 16384) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 20027:36359, ack 203, wi= n 1275, options [nop,nop,TS val 3752298640 ecr 1684019219], length 16332 22:34:01.354168 IP (tos 0x0, ttl 64, id 31064, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 36359, win 712,= options [nop,nop,TS val 1684019220 ecr 3752298640], length 0 22:34:01.354207 IP (tos 0x0, ttl 64, id 31065, offset 0, flags [DF], proto = TCP (6), length 8715) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [P.], seq 36359:45022, ack 203, w= in 1275, options [nop,nop,TS val 3752298641 ecr 1684019220], length 8663 22:34:01.354299 IP (tos 0x0, ttl 64, id 31066, offset 0, flags [DF], proto = TCP (6), length 16384) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 45022:61354, ack 203, wi= n 1275, options [nop,nop,TS val 3752298641 ecr 1684019220], length 16332 22:34:01.354346 IP (tos 0x0, ttl 64, id 31067, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 61354, win 321,= options [nop,nop,TS val 1684019220 ecr 3752298641], length 0 22:34:01.354378 IP (tos 0x0, ttl 64, id 31069, offset 0, flags [DF], proto = TCP (6), length 8715) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [P.], seq 61354:70017, ack 203, w= in 1275, options [nop,nop,TS val 3752298641 ecr 1684019220], length 8663 22:34:01.354710 IP (tos 0x0, ttl 64, id 31071, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 70017, win 698,= options [nop,nop,TS val 1684019220 ecr 3752298641], length 0 22:34:01.354825 IP (tos 0x0, ttl 64, id 31073, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 70017, win 1210= , options [nop,nop,TS val 1684019220 ecr 3752298641], length 0 22:34:01.355049 IP (tos 0x0, ttl 64, id 31075, offset 0, flags [DF], proto = TCP (6), length 3716) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [FP.], seq 86349:90013, ack 203, = win 1275, options [nop,nop,TS val 3752298641 ecr 1684019220], length 3664 22:34:01.355107 IP (tos 0x0, ttl 64, id 31076, offset 0, flags [DF], proto = TCP (6), length 64) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 70017, win 1275= , options [nop,nop,TS val 1684019220 ecr 3752298641,nop,nop,sack 1 {86349:9= 0013}], length 0 22:34:01.588185 IP (tos 0x0, ttl 64, id 31079, offset 0, flags [DF], proto = TCP (6), length 16384) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 70017:86349, ack 203, wi= n 1275, options [nop,nop,TS val 3752298875 ecr 1684019220], length 16332 22:34:01.588268 IP (tos 0x0, ttl 64, id 31080, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 90014, win 963,= options [nop,nop,TS val 1684019454 ecr 3752298875], length 0 22:34:01.588946 IP (tos 0x0, ttl 64, id 31081, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [F.], seq 203, ack 90014, win 127= 5, options [nop,nop,TS val 1684019454 ecr 3752298875], length 0 22:34:01.588999 IP (tos 0x0, ttl 64, id 31082, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 90014, ack 204, win 1275= , options [nop,nop,TS val 3752298875 ecr 1684019454], length 0 Most of the time the failures aren't logged by the kernel, but occasionally they result in messages like these: Nov 4 22:44:15 r500 kernel: [1431] TCP: [10.0.0.1]:81 to [10.0.0.1]:10946 = tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of = data after socket was closed, sending RST and removing tcpcb Nov 4 22:44:29 r500 kernel: [1445] TCP: [10.0.0.1]:81 to [10.0.0.1]:45803 = tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of = data after socket was closed, sending RST and removing tcpcb Nov 4 22:45:52 r500 kernel: [1527] TCP: [10.0.0.1]:81 to [10.0.0.1]:30760 = tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of = data after socket was closed, sending RST and removing tcpcb Nov 4 22:45:55 r500 kernel: [1531] TCP: [10.0.0.1]:81 to [10.0.0.1]:62527 = tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of = data after socket was closed, sending RST and removing tcpcb Nov 4 22:45:58 r500 kernel: [1534] TCP: [10.0.0.1]:81 to [10.0.0.1]:45876 = tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of = data after socket was closed, sending RST and removing tcpcb Fabian --Sig_/ImanUpxKjV_MSJJzuDjb3mG Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCW450ACgkQBYqIVf93VJ0kqwCgjnlcy+Hf0KPOIO/zSeRzStHh r3UAoJDFKd7mGqfw1QqaBq90Dc+IzBnY =0Opv -----END PGP SIGNATURE----- --Sig_/ImanUpxKjV_MSJJzuDjb3mG-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 22:15:29 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB4172E1 for ; Sun, 4 Nov 2012 22:15:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 00EF78FC08 for ; Sun, 4 Nov 2012 22:15:28 +0000 (UTC) Received: (qmail 43158 invoked from network); 4 Nov 2012 23:51:13 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Nov 2012 23:51:13 -0000 Message-ID: <5096E8FD.6040103@freebsd.org> Date: Sun, 04 Nov 2012 23:15:25 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Fabian Keil Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> <5096C6CA.4090306@freebsd.org> <20121104225226.500507a3@fabiankeil.de> In-Reply-To: <20121104225226.500507a3@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, null@pozo.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 22:15:30 -0000 On 04.11.2012 22:52, Fabian Keil wrote: > Andre Oppermann wrote: > >> On 04.11.2012 13:29, Fabian Keil wrote: >>> Andre Oppermann wrote: >>> >>>> thank you for the bug report. Please try the attached patch >>>> which should fix the issue you observed. >>> >>> Thanks for the patch, Andre. >>> >>> It seems to make the transfers 100% reliably again, >>> but they are frequently very slow: > >> The patch I sent was not correct. Please try this new attached patch >> instead. > > This seems to fix the issue for connections between curl and gatling, That's good. > I'm still frequently seeing problems with curl and Privoxy, though: > > fk@r500 ~ $echo $http_proxy > http://10.0.0.1:8118/ > fk@r500 ~ $i=1; while curl -o /dev/zero 'http://127.0.0.1:81/90k-file'; do echo $i; ((i=$i+1)); done > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 364k 0 --:--:-- --:--:-- --:--:-- 366k > 1 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 799k 0 --:--:-- --:--:-- --:--:-- 806k > 2 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 99 90000 99 89742 0 0 363k 0 --:--:-- --:--:-- --:--:-- 365k > curl: (18) transfer closed with 258 bytes remaining to read This message from curl points to a problem in the interaction between the server and curl. See this description: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572276 So unless you can rule out a curl/privoxy interop issue and with gatling it is working reliably we can assume this particular TCP problem to be fixed. Here on my test machine with nginx it works realiably as well again. There is an interesting edge case with socket buffer autoscaling on loopback but that is neither fatal nor related to this problem. > In this cases Privoxy wrote most of the response body in chunks of > 4999 bytes, near the end of the transfer write() returned -1: The write returns -1 because the client (curl) has closed the socket and the last write can be accepted anymore. Curl has prematurely closed the connection. -snip- > Most of the time the failures aren't logged by the kernel, > but occasionally they result in messages like these: > > Nov 4 22:44:15 r500 kernel: [1431] TCP: [10.0.0.1]:81 to [10.0.0.1]:10946 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of data after socket was closed, sending RST and removing tcpcb > Nov 4 22:44:29 r500 kernel: [1445] TCP: [10.0.0.1]:81 to [10.0.0.1]:45803 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of data after socket was closed, sending RST and removing tcpcb > Nov 4 22:45:52 r500 kernel: [1527] TCP: [10.0.0.1]:81 to [10.0.0.1]:30760 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of data after socket was closed, sending RST and removing tcpcb > Nov 4 22:45:55 r500 kernel: [1531] TCP: [10.0.0.1]:81 to [10.0.0.1]:62527 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of data after socket was closed, sending RST and removing tcpcb > Nov 4 22:45:58 r500 kernel: [1534] TCP: [10.0.0.1]:81 to [10.0.0.1]:45876 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 284 bytes of data after socket was closed, sending RST and removing tcpcb When the socket was abruptly closed by the client and the server still had data in flight you're going to see this message. This is normal and expected. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 23:29:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46318412; Sun, 4 Nov 2012 23:29:48 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by mx1.freebsd.org (Postfix) with ESMTP id C201D8FC0C; Sun, 4 Nov 2012 23:29:47 +0000 (UTC) Received: from [78.35.133.171] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TV9aN-0007kB-G8; Mon, 05 Nov 2012 00:26:35 +0100 Date: Mon, 5 Nov 2012 00:25:09 +0100 From: Fabian Keil To: freebsd-net@freebsd.org Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] Message-ID: <20121105002509.670ca1fc@fabiankeil.de> In-Reply-To: <5096E8FD.6040103@freebsd.org> References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> <5096C6CA.4090306@freebsd.org> <20121104225226.500507a3@fabiankeil.de> <5096E8FD.6040103@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/IKc=8VdyEr.Gdqlw91yR=sN"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: Andre Oppermann X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 23:29:48 -0000 --Sig_/IKc=8VdyEr.Gdqlw91yR=sN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > On 04.11.2012 22:52, Fabian Keil wrote: > > Andre Oppermann wrote: > >> The patch I sent was not correct. Please try this new attached patch > >> instead. > > > > This seems to fix the issue for connections between curl and gatling, >=20 > That's good. >=20 > > I'm still frequently seeing problems with curl and Privoxy, though: > > > > fk@r500 ~ $echo $http_proxy > > http://10.0.0.1:8118/ > > fk@r500 ~ $i=3D1; while curl -o /dev/zero 'http://127.0.0.1:81/90k-file= '; do echo $i; ((i=3D$i+1)); done > > % Total % Received % Xferd Average Speed Time Time Time= Current > > Dload Upload Total Spent Left= Speed > > 100 90000 100 90000 0 0 364k 0 --:--:-- --:--:-- --:--:-= - 366k > > 1 > > % Total % Received % Xferd Average Speed Time Time Time= Current > > Dload Upload Total Spent Left= Speed > > 100 90000 100 90000 0 0 799k 0 --:--:-- --:--:-- --:--:-= - 806k > > 2 > > % Total % Received % Xferd Average Speed Time Time Time= Current > > Dload Upload Total Spent Left= Speed > > 99 90000 99 89742 0 0 363k 0 --:--:-- --:--:-- --:--:= -- 365k > > curl: (18) transfer closed with 258 bytes remaining to read >=20 > This message from curl points to a problem in the interaction between the > server and curl. See this description: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D572276 > > So unless you can rule out a curl/privoxy interop issue and with gatling = it > is working reliably we can assume this particular TCP problem to be fixed. > > Here on my test machine with nginx it works realiably as well again. The= re > is an interesting edge case with socket buffer autoscaling on loopback but > that is neither fatal nor related to this problem. Sorry, my description was a bit misleading. I didn't mean that Privoxy is generating HTTP chunks (in which case the Debian bug might apply), but that it uses one write() call per ~4999 bytes of data. I work on Privoxy upstream, the regression tests rely on curl and there weren't any (known) compatibility issues before r242262. In the above setup, Privoxy is acting as proxy between curl and gatling and just passes on the received data in a read/write loop. If I let curl request a document Privoxy serves itself and thus can send it with a single write() call, the problem happens a lot less often. Probably your nginx setup is closer to this scenario. Maybe you can reproduce the problem by running two nginx instances and letting the first one act as a proxy before the second one. > > In this cases Privoxy wrote most of the response body in chunks of > > 4999 bytes, near the end of the transfer write() returned -1: >=20 > The write returns -1 because the client (curl) has closed the socket and > the last write can be accepted anymore. Curl has prematurely closed the > connection. The tcpdump from my previous message seems to show that the server side is closing the connection: 22:34:01.355049 IP (tos 0x0, ttl 64, id 31075, offset 0, flags [DF], proto = TCP (6), length 3716) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [FP.], seq 86349:90013, ack 203, = win 1275, options [nop,nop,TS val 3752298641 ecr 1684019220], length 3664 22:34:01.355107 IP (tos 0x0, ttl 64, id 31076, offset 0, flags [DF], proto = TCP (6), length 64) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 70017, win 1275= , options [nop,nop,TS val 1684019220 ecr 3752298641,nop,nop,sack 1 {86349:9= 0013}], length 0 22:34:01.588185 IP (tos 0x0, ttl 64, id 31079, offset 0, flags [DF], proto = TCP (6), length 16384) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 70017:86349, ack 203, wi= n 1275, options [nop,nop,TS val 3752298875 ecr 1684019220], length 16332 22:34:01.588268 IP (tos 0x0, ttl 64, id 31080, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 90014, win 963,= options [nop,nop,TS val 1684019454 ecr 3752298875], length 0 22:34:01.588946 IP (tos 0x0, ttl 64, id 31081, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.55930 > 10.0.0.1.8118: Flags [F.], seq 203, ack 90014, win 127= 5, options [nop,nop,TS val 1684019454 ecr 3752298875], length 0 22:34:01.588999 IP (tos 0x0, ttl 64, id 31082, offset 0, flags [DF], proto = TCP (6), length 52) 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 90014, ack 204, win 1275= , options [nop,nop,TS val 3752298875 ecr 1684019454], length 0 Fabian --Sig_/IKc=8VdyEr.Gdqlw91yR=sN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCW+VcACgkQBYqIVf93VJ2EKwCgjnfj2G7zAvZ7ZpkayhUwrfFS DZQAn07KHE4grEQ21fi0oxfakejvt53F =l61E -----END PGP SIGNATURE----- --Sig_/IKc=8VdyEr.Gdqlw91yR=sN-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 00:02:00 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE7B6773 for ; Mon, 5 Nov 2012 00:02:00 +0000 (UTC) (envelope-from apache@vvps-542115.dailyvps.co.uk) Received: from vvps-542115.dailyvps.co.uk (vvps-542115.dailyvps.co.uk [195.234.11.180]) by mx1.freebsd.org (Postfix) with ESMTP id AFB6F8FC0A for ; Mon, 5 Nov 2012 00:02:00 +0000 (UTC) Received: from vvps-542115.dailyvps.co.uk (localhost.localdomain [127.0.0.1]) by vvps-542115.dailyvps.co.uk (Postfix) with ESMTP id 9507659EC0FC for ; Sun, 4 Nov 2012 23:30:18 +0000 (GMT) Received: by vvps-542115.dailyvps.co.uk (Postfix, from userid 48) id 0931659ECEF8; Sun, 4 Nov 2012 23:29:48 +0000 (GMT) To: net@freebsd.org Subject: account notice From: ANZ Online Banking Message-Id: <20121104232948.0931659ECEF8@vvps-542115.dailyvps.co.uk> Date: Sun, 4 Nov 2012 23:29:48 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 00:02:01 -0000 Please note that we have made new and important changes to your ANZ Bank account. [1]Login to view new updates. References 1. http://www.sopromat.info/img/www.anz.com/nz/inetbanking/bankmain.html From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 02:38:12 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A48B8E3A; Mon, 5 Nov 2012 02:38:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 725238FC08; Mon, 5 Nov 2012 02:38:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA52cCv0056761; Mon, 5 Nov 2012 02:38:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA52cCbU056757; Mon, 5 Nov 2012 02:38:12 GMT (envelope-from linimon) Date: Mon, 5 Nov 2012 02:38:12 GMT Message-Id: <201211050238.qA52cCbU056757@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173004: [netinet] [patch] Incorrect IP checksums when forwarding results in fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 02:38:12 -0000 Old Synopsis: Incorrect IP checksums when forwarding results in fragmentation New Synopsis: [netinet] [patch] Incorrect IP checksums when forwarding results in fragmentation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 5 02:37:38 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173004 From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 08:11:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70659CCD for ; Mon, 5 Nov 2012 08:11:20 +0000 (UTC) (envelope-from tommy@anakin.ws) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id D831A8FC0A for ; Mon, 5 Nov 2012 08:11:19 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so4950853lbd.13 for ; Mon, 05 Nov 2012 00:11:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-gm-message-state; bh=C14I1HOeVmJO9BgYNT2bOU68bNpPDC8CjfPL1uf6mXQ=; b=SZhnboi7/yj31VztdcFPoE/EgPxfHuzF4xgToP0qDzVGpMUVM4Bxk3P/gEcuL0FmfA S4NiYZ2fzWbYCKOpRm02SJX4uT8aB+aH5a8MXBr7X6Bw5neNiflMii7DXNvFe/Sb1xXa fzJnIUCnXX7+15oZqb4z78awrluBL13apo7etVyxOwlmIPqet65zT5guhyF6HhXyAUB2 FnOdlOiNrRUwAJ9maUa9ad2qPkNkIAgOW5nOt8/HZXwZHBlIRuDaI3IqHUZxFkWzeMlJ Hdo+h2AayUmtJtqPDEeHgYxUdt9wNCRpll/aEIWgVypkvgt8//WMUfU5uaQxeW9wlMgH a1xw== Received: by 10.112.25.42 with SMTP id z10mr3629325lbf.103.1352103078169; Mon, 05 Nov 2012 00:11:18 -0800 (PST) Received: from [130.225.71.10] (pctsal.imm.dtu.dk. [130.225.71.10]) by mx.google.com with ESMTPS id sy1sm5305398lab.16.2012.11.05.00.11.16 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 00:11:17 -0800 (PST) Message-ID: <509774FF.2030904@anakin.ws> Date: Mon, 05 Nov 2012 09:12:47 +0100 From: =?ISO-8859-1?Q?Tommy_Sonne_Alstr=F8m?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-bugs@freebsd.org, freebsd-net@freebsd.org Subject: Fwd: Re: amd64/173235: Have received two crashes within 1 day after installing new packages: Fatal trap 12: page fault in kernel mode References: <5093BF1A.5080706@FreeBSD.org> In-Reply-To: <5093BF1A.5080706@FreeBSD.org> X-Forwarded-Message-Id: <5093BF1A.5080706@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmJQPXi/7zGvZj0y+mhXlw0kY4jfQ5a4Gp93pM/cuuTroe83yz2y0y1Q53Pkgg/8oRgfkzg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 08:11:20 -0000 Hello all, I've submitted bug report accidentally in the wrong category: http://www.freebsd.org/cgi/query-pr.cgi?pr=173235 So I was adviced to send a note here. Basically I had 2 Fatal trap 12: page fault in kernel mode last week: 1st) current process = 1192 (smbiod1) 2nd) current process = 1068 (named) I have the core dump files as well, but they are quite big so I don't know how to post them. I could put them on my webserver if some is interested in debugging. Best Regards Tommy From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 09:18:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A1C0B4C for ; Mon, 5 Nov 2012 09:18:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0876F8FC19 for ; Mon, 5 Nov 2012 09:18:36 +0000 (UTC) Received: (qmail 80227 invoked from network); 5 Nov 2012 10:54:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Nov 2012 10:54:17 -0000 Message-ID: <50978469.8000001@freebsd.org> Date: Mon, 05 Nov 2012 10:18:33 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Fabian Keil Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> <5096C6CA.4090306@freebsd.org> <20121104225226.500507a3@fabiankeil.de> <5096E8FD.6040103@freebsd.org> <20121105002509.670ca1fc@fabiankeil.de> In-Reply-To: <20121105002509.670ca1fc@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 09:18:38 -0000 On 05.11.2012 00:25, Fabian Keil wrote: > Andre Oppermann wrote: > >> On 04.11.2012 22:52, Fabian Keil wrote: >>> Andre Oppermann wrote: > >>>> The patch I sent was not correct. Please try this new attached patch >>>> instead. >>> >>> This seems to fix the issue for connections between curl and gatling, >> >> That's good. >> >>> I'm still frequently seeing problems with curl and Privoxy, though: >>> >>> fk@r500 ~ $echo $http_proxy >>> http://10.0.0.1:8118/ >>> fk@r500 ~ $i=1; while curl -o /dev/zero 'http://127.0.0.1:81/90k-file'; do echo $i; ((i=$i+1)); done >>> % Total % Received % Xferd Average Speed Time Time Time Current >>> Dload Upload Total Spent Left Speed >>> 100 90000 100 90000 0 0 364k 0 --:--:-- --:--:-- --:--:-- 366k >>> 1 >>> % Total % Received % Xferd Average Speed Time Time Time Current >>> Dload Upload Total Spent Left Speed >>> 100 90000 100 90000 0 0 799k 0 --:--:-- --:--:-- --:--:-- 806k >>> 2 >>> % Total % Received % Xferd Average Speed Time Time Time Current >>> Dload Upload Total Spent Left Speed >>> 99 90000 99 89742 0 0 363k 0 --:--:-- --:--:-- --:--:-- 365k >>> curl: (18) transfer closed with 258 bytes remaining to read >> >> This message from curl points to a problem in the interaction between the >> server and curl. See this description: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572276 >> >> So unless you can rule out a curl/privoxy interop issue and with gatling it >> is working reliably we can assume this particular TCP problem to be fixed. >> >> Here on my test machine with nginx it works realiably as well again. There >> is an interesting edge case with socket buffer autoscaling on loopback but >> that is neither fatal nor related to this problem. > > Sorry, my description was a bit misleading. I didn't mean that Privoxy is > generating HTTP chunks (in which case the Debian bug might apply), > but that it uses one write() call per ~4999 bytes of data. > > I work on Privoxy upstream, the regression tests rely on curl and > there weren't any (known) compatibility issues before r242262. > > In the above setup, Privoxy is acting as proxy between curl and gatling > and just passes on the received data in a read/write loop. > > If I let curl request a document Privoxy serves itself and thus can > send it with a single write() call, the problem happens a lot less > often. > > Probably your nginx setup is closer to this scenario. Maybe you can > reproduce the problem by running two nginx instances and letting > the first one act as a proxy before the second one. > >>> In this cases Privoxy wrote most of the response body in chunks of >>> 4999 bytes, near the end of the transfer write() returned -1: >> >> The write returns -1 because the client (curl) has closed the socket and >> the last write can be accepted anymore. Curl has prematurely closed the >> connection. > > The tcpdump from my previous message seems to show that the server > side is closing the connection: > > 22:34:01.355049 IP (tos 0x0, ttl 64, id 31075, offset 0, flags [DF], proto TCP (6), length 3716) > 10.0.0.1.8118 > 10.0.0.1.55930: Flags [FP.], seq 86349:90013, ack 203, win 1275, options [nop,nop,TS val 3752298641 ecr 1684019220], length 3664 > 22:34:01.355107 IP (tos 0x0, ttl 64, id 31076, offset 0, flags [DF], proto TCP (6), length 64) > 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 70017, win 1275, options [nop,nop,TS val 1684019220 ecr 3752298641,nop,nop,sack 1 {86349:90013}], length 0 > 22:34:01.588185 IP (tos 0x0, ttl 64, id 31079, offset 0, flags [DF], proto TCP (6), length 16384) > 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 70017:86349, ack 203, win 1275, options [nop,nop,TS val 3752298875 ecr 1684019220], length 16332 > 22:34:01.588268 IP (tos 0x0, ttl 64, id 31080, offset 0, flags [DF], proto TCP (6), length 52) > 10.0.0.1.55930 > 10.0.0.1.8118: Flags [.], seq 203, ack 90014, win 963, options [nop,nop,TS val 1684019454 ecr 3752298875], length 0 > 22:34:01.588946 IP (tos 0x0, ttl 64, id 31081, offset 0, flags [DF], proto TCP (6), length 52) > 10.0.0.1.55930 > 10.0.0.1.8118: Flags [F.], seq 203, ack 90014, win 1275, options [nop,nop,TS val 1684019454 ecr 3752298875], length 0 > 22:34:01.588999 IP (tos 0x0, ttl 64, id 31082, offset 0, flags [DF], proto TCP (6), length 52) > 10.0.0.1.8118 > 10.0.0.1.55930: Flags [.], seq 90014, ack 204, win 1275, options [nop,nop,TS val 3752298875 ecr 1684019454], length 0 Thank you for the detailed report and testing. I've backed out the change with r242601 as it exhibits still too many problems. I'll fix these problems in the next days but in the mean time HEAD should be in a working state. I'll be grateful if I could send you the fixed change for testing before it goes into HEAD again. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 10:56:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BE83998; Mon, 5 Nov 2012 10:56:15 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by mx1.freebsd.org (Postfix) with ESMTP id B62CA8FC12; Mon, 5 Nov 2012 10:56:13 +0000 (UTC) Received: from [87.79.249.197] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TVKL0-00009s-RG; Mon, 05 Nov 2012 11:55:26 +0100 Date: Mon, 5 Nov 2012 11:09:28 +0100 From: Fabian Keil To: Andre Oppermann Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] Message-ID: <20121105110928.480a68b3@fabiankeil.de> In-Reply-To: <50978469.8000001@freebsd.org> References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> <5096C6CA.4090306@freebsd.org> <20121104225226.500507a3@fabiankeil.de> <5096E8FD.6040103@freebsd.org> <20121105002509.670ca1fc@fabiankeil.de> <50978469.8000001@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Zn2dnb/_YkbxfG/gC/nWDut"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 10:56:15 -0000 --Sig_/Zn2dnb/_YkbxfG/gC/nWDut Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > I've backed out the change with r242601 as it exhibits still too > many problems. I'll fix these problems in the next days but in > the mean time HEAD should be in a working state. >=20 > I'll be grateful if I could send you the fixed change for testing > before it goes into HEAD again. Sure. Fabian=20 --Sig_/Zn2dnb/_YkbxfG/gC/nWDut Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCXkFwACgkQBYqIVf93VJ2UaACfRqJ0ItEXDGnBFS4RtgAqZFF1 yn4AoIrFPPxduCHQfjXuEJ5mtuGccc9F =45aA -----END PGP SIGNATURE----- --Sig_/Zn2dnb/_YkbxfG/gC/nWDut-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 11:06:36 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B554ACF4 for ; Mon, 5 Nov 2012 11:06:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 994298FC08 for ; Mon, 5 Nov 2012 11:06:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA5B6aZ3001230 for ; Mon, 5 Nov 2012 11:06:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA5B6aX8001228 for freebsd-net@FreeBSD.org; Mon, 5 Nov 2012 11:06:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Nov 2012 11:06:36 GMT Message-Id: <201211051106.qA5B6aX8001228@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:06:36 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173004 net [netinet] [patch] Incorrect IP checksums when forwardi o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171697 net [ip6] [ndp] panic when changing routes o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 428 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 11:35:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A46F0C9E for ; Mon, 5 Nov 2012 11:35:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 01A048FC15 for ; Mon, 5 Nov 2012 11:35:28 +0000 (UTC) Received: (qmail 80774 invoked from network); 5 Nov 2012 13:11:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Nov 2012 13:11:07 -0000 Message-ID: <5097A47D.1060005@freebsd.org> Date: Mon, 05 Nov 2012 12:35:25 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Fabian Keil Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> <5096C6CA.4090306@freebsd.org> <20121104225226.500507a3@fabiankeil.de> <5096E8FD.6040103@freebsd.org> <20121105002509.670ca1fc@fabiankeil.de> <50978469.8000001@freebsd.org> <20121105110928.480a68b3@fabiankeil.de> In-Reply-To: <20121105110928.480a68b3@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 11:35:29 -0000 On 05.11.2012 11:09, Fabian Keil wrote: > Andre Oppermann wrote: > >> I've backed out the change with r242601 as it exhibits still too >> many problems. I'll fix these problems in the next days but in >> the mean time HEAD should be in a working state. >> >> I'll be grateful if I could send you the fixed change for testing >> before it goes into HEAD again. > > Sure. Thanks. Can you please confirm that HEAD after the backout is behaving as it should again? -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 12:59:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F31CC50; Mon, 5 Nov 2012 12:59:40 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by mx1.freebsd.org (Postfix) with ESMTP id 01A048FC08; Mon, 5 Nov 2012 12:59:39 +0000 (UTC) Received: from [87.79.249.197] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TVMHB-0002LE-W5; Mon, 05 Nov 2012 13:59:38 +0100 Date: Mon, 5 Nov 2012 13:57:12 +0100 From: Fabian Keil To: Andre Oppermann Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] Message-ID: <20121105135712.17634dda@fabiankeil.de> In-Reply-To: <5097A47D.1060005@freebsd.org> References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> <5096C6CA.4090306@freebsd.org> <20121104225226.500507a3@fabiankeil.de> <5096E8FD.6040103@freebsd.org> <20121105002509.670ca1fc@fabiankeil.de> <50978469.8000001@freebsd.org> <20121105110928.480a68b3@fabiankeil.de> <5097A47D.1060005@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/PB/wnOvVFT=oWb0vGXWCF+o"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:59:40 -0000 --Sig_/PB/wnOvVFT=oWb0vGXWCF+o Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > On 05.11.2012 11:09, Fabian Keil wrote: > > Andre Oppermann wrote: > > > >> I've backed out the change with r242601 as it exhibits still too > >> many problems. I'll fix these problems in the next days but in > >> the mean time HEAD should be in a working state. > >> > >> I'll be grateful if I could send you the fixed change for testing > >> before it goes into HEAD again. > > > > Sure. >=20 > Thanks. Can you please confirm that HEAD after the backout is behaving > as it should again? The cvsup mirrors don't seem to carry r242601 yet, so I just applied the r242601 diff that went to svn-src-all@ on top of whatever my cvsup mirror carries. I let curl request the 90000k file ~1000 times directly from gatling, ~1000 times from gatling using Privoxy as proxy and additionally executed ~900 Privoxy regression tests (which rely on TCP/IP and fail in case of incomplete transfers). Everything seems to behave like it should again. Fabian --Sig_/PB/wnOvVFT=oWb0vGXWCF+o Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCXt68ACgkQBYqIVf93VJ1e5QCeLRZ831ChE0ez0myzTA2OT6nH uQcAnRo2oDwgEf1XRvJfv6OCRLUHrob5 =WsON -----END PGP SIGNATURE----- --Sig_/PB/wnOvVFT=oWb0vGXWCF+o-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 20:45:03 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A53136E; Mon, 5 Nov 2012 20:45:03 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 277CC8FC15; Mon, 5 Nov 2012 20:45:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA5Kj3sq043858; Mon, 5 Nov 2012 20:45:03 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA5Kj23Y043853; Mon, 5 Nov 2012 20:45:02 GMT (envelope-from glebius) Date: Mon, 5 Nov 2012 20:45:02 GMT Message-Id: <201211052045.qA5Kj23Y043853@freefall.freebsd.org> To: seb@lineratesystems.com, glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Subject: Re: kern/173004: [netinet] [patch] Incorrect IP checksums when forwarding results in fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:45:03 -0000 Synopsis: [netinet] [patch] Incorrect IP checksums when forwarding results in fragmentation State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Mon Nov 5 20:44:43 UTC 2012 State-Changed-Why: Committed to head. Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Mon Nov 5 20:44:43 UTC 2012 Responsible-Changed-Why: Committed to head. http://www.freebsd.org/cgi/query-pr.cgi?pr=173004 From owner-freebsd-net@FreeBSD.ORG Mon Nov 5 23:42:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AA82494 for ; Mon, 5 Nov 2012 23:42:53 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail.palisadesystems.com (mail.palisadesystems.com [216.81.178.129]) by mx1.freebsd.org (Postfix) with ESMTP id 120DE8FC08 for ; Mon, 5 Nov 2012 23:42:52 +0000 (UTC) Received: from [192.168.221.160] ([192.168.221.160]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id qA5Ng9wF029567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Nov 2012 17:42:16 -0600 (CST) (envelope-from guy.helmer@gmail.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com qA5Ng9wF029567 From: Guy Helmer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 5 Nov 2012 17:42:06 -0600 To: "freebsd-net@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Mon, 05 Nov 2012 17:42:17 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: qA5Ng9wF029567 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.084, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, FREEMAIL_FROM 1.00, RP_8BIT 1.98) X-Palisade-MailScanner-From: guy.helmer@gmail.com Subject: Panic in bpf.c catchpacket() X-Spam-Status: No X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:42:53 -0000 Still working this problem I've previously mentioned on the list, and my = working theory now is a race between catchpacket() and this code in = bpfread(): /* * At this point, we know we have something in the hold slot. */ BPFD_UNLOCK(d); /* * Move data from hold buffer into user space. * We know the entire buffer is transferred since * we checked above that the read buffer is bpf_bufsize bytes. * * XXXRW: More synchronization needed here: what if a second = thread * issues a read on the same fd at the same time? Don't want = this * getting invalidated. */ error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); =20 BPFD_LOCK(d); d->bd_fbuf =3D d->bd_hbuf; d->bd_hbuf =3D NULL; d->bd_hlen =3D 0; bpf_buf_reclaimed(d); BPFD_UNLOCK(d); Assuming it's unwise to hold the descriptor lock over the uiomove() = call, it seems we at least need to check to make sure bd_hbuf is still = valid: @@ -809,10 +948,15 @@ bpfread(struct cdev *dev, struct uio *uio, int iof error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); =20 BPFD_LOCK(d); - d->bd_fbuf =3D d->bd_hbuf; - d->bd_hbuf =3D NULL; - d->bd_hlen =3D 0; - bpf_buf_reclaimed(d); + if (d->bd_hbuf =3D=3D NULL) { + printf("bpfread: lost race: bd_hbuf=3D%p bd_sbuf=3D%p = bd_fbuf=3D%p\n", + d->bd_hbuf, d->bd_sbuf, d->bd_fbuf); + } else { + d->bd_fbuf =3D d->bd_hbuf; + d->bd_hbuf =3D NULL; + d->bd_hlen =3D 0; + bpf_buf_reclaimed(d); + } BPFD_UNLOCK(d); =20 return (error); This still seems vulnerable to me -- a ROTATE_BUFFERS() or reset_d() = could be done between the BPFD_UNLOCK() and the bpf_uiomove(). Would a = new lock to protect the buffers be necessary, or a flag+condition = variable to indicate "hold buffer in use"? Guy= From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 07:50:01 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1FBFB84 for ; Tue, 6 Nov 2012 07:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD7E8FC08 for ; Tue, 6 Nov 2012 07:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA67o1WI095531 for ; Tue, 6 Nov 2012 07:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA67o1kU095530; Tue, 6 Nov 2012 07:50:01 GMT (envelope-from gnats) Date: Tue, 6 Nov 2012 07:50:01 GMT Message-Id: <201211060750.qA67o1kU095530@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Venkat Duvvuru Subject: Re: misc/171838: Possible lock reversal and duplicate locks as reported by Witness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Venkat Duvvuru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 07:50:01 -0000 The following reply was made to PR kern/171838; it has been noted by GNATS. From: Venkat Duvvuru To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Cc: Subject: Re: misc/171838: Possible lock reversal and duplicate locks as reported by Witness Date: Tue, 6 Nov 2012 13:10:43 +0530 --14dae93411552656d804cdceb81f Content-Type: text/plain; charset=ISO-8859-1 Could you please let me know when this will be pulled in? /Venkat On Fri, Sep 21, 2012 at 12:20 PM, wrote: > Thank you very much for your problem report. > It has the internal identification `misc/171838'. > The individual assigned to look at your > report is: freebsd-bugs. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=171838 > > >Category: misc > >Responsible: freebsd-bugs > >Synopsis: Possible lock reversal and duplicate locks as reported by > Witness > >Arrival-Date: Fri Sep 21 06:50:07 UTC 2012 > --14dae93411552656d804cdceb81f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could you please let me know when this will be pulled in?

/Venkat

On Fri, Sep 21, 2012 at 12:20 P= M, <FreeBSD-gnats-submit@freebsd.org> wrote:=
Thank you very much for your problem report.=
It has the internal identification `misc/171838'.
The individual assigned to look at your
report is: freebsd-bugs.

You can access the state of your problem report at any time
via this link:

http://www.freebsd.org/cgi/query-pr.cgi?pr=3D171838

>Category: =A0 =A0 =A0 misc
>Responsible: =A0 =A0freebsd-bugs
>Synopsis: =A0 =A0 =A0 Possible lock reversal and duplicate locks as rep= orted by Witness
>Arrival-Date: =A0 Fri Sep 21 06:50:07 UTC 2012

--14dae93411552656d804cdceb81f-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 08:27:18 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95AF3663; Tue, 6 Nov 2012 08:27:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 617708FC08; Tue, 6 Nov 2012 08:27:18 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so157652pad.13 for ; Tue, 06 Nov 2012 00:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wyGVsZ/ekWk1lrfRwaiiuvXfoIN6s60I+a1eh+kqS6U=; b=P+6cZhcyNF5PM6qyWRtwQT/ErIX+T5ecSUKJtE1ifYyEhhr0BcD17UBAtAMXotm5w/ AhgAeqYhuGFy5HChkZoKV+aNEqo3i83UHgt6Xfs/hJi+uvexq2OXAZ12pX3Ihe8N8MWO +8633wJNZju5JgJaIo1QNvlDeWLEgZiKLf8D71Xw2MvPc/1ISyae9q1brbbG1Y/X32Mv by267FQZ+9Kx9ttwyyOczc+q+yrofr+hs1o9Ww3LU4Q79IWAIQWDHdru1WZMJEJo16ZR vcMjW3g/Jr12S/F7Rpg3PnAih9W7Zipq8wQZAYyNTEmgNs+3wWS/VjZCFvOkNvhQ99wu 4zMA== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr1188286pbc.69.1352190437860; Tue, 06 Nov 2012 00:27:17 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Tue, 6 Nov 2012 00:27:17 -0800 (PST) In-Reply-To: <20121102123817.GP70741@FreeBSD.org> References: <20121102123817.GP70741@FreeBSD.org> Date: Tue, 6 Nov 2012 00:27:17 -0800 X-Google-Sender-Auth: Z333sf_o5ulh4umGh_DXJXgGs2U Message-ID: Subject: Re: splitting m_flags to pkthdr.flags + m_flags From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 08:27:18 -0000 Hiya, On 2 November 2012 05:38, Gleb Smirnoff wrote: > Hello networkers, > > some (most) of m_flags bits are describing features that can > be present on a packet only, not on a single mbuf. Since we are > close to exhaustion of available bits, and many subsystems prefer > to use one of M_PROTO bits instead of grabbing a flag, I propose > to split m_flags to two parts: The idea of splitting things up is nice and it does make sense. > In the m_flags remain: > #define M_EXT 0x00000001 /* has associated external storage */ > #define M_PKTHDR 0x00000002 /* start of record */ > #define M_EOR 0x00000004 /* end of record */ > #define M_RDONLY 0x00000008 /* associated data is marked read-only */ > and all M_PROTO flags. > > struct pkthdr grows by one word and its new flag word now > posesses: > > #define M_BCAST 0x00000200 /* send/received as link-level broadcast */ > #define M_MCAST 0x00000400 /* send/received as link-level multicast */ > #define M_FRAG 0x00000800 /* packet is a fragment of a larger packet */ > #define M_FIRSTFRAG 0x00001000 /* packet is first fragment */ > #define M_LASTFRAG 0x00002000 /* packet is last fragment */ > #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ > #define M_VLANTAG 0x00010000 /* ether_vtag is valid */ > #define M_PROMISC 0x00020000 /* packet was not for us */ > #define M_FLOWID 0x00400000 /* deprecated: flowid is valid */ > #define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid hash type */ > > Some M_PROTO abusements like M_FASTFWD_OURS and recently added M_IP_NEXTHOP > also go to the pkthdr mbuf flags. > > P.S. > An attentive reader may have noticed that I missed M_NOFREE and M_FREELIST. > Yep, these flags coming from historical mbuf allocator from FreeBSD 4.x times > are about to be deleted, we carefully examine them, but never set. Patch > for review attached. My comments: * We don't know if any downstream clients are using M_NOFREE for whatever reason. M_FREELIST may be easy to kill but again, who knows who's reused it in their own code. So I'd prefer that this sort of thing was more widely communicated to the major (known) FreeBSD companies before you go and change this stuff. * .. I'm not sure whether you want to churn the mbuf API through some accessor API at this stage - ie, instead of just separating things out, what about also at the same time creating accessor macros that right now just go to the mbuf flags, but later on break it out to the hdr and non-hdr flags? * There's been a lot of network stack churn lately. I personally think we should wait a while longer and let the fallout .. well, finish falling out, before you continue churning things. :-) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 09:25:12 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12B495E8 for ; Tue, 6 Nov 2012 09:25:12 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE908FC0C for ; Tue, 6 Nov 2012 09:25:10 +0000 (UTC) Received: (qmail 8297 invoked from network); 6 Nov 2012 11:00:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Nov 2012 11:00:39 -0000 Message-ID: <5098D772.60002@networx.ch> Date: Tue, 06 Nov 2012 10:25:06 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: splitting m_flags to pkthdr.flags + m_flags References: <20121102123817.GP70741@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 09:25:12 -0000 On 06.11.2012 09:27, Adrian Chadd wrote: > Hiya, > > On 2 November 2012 05:38, Gleb Smirnoff wrote: >> Hello networkers, >> >> some (most) of m_flags bits are describing features that can >> be present on a packet only, not on a single mbuf. Since we are >> close to exhaustion of available bits, and many subsystems prefer >> to use one of M_PROTO bits instead of grabbing a flag, I propose >> to split m_flags to two parts: > > The idea of splitting things up is nice and it does make sense. > >> In the m_flags remain: >> #define M_EXT 0x00000001 /* has associated external storage */ >> #define M_PKTHDR 0x00000002 /* start of record */ >> #define M_EOR 0x00000004 /* end of record */ >> #define M_RDONLY 0x00000008 /* associated data is marked read-only */ >> and all M_PROTO flags. >> >> struct pkthdr grows by one word and its new flag word now >> posesses: >> >> #define M_BCAST 0x00000200 /* send/received as link-level broadcast */ >> #define M_MCAST 0x00000400 /* send/received as link-level multicast */ >> #define M_FRAG 0x00000800 /* packet is a fragment of a larger packet */ >> #define M_FIRSTFRAG 0x00001000 /* packet is first fragment */ >> #define M_LASTFRAG 0x00002000 /* packet is last fragment */ >> #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ >> #define M_VLANTAG 0x00010000 /* ether_vtag is valid */ >> #define M_PROMISC 0x00020000 /* packet was not for us */ >> #define M_FLOWID 0x00400000 /* deprecated: flowid is valid */ >> #define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid hash type */ >> >> Some M_PROTO abusements like M_FASTFWD_OURS and recently added M_IP_NEXTHOP >> also go to the pkthdr mbuf flags. >> >> P.S. >> An attentive reader may have noticed that I missed M_NOFREE and M_FREELIST. >> Yep, these flags coming from historical mbuf allocator from FreeBSD 4.x times >> are about to be deleted, we carefully examine them, but never set. Patch >> for review attached. > > My comments: > > * We don't know if any downstream clients are using M_NOFREE for > whatever reason. M_FREELIST may be easy to kill but again, who knows > who's reused it in their own code. So I'd prefer that this sort of > thing was more widely communicated to the major (known) FreeBSD > companies before you go and change this stuff. It's unlikely anybody is using it instead of our native UMA allocator. If they do, they have a heavily modified stack anyway. If they do, they have just to reintroduce that flag again possibly as an overlay or with a separate bit. > * .. I'm not sure whether you want to churn the mbuf API through some > accessor API at this stage - ie, instead of just separating things > out, what about also at the same time creating accessor macros that > right now just go to the mbuf flags, but later on break it out to the > hdr and non-hdr flags? This is probably not worth it and really complicates things much more than not. > * There's been a lot of network stack churn lately. I personally think > we should wait a while longer and let the fallout .. well, finish > falling out, before you continue churning things. :-) We've been stagnating in some areas far too long. If there is a reasonable justification we must not be afraid to move/break things. To make a tasty omelette some eggs have to be broken. If you're afraid of making changes and wait for signoff from unknown parties nothing is ever going to happen. Rather than breaking things all the time we'd rather make all the sweeping changes for 10.0 in one swoop and then have to mostly stable for some time again. Instead of breaking half of the things with every major release. In fact most changes make it eventually easier for vendors to track FreeBSD than before. A couple of those changes are even driven by the vendors. Also we are not are not working for the vendors (well, most of us). The vendor is working with us. We want to drive FreeBSD into the future and make it even more attractive to them to work with us. Most of them have got by now that one-off branching is not a good long-term option and started to feed back their non-core IP changes. Also driver vendors have understood that maintaining their driver in the tree is far easier than outside of it. Note that I'm not saying that we should break and move things nilly willy just for the sake of it as it seems to happen in other OS's. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 10:02:42 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFD19E6A for ; Tue, 6 Nov 2012 10:02:42 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id 872888FC17 for ; Tue, 6 Nov 2012 10:02:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 0C1A858DDB for ; Tue, 6 Nov 2012 10:56:40 +0100 (CET) Received: from [10.0.2.53] (edge-pf.coltex.nl [91.227.27.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 6353758E1A for ; Tue, 6 Nov 2012 10:56:35 +0100 (CET) Message-ID: <5098DED2.80100@dds.nl> Date: Tue, 06 Nov 2012 10:56:34 +0100 From: Seth Mos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: net@freebsd.org Subject: 6rd patch status Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at rotring X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:02:42 -0000 Hello, The pfSense project uses the 6rd patch against the stf interface, which works but does not work with prefix lengths larger then 32 bits. What is the status of this work? As it is we can not support 6rd networks that deploy a 41 bit prefix length with a 15 bit ipv4 mask for a /56 delegated prefix. Kind regards, Seth From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 10:48:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD783CF5 for ; Tue, 6 Nov 2012 10:48:34 +0000 (UTC) (envelope-from nevzorovn@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 419418FC15 for ; Tue, 6 Nov 2012 10:48:33 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so276452lag.13 for ; Tue, 06 Nov 2012 02:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4CHKrgpHLr4nKUJA1rCSuzmrtO0FQJYkJ9FUhYaiyIA=; b=YoCnr8Z1AeUHgu3XTEfkG6r5pzVHT2qllxo5q6KeO7VEB9axdaeggQ6ghCBkpBzk8H tw8ZGHxuCWG+7l3nEBLFzxoP0XnQdigPfdUDhzdjVSjS5b70TxMn3k2RRPiAq+MhmTEQ YklsCQneWYHgt2KlnBHY60JjZQ18PNFHpnHSRvwmDupcKIds8Okbw5zHO7imzwdEHJLV S6wvwbpzwk236AjQtdcCl5ftiQ2z6oD9sbW0d5j341mVVTU9B8a27JOiwEXDYBAfDF/2 F+nIwzmcLd3rrcaKwjiiBEPrBnDI/e7NeioBOJSWC8G5fcImn0AkQSFeVSRJDEyvcRR/ uCsw== MIME-Version: 1.0 Received: by 10.112.27.70 with SMTP id r6mr341220lbg.51.1352198912315; Tue, 06 Nov 2012 02:48:32 -0800 (PST) Received: by 10.112.42.70 with HTTP; Tue, 6 Nov 2012 02:48:32 -0800 (PST) Date: Tue, 6 Nov 2012 16:48:32 +0600 Message-ID: Subject: NG nodes on cisco-style vlan interfaces From: Nikolay Nevzorov To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:48:34 -0000 Create vlan interface in cisco-style, eg vlan 3 on fxp0 is fxp0.3, but in ngctl list i can't find node named fxp0.3. But i can see new ethernet node What cause this problem? Dot in the name of interface? How can i rename unnamed node to use it? -- Nikolay Nevzorov From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 12:30:01 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1C247A8 for ; Tue, 6 Nov 2012 12:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A81DF8FC14 for ; Tue, 6 Nov 2012 12:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA6CU1K1016091 for ; Tue, 6 Nov 2012 12:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA6CU19J016090; Tue, 6 Nov 2012 12:30:01 GMT (envelope-from gnats) Date: Tue, 6 Nov 2012 12:30:01 GMT Message-Id: <201211061230.qA6CU19J016090@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Nicholas Wilson Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Nicholas Wilson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 12:30:01 -0000 The following reply was made to PR kern/152036; it has been noted by GNATS. From: Nicholas Wilson To: bug-followup@FreeBSD.org, kbyanc@gmail.com Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks Date: Tue, 06 Nov 2012 12:19:08 +0000 Note that although this is a little surprising initially, it could well be intentional. For comparison, SIOCGIFNETMASK has the same behaviour on other platforms that have sa_len, including Darwin and AIX, so FreeBSD's behaviour is in line with other implementations. Changing the behaviour of the ioctl might break someone's code. Nicholas Wilson From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 16:14:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABE6E73B for ; Tue, 6 Nov 2012 16:14:44 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 538648FC0A for ; Tue, 6 Nov 2012 16:14:43 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so722962vcb.13 for ; Tue, 06 Nov 2012 08:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6qO7JWiYJ0Ia/rKSA6mzT4XfaM0qbASE5KUACb7o1UY=; b=SK/ohEitX0IQU4BB3D0jIB76TD9j6j0Q3bZ4YCeuzGFx8eqvsn7XwBhJqKgrBQZoc/ 1luM2kqFCaVGDWiHxFP+cIIVLmjnKvzxzGzc6oYK50t78UOe6gCjbGFmFdp64OPPA2wN fCf/89XRYgX9n5twJ5ZlnRvWY+udElhmgBAEjo7CWf7+RxroW4Urwsx+Ql0pZh8VQcym rOvI4bReIaWEoTpjT/gSiTLTQpBkGYUB53H+udTNEThc9vJ5hhuPxSZs41kJsx+AaE8n IsEq3npGq622Ud7hWey+tCF/c5yzF/mvgNixftQhE+rMU/pFSh0pZlBGASur9L48AGZu vswg== MIME-Version: 1.0 Received: by 10.58.239.162 with SMTP id vt2mr1449066vec.1.1352218483262; Tue, 06 Nov 2012 08:14:43 -0800 (PST) Received: by 10.58.207.114 with HTTP; Tue, 6 Nov 2012 08:14:43 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 11:14:43 -0500 Message-ID: Subject: Re: NG nodes on cisco-style vlan interfaces From: Ryan Stone To: Nikolay Nevzorov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:14:44 -0000 Unfortunately netgraph doesn't allow dots in node names (or hook names), because that would cause an ambiguity in parsing netgraph paths. You can name an unnamed node by running "ngctl [nodeid]: name", but of course the name must be both valid and unique. On Tue, Nov 6, 2012 at 5:48 AM, Nikolay Nevzorov wrote: > Create vlan interface in cisco-style, eg vlan 3 on fxp0 is fxp0.3, but in > ngctl list i can't find node named fxp0.3. But i can see new > ethernet node > What cause this problem? Dot in the name of interface? How can i rename > unnamed node to use it? > > -- > Nikolay Nevzorov > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 19:34:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 315D82E8 for ; Tue, 6 Nov 2012 19:34:49 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2D708FC0C for ; Tue, 6 Nov 2012 19:34:48 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id c10so404686eaa.13 for ; Tue, 06 Nov 2012 11:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=S/kGXb92ouoVF7W2a+lfTFzs1IspazN8YGtvHJGD49A=; b=lKZVfJ0vr3360vCDDOMM5tGMGt5uV7vMsAvOmpvLWu427tjaRC5n05vLTRdDxsR8x/ bZL/fZP0pNpXPZ/bq96Ur21WbeBdRzdbLsai1VbEZpQZpLMDR6L4G9TRN7C5u0p8BC8H OLqwMhtJpbZojTbZCBmDGnjVHfwdfDy6iGgjzhfmrHBHsNrTfMznNgDAMK6wIZfHWE8N Nv0sLE4uQccOlJhm1m+ug1pmGNiC3QnlKSIabmUvM28DHzdHalgrOjeX6HuoGXxfPHtL NfwAOQqcGqSddxJDRTdhFUqddo0TvBVIXUVy644rwqzdE6C8J5MirRsOqja14sN+qnA8 4x4A== Received: by 10.14.194.2 with SMTP id l2mr6805594een.12.1352230481302; Tue, 06 Nov 2012 11:34:41 -0800 (PST) Received: from [10.0.0.86] ([93.152.184.10]) by mx.google.com with ESMTPS id c6sm58322111eep.17.2012.11.06.11.34.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 11:34:40 -0800 (PST) Subject: Re: NG nodes on cisco-style vlan interfaces Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Tue, 6 Nov 2012 21:34:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7883D2F7-EF11-4EFF-855F-D66DE06D7941@gmail.com> References: To: Nikolay Nevzorov X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:34:49 -0000 On Nov 6, 2012, at 12:48 PM, Nikolay Nevzorov = wrote: > Create vlan interface in cisco-style, eg vlan 3 on fxp0 is fxp0.3, but = in > ngctl list i can't find node named fxp0.3. But i can see new > ethernet node > What cause this problem? Dot in the name of interface? How can i = rename > unnamed node to use it? >=20 > --=20 > Nikolay Nevzorov > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" I've had the same problem in the past : = http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2011-02/msg00251.html Patch URL is now broken, but the patch is also in the email body. Also I've opened the following PR : = http://www.freebsd.org/cgi/query-pr.cgi?pr=3D154850&cat=3Dkern Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Wed Nov 7 16:09:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2322676E for ; Wed, 7 Nov 2012 16:09:34 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id CB6BB8FC08 for ; Wed, 7 Nov 2012 16:09:33 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TW7YX-000Dvm-Gh for freebsd-net@freebsd.org; Wed, 07 Nov 2012 16:28:41 +0100 Date: Wed, 7 Nov 2012 16:28:16 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <805416930.20121107162816@nitronet.pl> To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: IPFW pipe list - invalid oid len 0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:09:34 -0000 Hi lists, I'm running: /sbin/ipfw pipe list > pipestats-`date "+%Y%m%d-%H%M%S"` from cron every minute for statistical purposes. Randomly (more often in loaded hours) it results in: ipfw: invalid oid len 0 Is this enough to squash this bug? From owner-freebsd-net@FreeBSD.ORG Wed Nov 7 16:22:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9EC4E1F for ; Wed, 7 Nov 2012 16:22:53 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 892688FC19 for ; Wed, 7 Nov 2012 16:22:53 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TW8Oy-000FP2-P4 for freebsd-net@freebsd.org; Wed, 07 Nov 2012 17:22:52 +0100 Date: Wed, 7 Nov 2012 17:22:28 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1688071357.20121107172228@nitronet.pl> To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: IPFW pipe list - invalid oid len 0 In-Reply-To: <805416930.20121107162816@nitronet.pl> References: <805416930.20121107162816@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:22:53 -0000 > I'm running: > /sbin/ipfw pipe list > pipestats-`date "+%Y%m%d-%H%M%S"` > from cron every minute for statistical purposes. > Randomly (more often in loaded hours) it results in: > ipfw: invalid oid len 0 > Is this enough to squash this bug? Just a quick note: It happened since 8.2, and it's still happening on 12-hour old 9-PRERELEASE. From owner-freebsd-net@FreeBSD.ORG Wed Nov 7 22:48:39 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91459DC9 for ; Wed, 7 Nov 2012 22:48:39 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 27B7A8FC08 for ; Wed, 7 Nov 2012 22:48:39 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWETe-000HPz-Cl for freebsd-net@FreeBSD.org; Thu, 08 Nov 2012 02:52:06 +0400 Message-ID: <509AE539.5050102@FreeBSD.org> Date: Thu, 08 Nov 2012 02:48:25 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: arp/ndp default hash size Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:48:39 -0000 Hello list! Currently size of arp/ndp hash is the following: #define LLTBL_HASHTBL_SIZE 32 /* default 32 ? */ This may be OK for end hosts, but this is definitely not enough for router howadays. Especially given that IPv6 hosts generate 2 ndp records. Output from 2 random v4 / v6 routers from my $job: 2:23 [0] m@matisse arp -an | wc -l 1494 2:24 [0] m@singapore ndp -an | wc -l 3999 Given that LIST_HEAD is just a pointer, and we currently have single global (actually per-VNET) instance for every l3 proto, bumping hash to, say, at least 4096 should do no harm. From owner-freebsd-net@FreeBSD.ORG Wed Nov 7 23:24:39 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F20CB75; Wed, 7 Nov 2012 23:24:39 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id D538F8FC0A; Wed, 7 Nov 2012 23:24:38 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWF2U-000HvY-7R; Thu, 08 Nov 2012 03:28:06 +0400 Message-ID: <509AEDAC.10002@FreeBSD.org> Date: Thu, 08 Nov 2012 03:24:28 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: [patch] reducing arp locking Content-Type: multipart/mixed; boundary="------------030808050000070300050904" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:24:39 -0000 This is a multi-part message in MIME format. --------------030808050000070300050904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello list! Currently we need to acquire 2 read locks to perform simple 6-byte copying from arp record to packet ethernet header. It seems that acquiring lle lock for fast path (main traffic flow) is not necessary even with current code. My tests shows ~10% improvement with this patch applied. If nobody objects I plan to commit this change at the end of next week. --------------030808050000070300050904 Content-Type: text/plain; name="no_arp_lle_lock.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="no_arp_lle_lock.diff" Index: sys/netinet/in.c =================================================================== --- sys/netinet/in.c (revision 242524) +++ sys/netinet/in.c (working copy) @@ -1476,7 +1476,7 @@ in_lltable_lookup(struct lltable *llt, u_int flags if (LLE_IS_VALID(lle)) { if (flags & LLE_EXCLUSIVE) LLE_WLOCK(lle); - else + else if (!(flags & LLE_UNLOCKED)) LLE_RLOCK(lle); } done: Index: sys/netinet/if_ether.c =================================================================== --- sys/netinet/if_ether.c (revision 242524) +++ sys/netinet/if_ether.c (working copy) @@ -293,10 +293,10 @@ arpresolve(struct ifnet *ifp, struct rtentry *rt0, struct sockaddr *dst, u_char *desten, struct llentry **lle) { struct llentry *la = 0; - u_int flags = 0; + u_int flags = LLE_UNLOCKED; struct mbuf *curr = NULL; struct mbuf *next = NULL; - int error, renew; + int error, renew = 0; *lle = NULL; if (m != NULL) { @@ -315,7 +315,41 @@ arpresolve(struct ifnet *ifp, struct rtentry *rt0, retry: IF_AFDATA_RLOCK(ifp); la = lla_lookup(LLTABLE(ifp), flags, dst); + + /* + * Fast path. Do not require rlock on llentry. + */ + if ((la != NULL) && (flags & LLE_UNLOCKED)) { + if ((la->la_flags & LLE_VALID) && + ((la->la_flags & LLE_STATIC) || la->la_expire > time_uptime)) { + bcopy(&la->ll_addr, desten, ifp->if_addrlen); + /* + * If entry has an expiry time and it is approaching, + * see if we need to send an ARP request within this + * arpt_down interval. + */ + if (!(la->la_flags & LLE_STATIC) && + time_uptime + la->la_preempt > la->la_expire) { + renew = 1; + la->la_preempt--; + } + + IF_AFDATA_RUNLOCK(ifp); + if (renew != 0) + arprequest(ifp, NULL, &SIN(dst)->sin_addr, NULL); + + return (0); + } + + /* Revert to normal path for other cases */ + flags &= ~LLE_UNLOCKED; + *lle = la; + LLE_RNLOCK(la); + } + + IF_AFDATA_RUNLOCK(ifp); + if ((la == NULL) && ((flags & LLE_EXCLUSIVE) == 0) && ((ifp->if_flags & (IFF_NOARP | IFF_STATICARP)) == 0)) { flags |= (LLE_CREATE | LLE_EXCLUSIVE); @@ -332,25 +366,6 @@ retry: return (EINVAL); } - if ((la->la_flags & LLE_VALID) && - ((la->la_flags & LLE_STATIC) || la->la_expire > time_uptime)) { - bcopy(&la->ll_addr, desten, ifp->if_addrlen); - /* - * If entry has an expiry time and it is approaching, - * see if we need to send an ARP request within this - * arpt_down interval. - */ - if (!(la->la_flags & LLE_STATIC) && - time_uptime + la->la_preempt > la->la_expire) { - arprequest(ifp, NULL, &SIN(dst)->sin_addr, NULL); - la->la_preempt--; - } - - *lle = la; - error = 0; - goto done; - } - if (la->la_flags & LLE_STATIC) { /* should not happen! */ log(LOG_DEBUG, "arpresolve: ouch, empty static llinfo for %s\n", inet_ntoa(SIN(dst)->sin_addr)); Index: sys/net/if_llatbl.h =================================================================== --- sys/net/if_llatbl.h (revision 242524) +++ sys/net/if_llatbl.h (working copy) @@ -178,6 +178,7 @@ MALLOC_DECLARE(M_LLTABLE); #define LLE_EXCLUSIVE 0x2000 /* return lle xlocked */ #define LLE_DELETE 0x4000 /* delete on a lookup - match LLE_IFADDR */ #define LLE_CREATE 0x8000 /* create on a lookup miss */ +#define LLE_UNLOCKED 0x10000 /* return lle unlocked */ #define LLATBL_HASH(key, mask) \ (((((((key >> 8) ^ key) >> 8) ^ key) >> 8) ^ key) & mask) --------------030808050000070300050904-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 7 23:40:02 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D03BBFC for ; Wed, 7 Nov 2012 23:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B4C388FC08 for ; Wed, 7 Nov 2012 23:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA7Ne1cS079629 for ; Wed, 7 Nov 2012 23:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA7Ne1Ur079628; Wed, 7 Nov 2012 23:40:01 GMT (envelope-from gnats) Date: Wed, 7 Nov 2012 23:40:01 GMT Message-Id: <201211072340.qA7Ne1Ur079628@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: "Steven Hartland" Subject: Re: kern/173201: [ixgbe] [patch] Missing / broken ixgbe sysctl' s and tunables (patch included) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Steven Hartland List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:40:02 -0000 The following reply was made to PR kern/173201; it has been noted by GNATS. From: "Steven Hartland" To: Cc: Subject: Re: kern/173201: [ixgbe] [patch] Missing / broken ixgbe sysctl's and tunables (patch included) Date: Wed, 7 Nov 2012 23:34:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01CDBD40.74878ED0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Updated patch that applies to HEAD as of yesterday. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_00B9_01CDBD40.74878ED0 Content-Type: text/plain; format=flowed; name="ixgbe-sysctl.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ixgbe-sysctl.txt" Added sysctl's for ixgbe all tunables=0A= =0A= Added back in hw.ixgbe.flow_control which enable the default flow_control=0A= of all ixgbe interfaces to be set in loader.conf=0A= =0A= Added hw.ixgbe.advertise_speed which allows /boot/loader.conf to = configure=0A= advertised speed as sysctl.conf is too late for driver changes.=0A= =0A= Made enable_aim device independent based on hw.ixgbe.enable_aim default.=0A= --- sys/dev/ixgbe/ixgbe.c.orig 2012-11-06 12:28:35.607778862 +0000=0A= +++ sys/dev/ixgbe/ixgbe.c 2012-11-06 14:20:02.774297585 +0000=0A= @@ -157,8 +157,10 @@=0A= static void ixgbe_update_link_status(struct adapter *);=0A= static void ixgbe_refresh_mbufs(struct rx_ring *, int);=0A= static int ixgbe_xmit(struct tx_ring *, struct mbuf **);=0A= -static int ixgbe_set_flowcntl(SYSCTL_HANDLER_ARGS);=0A= -static int ixgbe_set_advertise(SYSCTL_HANDLER_ARGS);=0A= +static int ixgbe_set_flowcntl_sysctl(SYSCTL_HANDLER_ARGS);=0A= +static int ixgbe_set_flowcntl(struct adapter *);=0A= +static int ixgbe_set_advertise_sysctl(SYSCTL_HANDLER_ARGS);=0A= +static int ixgbe_set_advertise(struct adapter *);=0A= static int ixgbe_set_thermal_test(SYSCTL_HANDLER_ARGS);=0A= static int ixgbe_dma_malloc(struct adapter *, bus_size_t,=0A= struct ixgbe_dma_alloc *, int);=0A= @@ -230,32 +232,52 @@=0A= MODULE_DEPEND(ixgbe, ether, 1, 1, 1);=0A= =0A= /*=0A= -** TUNEABLE PARAMETERS:=0A= -*/=0A= + * TUNEABLE PARAMETERS:=0A= + */=0A= +static SYSCTL_NODE(_hw, OID_AUTO, ixgbe, CTLFLAG_RD, 0, "IXGBE driver = parameters");=0A= =0A= /*=0A= -** AIM: Adaptive Interrupt Moderation=0A= -** which means that the interrupt rate=0A= -** is varied over time based on the=0A= -** traffic for that interrupt vector=0A= -*/=0A= + * AIM: Adaptive Interrupt Moderation=0A= + * which means that the interrupt rate=0A= + * is varied over time based on the=0A= + * traffic for that interrupt vector=0A= + */=0A= static int ixgbe_enable_aim =3D TRUE;=0A= TUNABLE_INT("hw.ixgbe.enable_aim", &ixgbe_enable_aim);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, enable_aim, CTLFLAG_RDTUN,=0A= + &ixgbe_enable_aim, 0, "Enable adaptive interrupt moderation");=0A= =0A= static int ixgbe_max_interrupt_rate =3D (4000000 / IXGBE_LOW_LATENCY);=0A= TUNABLE_INT("hw.ixgbe.max_interrupt_rate", &ixgbe_max_interrupt_rate);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, max_interrupt_rate, CTLFLAG_RDTUN,=0A= + &ixgbe_max_interrupt_rate, 0, "Maximum interrupt rate used in AIM");=0A= =0A= /* How many packets rxeof tries to clean at a time */=0A= static int ixgbe_rx_process_limit =3D 128;=0A= TUNABLE_INT("hw.ixgbe.rx_process_limit", &ixgbe_rx_process_limit);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, rx_process_limit, CTLFLAG_RDTUN,=0A= + &ixgbe_rx_process_limit, 0, "Maximum number of received packets to = process"=0A= + " at a time, -1 means unlimited");=0A= +=0A= +/* Flow control setting, default to full */=0A= +static int ixgbe_flow_control =3D ixgbe_fc_full;=0A= +TUNABLE_INT("hw.ixgbe.flow_control", &ixgbe_flow_control);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, flow_control, CTLFLAG_RDTUN,=0A= + &ixgbe_flow_control, 0, "Default flow control used for all = adapters");=0A= +=0A= +/* Advertise Speed, default to 0 (10G) */=0A= +static int ixgbe_advertise_speed =3D 0;=0A= +TUNABLE_INT("hw.ixgbe.advertise_speed", &ixgbe_advertise_speed);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, advertise_speed, CTLFLAG_RDTUN,=0A= + &ixgbe_advertise_speed, 0, "Default advertised speed for all = adapters");=0A= =0A= /*=0A= -** Smart speed setting, default to on=0A= -** this only works as a compile option=0A= -** right now as its during attach, set=0A= -** this to 'ixgbe_smart_speed_off' to=0A= -** disable.=0A= -*/=0A= + * Smart speed setting, default to on=0A= + * this only works as a compile option=0A= + * right now as its during attach, set=0A= + * this to 'ixgbe_smart_speed_off' to=0A= + * disable.=0A= + */=0A= static int ixgbe_smart_speed =3D ixgbe_smart_speed_on;=0A= =0A= /*=0A= @@ -264,6 +286,8 @@=0A= */=0A= static int ixgbe_enable_msix =3D 1;=0A= TUNABLE_INT("hw.ixgbe.enable_msix", &ixgbe_enable_msix);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, enable_msix, CTLFLAG_RDTUN, = &ixgbe_enable_msix,=0A= + 0, "Enable/disble MSIX for ixgbe adapters");=0A= =0A= /*=0A= * Header split: this causes the hardware to DMA=0A= @@ -273,6 +297,8 @@=0A= */=0A= static int ixgbe_header_split =3D FALSE;=0A= TUNABLE_INT("hw.ixgbe.hdr_split", &ixgbe_header_split);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, hdr_split, CTLFLAG_RDTUN, = &ixgbe_header_split,=0A= + 0, "Enable receive mbuf header split");=0A= =0A= /*=0A= * Number of Queues, can be set to 0,=0A= @@ -282,6 +308,8 @@=0A= */=0A= static int ixgbe_num_queues =3D 0;=0A= TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, num_queues, CTLFLAG_RDTUN, = &ixgbe_num_queues, 0,=0A= + "Number of queues to configure, 0 indicates autoconfigure");=0A= =0A= /*=0A= ** Number of TX descriptors per ring,=0A= @@ -290,10 +318,14 @@=0A= */=0A= static int ixgbe_txd =3D PERFORM_TXD;=0A= TUNABLE_INT("hw.ixgbe.txd", &ixgbe_txd);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, txd, CTLFLAG_RDTUN, &ixgbe_txd, 0,=0A= + "Number of receive descriptors per queue");=0A= =0A= /* Number of RX descriptors per ring */=0A= static int ixgbe_rxd =3D PERFORM_RXD;=0A= TUNABLE_INT("hw.ixgbe.rxd", &ixgbe_rxd);=0A= +SYSCTL_INT(_hw_ixgbe, OID_AUTO, rxd, CTLFLAG_RDTUN, &ixgbe_rxd, 0,=0A= + "Number of transmit descriptors per queue");=0A= =0A= /*=0A= ** HW RSC control: =0A= @@ -426,12 +458,19 @@=0A= /* Core Lock Init*/=0A= IXGBE_CORE_LOCK_INIT(adapter, device_get_nameunit(dev));=0A= =0A= + /* hw.ixgbe defaults init */=0A= + adapter->advertise =3D ixgbe_advertise_speed;=0A= + adapter->fc =3D ixgbe_flow_control;=0A= + adapter->enable_aim =3D ixgbe_enable_aim;=0A= + ixgbe_set_advertise(adapter);=0A= + ixgbe_set_flowcntl(adapter);=0A= +=0A= /* SYSCTL APIs */=0A= =0A= SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),=0A= SYSCTL_CHILDREN(device_get_sysctl_tree(dev)),=0A= OID_AUTO, "fc", CTLTYPE_INT | CTLFLAG_RW,=0A= - adapter, 0, ixgbe_set_flowcntl, "I", "Flow Control");=0A= + adapter, 0, ixgbe_set_flowcntl_sysctl, "I", "Flow Control");=0A= =0A= SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),=0A= SYSCTL_CHILDREN(device_get_sysctl_tree(dev)),=0A= @@ -446,7 +485,7 @@=0A= SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),=0A= SYSCTL_CHILDREN(device_get_sysctl_tree(dev)),=0A= OID_AUTO, "advertise_speed", CTLTYPE_INT | CTLFLAG_RW,=0A= - adapter, 0, ixgbe_set_advertise, "I", "Link Speed");=0A= + adapter, 0, ixgbe_set_advertise_sysctl, "I", "Link Speed");=0A= =0A= SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),=0A= SYSCTL_CHILDREN(device_get_sysctl_tree(dev)),=0A= @@ -1528,7 +1567,7 @@=0A= =0A= /* Do AIM now? */=0A= =0A= - if (ixgbe_enable_aim =3D=3D FALSE)=0A= + if (adapter->enable_aim =3D=3D FALSE)=0A= goto no_calc;=0A= /*=0A= ** Do Adaptive Interrupt Moderation:=0A= @@ -5744,7 +5787,7 @@=0A= ** 3 - full=0A= */=0A= static int=0A= -ixgbe_set_flowcntl(SYSCTL_HANDLER_ARGS)=0A= +ixgbe_set_flowcntl_sysctl(SYSCTL_HANDLER_ARGS)=0A= {=0A= int error, last;=0A= struct adapter *adapter =3D (struct adapter *) arg1;=0A= @@ -5758,6 +5801,13 @@=0A= if (adapter->fc =3D=3D last)=0A= return (0);=0A= =0A= + return ixgbe_set_flowcntl(adapter);=0A= +}=0A= +=0A= +static int=0A= +ixgbe_set_flowcntl(struct adapter *adapter)=0A= +{=0A= +=0A= switch (adapter->fc) {=0A= case ixgbe_fc_rx_pause:=0A= case ixgbe_fc_tx_pause:=0A= @@ -5775,7 +5825,7 @@=0A= /* Don't autoneg if forcing a value */=0A= adapter->hw.fc.disable_fc_autoneg =3D TRUE;=0A= ixgbe_fc_enable(&adapter->hw);=0A= - return error;=0A= + return 0;=0A= }=0A= =0A= static void=0A= @@ -5795,23 +5845,32 @@=0A= ** 3 - advertise normal=0A= */=0A= static int=0A= -ixgbe_set_advertise(SYSCTL_HANDLER_ARGS)=0A= +ixgbe_set_advertise_sysctl(SYSCTL_HANDLER_ARGS)=0A= {=0A= int error =3D 0;=0A= struct adapter *adapter;=0A= - device_t dev;=0A= - struct ixgbe_hw *hw;=0A= - ixgbe_link_speed speed, last;=0A= =0A= adapter =3D (struct adapter *) arg1;=0A= - dev =3D adapter->dev;=0A= - hw =3D &adapter->hw;=0A= - last =3D adapter->advertise;=0A= =0A= error =3D sysctl_handle_int(oidp, &adapter->advertise, 0, req);=0A= if ((error) || (adapter->advertise =3D=3D -1))=0A= return (error);=0A= =0A= + return ixgbe_set_advertise(adapter);=0A= +}=0A= + =0A= +static int=0A= +ixgbe_set_advertise(struct adapter *adapter)=0A= +{=0A= + int error =3D 0;=0A= + device_t dev;=0A= + struct ixgbe_hw *hw;=0A= + ixgbe_link_speed speed, last;=0A= +=0A= + hw =3D &adapter->hw;=0A= + dev =3D adapter->dev;=0A= + last =3D hw->phy.autoneg_advertised;=0A= +=0A= if (adapter->advertise =3D=3D last) /* no change */=0A= return (0);=0A= =0A= --- sys/dev/ixgbe/ixgbe.h.orig 2012-11-06 12:28:48.969656479 +0000=0A= +++ sys/dev/ixgbe/ixgbe.h 2012-11-06 12:48:39.784556819 +0000=0A= @@ -410,6 +410,7 @@=0A= u32 optics;=0A= u32 fc; /* local flow ctrl setting */=0A= int advertise; /* link speeds */=0A= + bool enable_aim; /* adaptive interrupt moderation */=0A= bool link_active;=0A= u16 max_frame_size;=0A= u16 num_segs;=0A= ------=_NextPart_000_00B9_01CDBD40.74878ED0-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 7 23:46:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97D4F37F; Wed, 7 Nov 2012 23:46:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4F18FC08; Wed, 7 Nov 2012 23:46:32 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1642235pad.13 for ; Wed, 07 Nov 2012 15:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1dOelbSSJQcmAOG7UkuvSb1cLBMTZyKpbOJ4iWxkMlI=; b=ja50FWPvKjt98p3THTqjRR3X6+4CV9DaqAIe1akX3P6wstOIb1j/HO7mpeRFTA51YX NdwNGrmmhBBOWyfXlqwTht9oVwnn/jgeLezzzSzplwCc/DsKXcsCQGnzUmj/UqtX6tGf tWycjPoQkK18mR3MZb8AsZAWeTtmVpOagC8p5yNRShjJMi9ysKwTFygffGUVGESAkfIW yB3EG65eWJjFqIkFZ4rP9R01vwN76Ol2uGT5aq0p3Edg/YmwI9/u7r5A5SQR7E/7Pgr0 2+MvOCy+c+goalaJlUu9pScYFxob6NeaZ1iv8dBQL79V4Dk8ntTJUlUh9FiDyGoaPvMx qarg== MIME-Version: 1.0 Received: by 10.68.137.41 with SMTP id qf9mr18231413pbb.103.1352331992011; Wed, 07 Nov 2012 15:46:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 7 Nov 2012 15:46:31 -0800 (PST) In-Reply-To: <509AEDAC.10002@FreeBSD.org> References: <509AEDAC.10002@FreeBSD.org> Date: Wed, 7 Nov 2012 15:46:31 -0800 X-Google-Sender-Auth: jNar6e2WSwl_0DvDNZnoj8EG93c Message-ID: Subject: Re: [patch] reducing arp locking From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:46:32 -0000 On 7 November 2012 15:24, Alexander V. Chernikov wrote: > Hello list! > > Currently we need to acquire 2 read locks to perform simple 6-byte copying > from arp record to packet ethernet header. > > It seems that acquiring lle lock for fast path (main traffic flow) is not > necessary even with current code. > > My tests shows ~10% improvement with this patch applied. > > If nobody objects I plan to commit this change at the end of next week. That's a great catch! How'd you discover it? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 00:38:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A92A9FB6 for ; Thu, 8 Nov 2012 00:38:56 +0000 (UTC) (envelope-from frederic.perrin@resel.fr) Received: from mail.fperrin.net (mail.fperrin.net [IPv6:2001:41d0:2:2be3::25]) by mx1.freebsd.org (Postfix) with ESMTP id 455408FC0A for ; Thu, 8 Nov 2012 00:38:56 +0000 (UTC) Received: from antre.fperrin.net (antre.priv.fperrin.net [IPv6:fd93:c8e5:9cb3:666::22]) by mail.fperrin.net (Postfix) with ESMTP id 9447733A6 for ; Thu, 8 Nov 2012 01:38:54 +0100 (CET) Received: (from fred@localhost) by antre.fperrin.net (8.14.5/8.14.5/Submit) id qA80crGB077095; Thu, 8 Nov 2012 01:38:53 +0100 (CET) (envelope-from frederic.perrin@resel.fr) X-Authentication-Warning: antre.fperrin.net: fred set sender to frederic.perrin@resel.fr using -f From: =?utf-8?Q?Fr=C3=A9d=C3=A9ric_Perrin?= To: freebsd-net@freebsd.org Subject: Typo in man page for icmp6 Organization: =?utf-8?Q?R=C3=A9seau?= des =?utf-8?B?w4lsw6h2ZXM=?= Date: Thu, 08 Nov 2012 01:38:53 +0100 Message-ID: <86r4o5x71e.fsf@antre.fperrin.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 00:38:56 -0000 Hi list, In the man page for icmp6(4), the setsockopt() option name is ICMP6_FILTER, not ICMPV6_FILTER (RFC3542 and netinet6/in6.h agree). --- /usr/src/share/man/man4/icmp6.4 2012-01-03 04:25:44.000000000 +0100 +++ icmp6.4 2012-11-08 01:02:45.799293040 +0100 @@ -234,7 +234,7 @@ option level .Dv IPPROTO_ICMPV6 and name -.Dv ICMPV6_FILTER +.Dv ICMP6_FILTER with a pointer to the .Vt icmp6_filter structure as the option value. -- Fred From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 00:55:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEDA4446 for ; Thu, 8 Nov 2012 00:55:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 905638FC14 for ; Thu, 8 Nov 2012 00:55:03 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6F09921DF5; Wed, 7 Nov 2012 16:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1352336103; bh=q7gkoHr/GoTx8Y8vGaUgNUPJ54DplU2KRXyAdGZVq30=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=psErzrMz3xbPh7oEvoRjDKe2rz+Jw9SBge1v7H9sqj8eHph1dqgvIHQgF3JroQUlD caJhpQkfk+k6qQGoB5aC78h/226J3afMXNlx49qO7DOtWlaL0VXafX/p7Ll2UtdSm4 HqvYB4UzUDUh/Yruulpfw+THJoV3gY9ssmKCnvKU= Message-ID: <509B02E7.4070608@delphij.net> Date: Wed, 07 Nov 2012 16:55:03 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: =?ISO-8859-1?Q?Fr=E9d=E9ric_Perrin?= Subject: Re: Typo in man page for icmp6 References: <86r4o5x71e.fsf@antre.fperrin.net> In-Reply-To: <86r4o5x71e.fsf@antre.fperrin.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 00:55:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/07/12 16:38, Frédéric Perrin wrote: > Hi list, > > In the man page for icmp6(4), the setsockopt() option name is > ICMP6_FILTER, not ICMPV6_FILTER (RFC3542 and netinet6/in6.h > agree). > > --- /usr/src/share/man/man4/icmp6.4 2012-01-03 > 04:25:44.000000000 +0100 +++ icmp6.4 2012-11-08 > 01:02:45.799293040 +0100 @@ -234,7 +234,7 @@ option level .Dv > IPPROTO_ICMPV6 and name -.Dv ICMPV6_FILTER +.Dv ICMP6_FILTER with a > pointer to the .Vt icmp6_filter structure as the option value. Committed, thanks! Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQmwLnAAoJEG80Jeu8UPuzp10H/AyyJxGacbg14ntZVbPiEJSa ZyU9eHjvaJHiLZK3YnSPm0FR49/5Gqu73lXwVCW5wt16YyV6hSrkXZsCaIWU6cic osSVY2OgPREK2YNeFg9fqs9Dce8SRHue1nwz89i6zGkWsjcG5xf/VDNOx83JQ+mr nGmyIc9Qd+ZE4CyyWpNv9/hEYV+gm234BiwMYf/fBn6Zdv91vub2wtLy5Zi/qj1Z y1mmO6qR/hdYFN9H82ND4W4QUHu/cM0nbS0XEVZNq/xQLD2fj3S0PDky2a+ys+43 Z9WMJaimBNRWW1rmveVXGUhe7cqzIrKc5BlcL30/7nsHzliYbuPPkgKieeoV8EM= =8wJa -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 02:15:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF9F758E; Thu, 8 Nov 2012 02:15:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id B8A3A8FC0A; Thu, 8 Nov 2012 02:15:30 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1724003pad.13 for ; Wed, 07 Nov 2012 18:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ErI1HVLcimIzDCsGrySEB+4h4FYEG9UEO3oN5WEEkJA=; b=CUr8MwbQOOTJyJhh7uJ9webLUrOGmm6spAyjROnomoTFGNmxhh58aVuHSCoVuaBobw p4ZpHEH9feBx5wcdQyPPRkHKvzqxcFMq22bAyt79xTBmmtkZv6WzgpRXPWYq5B5aLnEV CiGWVoXmXHu5KVtJqe1uvZkQV9NRzj6ixmlUAdNEC8Gv3lw8euVniYn8AaGmsSxpT8SQ +MRq8Y2sn95huUymVwCcx/uNlBy6c4VCATt75wXHqzJknVQ+J7mDJLvCADx7flhuAMUb vnV8vvxPy9h8R/A1VKcwV36VEnfiKFRwIInlxzNlI+ZNniYt+HgE3w0JV/G3Q14zIcRL 0GMw== MIME-Version: 1.0 Received: by 10.66.87.105 with SMTP id w9mr18060914paz.5.1352340930526; Wed, 07 Nov 2012 18:15:30 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 7 Nov 2012 18:15:30 -0800 (PST) In-Reply-To: <201211080206.qA826RiN054539@svn.freebsd.org> References: <201211080206.qA826RiN054539@svn.freebsd.org> Date: Wed, 7 Nov 2012 18:15:30 -0800 X-Google-Sender-Auth: DcywpRTnalmexLZ4wwD8DvV_BhI Message-ID: Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti From: Adrian Chadd To: Pyun YongHyeon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 02:15:31 -0000 So I am curious - did this give a real benefit? If so, may I suggest we perhaps accelerate discussing if_transmit() of multiple frames per call? That would allow features like this to be re-enabled. Adrian On 7 November 2012 18:06, Pyun YongHyeon wrote: > Author: yongari > Date: Thu Nov 8 02:06:27 2012 > New Revision: 242739 > URL: http://svnweb.freebsd.org/changeset/base/242739 > > Log: > MFC r242425: > Remove TCP/UDP checksum offloading feature for IP fragmented > datagrams. Traditionally upper stack fragmented packets without > computing TCP/UDP checksum and these datagrams were passed to > driver. But there are chances that other packets slip into the > interface queue in SMP world. If this happens firmware running on > MIPS 4000 processor in the controller would see mixed packets and > it shall send out corrupted packets. > While I'm here simplify checksum offloading setup. > > Modified: > stable/9/sys/dev/ti/if_ti.c > Directory Properties: > stable/9/sys/ (props changed) > stable/9/sys/dev/ (props changed) > > Modified: stable/9/sys/dev/ti/if_ti.c > ============================================================================== > --- stable/9/sys/dev/ti/if_ti.c Thu Nov 8 02:01:04 2012 (r242738) > +++ stable/9/sys/dev/ti/if_ti.c Thu Nov 8 02:06:27 2012 (r242739) > @@ -127,7 +127,7 @@ __FBSDID("$FreeBSD$"); > > #include > > -#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP | CSUM_IP_FRAGS) > +#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP) > /* > * We can only turn on header splitting if we're using extended receive > * BDs. > @@ -3083,16 +3083,10 @@ ti_encap(struct ti_softc *sc, struct mbu > > m = *m_head; > csum_flags = 0; > - if (m->m_pkthdr.csum_flags) { > - if (m->m_pkthdr.csum_flags & CSUM_IP) > - csum_flags |= TI_BDFLAG_IP_CKSUM; > - if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP)) > - csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM; > - if (m->m_flags & M_LASTFRAG) > - csum_flags |= TI_BDFLAG_IP_FRAG_END; > - else if (m->m_flags & M_FRAG) > - csum_flags |= TI_BDFLAG_IP_FRAG; > - } > + if (m->m_pkthdr.csum_flags & CSUM_IP) > + csum_flags |= TI_BDFLAG_IP_CKSUM; > + if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP)) > + csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM; > > frag = sc->ti_tx_saved_prodidx; > for (i = 0; i < nseg; i++) { From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 02:39:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B571EC07; Thu, 8 Nov 2012 02:39:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7002B8FC08; Thu, 8 Nov 2012 02:39:12 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so1026259dad.13 for ; Wed, 07 Nov 2012 18:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=OsP6Dc1/UrKwNwmjmNMKXoYTShtfJoECeOW8Zc36O+o=; b=jpmGH5X5A6T0n4cll05PEgi7xgCcTGY9/0AvL/xoVAJRkG/yDeIC7lBAM/yGZtF0u/ tP+E7jAIhJn6tXndWdHcO5yyyzB0b1xTA5ybi7MF/xhLQttb2zn6fgn6lXOZxjTfhmCI OMW9mh4wABSjhO4a/UD3ixuuaPcsENwxngYUObN7lI1j8ZicvFTWLhHcFN3xAKeGnM3k r3A527kiPgBYaIBtg+VC8u7W7l5IMmH1VnEP8gb7PiMdLUfLl2Ma2Gm3buFUGmSrFLlB SVCz+hukfiGesxM8ZX61tRzH0sWPUECN8wCCalnaTx8HSo3t8sClEZG3X2ZNOGjH2OKz buUw== Received: by 10.66.88.4 with SMTP id bc4mr17954266pab.42.1352342351905; Wed, 07 Nov 2012 18:39:11 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id o5sm15248795paz.32.2012.11.07.18.39.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 18:39:10 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 08 Nov 2012 11:38:58 +0900 From: YongHyeon PYUN Date: Thu, 8 Nov 2012 11:38:58 +0900 To: Adrian Chadd Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti Message-ID: <20121108023858.GA3127@michelle.cdnetworks.com> References: <201211080206.qA826RiN054539@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 02:39:13 -0000 On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote: > So I am curious - did this give a real benefit? In 3.x/4.x days it surely have had helped a lot, I guess mainly because the CPU was not fast enough to saturate the link with software checksum(i.e. NFS over UDP). Generally I prefer correctness to performance and it seems there is no easy way to get full advantage of TCP/UDP checksum offloading of controller on fragmented IP packets on FreeBSD 8+. So I disabled it to reduce the chance of generating corrupted packets. > > If so, may I suggest we perhaps accelerate discussing if_transmit() of > multiple frames per call? Hmm, actually I'm still not a fan of if_transmit() at this moment. Honestly I don't have good queuing code in driver to handle queue full condition. Interactions with altq(9) is also one of my concern as well as packet reordering issue of drbr(9) interface. > That would allow features like this to be re-enabled. > > > > Adrian > > On 7 November 2012 18:06, Pyun YongHyeon wrote: > > Author: yongari > > Date: Thu Nov 8 02:06:27 2012 > > New Revision: 242739 > > URL: http://svnweb.freebsd.org/changeset/base/242739 > > > > Log: > > MFC r242425: > > Remove TCP/UDP checksum offloading feature for IP fragmented > > datagrams. Traditionally upper stack fragmented packets without > > computing TCP/UDP checksum and these datagrams were passed to > > driver. But there are chances that other packets slip into the > > interface queue in SMP world. If this happens firmware running on > > MIPS 4000 processor in the controller would see mixed packets and > > it shall send out corrupted packets. > > While I'm here simplify checksum offloading setup. > > > > Modified: > > stable/9/sys/dev/ti/if_ti.c > > Directory Properties: > > stable/9/sys/ (props changed) > > stable/9/sys/dev/ (props changed) > > > > Modified: stable/9/sys/dev/ti/if_ti.c > > ============================================================================== > > --- stable/9/sys/dev/ti/if_ti.c Thu Nov 8 02:01:04 2012 (r242738) > > +++ stable/9/sys/dev/ti/if_ti.c Thu Nov 8 02:06:27 2012 (r242739) > > @@ -127,7 +127,7 @@ __FBSDID("$FreeBSD$"); > > > > #include > > > > -#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP | CSUM_IP_FRAGS) > > +#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP) > > /* > > * We can only turn on header splitting if we're using extended receive > > * BDs. > > @@ -3083,16 +3083,10 @@ ti_encap(struct ti_softc *sc, struct mbu > > > > m = *m_head; > > csum_flags = 0; > > - if (m->m_pkthdr.csum_flags) { > > - if (m->m_pkthdr.csum_flags & CSUM_IP) > > - csum_flags |= TI_BDFLAG_IP_CKSUM; > > - if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP)) > > - csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM; > > - if (m->m_flags & M_LASTFRAG) > > - csum_flags |= TI_BDFLAG_IP_FRAG_END; > > - else if (m->m_flags & M_FRAG) > > - csum_flags |= TI_BDFLAG_IP_FRAG; > > - } > > + if (m->m_pkthdr.csum_flags & CSUM_IP) > > + csum_flags |= TI_BDFLAG_IP_CKSUM; > > + if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP)) > > + csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM; > > > > frag = sc->ti_tx_saved_prodidx; > > for (i = 0; i < nseg; i++) { From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 02:52:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48B47ECF for ; Thu, 8 Nov 2012 02:52:56 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8948FC08 for ; Thu, 8 Nov 2012 02:52:54 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id c10so1121179eaa.13 for ; Wed, 07 Nov 2012 18:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PkNOLnUW4dwvKcDg7ryfFVxcyYrLlmlTyT1XIwA0pfE=; b=hnkGBFtqrtg8dwOZYGKXT2htACePN9W4yYvOy4OYbJi7OfZ4dv7Lh9Bzwxb6yEiMv1 oWiXCEIBwLtXBo6jZXKgx3LAOKmdbk1GZdSAfJoluSekjj8PdzOJxwsTWC4SEfiRTx4b qFug0wb3wYIP3DBx+qoC4kCtgfoTqmChwReoCNtAWSMuuZRHtlEp6U+kG+AtcZvzkrij 09oxLMxhKLsbxPjfnw8exQ8LJ1iSTvU5DKpFPkJjl6APv/egYVYn4P/Xczqr48EmDy3W Vwqa/KJ0Tn16mx0MQs9bPLJ3O59Ody2u2rQLODaYB4AY6TaUoH6GX6r7jCkLzHnWJrgU 0SHw== MIME-Version: 1.0 Received: by 10.14.173.67 with SMTP id u43mr22462245eel.27.1352343173680; Wed, 07 Nov 2012 18:52:53 -0800 (PST) Received: by 10.14.176.7 with HTTP; Wed, 7 Nov 2012 18:52:53 -0800 (PST) Date: Wed, 7 Nov 2012 18:52:53 -0800 Message-ID: Subject: SSL with kernel sockets From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 02:52:56 -0000 Hi, I am working on a project with FreeBSD that requires the use of SSL with kernel sockets (in a kmod). Does FreeBSD support this? From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 04:53:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3274E0E; Thu, 8 Nov 2012 04:53:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B86F78FC08; Thu, 8 Nov 2012 04:53:20 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz17so99809pbc.13 for ; Wed, 07 Nov 2012 20:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=f/DGVy/ZIitPcRqTGq2rF/a4iXJspF2SS3isMtqv5+U=; b=wsU7zKMVW85CdYHfxbiC6aGCbnJ0j4puH7LJ9wm1SVRbufrTEStKj1+AutVtFKDDWW sR60AB76gCgOv+NKSiwgGON3wwUJRD9cn7GTuhFQft43ZX/v53AcX/sB+/sPQk2pyzNq ficz2SV4TbM47EBrB/snEmWn/fKA2hV0JhRNrrBtUvWRj6M3SS0kPrhgoE2gYMOkI47E oOFK7DYsD+uQ+m4DvBfy1+JFTnPgrrKa2BY25ikTRZ4vMXESu/4uE58FrCfgITxb0/vV pl7TZogs0E6zUa7pan6OAVXJGQEouBHfWlY90TZrvFd/715+vCf9G3FOKScGd6zbLSQ6 Z5XQ== MIME-Version: 1.0 Received: by 10.68.193.228 with SMTP id hr4mr13983003pbc.95.1352350394785; Wed, 07 Nov 2012 20:53:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 7 Nov 2012 20:53:14 -0800 (PST) In-Reply-To: <20121108023858.GA3127@michelle.cdnetworks.com> References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> Date: Wed, 7 Nov 2012 20:53:14 -0800 X-Google-Sender-Auth: QPBcv0wSdhb1ckrDWcts1xvUv20 Message-ID: Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti From: Adrian Chadd To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 04:53:21 -0000 On 7 November 2012 18:38, YongHyeon PYUN wrote: > On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote: >> So I am curious - did this give a real benefit? > > In 3.x/4.x days it surely have had helped a lot, I guess mainly > because the CPU was not fast enough to saturate the link with > software checksum(i.e. NFS over UDP). Right. > Generally I prefer correctness to performance and it seems there > is no easy way to get full advantage of TCP/UDP checksum offloading > of controller on fragmented IP packets on FreeBSD 8+. So I disabled > it to reduce the chance of generating corrupted packets. Right. The problem here is that if_transmit pushes the locking to the driver, but there's no way to guarantee that the frames aren't interleaved with other parallel invocations of if_transmit(). Since SMP in 3.x and 4.x didn't really support multiple CPUs in kernel space, this wouldn't have been a problem. Ie, the network layer didn't explicitly define the behaviour with concurrent kernel senders, because that concept didn't exist yet. >> If so, may I suggest we perhaps accelerate discussing if_transmit() of >> multiple frames per call? > > Hmm, actually I'm still not a fan of if_transmit() at this moment. > Honestly I don't have good queuing code in driver to handle queue > full condition. Interactions with altq(9) is also one of my > concern as well as packet reordering issue of drbr(9) interface. > Well, can you provide me with some embedded hardware that has this particular NIC and multiple CPUs? I'd like to tinker with this but the SMP systems I have contain em NICs and I don't really feel up to hacking up this idea on the em(4) driver. :-) I have a vague idea of making if_transmit() as an interface be able to send multiple frames at once - so the TCP/UDP code could generate all the fragments and fire them off at once to the NIC. This should fix your issue and begin allowing devices to take advantage of multiple-dispatch rather than one if_transmit() call at a time. We could create a device or interface flag that indicates whether the driver can handle multiple mbufs chained via m_nextpkt through if_transmit(), and then teach one or two drivers that particular logic. What do you think? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 10:18:04 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FB7DC31 for ; Thu, 8 Nov 2012 10:18:04 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 984768FC22 for ; Thu, 8 Nov 2012 10:18:02 +0000 (UTC) Received: (qmail 64186 invoked from network); 8 Nov 2012 11:53:10 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 11:53:10 -0000 Message-ID: <509B86D5.6090401@networx.ch> Date: Thu, 08 Nov 2012 11:17:57 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: arp/ndp default hash size References: <509AE539.5050102@FreeBSD.org> In-Reply-To: <509AE539.5050102@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 10:18:04 -0000 On 07.11.2012 23:48, Alexander V. Chernikov wrote: > Hello list! > > Currently size of arp/ndp hash is the following: > #define LLTBL_HASHTBL_SIZE 32 /* default 32 ? */ > > This may be OK for end hosts, but this is definitely not enough for router howadays. Especially > given that IPv6 hosts generate 2 ndp records. > > Output from 2 random v4 / v6 routers from my $job: > 2:23 [0] m@matisse arp -an | wc -l > 1494 > 2:24 [0] m@singapore ndp -an | wc -l > 3999 > > Given that LIST_HEAD is just a pointer, and we currently have single global (actually per-VNET) > instance for every l3 proto, bumping hash to, say, at least 4096 should do no harm. A small list per hash bucket isn't bad. The hash should be about 1/4 of the expected table size. One problem here may be the memory consumption on smaller systems. A very large hash table size may hurt and isn't needed for a few entries. For a compromise I'd say the default hash table size should be 256 or 512. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 10:24:23 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0251610E for ; Thu, 8 Nov 2012 10:24:23 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 598868FC17 for ; Thu, 8 Nov 2012 10:24:21 +0000 (UTC) Received: (qmail 64230 invoked from network); 8 Nov 2012 11:59:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 11:59:29 -0000 Message-ID: <509B884F.7040106@networx.ch> Date: Thu, 08 Nov 2012 11:24:15 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> In-Reply-To: <509AEDAC.10002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 10:24:23 -0000 On 08.11.2012 00:24, Alexander V. Chernikov wrote: > Hello list! > > Currently we need to acquire 2 read locks to perform simple 6-byte copying from arp record to packet > ethernet header. > > It seems that acquiring lle lock for fast path (main traffic flow) is not necessary even with > current code. > > My tests shows ~10% improvement with this patch applied. > > If nobody objects I plan to commit this change at the end of next week. This is risky and prone to race conditions. The copy of the MAC address should be done while the table read lock is held to protect against the entry going away. You can either return with table lock held and drop it after the copy, or you could a modified lookup function that takes a pointer for the copy destination, do the copy with the read lock, and then return. If no entry is found an error is returned and obviously no copy is done. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 10:27:57 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE3CA27A; Thu, 8 Nov 2012 10:27:57 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 544CB8FC0C; Thu, 8 Nov 2012 10:27:57 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWPOO-000OgF-Ip; Thu, 08 Nov 2012 14:31:24 +0400 Message-ID: <509B88B1.3070905@FreeBSD.org> Date: Thu, 08 Nov 2012 14:25:53 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> In-Reply-To: <509B884F.7040106@networx.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 10:27:57 -0000 On 08.11.2012 14:24, Andre Oppermann wrote: > On 08.11.2012 00:24, Alexander V. Chernikov wrote: >> Hello list! >> >> Currently we need to acquire 2 read locks to perform simple 6-byte >> copying from arp record to packet >> ethernet header. >> >> It seems that acquiring lle lock for fast path (main traffic flow) is >> not necessary even with >> current code. >> >> My tests shows ~10% improvement with this patch applied. >> >> If nobody objects I plan to commit this change at the end of next week. > > This is risky and prone to race conditions. The copy of the MAC address > should be done while the table read lock is held to protect against the It is done exactly as you say: table read lock is held. > entry going away. You can either return with table lock held and drop > it after the copy, or you could a modified lookup function that takes a > pointer for the copy destination, do the copy with the read lock, and then > return. If no entry is found an error is returned and obviously no copy > is done. > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 10:39:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2EFB878F for ; Thu, 8 Nov 2012 10:39:30 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 80E1A8FC19 for ; Thu, 8 Nov 2012 10:39:29 +0000 (UTC) Received: (qmail 64326 invoked from network); 8 Nov 2012 12:14:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 12:14:36 -0000 Message-ID: <509B8BDB.4070000@networx.ch> Date: Thu, 08 Nov 2012 11:39:23 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti References: <201211080206.qA826RiN054539@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 10:39:30 -0000 On 08.11.2012 03:15, Adrian Chadd wrote: > So I am curious - did this give a real benefit? No. Not really. The only place where it would have helped was with locally sourced packets (from a socket) that are larger than the MTU. For TCP we set the DF bit (don't fragment) so we get EMSGSIZE when the MTU is smaller than the packet and no fragmentation happens in any case. For UDP fragmentation does happen. However the UDP checksum is optional and disabled by default anyway. So UDP fragment checksum offloading wouldn't be a gain either way. What really helps here is full UDP fragmentation offload (like TSO TCP segmentation offload) where a large packet is passed down and the NIC splits it up into MTU sized packets by itself. Intel and Broadcom do support that but the feature lay dormant and wasn't exposed to the stack so far. I've added support for that in my tcp_workqueue branch and plan on merging it to HEAD once shaken out. It may be that cards other than Intel and Broadcom support it as well but so far I've only read the datasheet of those two. For forwarded packets no payload checksum has to be recalculated on fragmentation, only the IP header checksum is recomputed. That is still working. -- Andre > If so, may I suggest we perhaps accelerate discussing if_transmit() of > multiple frames per call? > That would allow features like this to be re-enabled. > > > > Adrian > > On 7 November 2012 18:06, Pyun YongHyeon wrote: >> Author: yongari >> Date: Thu Nov 8 02:06:27 2012 >> New Revision: 242739 >> URL: http://svnweb.freebsd.org/changeset/base/242739 >> >> Log: >> MFC r242425: >> Remove TCP/UDP checksum offloading feature for IP fragmented >> datagrams. Traditionally upper stack fragmented packets without >> computing TCP/UDP checksum and these datagrams were passed to >> driver. But there are chances that other packets slip into the >> interface queue in SMP world. If this happens firmware running on >> MIPS 4000 processor in the controller would see mixed packets and >> it shall send out corrupted packets. >> While I'm here simplify checksum offloading setup. >> >> Modified: >> stable/9/sys/dev/ti/if_ti.c >> Directory Properties: >> stable/9/sys/ (props changed) >> stable/9/sys/dev/ (props changed) >> From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 10:48:28 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AC47CD5 for ; Thu, 8 Nov 2012 10:48:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 83DF38FC0C for ; Thu, 8 Nov 2012 10:48:27 +0000 (UTC) Received: (qmail 64365 invoked from network); 8 Nov 2012 12:23:34 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 12:23:34 -0000 Message-ID: <509B8DF5.5010101@freebsd.org> Date: Thu, 08 Nov 2012 11:48:21 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> In-Reply-To: <509B88B1.3070905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 10:48:28 -0000 On 08.11.2012 11:25, Alexander V. Chernikov wrote: > On 08.11.2012 14:24, Andre Oppermann wrote: >> On 08.11.2012 00:24, Alexander V. Chernikov wrote: >>> Hello list! >>> >>> Currently we need to acquire 2 read locks to perform simple 6-byte >>> copying from arp record to packet >>> ethernet header. >>> >>> It seems that acquiring lle lock for fast path (main traffic flow) is >>> not necessary even with >>> current code. >>> >>> My tests shows ~10% improvement with this patch applied. >>> >>> If nobody objects I plan to commit this change at the end of next week. >> >> This is risky and prone to race conditions. The copy of the MAC address >> should be done while the table read lock is held to protect against the > It is done exactly as you say: table read lock is held. Right. Sorry. I didn't immediately get that the IF_AFDATA_LOCK is the table lock. -- Andre >> entry going away. You can either return with table lock held and drop >> it after the copy, or you could a modified lookup function that takes a >> pointer for the copy destination, do the copy with the read lock, and then >> return. If no entry is found an error is returned and obviously no copy >> is done. >> > > From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 11:13:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 227F9987 for ; Thu, 8 Nov 2012 11:13:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C1798FC0C for ; Thu, 8 Nov 2012 11:13:20 +0000 (UTC) Received: (qmail 64485 invoked from network); 8 Nov 2012 12:48:27 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 12:48:27 -0000 Message-ID: <509B93CA.90609@freebsd.org> Date: Thu, 08 Nov 2012 12:13:14 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> In-Reply-To: <20121108023858.GA3127@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Adrian Chadd , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 11:13:22 -0000 On 08.11.2012 03:38, YongHyeon PYUN wrote: > On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote: >> If so, may I suggest we perhaps accelerate discussing if_transmit() of >> multiple frames per call? > > Hmm, actually I'm still not a fan of if_transmit() at this moment. > Honestly I don't have good queuing code in driver to handle queue > full condition. Interactions with altq(9) is also one of my > concern as well as packet reordering issue of drbr(9) interface. The whole interface packet handoff needs some serious reconsideration. These days we have two queues/buffers at the interfaces. One is the DMA ring which can take a considerable number of packets and the second one is the ifq (if enabled). The DMA ring already adds significant depth and latency so that a packet scheduler like altq(9) become almost useless. Also modern queue management algorithms like CoDel don't work with the current framework. Also bufferbloat is a major concern. See ACM queue article by Jim Gettys. What we need to take make this functionality available again is a well specified and reasonably simple interface handoff. It should include information on the maximum tx DMA ring depth and the current depth. There should also be a function to limit the current depth to a certain value. What I'd like to see is this (names are not fixed): if_send() as the main entry point for the stack. It's a function pointer within struct ifnet. In normal operation it is the same as if_transmit() and directly adds a packet to the tx DMA ring. Locking of the DMA ring is done in this function and a property of the driver. The stack always calls unlocked. Obviously the tx DMA ring lock must not be a sleep lock. When altq(9) or equivalent is active this function pointer is replaced with a call to the alternative queuing function that does it's magic. Again locking of the queuing mechanism is the property of that mechanism. When a NIC has multiple queues that it can bind to CPU's locking may not be necessary. We gain this flexibility in the driver to do that. if_transmit() is a function pointer for a function that directly adds a packet to the tx DMA ring (if a free slot is available). It is never called by the stack directly except in special circumstances. The altq(9), if active, uses if_transmit() to add packets to the tx DMA ring. If not active, if_send() is this function pointer. if_txeof() is a function pointer for a callback from the driver to an altq(9) dequeue function, if active. It is called when when new free slots on the tx DMA ring are available. When a driver needs a software interface queue because the tx DMA is too small, then the stack should provide a generic queuing implementation the driver can use. I've begun to explore this area while hacking on bge(4) and em(4) in tcp_workqueue branch. It's a very interesting path and we going to have a couple more discussions before we arrive at the optimal solution. :) -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 14:34:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78BB14DD for ; Thu, 8 Nov 2012 14:34:18 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C95208FC19 for ; Thu, 8 Nov 2012 14:34:17 +0000 (UTC) Received: (qmail 66037 invoked from network); 8 Nov 2012 16:09:22 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 16:09:22 -0000 Message-ID: <509BC2E2.4030907@freebsd.org> Date: Thu, 08 Nov 2012 15:34:10 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:34:18 -0000 On 08.11.2012 05:53, Adrian Chadd wrote: > On 7 November 2012 18:38, YongHyeon PYUN wrote: >> On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote: >>> If so, may I suggest we perhaps accelerate discussing if_transmit() of >>> multiple frames per call? >> >> Hmm, actually I'm still not a fan of if_transmit() at this moment. >> Honestly I don't have good queuing code in driver to handle queue >> full condition. Interactions with altq(9) is also one of my >> concern as well as packet reordering issue of drbr(9) interface. >> -snip- > > I have a vague idea of making if_transmit() as an interface be able to > send multiple frames at once - so the TCP/UDP code could generate all > the fragments and fire them off at once to the NIC. This should fix > your issue and begin allowing devices to take advantage of > multiple-dispatch rather than one if_transmit() call at a time. TCP/UDP doesn't (want to) generate any fragments at all and tries to avoid it at almost all cost. We want to send very large packets and have the NIC fragment/segment it (TSO/UDP frag offload). > We could create a device or interface flag that indicates whether the > driver can handle multiple mbufs chained via m_nextpkt through > if_transmit(), and then teach one or two drivers that particular > logic. Agreed. I think that's the way to go. It must be very well specified in semantics though. Otherwise it's just too easy to leak mbuf all over the place. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 17:00:02 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7698ABA3 for ; Thu, 8 Nov 2012 17:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6DF8FC19 for ; Thu, 8 Nov 2012 17:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8H01ZI052158 for ; Thu, 8 Nov 2012 17:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8H01g5052157; Thu, 8 Nov 2012 17:00:01 GMT (envelope-from gnats) Date: Thu, 8 Nov 2012 17:00:01 GMT Message-Id: <201211081700.qA8H01g5052157@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Ingo Flaschberger Subject: Re: kern/156283: [ip6] [patch] nd6_ns_input - rtalloc_mpath does not return a locked rtentry X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ingo Flaschberger List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:00:02 -0000 The following reply was made to PR kern/156283; it has been noted by GNATS. From: Ingo Flaschberger To: bug-followup@FreeBSD.org, if@FreeBSD.org Cc: Subject: Re: kern/156283: [ip6] [patch] nd6_ns_input - rtalloc_mpath does not return a locked rtentry Date: Thu, 08 Nov 2012 17:55:11 +0100 Why is this bug not fixed in tree? From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 19:23:38 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 688A7932; Thu, 8 Nov 2012 19:23:38 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 34DE98FC08; Thu, 8 Nov 2012 19:23:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8JNcuG062975; Thu, 8 Nov 2012 19:23:38 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8JNcNA062971; Thu, 8 Nov 2012 19:23:38 GMT (envelope-from eadler) Date: Thu, 8 Nov 2012 19:23:38 GMT Message-Id: <201211081923.qA8JNcNA062971@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: kern/173481: [NFS] RH63 NFSv4 client does not reconnect to FreeBSD 9.1RC3 NFSv4 server after server is rebooted X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:23:38 -0000 Old Synopsis: RH63 NFSv4 client does not reconnect to FreeBSD 9.1RC3 NFSv4 server after server is rebooted New Synopsis: [NFS] RH63 NFSv4 client does not reconnect to FreeBSD 9.1RC3 NFSv4 server after server is rebooted Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Thu Nov 8 19:23:13 UTC 2012 Responsible-Changed-Why: change synopsis and assign http://www.freebsd.org/cgi/query-pr.cgi?pr=173481 From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 19:33:43 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 147BFC7F; Thu, 8 Nov 2012 19:33:43 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D57D08FC08; Thu, 8 Nov 2012 19:33:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8JXg1k063397; Thu, 8 Nov 2012 19:33:42 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8JXg3l063393; Thu, 8 Nov 2012 19:33:42 GMT (envelope-from eadler) Date: Thu, 8 Nov 2012 19:33:42 GMT Message-Id: <201211081933.qA8JXg3l063393@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:33:43 -0000 Old Synopsis: chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client New Synopsis: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Thu Nov 8 19:33:17 UTC 2012 Responsible-Changed-Why: change synopsis and assign http://www.freebsd.org/cgi/query-pr.cgi?pr=173479 From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 19:46:06 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7837FFCA; Thu, 8 Nov 2012 19:46:06 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 477418FC18; Thu, 8 Nov 2012 19:46:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8Jk6W5064293; Thu, 8 Nov 2012 19:46:06 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8Jk6vf064289; Thu, 8 Nov 2012 19:46:06 GMT (envelope-from eadler) Date: Thu, 8 Nov 2012 19:46:06 GMT Message-Id: <201211081946.qA8Jk6vf064289@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: kern/173478: icmp forward bandwithlimit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:46:06 -0000 Synopsis: icmp forward bandwithlimit Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Thu Nov 8 19:45:47 UTC 2012 Responsible-Changed-Why: over to net http://www.freebsd.org/cgi/query-pr.cgi?pr=173478 From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 21:39:28 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D276CE3 for ; Thu, 8 Nov 2012 21:39:28 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 328D88FC14 for ; Thu, 8 Nov 2012 21:39:28 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWZsF-0003Mq-Bp; Fri, 09 Nov 2012 01:42:55 +0400 Message-ID: <509C2681.9020303@FreeBSD.org> Date: Fri, 09 Nov 2012 01:39:13 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: arp/ndp default hash size References: <509AE539.5050102@FreeBSD.org> <509B86D5.6090401@networx.ch> In-Reply-To: <509B86D5.6090401@networx.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:39:28 -0000 On 08.11.2012 14:17, Andre Oppermann wrote: > On 07.11.2012 23:48, Alexander V. Chernikov wrote: >> Hello list! >> >> Currently size of arp/ndp hash is the following: >> #define LLTBL_HASHTBL_SIZE 32 /* default 32 ? */ >> >> This may be OK for end hosts, but this is definitely not enough for >> router howadays. Especially >> given that IPv6 hosts generate 2 ndp records. >> >> Output from 2 random v4 / v6 routers from my $job: >> 2:23 [0] m@matisse arp -an | wc -l >> 1494 >> 2:24 [0] m@singapore ndp -an | wc -l >> 3999 >> >> Given that LIST_HEAD is just a pointer, and we currently have single >> global (actually per-VNET) >> instance for every l3 proto, bumping hash to, say, at least 4096 >> should do no harm. > > A small list per hash bucket isn't bad. The hash should be about 1/4 > of the expected table size. > > One problem here may be the memory consumption on smaller systems. A > very large hash table size may hurt and isn't needed for a few entries. I was afraid of proposing too small hash size. 4k costs 16kbytes which is not much nowadays :) > > For a compromise I'd say the default hash table size should be 256 or 512. For me, 512 seems to be quite good default for generic box. > From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 21:48:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D476126F; Thu, 8 Nov 2012 21:48:22 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7458FC08; Thu, 8 Nov 2012 21:48:22 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWa0r-0003QI-UJ; Fri, 09 Nov 2012 01:51:50 +0400 Message-ID: <509C2899.8010701@FreeBSD.org> Date: Fri, 09 Nov 2012 01:48:09 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:48:23 -0000 On 08.11.2012 03:46, Adrian Chadd wrote: > On 7 November 2012 15:24, Alexander V. Chernikov wrote: >> Hello list! >> >> Currently we need to acquire 2 read locks to perform simple 6-byte copying >> from arp record to packet ethernet header. >> >> It seems that acquiring lle lock for fast path (main traffic flow) is not >> necessary even with current code. >> >> My tests shows ~10% improvement with this patch applied. >> >> If nobody objects I plan to commit this change at the end of next week. > > That's a great catch! How'd you discover it? We have lots of FreeBSD routers doing 10G firewalling, so we're very much concerned with forwarding/firewalling performance, constantly looking for something to optimize :) > > > > Adrian > From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 23:33:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11028EF7; Thu, 8 Nov 2012 23:33:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C51BC8FC12; Thu, 8 Nov 2012 23:32:59 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz17so791012pbc.13 for ; Thu, 08 Nov 2012 15:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EdAfVcmobIuGRHeDqQbtGSRe1a1SHLbU8snzTpLwqMQ=; b=hpTFQyHSY29vT6NR2Ui+FzHprrVgn6EXzn1FtdhqUF3TtuU3/DHt1UaJv4zyCEuNaO hwFU4e5p2iCtmfnxeTw93Vwk/OIaV2/DLt4fpV87kQbPBf1GQc7DlOBLB530NzSV2jua KYFQMzqEeAbxVKKn1dTTfJPBpPI23o0DFFYJHpxfAVnfq+xKsfPodGsco/qDN0xeFRiO Y0EnVIHfrhBFzTB+ItjP7rvy+KmkKwrIiNBJZtg1B1SD7B5RPcbEE5ttGM4dK4xOo/Rf ZOMB/lyjnBuAptsAVCO09gzdxt2/xpVvC2QXtBlCrrtJizMO4+yn7UTeAN61S2GPeZJG Rihw== MIME-Version: 1.0 Received: by 10.68.209.166 with SMTP id mn6mr376748pbc.95.1352417579609; Thu, 08 Nov 2012 15:32:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 8 Nov 2012 15:32:59 -0800 (PST) In-Reply-To: <509BC2E2.4030907@freebsd.org> References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> <509BC2E2.4030907@freebsd.org> Date: Thu, 8 Nov 2012 15:32:59 -0800 X-Google-Sender-Auth: DHIUUH5FPDDmDKcoGoowNfKBwSY Message-ID: Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti From: Adrian Chadd To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:33:00 -0000 On 8 November 2012 06:34, Andre Oppermann wrote: > TCP/UDP doesn't (want to) generate any fragments at all and tries > to avoid it at almost all cost. We want to send very large packets > and have the NIC fragment/segment it (TSO/UDP frag offload). What about if it's a router and the frames don't have DF set? Not that it should happen often, however.. > >> We could create a device or interface flag that indicates whether the >> driver can handle multiple mbufs chained via m_nextpkt through >> if_transmit(), and then teach one or two drivers that particular >> logic. > > > Agreed. I think that's the way to go. It must be very well specified > in semantics though. Otherwise it's just too easy to leak mbuf all > over the place. I mentioned this to Robert Watson today at the FreeBSD vendor summit and he said much the same thing about testing and assertions. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 23:34:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50596F92; Thu, 8 Nov 2012 23:34:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 126F58FC0A; Thu, 8 Nov 2012 23:34:34 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so2513668pad.13 for ; Thu, 08 Nov 2012 15:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=URQTbeENgXzGY55hA2nMfhJn87xUmnN4dLd+ppBblfM=; b=gBTkcdxkaw2tPkwHKHskDXIHljpGeABoh680jNEd6fmQDNlVHAuTEbUTkt7RIw1U8r Md7Bdue8qgIM7NbwQdBPC/PP01SAV3ymX7Y2s9k4PRdleGsO1cAc2TZ9oTRzYBtIPTSC NppMQ5rYV6RS7UOVgK3resW3tff+P8wysl+zCBkPSrOgS9RD3CBUgFeBllPdjpPCC335 SfOy6pxu5mkm28XTAC+kmjWwxSiANZbJyi81FwYqw+ucbCoZM6V2ygbZOxF0iqjuPKCF Vg5DjEprXCrW4IXn9gq7pVqeQM7h98bv8r4O/z/El78s/Prm4qh6T2EiXjhyCaePfawl 0Nsg== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr27994955pbc.105.1352417674573; Thu, 08 Nov 2012 15:34:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 8 Nov 2012 15:34:34 -0800 (PST) In-Reply-To: <509C2899.8010701@FreeBSD.org> References: <509AEDAC.10002@FreeBSD.org> <509C2899.8010701@FreeBSD.org> Date: Thu, 8 Nov 2012 15:34:34 -0800 X-Google-Sender-Auth: d6ANbmtUjZmxzKr_bHId9NUGox8 Message-ID: Subject: Re: [patch] reducing arp locking From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:34:35 -0000 On 8 November 2012 13:48, Alexander V. Chernikov wrote: >> That's a great catch! How'd you discover it? > > We have lots of FreeBSD routers doing 10G firewalling, so we're very much > concerned with forwarding/firewalling performance, constantly looking for > something to optimize :) I mean, how'd you go about finding it? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 23:44:06 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 879964B7; Thu, 8 Nov 2012 23:44:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 550728FC08; Thu, 8 Nov 2012 23:44:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8Ni6V0081221; Thu, 8 Nov 2012 23:44:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8Ni6pQ081217; Thu, 8 Nov 2012 23:44:06 GMT (envelope-from linimon) Date: Thu, 8 Nov 2012 23:44:06 GMT Message-Id: <201211082344.qA8Ni6pQ081217@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is terminated X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:44:06 -0000 Old Synopsis: /dev/tun stayes opened by PID after process is terminated New Synopsis: [tun] tun(4) stays opened by PID after process is terminated Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 8 23:43:39 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173475 From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 23:49:10 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA1DD90A; Thu, 8 Nov 2012 23:49:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B848E8FC08; Thu, 8 Nov 2012 23:49:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8NnAwq081746; Thu, 8 Nov 2012 23:49:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8NnAM2081742; Thu, 8 Nov 2012 23:49:10 GMT (envelope-from linimon) Date: Thu, 8 Nov 2012 23:49:10 GMT Message-Id: <201211082349.qA8NnAM2081742@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173444: [socket] [patch] IPV6_USE_MIN_MTU and TCP is broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:49:11 -0000 Old Synopsis: IPV6_USE_MIN_MTU and TCP is broken New Synopsis: [socket] [patch] IPV6_USE_MIN_MTU and TCP is broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 8 23:48:35 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173444 From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 23:56:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 862F1E11 for ; Thu, 8 Nov 2012 23:56:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D6DD18FC15 for ; Thu, 8 Nov 2012 23:56:01 +0000 (UTC) Received: (qmail 68915 invoked from network); 9 Nov 2012 01:30:56 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2012 01:30:56 -0000 Message-ID: <509C4684.2030102@freebsd.org> Date: Fri, 09 Nov 2012 00:55:48 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> <509BC2E2.4030907@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:56:02 -0000 On 09.11.2012 00:32, Adrian Chadd wrote: > On 8 November 2012 06:34, Andre Oppermann wrote: > >> TCP/UDP doesn't (want to) generate any fragments at all and tries >> to avoid it at almost all cost. We want to send very large packets >> and have the NIC fragment/segment it (TSO/UDP frag offload). > > What about if it's a router and the frames don't have DF set? At the risk of repeating myself: when a routed packet is fragmented the payload (layer 4, eg. TCP/UDP/SCTP) is NOT recalculated or changed or anything else. It remains as originally calculated by the sender unchanged in the first fragment L4 header. Only the IPv4 header checksum, which DOES NOT include any payload data, has to be calculated for every fragment. The IPv4 header checksum is offloaded with CSUM_IP and continues to work as expected. :) > Not that it should happen often, however.. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 23:58:42 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9D5DEC6; Thu, 8 Nov 2012 23:58:42 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 775E78FC08; Thu, 8 Nov 2012 23:58:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA8NwgSm082526; Thu, 8 Nov 2012 23:58:42 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA8Nwg9t082521; Thu, 8 Nov 2012 23:58:42 GMT (envelope-from andre) Date: Thu, 8 Nov 2012 23:58:42 GMT Message-Id: <201211082358.qA8Nwg9t082521@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Subject: Re: kern/173444: [socket] [patch] IPV6_USE_MIN_MTU and TCP is broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 23:58:42 -0000 Synopsis: [socket] [patch] IPV6_USE_MIN_MTU and TCP is broken Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Thu Nov 8 23:58:17 UTC 2012 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=173444 From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 00:00:53 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B257EF99; Fri, 9 Nov 2012 00:00:53 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 820AA8FC13; Fri, 9 Nov 2012 00:00:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA900rNO082917; Fri, 9 Nov 2012 00:00:53 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA900rO9082911; Fri, 9 Nov 2012 00:00:53 GMT (envelope-from andre) Date: Fri, 9 Nov 2012 00:00:53 GMT Message-Id: <201211090000.qA900rO9082911@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Subject: Re: kern/173478: [netinet] [patch] icmp forward bandwithlimit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 00:00:53 -0000 Synopsis: [netinet] [patch] icmp forward bandwithlimit Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Fri Nov 9 00:00:22 UTC 2012 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=173478 From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 00:19:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 151A440A; Fri, 9 Nov 2012 00:19:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C7AC78FC13; Fri, 9 Nov 2012 00:19:50 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz17so813733pbc.13 for ; Thu, 08 Nov 2012 16:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RYrRdswpXPfxx96Ck618vgr7e1I6lkDLkqjapFDUIbI=; b=e4CuW3TwjairgcvpfMGfHkgtNdHRDnQGJdUt+2dXDEBIaaxAvUr2RgmWIaI0P8KGdG N1XCJXaMF7Kg7C3JqyKSmTuBCSHRKRqMjvjsA8VbKO2EeQfce6HhDL6RKkSb53Ra0jpv hav5iJ/yJSNB/I/HJSQHMH4qMWCyE7y0+t3o2IEjR8DuSpFV4yipIBa83NH36MJys9QW TvAYuF4AAQ6M6Vh77kObJ3ZvlANqZl7webSrcEiuTIiZxFaEkSvhcJbmNUS81isibqw9 sHkZeggTzJdXkDg/dSuE8CbnvAuXh3wITGHGTaYbYgYGhYP3+ErCKul9N2H0TcNV5Ag9 eJAQ== MIME-Version: 1.0 Received: by 10.68.137.41 with SMTP id qf9mr28519532pbb.103.1352420389961; Thu, 08 Nov 2012 16:19:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 8 Nov 2012 16:19:49 -0800 (PST) In-Reply-To: <509C4684.2030102@freebsd.org> References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> <509BC2E2.4030907@freebsd.org> <509C4684.2030102@freebsd.org> Date: Thu, 8 Nov 2012 16:19:49 -0800 X-Google-Sender-Auth: RZWDD5-PLwSborZc6YXzW5GBlMs Message-ID: Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti From: Adrian Chadd To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 00:19:51 -0000 On 8 November 2012 15:55, Andre Oppermann wrote: > At the risk of repeating myself: when a routed packet is fragmented > the payload (layer 4, eg. TCP/UDP/SCTP) is NOT recalculated or changed > or anything else. It remains as originally calculated by the sender > unchanged in the first fragment L4 header. Only the IPv4 header > checksum, which DOES NOT include any payload data, has to be calculated > for every fragment. The IPv4 header checksum is offloaded with CSUM_IP > and continues to work as expected. :) NAT and firewalling? :) Adrian From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 00:22:57 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7D6D59D for ; Fri, 9 Nov 2012 00:22:57 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 589808FC12 for ; Fri, 9 Nov 2012 00:22:56 +0000 (UTC) Received: (qmail 3379 invoked from network); 9 Nov 2012 01:22:55 +0100 Received: from fw.xip.at (HELO filebunker.xip.at) (89.207.145.147) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Nov 2012 01:22:55 +0100 Date: Fri, 9 Nov 2012 01:22:54 +0100 (CET) From: Ingo Flaschberger To: "Alexander V. Chernikov" Subject: Re: [patch] reducing arp locking In-Reply-To: <509AEDAC.10002@FreeBSD.org> Message-ID: References: <509AEDAC.10002@FreeBSD.org> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 00:22:57 -0000 Dear Alexander, > If nobody objects I plan to commit this change at the end of next week. LLE_RNLOCK(la); should be LLE_RLOCK(la); in arpresolve Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 08:08:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 180186B6 for ; Fri, 9 Nov 2012 08:08:53 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF1B8FC12 for ; Fri, 9 Nov 2012 08:08:52 +0000 (UTC) Received: (qmail 71583 invoked from network); 9 Nov 2012 09:43:49 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2012 09:43:49 -0000 Message-ID: <509CBA0C.3070008@freebsd.org> Date: Fri, 09 Nov 2012 09:08:44 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> <509BC2E2.4030907@freebsd.org> <509C4684.2030102@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:08:53 -0000 On 09.11.2012 01:19, Adrian Chadd wrote: > On 8 November 2012 15:55, Andre Oppermann wrote: > >> At the risk of repeating myself: when a routed packet is fragmented >> the payload (layer 4, eg. TCP/UDP/SCTP) is NOT recalculated or changed >> or anything else. It remains as originally calculated by the sender >> unchanged in the first fragment L4 header. Only the IPv4 header >> checksum, which DOES NOT include any payload data, has to be calculated >> for every fragment. The IPv4 header checksum is offloaded with CSUM_IP >> and continues to work as expected. :) > > NAT and firewalling? :) Firewalling doesn't change the packet and no checksum is needed. NAT does change the packet and the pesky pseudo-header in the TCP/ UDP checksum. However here only the pseudo-header checksum is recalculated and reintegrated into the one-complement payload checksum. The payload itself is not being looked at, except for protocols that do contain IP addresses in their internal commands or such. There the payload is modified. The same reintegration trick can be used. In the majority of cases these packets are very small though and the entire checksum is simply recalculated. As the packets are very small no fragmentation is occuring. The IPv4 header checksum is never ever a problem and always works. Can we please put this to rest now. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 08:51:50 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6665D184; Fri, 9 Nov 2012 08:51:50 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 268918FC0A; Fri, 9 Nov 2012 08:51:49 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 3F4A12705266; Fri, 9 Nov 2012 09:51:48 +0100 (CET) Subject: Re: [patch] reducing arp locking Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Fabien Thomas In-Reply-To: <509B88B1.3070905@FreeBSD.org> Date: Fri, 9 Nov 2012 09:51:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> To: Alexander V. Chernikov X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:51:50 -0000 Le 8 nov. 2012 =E0 11:25, Alexander V. Chernikov a =E9crit : > On 08.11.2012 14:24, Andre Oppermann wrote: >> On 08.11.2012 00:24, Alexander V. Chernikov wrote: >>> Hello list! >>>=20 >>> Currently we need to acquire 2 read locks to perform simple 6-byte >>> copying from arp record to packet >>> ethernet header. >>>=20 >>> It seems that acquiring lle lock for fast path (main traffic flow) = is >>> not necessary even with >>> current code. >>>=20 >>> My tests shows ~10% improvement with this patch applied. >>>=20 >>> If nobody objects I plan to commit this change at the end of next = week. >>=20 >> This is risky and prone to race conditions. The copy of the MAC = address >> should be done while the table read lock is held to protect against = the > It is done exactly as you say: table read lock is held. How do you protect from entry update if i've a ref to the entry ? You can end up doing bcopy of a partial mac address. la_preempt modification is also write access to an unlocked structure. >=20 >> entry going away. You can either return with table lock held and = drop >> it after the copy, or you could a modified lookup function that takes = a >> pointer for the copy destination, do the copy with the read lock, and = then >> return. If no entry is found an error is returned and obviously no = copy >> is done. >>=20 >=20 >=20 > --=20 > WBR, Alexander >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 09:06:13 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8798973F; Fri, 9 Nov 2012 09:06:13 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 198848FC0C; Fri, 9 Nov 2012 09:06:13 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWkap-000Akh-VY; Fri, 09 Nov 2012 13:09:40 +0400 Message-ID: <509CC776.9010200@FreeBSD.org> Date: Fri, 09 Nov 2012 13:05:58 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Fabien Thomas Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> In-Reply-To: <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 09:06:13 -0000 On 09.11.2012 12:51, Fabien Thomas wrote: > > Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit : > >> On 08.11.2012 14:24, Andre Oppermann wrote: >>> On 08.11.2012 00:24, Alexander V. Chernikov wrote: >>>> Hello list! >>>> >>>> Currently we need to acquire 2 read locks to perform simple 6-byte >>>> copying from arp record to packet >>>> ethernet header. >>>> >>>> It seems that acquiring lle lock for fast path (main traffic flow) is >>>> not necessary even with >>>> current code. >>>> >>>> My tests shows ~10% improvement with this patch applied. >>>> >>>> If nobody objects I plan to commit this change at the end of next week. >>> >>> This is risky and prone to race conditions. The copy of the MAC address >>> should be done while the table read lock is held to protect against the >> It is done exactly as you say: table read lock is held. > > How do you protect from entry update if i've a ref to the entry ? > You can end up doing bcopy of a partial mac address. I see no problems in copying incorrect mac address in that case: if host mac address id updated, this is, most likely, another host, and several packets being lost changes nothing. However, there can be some realistic scenario where this can be the case (L2 load balancing/failover). I'll update in_arpinput() to do lle removal/insertion in that case. > la_preempt modification is also write access to an unlocked structure. This one changes nothing: current code does this under _read_ lock. > > >> >>> entry going away. You can either return with table lock held and drop >>> it after the copy, or you could a modified lookup function that takes a >>> pointer for the copy destination, do the copy with the read lock, and then >>> return. If no entry is found an error is returned and obviously no copy >>> is done. >>> >> >> >> -- >> WBR, Alexander >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 09:59:22 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0225649C; Fri, 9 Nov 2012 09:59:21 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id B15918FC12; Fri, 9 Nov 2012 09:59:21 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id D30ED2705341; Fri, 9 Nov 2012 10:59:19 +0100 (CET) Subject: Re: [patch] reducing arp locking Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Fabien Thomas In-Reply-To: <509CC776.9010200@FreeBSD.org> Date: Fri, 9 Nov 2012 10:59:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> <509CC776.9010200@FreeBSD.org> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 09:59:22 -0000 Le 9 nov. 2012 =E0 10:05, Alexander V. Chernikov a =E9crit : > On 09.11.2012 12:51, Fabien Thomas wrote: >>=20 >> Le 8 nov. 2012 =E0 11:25, Alexander V. Chernikov a =E9crit : >>=20 >>> On 08.11.2012 14:24, Andre Oppermann wrote: >>>> On 08.11.2012 00:24, Alexander V. Chernikov wrote: >>>>> Hello list! >>>>>=20 >>>>> Currently we need to acquire 2 read locks to perform simple 6-byte >>>>> copying from arp record to packet >>>>> ethernet header. >>>>>=20 >>>>> It seems that acquiring lle lock for fast path (main traffic flow) = is >>>>> not necessary even with >>>>> current code. >>>>>=20 >>>>> My tests shows ~10% improvement with this patch applied. >>>>>=20 >>>>> If nobody objects I plan to commit this change at the end of next = week. >>>>=20 >>>> This is risky and prone to race conditions. The copy of the MAC = address >>>> should be done while the table read lock is held to protect against = the >>> It is done exactly as you say: table read lock is held. >>=20 >> How do you protect from entry update if i've a ref to the entry ? >> You can end up doing bcopy of a partial mac address. > I see no problems in copying incorrect mac address in that case: > if host mac address id updated, this is, most likely, another host, = and several packets being lost changes nothing. Sending packet to a bogus mac address is not really nothing :) >=20 > However, there can be some realistic scenario where this can be the = case (L2 load balancing/failover). I'll update in_arpinput() to do lle = removal/insertion in that case. >=20 >> la_preempt modification is also write access to an unlocked = structure. > This one changes nothing: > current code does this under _read_ lock. Under the table lock not the entry lock ? Table lock is here to protect the table if I've understood the code = correctly. If i get an exclusive reference to the entry you will end up reading and = writing to the entry without any lock. >=20 >>=20 >>=20 >>>=20 >>>> entry going away. You can either return with table lock held and = drop >>>> it after the copy, or you could a modified lookup function that = takes a >>>> pointer for the copy destination, do the copy with the read lock, = and then >>>> return. If no entry is found an error is returned and obviously no = copy >>>> is done. >>>>=20 >>>=20 >>>=20 >>> -- >>> WBR, Alexander >>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >>=20 >>=20 >=20 From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 11:21:06 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43FFA2A8; Fri, 9 Nov 2012 11:21:06 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id B2DDB8FC0C; Fri, 9 Nov 2012 11:21:05 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWmhM-000DAD-9a; Fri, 09 Nov 2012 15:24:32 +0400 Message-ID: <509CE6A2.2040200@FreeBSD.org> Date: Fri, 09 Nov 2012 15:18:58 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabien Thomas Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> <509CC776.9010200@FreeBSD.org> <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> In-Reply-To: <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:21:06 -0000 On 09.11.2012 13:59, Fabien Thomas wrote: > > Le 9 nov. 2012 à 10:05, Alexander V. Chernikov a écrit : > >> On 09.11.2012 12:51, Fabien Thomas wrote: >>> >>> Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit : >>> >>>> On 08.11.2012 14:24, Andre Oppermann wrote: >>>>> On 08.11.2012 00:24, Alexander V. Chernikov wrote: >>>>>> Hello list! >>>>>> >>>>>> Currently we need to acquire 2 read locks to perform simple 6-byte >>>>>> copying from arp record to packet >>>>>> ethernet header. >>>>>> >>>>>> It seems that acquiring lle lock for fast path (main traffic flow) is >>>>>> not necessary even with >>>>>> current code. >>>>>> >>>>>> My tests shows ~10% improvement with this patch applied. >>>>>> >>>>>> If nobody objects I plan to commit this change at the end of next week. >>>>> >>>>> This is risky and prone to race conditions. The copy of the MAC address >>>>> should be done while the table read lock is held to protect against the >>>> It is done exactly as you say: table read lock is held. >>> >>> How do you protect from entry update if i've a ref to the entry ? >>> You can end up doing bcopy of a partial mac address. >> I see no problems in copying incorrect mac address in that case: >> if host mac address id updated, this is, most likely, another host, and several packets being lost changes nothing. > > Sending packet to a bogus mac address is not really nothing :) > >> >> However, there can be some realistic scenario where this can be the case (L2 load balancing/failover). I'll update in_arpinput() to do lle removal/insertion in that case. >> >>> la_preempt modification is also write access to an unlocked structure. >> This one changes nothing: >> current code does this under _read_ lock. > > Under the table lock not the entry lock ? lle entry is read-locked while la_preempt is modified. > Table lock is here to protect the table if I've understood the code correctly. Yes. > If i get an exclusive reference to the entry you will end up reading and writing to the entry without any lock. Yes. And the only single drawback in worst case can be sending a bit more packets to right (but probably expired) MAC address. I'm talking about the following: ARP stack is just IP -> 6 bytes mapping, there is no reason to make it unnecessary complicated like rte, with references being held by upper layer stack. It does not contain interface pointer, etc.. We may need to r/w lock entry, but for 'control plane' code only. If one acquired exclusive lock and wants to change STATIC flag to non-static or change lle address - this is simply wrong and has to be handled by acquiring table wlock. Current ARP code has some flaws like handling arp expiration, but this patch doesn't change much here.. > >> >>> >>> >>>> >>>>> entry going away. You can either return with table lock held and drop >>>>> it after the copy, or you could a modified lookup function that takes a >>>>> pointer for the copy destination, do the copy with the read lock, and then >>>>> return. If no entry is found an error is returned and obviously no copy >>>>> is done. >>>>> >>>> >>>> >>>> -- >>>> WBR, Alexander >>>> >>>> >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >>> >> > > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 14:03:14 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5F4AB6E; Fri, 9 Nov 2012 14:03:14 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 39F128FC0A; Fri, 9 Nov 2012 14:03:13 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 364CC27052C5; Fri, 9 Nov 2012 15:03:07 +0100 (CET) Subject: Re: [patch] reducing arp locking Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Fabien Thomas In-Reply-To: <509CE6A2.2040200@FreeBSD.org> Date: Fri, 9 Nov 2012 15:03:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8169CD67-E444-46FC-A7C8-DD6FB59091E1@netasq.com> References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> <509CC776.9010200@FreeBSD.org> <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> <509CE6A2.2040200@FreeBSD.org> To: Alexander V. Chernikov X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:03:14 -0000 Le 9 nov. 2012 =E0 12:18, Alexander V. Chernikov a =E9crit : > On 09.11.2012 13:59, Fabien Thomas wrote: >>=20 >> Le 9 nov. 2012 =E0 10:05, Alexander V. Chernikov a =E9crit : >>=20 >>> On 09.11.2012 12:51, Fabien Thomas wrote: >>>>=20 >>>> Le 8 nov. 2012 =E0 11:25, Alexander V. Chernikov a =E9crit : >>>>=20 >>>>> On 08.11.2012 14:24, Andre Oppermann wrote: >>>>>> On 08.11.2012 00:24, Alexander V. Chernikov wrote: >>>>>>> Hello list! >>>>>>>=20 >>>>>>> Currently we need to acquire 2 read locks to perform simple = 6-byte >>>>>>> copying from arp record to packet >>>>>>> ethernet header. >>>>>>>=20 >>>>>>> It seems that acquiring lle lock for fast path (main traffic = flow) is >>>>>>> not necessary even with >>>>>>> current code. >>>>>>>=20 >>>>>>> My tests shows ~10% improvement with this patch applied. >>>>>>>=20 >>>>>>> If nobody objects I plan to commit this change at the end of = next week. >>>>>>=20 >>>>>> This is risky and prone to race conditions. The copy of the MAC = address >>>>>> should be done while the table read lock is held to protect = against the >>>>> It is done exactly as you say: table read lock is held. >>>>=20 >>>> How do you protect from entry update if i've a ref to the entry ? >>>> You can end up doing bcopy of a partial mac address. >>> I see no problems in copying incorrect mac address in that case: >>> if host mac address id updated, this is, most likely, another host, = and several packets being lost changes nothing. >>=20 >> Sending packet to a bogus mac address is not really nothing :) >>=20 >>>=20 >>> However, there can be some realistic scenario where this can be the = case (L2 load balancing/failover). I'll update in_arpinput() to do lle = removal/insertion in that case. >>>=20 >>>> la_preempt modification is also write access to an unlocked = structure. >>> This one changes nothing: >>> current code does this under _read_ lock. >>=20 >> Under the table lock not the entry lock ? > lle entry is read-locked while la_preempt is modified. >=20 >> Table lock is here to protect the table if I've understood the code = correctly. > Yes. >> If i get an exclusive reference to the entry you will end up reading = and writing to the entry without any lock. > Yes. And the only single drawback in worst case can be sending a bit = more packets to right (but probably expired) MAC address. Or partial copy of the new mac. >=20 > I'm talking about the following: > ARP stack is just IP -> 6 bytes mapping, there is no reason to make it = unnecessary complicated like rte, with references being held by upper = layer stack. It does not contain interface pointer, etc.. >=20 > We may need to r/w lock entry, but for 'control plane' code only. > If one acquired exclusive lock and wants to change STATIC flag to = non-static or change lle address - this is simply wrong and has to be = handled by acquiring table wlock. >=20 > Current ARP code has some flaws like handling arp expiration, but this = patch doesn't change much here.. In in_arpinput only exclusive access to the entry is taken during the = update no IF_AFDATA_LOCK that's why i was surprised. ; >=20 >>=20 >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>> entry going away. You can either return with table lock held and = drop >>>>>> it after the copy, or you could a modified lookup function that = takes a >>>>>> pointer for the copy destination, do the copy with the read lock, = and then >>>>>> return. If no entry is found an error is returned and obviously = no copy >>>>>> is done. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> WBR, Alexander >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>>> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > WBR, Alexander >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 16:43:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 975F23AA for ; Fri, 9 Nov 2012 16:43:59 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id AB9858FC12 for ; Fri, 9 Nov 2012 16:43:57 +0000 (UTC) Received: (qmail 32289 invoked from network); 9 Nov 2012 17:43:51 +0100 Received: from fw.xip.at (HELO ?127.0.0.1?) (89.207.145.147) by chile.gbit.at with SMTP; 9 Nov 2012 17:43:51 +0100 Message-ID: <509D32CC.6000201@xip.at> Date: Fri, 09 Nov 2012 17:43:56 +0100 From: Ingo Flaschberger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> <509CC776.9010200@FreeBSD.org> <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> <509CE6A2.2040200@FreeBSD.org> <8169CD67-E444-46FC-A7C8-DD6FB59091E1@netasq.com> In-Reply-To: <8169CD67-E444-46FC-A7C8-DD6FB59091E1@netasq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:43:59 -0000 Am 09.11.2012 15:03, schrieb Fabien Thomas: > In in_arpinput only exclusive access to the entry is taken during the update no IF_AFDATA_LOCK that's why i was surprised. what about this: -- --- /usr/src/sys/netinet/if_ether.c_org 2012-11-09 16:15:43.000000000 +0000 +++ /usr/src/sys/netinet/if_ether.c 2012-11-09 16:16:37.000000000 +0000 @@ -685,7 +685,7 @@ flags |= LLE_EXCLUSIVE; IF_AFDATA_LOCK(ifp); la = lla_lookup(LLTABLE(ifp), flags, (struct sockaddr *)&sin); - IF_AFDATA_UNLOCK(ifp); + if (la != NULL) { /* the following is not an error when doing bridging */ if (!bridged && la->lle_tbl->llt_ifp != ifp && !carp_match) { @@ -697,12 +697,14 @@ ifp->if_addrlen, (u_char *)ar_sha(ah), ":", ifp->if_xname); LLE_WUNLOCK(la); + IF_AFDATA_UNLOCK(ifp); goto reply; } if ((la->la_flags & LLE_VALID) && bcmp(ar_sha(ah), &la->ll_addr, ifp->if_addrlen)) { if (la->la_flags & LLE_STATIC) { LLE_WUNLOCK(la); + IF_AFDATA_UNLOCK(ifp); if (log_arp_permanent_modify) log(LOG_ERR, "arp: %*D attempts to modify " @@ -725,6 +727,7 @@ if (ifp->if_addrlen != ah->ar_hln) { LLE_WUNLOCK(la); + IF_AFDATA_UNLOCK(ifp); log(LOG_WARNING, "arp from %*D: addr len: new %d, " "i/f %d (ignored)\n", ifp->if_addrlen, (u_char *) ar_sha(ah), ":", ah->ar_hln, @@ -763,14 +766,19 @@ la->la_numheld = 0; memcpy(&sa, L3_ADDR(la), sizeof(sa)); LLE_WUNLOCK(la); + IF_AFDATA_UNLOCK(ifp); for (; m_hold != NULL; m_hold = m_hold_next) { m_hold_next = m_hold->m_nextpkt; m_hold->m_nextpkt = NULL; (*ifp->if_output)(ifp, m_hold, &sa, NULL); } - } else + } else { LLE_WUNLOCK(la); - } + IF_AFDATA_UNLOCK(ifp); + } + } else { + IF_AFDATA_UNLOCK(ifp); + } reply: if (op != ARPOP_REQUEST) goto drop; -- Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 16:51:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7380E6E1; Fri, 9 Nov 2012 16:51:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1928FC08; Fri, 9 Nov 2012 16:51:46 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz17so1379134pbc.13 for ; Fri, 09 Nov 2012 08:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lgNPxNlaibq5UZgkTHEFfaRmj13HpHDvH0qNw+algrA=; b=KC70jiHwuu73IeeG9IN9GutAB2b9ZIbP39w55k0JfU82RBql5NsgK01g5DYqWBhaEx EveFAJZ7I/1Fky1tr/zNBco2rs5KWEW8f1KSSMXWZSqaBGRCEFIx0zB/eoU3olMdS27K 7nnHh5epZOHB2hRerU7PRWQiL/q5lAeJdjUTbcdOtFETegOM2lpdwru5xkGEvg0+9hUe Zq3RU4nZE1EwxzYWPtgmvmO9twAFfD65iYo79RpnrMKVN69UvquZZmTgjqm6IH3yCG4H KnFXHCVtIIgbGI198wKydKdFoRrT8Whd9B6f4zXF5eexj8/4hZWLDa9ZhzIVbdom3yso S/Qw== MIME-Version: 1.0 Received: by 10.66.72.136 with SMTP id d8mr33271897pav.4.1352479906447; Fri, 09 Nov 2012 08:51:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Fri, 9 Nov 2012 08:51:46 -0800 (PST) In-Reply-To: <509CBA0C.3070008@freebsd.org> References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> <509BC2E2.4030907@freebsd.org> <509C4684.2030102@freebsd.org> <509CBA0C.3070008@freebsd.org> Date: Fri, 9 Nov 2012 08:51:46 -0800 X-Google-Sender-Auth: hbrRqlysoO_hx88eBW_fNDeq2XM Message-ID: Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti From: Adrian Chadd To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:51:47 -0000 On 9 November 2012 00:08, Andre Oppermann wrote: > Firewalling doesn't change the packet and no checksum is needed. > NAT does change the packet and the pesky pseudo-header in the TCP/ > UDP checksum. However here only the pseudo-header checksum is > recalculated and reintegrated into the one-complement payload checksum. > The payload itself is not being looked at, except for protocols that > do contain IP addresses in their internal commands or such. There > the payload is modified. The same reintegration trick can be used. > In the majority of cases these packets are very small though and > the entire checksum is simply recalculated. As the packets are very > small no fragmentation is occuring. > The IPv4 header checksum is never ever a problem and always works. > > Can we please put this to rest now. Andre, I'm assuming that Pyun fixed a real bug that he really did see. My day job is dealing with these kinds of corner cases with embedded hardware that does offload-y type stuff. So yes, I'd really like to know what's going on under the hood and fix it. You may be able to make it all go away with a bunch of logical reasoning but if it weren't a problem, Pyun would've never stumbled across it and had to disable checksumming. I'll chase this up privately with him and see what was really going on. Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 16:51:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F2CE768 for ; Fri, 9 Nov 2012 16:51:57 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id A6EE08FC0C for ; Fri, 9 Nov 2012 16:51:56 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id D3C822704754; Fri, 9 Nov 2012 17:51:49 +0100 (CET) Subject: Re: [patch] reducing arp locking Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Fabien Thomas In-Reply-To: <509D32CC.6000201@xip.at> Date: Fri, 9 Nov 2012 17:51:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> <509CC776.9010200@FreeBSD.org> <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> <509CE6A2.2040200@FreeBSD.org> <8169CD67-E444-46FC-A7C8-DD6FB59091E1@netasq.com> <509D32CC.6000201@xip.at> To: Ingo Flaschberger X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:51:57 -0000 Le 9 nov. 2012 =E0 17:43, Ingo Flaschberger a =E9crit : > Am 09.11.2012 15:03, schrieb Fabien Thomas: >> In in_arpinput only exclusive access to the entry is taken during the = update no IF_AFDATA_LOCK that's why i was surprised. >=20 > what about this: I'm not against optimizing but an API that seems clear (correct this if = i'm wrong): - one lock for list modification - one RW lock for lle entry access - one refcount for ptr unref is now a lot more unclear and from my point of view dangerous. My next question is why do we need a per entry lock if we use the table = lock to protect entry access? Fabien =20 > -- > --- /usr/src/sys/netinet/if_ether.c_org 2012-11-09 16:15:43.000000000 = +0000 > +++ /usr/src/sys/netinet/if_ether.c 2012-11-09 16:16:37.000000000 = +0000 > @@ -685,7 +685,7 @@ > flags |=3D LLE_EXCLUSIVE; > IF_AFDATA_LOCK(ifp); > la =3D lla_lookup(LLTABLE(ifp), flags, (struct sockaddr = *)&sin); > - IF_AFDATA_UNLOCK(ifp); > + > if (la !=3D NULL) { > /* the following is not an error when doing bridging */ > if (!bridged && la->lle_tbl->llt_ifp !=3D ifp && = !carp_match) { > @@ -697,12 +697,14 @@ > ifp->if_addrlen, (u_char = *)ar_sha(ah), ":", > ifp->if_xname); > LLE_WUNLOCK(la); > + IF_AFDATA_UNLOCK(ifp); > goto reply; > } > if ((la->la_flags & LLE_VALID) && > bcmp(ar_sha(ah), &la->ll_addr, ifp->if_addrlen)) { > if (la->la_flags & LLE_STATIC) { > LLE_WUNLOCK(la); > + IF_AFDATA_UNLOCK(ifp); > if (log_arp_permanent_modify) > log(LOG_ERR, > "arp: %*D attempts to = modify " > @@ -725,6 +727,7 @@ >=20 > if (ifp->if_addrlen !=3D ah->ar_hln) { > LLE_WUNLOCK(la); > + IF_AFDATA_UNLOCK(ifp); > log(LOG_WARNING, "arp from %*D: addr len: new = %d, " > "i/f %d (ignored)\n", ifp->if_addrlen, > (u_char *) ar_sha(ah), ":", ah->ar_hln, > @@ -763,14 +766,19 @@ > la->la_numheld =3D 0; > memcpy(&sa, L3_ADDR(la), sizeof(sa)); > LLE_WUNLOCK(la); > + IF_AFDATA_UNLOCK(ifp); > for (; m_hold !=3D NULL; m_hold =3D = m_hold_next) { > m_hold_next =3D m_hold->m_nextpkt; > m_hold->m_nextpkt =3D NULL; > (*ifp->if_output)(ifp, m_hold, &sa, = NULL); > } > - } else > + } else { > LLE_WUNLOCK(la); > - } > + IF_AFDATA_UNLOCK(ifp); > + } > + } else { > + IF_AFDATA_UNLOCK(ifp); > + } > reply: > if (op !=3D ARPOP_REQUEST) > goto drop; > -- >=20 > Kind regards, > Ingo Flaschberger >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 17:34:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B6474C1 for ; Fri, 9 Nov 2012 17:34:09 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA768FC13 for ; Fri, 9 Nov 2012 17:34:07 +0000 (UTC) Received: (qmail 73993 invoked from network); 9 Nov 2012 19:09:00 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2012 19:09:00 -0000 Message-ID: <509D3E87.9020701@freebsd.org> Date: Fri, 09 Nov 2012 18:33:59 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti References: <201211080206.qA826RiN054539@svn.freebsd.org> <20121108023858.GA3127@michelle.cdnetworks.com> <509BC2E2.4030907@freebsd.org> <509C4684.2030102@freebsd.org> <509CBA0C.3070008@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, FreeBSD Net , Pyun YongHyeon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:34:09 -0000 On 09.11.2012 17:51, Adrian Chadd wrote: > On 9 November 2012 00:08, Andre Oppermann wrote: > >> Firewalling doesn't change the packet and no checksum is needed. >> NAT does change the packet and the pesky pseudo-header in the TCP/ >> UDP checksum. However here only the pseudo-header checksum is >> recalculated and reintegrated into the one-complement payload checksum. >> The payload itself is not being looked at, except for protocols that >> do contain IP addresses in their internal commands or such. There >> the payload is modified. The same reintegration trick can be used. >> In the majority of cases these packets are very small though and >> the entire checksum is simply recalculated. As the packets are very >> small no fragmentation is occuring. >> The IPv4 header checksum is never ever a problem and always works. >> >> Can we please put this to rest now. > > Andre, > > I'm assuming that Pyun fixed a real bug that he really did see. My day > job is dealing with these kinds of corner cases with embedded hardware > that does offload-y type stuff. > So yes, I'd really like to know what's going on under the hood and fix it. There isn't anything to fix other than removing a poorly supported and implemented feature. Nothings breaks if it goes away. > You may be able to make it all go away with a bunch of logical > reasoning but if it weren't a problem, Pyun would've never stumbled > across it and had to disable checksumming. I found the problem and wanted to remove this particular mis-feature from the stack. To do that he removed it from two drivers, one of them very old with no known users. -- Andre > I'll chase this up privately with him and see what was really going on. > > Thanks, > > > > Adrian > > From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 18:57:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9D6C7DD for ; Fri, 9 Nov 2012 18:57:15 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 78CD98FC16 for ; Fri, 9 Nov 2012 18:57:15 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWton-000IMf-8T; Fri, 09 Nov 2012 23:00:41 +0400 Message-ID: <509D518A.9000803@FreeBSD.org> Date: Fri, 09 Nov 2012 22:55:06 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabien Thomas Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> <509CC776.9010200@FreeBSD.org> <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> <509CE6A2.2040200@FreeBSD.org> <8169CD67-E444-46FC-A7C8-DD6FB59091E1@netasq.com> <509D32CC.6000201@xip.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Ingo Flaschberger X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:57:16 -0000 On 09.11.2012 20:51, Fabien Thomas wrote: > > Le 9 nov. 2012 à 17:43, Ingo Flaschberger a écrit : > >> Am 09.11.2012 15:03, schrieb Fabien Thomas: >>> In in_arpinput only exclusive access to the entry is taken during the update no IF_AFDATA_LOCK that's why i was surprised. I'll update patch to reflect changes discussed in previous e-mails. >> >> what about this: > > I'm not against optimizing but an API that seems clear (correct this if i'm wrong): > - one lock for list modification > - one RW lock for lle entry access > - one refcount for ptr unref > > is now a lot more unclear and from my point of view dangerous. This can be changed/documented as the following: - table rW lock for list modification - table rW lock lle_addr, la_expire change - per-lle rw lock for refcount and other fields not used by 'main path' code > > My next question is why do we need a per entry lock if we use the table lock to protect entry access? Because there are other cases, like sending traffic to unresolved rte (arp request send, but reply is not received, and we have to maintain packets queue to that destination). .. and it seems flags handling (LLE_VALID) should be done with more care. > > Fabien >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Sat Nov 10 01:19:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5BB8580; Sat, 10 Nov 2012 01:19:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 682F68FC13; Sat, 10 Nov 2012 01:19:29 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so5800484oag.13 for ; Fri, 09 Nov 2012 17:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ca0ac+inXFkzNPj88ED0IDDiyPdZyjgr89A+F2aptvk=; b=hW1bjhxUOQpIN6uimsGZrmCfy7MmEz9Y4jJvVAhIuG9XG7H9lfbBsITVlMFGVlEUWC glx1b6JR3kp02IV7aqYfbYA8+HYTH/5j7R9EftD0o8PIEZFBIBAJk57n0Bss8elXwBpZ 4giIo1vPG5NkhUyvysUjs+dpGQXntWSJ3I/YLQmSsw7J9a/DNBD3HEOdps2EK0RAhA93 TXA06LviudrDo8XxdXVNJOCtkx/R7nqf+IKMFulZn34NBp3xN2fCVAePzfnKNP95ivvQ roMwYmRbOawUCpE4Ez0mS7oaWmFOEv1RNrToiKLzb7AKwDsyvX6fspY7cCePURN1iBec qpFw== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr10217462obb.9.1352510369650; Fri, 09 Nov 2012 17:19:29 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 9 Nov 2012 17:19:29 -0800 (PST) Date: Fri, 9 Nov 2012 17:19:29 -0800 Message-ID: Subject: Infiniband list available From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-infiniband@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 01:19:33 -0000 Hi all, With the help of postmaster, a new Infiniband list has been created for FreeBSD. If you are interested in IB on FreeBSD, please subscribe to the list. My group (Isilon) will be providing more details about the porting effort being done from our end to the latest 1.5.x and the group is working at improving IB documentation and the like in the interim. Feel free to discuss anything IB related on the list! Cheers! -Garrett