From owner-freebsd-net@FreeBSD.ORG Sun Nov 3 14:27:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D16F13BF for ; Sun, 3 Nov 2013 14:27:05 +0000 (UTC) (envelope-from danny.gabriel.winn@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70C65213D for ; Sun, 3 Nov 2013 14:27:05 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cb5so987783wib.0 for ; Sun, 03 Nov 2013 06:27:03 -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=iz0CMZsSmFUXH7gqpI3uuD/dRDwdooSFTt1eLY32f7E=; b=ATsqGwqXV3IN4sdzZ838LLlywhBY+hMTuYgrAEHZgea6VZQkfvz5wTrvfimR2WmWS7 FZkmZdlKkvYo5DjGFDsNj9gQ7Bx+Y4r6TWqd/vPl8yxXB2rgZa7fvhPSFhjMDlCoZBoA Tf5+mlxSbT0jY7M2n+2g6TB0oclmcwzbPcHPz1605a9syMhCs36OgTuf0swIT4uowHnE 7JaQLi360jbvQwzl5OTNbGWbDiyZAscZNx576PsV6iRftsxwbe7Qq95Hm3PlvQ4XAW4V 17BXDujSNWUifOgbQ4UeKQo+nsCNn49oSM7Rq6GblG4lCvKXvc0xBjBwSueoXtUSo7oX 85ZA== MIME-Version: 1.0 X-Received: by 10.180.94.100 with SMTP id db4mr9105578wib.14.1383488823649; Sun, 03 Nov 2013 06:27:03 -0800 (PST) Received: by 10.194.153.101 with HTTP; Sun, 3 Nov 2013 06:27:03 -0800 (PST) Date: Sun, 3 Nov 2013 15:27:03 +0100 Message-ID: Subject: RTL8111/8168B NIC & FreeBSD From: Danny Winn 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: Sun, 03 Nov 2013 14:27:05 -0000 Hello, we are trying to install FreeBSD on a computer that uses the NIC mentioned above. The NIC is running under linux without problems, which we've tested for several days transferring several GB of data. The NIC is neither detected by the FreeBSD installer when attempting to setup the network, nor after the system installation when booting from HD. We've tested FreeBSD 8.x, 9.x and 10.x; same issues with this NIC. We cannot use a different NIC (this one is onboard. The micro ATX mainboard has no room left for any other device) pciconf -l -v: none2@pci0:3:0:0: class=0x020000 card=0x81681849 chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet dmesg: re0: port 0xd000-0xd0ff mem 0xf3204000-0xf3204fff,0xf3200000-0xf3203fff irq 19 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: Chip rev. 0x4c000000 re0: MAC rev. 0x00000000 re0: Unknown H/W revision: 0x4c000000 device_attach: re0 attach returned 6 ifconfig -a: lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 Even though "dmesg" shows the device "re0", it remains unknown to "ifconfig". "if_re" is already in the generic kernel, so it can't be loaded via "kldload" as a module, right? We've already addressed this problem here: http://forums.freebsd.org/showthread.php?t=42952 They recommended to this mailing-list. Best Regards Danny From owner-freebsd-net@FreeBSD.ORG Sun Nov 3 16:40:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 838337D5 for ; Sun, 3 Nov 2013 16:40:18 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [64.147.113.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5DEC526CD for ; Sun, 3 Nov 2013 16:40:18 +0000 (UTC) Received: from acm.poly.edu (localhost [127.0.0.1]) by acm.poly.edu (Postfix) with ESMTP id B07101F13C2 for ; Sun, 3 Nov 2013 11:40:17 -0500 (EST) Received: (qmail 83446 invoked from network); 3 Nov 2013 16:40:17 -0000 Received: from unknown (HELO ?192.168.67.2?) (spawk@64.147.100.14) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 3 Nov 2013 16:40:17 -0000 Message-ID: <52767C6D.9010206@acm.poly.edu> Date: Sun, 03 Nov 2013 11:40:13 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130417 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Jail FIB? References: <52767B9A.6090002@acm.poly.edu> In-Reply-To: <52767B9A.6090002@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 03 Nov 2013 16:40:18 -0000 Figured out my own question. I was jexec'ing into it, and jexec inherits FIB 0 from the host. SSHing into the jail results in the desired behavior. Thanks. -Boris On 11/03/2013 11:36, Boris Kochergin wrote: > Hi. > > I am running 9.2-RELEASE/amd64 and would like to have a jail use FIB 1. > The host portion of this seems to work fine: > > # sysctl net.fibs net.fibs: 2 > > # setfib 0 route -n get default > ... > gateway: 64.147.127.17 > > # setfib 1 route -n get default > ... > gateway: 216.168.38.241 > > In my /etc/rc.conf, I have: > > jail_wa_console_fib="1" > > And, with rc_debug="YES", rc.d tells me that it picked that up: > > /etc/rc.d/jail: DEBUG: wa_console fib: 1 > > But, inside the jail: > > # sysctl net.my_fibnum > net.my_fibnum: 0 > > And, indeed, it takes the FIB 0 route out to the world. Why? How do I > make it use FIB 1? > > -Boris From owner-freebsd-net@FreeBSD.ORG Sun Nov 3 16:41:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7871D954 for ; Sun, 3 Nov 2013 16:41:59 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [64.147.113.26]) by mx1.freebsd.org (Postfix) with ESMTP id 52C3026E6 for ; Sun, 3 Nov 2013 16:41:59 +0000 (UTC) Received: from acm.poly.edu (localhost [127.0.0.1]) by acm.poly.edu (Postfix) with ESMTP id D081B1F1389 for ; Sun, 3 Nov 2013 11:36:46 -0500 (EST) Received: (qmail 83408 invoked from network); 3 Nov 2013 16:36:46 -0000 Received: from unknown (HELO ?192.168.67.2?) (spawk@64.147.100.14) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 3 Nov 2013 16:36:46 -0000 Message-ID: <52767B9A.6090002@acm.poly.edu> Date: Sun, 03 Nov 2013 11:36:42 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130417 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Jail FIB? Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 03 Nov 2013 16:41:59 -0000 Hi. I am running 9.2-RELEASE/amd64 and would like to have a jail use FIB 1. The host portion of this seems to work fine: # sysctl net.fibs net.fibs: 2 # setfib 0 route -n get default ... gateway: 64.147.127.17 # setfib 1 route -n get default ... gateway: 216.168.38.241 In my /etc/rc.conf, I have: jail_wa_console_fib="1" And, with rc_debug="YES", rc.d tells me that it picked that up: /etc/rc.d/jail: DEBUG: wa_console fib: 1 But, inside the jail: # sysctl net.my_fibnum net.my_fibnum: 0 And, indeed, it takes the FIB 0 route out to the world. Why? How do I make it use FIB 1? -Boris From owner-freebsd-net@FreeBSD.ORG Sun Nov 3 19:45:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20C5684F for ; Sun, 3 Nov 2013 19:45:10 +0000 (UTC) (envelope-from eocallaghan@alterapraxis.com) Received: from smtp.alterapraxis.com (unknown [101.164.33.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 947512EBE for ; Sun, 3 Nov 2013 19:45:09 +0000 (UTC) Received: from smtp.alterapraxis.com (tony [127.0.0.1]) by smtp.alterapraxis.com (Postfix) with ESMTP id 8DCAF633184 for ; Mon, 4 Nov 2013 06:42:27 +1100 (EST) Received: from tinkerbell.alterapraxis.com (unknown [101.164.33.212]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: eocallaghan@alterapraxis.com) by smtp.alterapraxis.com (Postfix) with ESMTPSA id 4EAD1633183 for ; Mon, 4 Nov 2013 06:42:26 +1100 (EST) Date: Mon, 4 Nov 2013 06:44:48 +1100 From: Edward O'Callaghan To: freebsd-net@freebsd.org Subject: Re: RTL8111/8168B NIC & FreeBSD Message-ID: <20131104064448.49e8efa7.eocallaghan@alterapraxis.com> In-Reply-To: References: Organization: Altera Praxis Pty Ltd X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/G6UUQQJ0nyOHq2VOo6ol/qX"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV using ClamSMTP 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, 03 Nov 2013 19:45:10 -0000 --Sig_/G6UUQQJ0nyOHq2VOo6ol/qX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 3 Nov 2013 15:27:03 +0100 Danny Winn wrote: Hi, I sent a patch this month to the list that adds support for that(0x4c000000) hw. You can apply the patch or try out HEAD where it has been committed. Let us know how you go! Cheers, Edward. > Hello, >=20 > we are trying to install FreeBSD on a computer that uses the NIC > mentioned above. The NIC is running under linux without problems, > which we've tested for several days transferring several GB of data. >=20 > The NIC is neither detected by the FreeBSD installer when attempting > to setup the network, nor after the system installation when booting > from HD. We've tested FreeBSD 8.x, 9.x and 10.x; same issues with > this NIC. >=20 > We cannot use a different NIC (this one is onboard. The micro ATX > mainboard has no room left for any other device) >=20 > pciconf -l -v: >=20 > none2@pci0:3:0:0: class=3D0x020000 card=3D0x81681849 chip=3D0x816810ec > rev=3D0x0c hdr=3D0x00 > vendor =3D 'Realtek Semiconductor Co., Ltd.' > device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet > controller' class =3D network > subclass =3D ethernet >=20 > dmesg: >=20 > re0: port > 0xd000-0xd0ff mem 0xf3204000-0xf3204fff,0xf3200000-0xf3203fff irq 19 > at device 0.0 on pci3 > re0: Using 1 MSI-X message > re0: Chip rev. 0x4c000000 > re0: MAC rev. 0x00000000 > re0: Unknown H/W revision: 0x4c000000 > device_attach: re0 attach returned 6 >=20 > ifconfig -a: >=20 > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 >=20 > Even though "dmesg" shows the device "re0", it remains unknown to > "ifconfig". >=20 > "if_re" is already in the generic kernel, so it can't be loaded via > "kldload" as a module, right? >=20 > We've already addressed this problem here: > http://forums.freebsd.org/showthread.php?t=3D42952 >=20 > They recommended to this mailing-list. >=20 >=20 > Best Regards > Danny > _______________________________________________ > 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" --Sig_/G6UUQQJ0nyOHq2VOo6ol/qX Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJSdqe2AAoJENeyf/ug44dt6SMQAIrsjlmrb/gRp7bZWDyqRIae fM2jT0RYrpfh7ETlxfYcdb0DhqVejYvuSxEKkaOw0hwoiq2rPSoAN/skYE8iG4S8 bTezQrbD1CsIQoO05aGjOLhev8gU+acuEilDnWWlcyfx1gs4XTyuNT5g0PkqrRDO sD3N0F8+xQXtHXjXcog2b9iaSN3V/Ti/xBBZsQ2U1ma/vKrwrWMo3qnWMMnVqL9Y fQ9iYWwZtzuosPkcwajJ+Zb0CxHTl9kHNSQloXeYUMr74IRq/E/X9FpgB4mwTjxb KRa1HUaPyMs9MwgMbF9slBCKIUJAT7FcqiwsC5yIN1XANGrtp3wdQSFjxtdyKyeK QYxewrvE1tqatsCy01AKX6w1InPtJWV7FsXzEmu67GnRZovFVmOC4bvcgnuaEqWB Tkupzw0CQXg9i+/+yKbXJxkxtwImGhVmV9VP/mDDfnscucVumRbuFGhQgpb3pxA2 Bkh4o2uWPpm1HXs/ZGOCET6wN3D7emJyVElpck0J6GtllfB9RGEHPKezXwl95Hwk kIj22OZNLaMh+UNqVs7tV36VQO/lsSraQXYh82mSaHquB3SBPLXfccDrUC17nkpa aAsDwnSqnqIjjoS3vurcf7+nRLf9xYwftxUdSl8hSZyO3GO+s7mzg4p+gc4P0nci ieQNoa30D0fyradWhKaZ =pTrZ -----END PGP SIGNATURE----- --Sig_/G6UUQQJ0nyOHq2VOo6ol/qX-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 4 00:54:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 357095F9 for ; Mon, 4 Nov 2013 00:54:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0962A2D38 for ; Mon, 4 Nov 2013 00:54:11 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rA40rrqh042438 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 16:54:01 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5276F01C.9010404@freebsd.org> Date: Sun, 03 Nov 2013 16:53:48 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Boris Kochergin , freebsd-net@freebsd.org Subject: Re: Jail FIB? References: <52767B9A.6090002@acm.poly.edu> <52767C6D.9010206@acm.poly.edu> In-Reply-To: <52767C6D.9010206@acm.poly.edu> 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: Mon, 04 Nov 2013 00:54:12 -0000 On 11/3/13, 8:40 AM, Boris Kochergin wrote: > Figured out my own question. I was jexec'ing into it, and jexec inherits > FIB 0 from the host. SSHing into the jail results in the desired behavior. > > Thanks. > > -Boris yeah, because the two things are actually orthogonal, and the jail-fib config capability hides this fact.. you would have to do setfib 1 jexec {cmd} to do what you want.. OR you could use a VIMAGE jail and give it its own stack (and routing table(s)) but then you;d have to put it on a bridge or give it its own interface.. From owner-freebsd-net@FreeBSD.ORG Mon Nov 4 05:26:54 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8405F8F0; Mon, 4 Nov 2013 05:26:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59DFA290F; Mon, 4 Nov 2013 05:26:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA45Qsdx059821; Mon, 4 Nov 2013 05:26:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA45Qs8l059820; Mon, 4 Nov 2013 05:26:54 GMT (envelope-from linimon) Date: Mon, 4 Nov 2013 05:26:54 GMT Message-Id: <201311040526.rA45Qs8l059820@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/183647: [re] re ethernet driver 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: Mon, 04 Nov 2013 05:26:54 -0000 Old Synopsis: re ethernet driver broken New Synopsis: [re] re ethernet driver broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 4 05:26:40 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=183647 From owner-freebsd-net@FreeBSD.ORG Mon Nov 4 07:13:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5A9036AE for ; Mon, 4 Nov 2013 07:13:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 326302E82 for ; Mon, 4 Nov 2013 07:13:06 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id w10so6314477pde.2 for ; Sun, 03 Nov 2013 23:13:05 -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=3kxKOobjbDp1O+hDK4tyGYtm2TF72MX7mj3Cw+BOppQ=; b=e3nCaq9E6ZmQeoiYdsn7oLaYjmT4mhfgzwZEjCnb3BLSIj0PGJFZDQp0TTKWDal38o kLkh0cu/BleAk2gQLEOcmTSYuM7y4lvz8Mr6gKQnEJ14+JmoeuEQGr16r5ZAyr7jHyny q9xzqDnUi4KqqiELTqaCF8fM/DuYePIa/pE5qsWuL6mTY8ZaQ7/WT9ixE1KLA+DAceTw Xw3wwyy8I6v9wO1308/cHKWivx3nf8LQtuoRXFxEHe2Qwl0WChVlZL/onx97FL7hkf6Y I+2KpHR/eFLyY4+JFwzJiw3pgCxKjsfaF9zNiJ7uxA5EMWNjXy6MmDKUIlljzSZeYWdC rBJg== X-Received: by 10.68.29.36 with SMTP id g4mr1214631pbh.145.1383549185897; Sun, 03 Nov 2013 23:13:05 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id gf5sm26273715pbc.22.2013.11.03.23.13.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Nov 2013 23:13:05 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Nov 2013 16:13:00 +0900 From: Yonghyeon PYUN Date: Mon, 4 Nov 2013 16:13:00 +0900 To: Danny Winn Subject: Re: RTL8111/8168B NIC & FreeBSD Message-ID: <20131104071300.GB1381@michelle.cdnetworks.com> References: 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@freebsd.org 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: Mon, 04 Nov 2013 07:13:06 -0000 On Sun, Nov 03, 2013 at 03:27:03PM +0100, Danny Winn wrote: > Hello, > > we are trying to install FreeBSD on a computer that uses the NIC mentioned > above. The NIC is running under linux without problems, which we've tested > for several days transferring several GB of data. > > The NIC is neither detected by the FreeBSD installer when attempting to > setup the network, nor after the system installation when booting from HD. > We've tested FreeBSD 8.x, 9.x and 10.x; same issues with this NIC. > > We cannot use a different NIC (this one is onboard. The micro ATX mainboard > has no room left for any other device) > > pciconf -l -v: > > none2@pci0:3:0:0: class=0x020000 card=0x81681849 chip=0x816810ec > rev=0x0c hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class = network > subclass = ethernet > > dmesg: > > re0: port > 0xd000-0xd0ff mem 0xf3204000-0xf3204fff,0xf3200000-0xf3203fff irq 19 at > device 0.0 on pci3 > re0: Using 1 MSI-X message > re0: Chip rev. 0x4c000000 > re0: MAC rev. 0x00000000 > re0: Unknown H/W revision: 0x4c000000 > device_attach: re0 attach returned 6 > > ifconfig -a: > > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > > Even though "dmesg" shows the device "re0", it remains unknown to > "ifconfig". > > "if_re" is already in the generic kernel, so it can't be loaded via > "kldload" as a module, right? > > We've already addressed this problem here: > http://forums.freebsd.org/showthread.php?t=42952 > > They recommended to this mailing-list. Just merged required change from HEAD to stable. Try either stable/10 or stable/9. From owner-freebsd-net@FreeBSD.ORG Mon Nov 4 08:19:49 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D3D3933; Mon, 4 Nov 2013 08:19:49 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30496235F; Mon, 4 Nov 2013 08:19:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA48JnWW012613; Mon, 4 Nov 2013 08:19:49 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA48JmL0012612; Mon, 4 Nov 2013 08:19:48 GMT (envelope-from yongari) Date: Mon, 4 Nov 2013 08:19:48 GMT Message-Id: <201311040819.rA48JmL0012612@freefall.freebsd.org> To: claus@endresconsulting.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Subject: Re: kern/183647: [re] re ethernet driver 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: Mon, 04 Nov 2013 08:19:49 -0000 Synopsis: [re] re ethernet driver broken State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Nov 4 08:19:08 UTC 2013 State-Changed-Why: Show me dmesg(re(4) and rgephy(4) only) and ifconfig re0 output. Since you've said received frame contents are all zeros, post captured traffic. It seems you've already installed vendor's driver so use stock 9.2-RELEASE live-cd to reproduce it. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Nov 4 08:19:08 UTC 2013 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=183647 From owner-freebsd-net@FreeBSD.ORG Mon Nov 4 11:06:53 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3849A6E2 for ; Mon, 4 Nov 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24C562C40 for ; Mon, 4 Nov 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA4B6rZJ048459 for ; Mon, 4 Nov 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA4B6qJt048457 for freebsd-net@FreeBSD.org; Mon, 4 Nov 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Nov 2013 11:06:52 GMT Message-Id: <201311041106.rA4B6qJt048457@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, 04 Nov 2013 11:06:53 -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 conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [ixgbe] 10gigabit networking problems with Emulex OCE o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN RealtekŪ 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181225 net [infiniband] [patch] unloading ipoib crashes the kerne o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term 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/173002 net [patch] data type size problem in if_spppsubr.c 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 p 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/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet 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/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/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/166462 net [gre] gre(4) when using a tunnel source address from c 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 p kern/165903 net mbuf leak 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/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/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/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S 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 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 [new driver] [request]: Port brcm80211 driver from Lin 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 p 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/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/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/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 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 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/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 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 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/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/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: 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] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan 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/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging 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/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ 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 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/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/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 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 471 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 4 14:27:51 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A6741938; Mon, 4 Nov 2013 14:27:51 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 794C728A1; Mon, 4 Nov 2013 14:27:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA4ERpko097142; Mon, 4 Nov 2013 14:27:51 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA4ERpGu097141; Mon, 4 Nov 2013 14:27:51 GMT (envelope-from eadler) Date: Mon, 4 Nov 2013 14:27:51 GMT Message-Id: <201311041427.rA4ERpGu097141@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: kern/183659: TCP stack lock contention with short-lived connections 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, 04 Nov 2013 14:27:51 -0000 Synopsis: TCP stack lock contention with short-lived connections Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Mon Nov 4 14:27:26 UTC 2013 Responsible-Changed-Why: Over to networking group http://www.freebsd.org/cgi/query-pr.cgi?pr=183659 From owner-freebsd-net@FreeBSD.ORG Mon Nov 4 21:25:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1C80E857 for ; Mon, 4 Nov 2013 21:25:15 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D00662408 for ; Mon, 4 Nov 2013 21:25:14 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VdRdu-0003ji-R7 for freebsd-net@freebsd.org; Mon, 04 Nov 2013 22:25:02 +0100 Received: from 217.30.88.7 ([217.30.88.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Nov 2013 22:25:02 +0100 Received: from jcharbon by 217.30.88.7 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Nov 2013 22:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: "Julien Charbon" Subject: TCP stack lock contention with short-lived connections Date: Mon, 04 Nov 2013 22:21:04 +0100 Lines: 29 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 217.30.88.7 User-Agent: Opera Mail/1.0 (MacIntel) 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, 04 Nov 2013 21:25:15 -0000 Hi list, just a follow-up of vBSDCon discussions about FreeBSD TCP performances with short-lived connections. In summary: Using a single NIC receive queue, the TCP stack performance results with short-lived connections on FreeBSD are great: We got 52,000 (52k) TCP queries per second (QPS) before being CPU bound, we achieved the same result on Linux. However, when configuring 4 NIC receive queues each bound to a different core of the same CPU, results are lower than expected: We got 56k QPS, where we reached 200k QPS on Linux on same hardware. Basically, FreeBSD TCP stack does not scale well across multiple receive queues/CPU cores due to a lock contention. I have put technical and how-to-repeat details in below PR: kern/183659: TCP stack lock contention with short-lived connections http://www.freebsd.org/cgi/query-pr.cgi?pr=183659 We are currently working on this performance improvement effort; it will impact only the TCP locking strategy not the TCP stack logic itself. We will share on freebsd-net the patches we made for reviewing and improvement propositions; anyway this change might also require enough eyeballs to avoid tricky race conditions introduction in TCP stack. Thanks. -- Julien From owner-freebsd-net@FreeBSD.ORG Tue Nov 5 11:01:18 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 255EC510; Tue, 5 Nov 2013 11:01:18 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C0312DAF; Tue, 5 Nov 2013 11:01:16 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rA5B1E6p007329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Nov 2013 15:01:14 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rA5B1Etu007328; Tue, 5 Nov 2013 15:01:14 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 5 Nov 2013 15:01:14 +0400 From: Gleb Smirnoff To: current@FreeBSD.org Subject: axing KAME interface ioctls Message-ID: <20131105110114.GQ1467@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) 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, 05 Nov 2013 11:01:18 -0000 Hello. Since 1999 we have got some dead code from KAME, namely support for these ioctls: SIOCALIFADDR SIOCGLIFADDR SIOCDLIFADDR SIOCSLIFPHYADDR SIOCGLIFPHYADDR We don not have any software in base that use (or used) them. The ports exp-run with SIOC.LIFADDR undefined didn't reveal any port that use them. I forgot to add SIOC.LIFPHYADDR to exp-run, but pretty sure these are unused, too. What did this ioctls do? They are KAME version of SIOCAIFADDR, and SIOCSIFPHYADDR respectively. Some operating systems (at least HPUX) have adopted them, and some software may use them on these systems. Anyway, in FreeBSD all software always used our native ioctls. I hope there is no objections against axing these in head/. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Nov 5 12:02:44 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 16C68874; Tue, 5 Nov 2013 12:02:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47F1021A0; Tue, 5 Nov 2013 12:02:42 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rA5C2eeB007670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Nov 2013 16:02:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rA5C2ePm007669; Tue, 5 Nov 2013 16:02:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 5 Nov 2013 16:02:40 +0400 From: Gleb Smirnoff To: current@FreeBSD.org Subject: Re: axing KAME interface ioctls Message-ID: <20131105120240.GA7577@FreeBSD.org> References: <20131105110114.GQ1467@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <20131105110114.GQ1467@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) 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, 05 Nov 2013 12:02:44 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 05, 2013 at 03:01:14PM +0400, Gleb Smirnoff wrote: T> Hello. T> T> Since 1999 we have got some dead code from KAME, namely support for these T> ioctls: T> T> SIOCALIFADDR T> SIOCGLIFADDR T> SIOCDLIFADDR T> SIOCSLIFPHYADDR T> SIOCGLIFPHYADDR T> T> We don not have any software in base that use (or used) them. The ports T> exp-run with SIOC.LIFADDR undefined didn't reveal any port that use them. T> I forgot to add SIOC.LIFPHYADDR to exp-run, but pretty sure these are unused, T> too. T> T> What did this ioctls do? They are KAME version of SIOCAIFADDR, and T> SIOCSIFPHYADDR respectively. Some operating systems (at least HPUX) T> have adopted them, and some software may use them on these systems. T> Anyway, in FreeBSD all software always used our native ioctls. T> T> I hope there is no objections against axing these in head/. Patch attached. -- Totus tuus, Glebius. --ikeVEW9yuYc//A+q Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="axe-KAME-ioctls.diff" Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 257696) +++ sys/net/if.c (working copy) @@ -2414,7 +2414,6 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d #ifdef INET6 case SIOCSIFPHYADDR_IN6: #endif - case SIOCSLIFPHYADDR: case SIOCSIFMEDIA: case SIOCSIFGENERIC: error = priv_check(td, PRIV_NET_HWIOCTL); @@ -2433,7 +2432,6 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d case SIOCGIFPSRCADDR: case SIOCGIFPDSTADDR: - case SIOCGLIFPHYADDR: case SIOCGIFMEDIA: case SIOCGIFGENERIC: if (ifp->if_ioctl == NULL) Index: sys/net/if.h =================================================================== --- sys/net/if.h (revision 257696) +++ sys/net/if.h (working copy) @@ -489,18 +489,6 @@ struct ifgroupreq { #define ifgr_groups ifgr_ifgru.ifgru_groups }; -/* - * Structure for SIOC[AGD]LIFADDR - */ -struct if_laddrreq { - char iflr_name[IFNAMSIZ]; - u_int flags; -#define IFLR_PREFIX 0x8000 /* in: prefix given out: kernel fills id */ - u_int prefixlen; /* in/out */ - struct sockaddr_storage addr; /* in/out */ - struct sockaddr_storage dstaddr; /* out */ -}; - #endif /* __BSD_VISIBLE */ #ifdef _KERNEL Index: sys/net/if_gif.c =================================================================== --- sys/net/if_gif.c (revision 257694) +++ sys/net/if_gif.c (working copy) @@ -710,7 +710,6 @@ gif_ioctl(ifp, cmd, data) #ifdef INET6 case SIOCSIFPHYADDR_IN6: #endif /* INET6 */ - case SIOCSLIFPHYADDR: switch (cmd) { #ifdef INET case SIOCSIFPHYADDR: @@ -728,12 +727,6 @@ gif_ioctl(ifp, cmd, data) &(((struct in6_aliasreq *)data)->ifra_dstaddr); break; #endif - case SIOCSLIFPHYADDR: - src = (struct sockaddr *) - &(((struct if_laddrreq *)data)->addr); - dst = (struct sockaddr *) - &(((struct if_laddrreq *)data)->dstaddr); - break; default: return EINVAL; } @@ -788,9 +781,6 @@ gif_ioctl(ifp, cmd, data) break; return EAFNOSUPPORT; #endif /* INET6 */ - case SIOCSLIFPHYADDR: - /* checks done in the above */ - break; } error = gif_set_tunnel(GIF2IFP(sc), src, dst); @@ -886,31 +876,6 @@ gif_ioctl(ifp, cmd, data) #endif break; - case SIOCGLIFPHYADDR: - if (sc->gif_psrc == NULL || sc->gif_pdst == NULL) { - error = EADDRNOTAVAIL; - goto bad; - } - - /* copy src */ - src = sc->gif_psrc; - dst = (struct sockaddr *) - &(((struct if_laddrreq *)data)->addr); - size = sizeof(((struct if_laddrreq *)data)->addr); - if (src->sa_len > size) - return EINVAL; - bcopy((caddr_t)src, (caddr_t)dst, src->sa_len); - - /* copy dst */ - src = sc->gif_pdst; - dst = (struct sockaddr *) - &(((struct if_laddrreq *)data)->dstaddr); - size = sizeof(((struct if_laddrreq *)data)->dstaddr); - if (src->sa_len > size) - return EINVAL; - bcopy((caddr_t)src, (caddr_t)dst, src->sa_len); - break; - case SIOCSIFFLAGS: /* if_ioctl() takes care of it */ break; Index: sys/net/if_gre.c =================================================================== --- sys/net/if_gre.c (revision 257694) +++ sys/net/if_gre.c (working copy) @@ -519,7 +519,6 @@ static int gre_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) { struct ifreq *ifr = (struct ifreq *)data; - struct if_laddrreq *lifr = (struct if_laddrreq *)data; struct in_aliasreq *aifr = (struct in_aliasreq *)data; struct gre_softc *sc = ifp->if_softc; struct sockaddr_in si; @@ -734,27 +733,6 @@ gre_ioctl(struct ifnet *ifp, u_long cmd, caddr_t d sc->g_src = aifr->ifra_addr.sin_addr; sc->g_dst = aifr->ifra_dstaddr.sin_addr; goto recompute; - case SIOCSLIFPHYADDR: - /* - * XXXRW: Isn't this priv_check() redundant to the ifnet - * layer check? - */ - if ((error = priv_check(curthread, PRIV_NET_SETIFPHYS)) != 0) - break; - if (lifr->addr.ss_family != AF_INET || - lifr->dstaddr.ss_family != AF_INET) { - error = EAFNOSUPPORT; - break; - } - if (lifr->addr.ss_len != sizeof(si) || - lifr->dstaddr.ss_len != sizeof(si)) { - error = EINVAL; - break; - } - sc->g_src = (satosin(&lifr->addr))->sin_addr; - sc->g_dst = - (satosin(&lifr->dstaddr))->sin_addr; - goto recompute; case SIOCDIFPHYADDR: /* * XXXRW: Isn't this priv_check() redundant to the ifnet @@ -765,26 +743,6 @@ gre_ioctl(struct ifnet *ifp, u_long cmd, caddr_t d sc->g_src.s_addr = INADDR_ANY; sc->g_dst.s_addr = INADDR_ANY; goto recompute; - case SIOCGLIFPHYADDR: - if (sc->g_src.s_addr == INADDR_ANY || - sc->g_dst.s_addr == INADDR_ANY) { - error = EADDRNOTAVAIL; - break; - } - memset(&si, 0, sizeof(si)); - si.sin_family = AF_INET; - si.sin_len = sizeof(struct sockaddr_in); - si.sin_addr.s_addr = sc->g_src.s_addr; - error = prison_if(curthread->td_ucred, (struct sockaddr *)&si); - if (error != 0) - break; - memcpy(&lifr->addr, &si, sizeof(si)); - si.sin_addr.s_addr = sc->g_dst.s_addr; - error = prison_if(curthread->td_ucred, (struct sockaddr *)&si); - if (error != 0) - break; - memcpy(&lifr->dstaddr, &si, sizeof(si)); - break; case SIOCGIFPSRCADDR: #ifdef INET6 case SIOCGIFPSRCADDR_IN6: Index: sys/netinet/in.c =================================================================== --- sys/netinet/in.c (revision 257694) +++ sys/netinet/in.c (working copy) @@ -68,10 +68,6 @@ __FBSDID("$FreeBSD$"); #include #include -static int in_mask2len(struct in_addr *); -static void in_len2mask(struct in_addr *, int); -static int in_lifaddr_ioctl(struct socket *, u_long, caddr_t, - struct ifnet *, struct thread *); static int in_aifaddr_ioctl(caddr_t, struct ifnet *, struct thread *); static int in_difaddr_ioctl(caddr_t, struct ifnet *, struct thread *); @@ -192,42 +188,6 @@ in_socktrim(struct sockaddr_in *ap) } } -static int -in_mask2len(mask) - struct in_addr *mask; -{ - int x, y; - u_char *p; - - p = (u_char *)mask; - for (x = 0; x < sizeof(*mask); x++) { - if (p[x] != 0xff) - break; - } - y = 0; - if (x < sizeof(*mask)) { - for (y = 0; y < 8; y++) { - if ((p[x] & (0x80 >> y)) == 0) - break; - } - } - return (x * 8 + y); -} - -static void -in_len2mask(struct in_addr *mask, int len) -{ - int i; - u_char *p; - - p = (u_char *)mask; - bzero(mask, sizeof(*mask)); - for (i = 0; i < len / 8; i++) - p[i] = 0xff; - if (len % 8) - p[i] = (0xff00 >> (len % 8)) & 0xff; -} - /* * Generic internet control operations (ioctl's). */ @@ -263,10 +223,6 @@ in_control(struct socket *so, u_long cmd, caddr_t error = in_aifaddr_ioctl(data, ifp, td); sx_xunlock(&in_control_sx); return (error); - case SIOCALIFADDR: - case SIOCDLIFADDR: - case SIOCGLIFADDR: - return (in_lifaddr_ioctl(so, cmd, data, ifp, td)); case SIOCSIFADDR: case SIOCSIFBRDADDR: case SIOCSIFDSTADDR: @@ -634,194 +590,6 @@ in_difaddr_ioctl(caddr_t data, struct ifnet *ifp, return (0); } -/* - * SIOC[GAD]LIFADDR. - * SIOCGLIFADDR: get first address. (?!?) - * SIOCGLIFADDR with IFLR_PREFIX: - * get first address that matches the specified prefix. - * SIOCALIFADDR: add the specified address. - * SIOCALIFADDR with IFLR_PREFIX: - * EINVAL since we can't deduce hostid part of the address. - * SIOCDLIFADDR: delete the specified address. - * SIOCDLIFADDR with IFLR_PREFIX: - * delete the first address that matches the specified prefix. - * return values: - * EINVAL on invalid parameters - * EADDRNOTAVAIL on prefix match failed/specified address not found - * other values may be returned from in_ioctl() - */ -static int -in_lifaddr_ioctl(struct socket *so, u_long cmd, caddr_t data, - struct ifnet *ifp, struct thread *td) -{ - struct if_laddrreq *iflr = (struct if_laddrreq *)data; - struct ifaddr *ifa; - int error; - - switch (cmd) { - case SIOCALIFADDR: - if (td != NULL) { - error = priv_check(td, PRIV_NET_ADDIFADDR); - if (error) - return (error); - } - break; - case SIOCDLIFADDR: - if (td != NULL) { - error = priv_check(td, PRIV_NET_DELIFADDR); - if (error) - return (error); - } - break; - } - - switch (cmd) { - case SIOCGLIFADDR: - /* address must be specified on GET with IFLR_PREFIX */ - if ((iflr->flags & IFLR_PREFIX) == 0) - break; - /*FALLTHROUGH*/ - case SIOCALIFADDR: - case SIOCDLIFADDR: - /* address must be specified on ADD and DELETE */ - if (iflr->addr.ss_family != AF_INET) - return (EINVAL); - if (iflr->addr.ss_len != sizeof(struct sockaddr_in)) - return (EINVAL); - /* XXX need improvement */ - if (iflr->dstaddr.ss_family - && iflr->dstaddr.ss_family != AF_INET) - return (EINVAL); - if (iflr->dstaddr.ss_family - && iflr->dstaddr.ss_len != sizeof(struct sockaddr_in)) - return (EINVAL); - break; - default: /*shouldn't happen*/ - return (EOPNOTSUPP); - } - if (sizeof(struct in_addr) * 8 < iflr->prefixlen) - return (EINVAL); - - switch (cmd) { - case SIOCALIFADDR: - { - struct in_aliasreq ifra; - - if (iflr->flags & IFLR_PREFIX) - return (EINVAL); - - /* copy args to in_aliasreq, perform ioctl(SIOCAIFADDR). */ - bzero(&ifra, sizeof(ifra)); - bcopy(iflr->iflr_name, ifra.ifra_name, - sizeof(ifra.ifra_name)); - - bcopy(&iflr->addr, &ifra.ifra_addr, iflr->addr.ss_len); - - if (iflr->dstaddr.ss_family) { /*XXX*/ - bcopy(&iflr->dstaddr, &ifra.ifra_dstaddr, - iflr->dstaddr.ss_len); - } - - ifra.ifra_mask.sin_family = AF_INET; - ifra.ifra_mask.sin_len = sizeof(struct sockaddr_in); - in_len2mask(&ifra.ifra_mask.sin_addr, iflr->prefixlen); - - return (in_control(so, SIOCAIFADDR, (caddr_t)&ifra, ifp, td)); - } - case SIOCGLIFADDR: - case SIOCDLIFADDR: - { - struct in_ifaddr *ia; - struct in_addr mask, candidate, match; - struct sockaddr_in *sin; - - bzero(&mask, sizeof(mask)); - bzero(&match, sizeof(match)); - if (iflr->flags & IFLR_PREFIX) { - /* lookup a prefix rather than address. */ - in_len2mask(&mask, iflr->prefixlen); - - sin = (struct sockaddr_in *)&iflr->addr; - match.s_addr = sin->sin_addr.s_addr; - match.s_addr &= mask.s_addr; - - /* if you set extra bits, that's wrong */ - if (match.s_addr != sin->sin_addr.s_addr) - return (EINVAL); - - } else { - /* on getting an address, take the 1st match */ - /* on deleting an address, do exact match */ - if (cmd != SIOCGLIFADDR) { - in_len2mask(&mask, 32); - sin = (struct sockaddr_in *)&iflr->addr; - match.s_addr = sin->sin_addr.s_addr; - } - } - - IF_ADDR_RLOCK(ifp); - TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { - if (ifa->ifa_addr->sa_family != AF_INET) - continue; - if (match.s_addr == 0) - break; - sin = (struct sockaddr_in *)&ifa->ifa_addr; - candidate.s_addr = sin->sin_addr.s_addr; - candidate.s_addr &= mask.s_addr; - if (candidate.s_addr == match.s_addr) - break; - } - if (ifa != NULL) - ifa_ref(ifa); - IF_ADDR_RUNLOCK(ifp); - if (ifa == NULL) - return (EADDRNOTAVAIL); - ia = (struct in_ifaddr *)ifa; - - if (cmd == SIOCGLIFADDR) { - /* fill in the if_laddrreq structure */ - bcopy(&ia->ia_addr, &iflr->addr, ia->ia_addr.sin_len); - - if ((ifp->if_flags & IFF_POINTOPOINT) != 0) { - bcopy(&ia->ia_dstaddr, &iflr->dstaddr, - ia->ia_dstaddr.sin_len); - } else - bzero(&iflr->dstaddr, sizeof(iflr->dstaddr)); - - iflr->prefixlen = - in_mask2len(&ia->ia_sockmask.sin_addr); - - iflr->flags = 0; /*XXX*/ - ifa_free(ifa); - - return (0); - } else { - struct in_aliasreq ifra; - - /* fill in_aliasreq and do ioctl(SIOCDIFADDR) */ - bzero(&ifra, sizeof(ifra)); - bcopy(iflr->iflr_name, ifra.ifra_name, - sizeof(ifra.ifra_name)); - - bcopy(&ia->ia_addr, &ifra.ifra_addr, - ia->ia_addr.sin_len); - if ((ifp->if_flags & IFF_POINTOPOINT) != 0) { - bcopy(&ia->ia_dstaddr, &ifra.ifra_dstaddr, - ia->ia_dstaddr.sin_len); - } - bcopy(&ia->ia_sockmask, &ifra.ifra_dstaddr, - ia->ia_sockmask.sin_len); - ifa_free(ifa); - - return (in_control(so, SIOCDIFADDR, (caddr_t)&ifra, - ifp, td)); - } - } - } - - return (EOPNOTSUPP); /*just for safety*/ -} - #define rtinitflags(x) \ ((((x)->ia_ifp->if_flags & (IFF_LOOPBACK | IFF_POINTOPOINT)) != 0) \ ? RTF_HOST : 0) Index: sys/netinet6/in6.c =================================================================== --- sys/netinet6/in6.c (revision 257694) +++ sys/netinet6/in6.c (working copy) @@ -133,8 +133,6 @@ const struct in6_addr in6mask128 = IN6MASK128; const struct sockaddr_in6 sa6_any = { sizeof(sa6_any), AF_INET6, 0, 0, IN6ADDR_ANY_INIT, 0 }; -static int in6_lifaddr_ioctl(struct socket *, u_long, caddr_t, - struct ifnet *, struct thread *); static int in6_ifinit(struct ifnet *, struct in6_ifaddr *, struct sockaddr_in6 *, int); static void in6_unlink_ifa(struct in6_ifaddr *, struct ifnet *); @@ -376,26 +374,6 @@ in6_control(struct socket *so, u_long cmd, caddr_t ifr->ifr_ifru.ifru_scope_id)); } - switch (cmd) { - case SIOCALIFADDR: - if (td != NULL) { - error = priv_check(td, PRIV_NET_ADDIFADDR); - if (error) - return (error); - } - return in6_lifaddr_ioctl(so, cmd, data, ifp, td); - - case SIOCDLIFADDR: - if (td != NULL) { - error = priv_check(td, PRIV_NET_DELIFADDR); - if (error) - return (error); - } - /* FALLTHROUGH */ - case SIOCGLIFADDR: - return in6_lifaddr_ioctl(so, cmd, data, ifp, td); - } - /* * Find address for this interface, if it exists. * @@ -1601,277 +1579,6 @@ in6_purgeif(struct ifnet *ifp) } /* - * SIOC[GAD]LIFADDR. - * SIOCGLIFADDR: get first address. (?) - * SIOCGLIFADDR with IFLR_PREFIX: - * get first address that matches the specified prefix. - * SIOCALIFADDR: add the specified address. - * SIOCALIFADDR with IFLR_PREFIX: - * add the specified prefix, filling hostid part from - * the first link-local address. prefixlen must be <= 64. - * SIOCDLIFADDR: delete the specified address. - * SIOCDLIFADDR with IFLR_PREFIX: - * delete the first address that matches the specified prefix. - * return values: - * EINVAL on invalid parameters - * EADDRNOTAVAIL on prefix match failed/specified address not found - * other values may be returned from in6_ioctl() - * - * NOTE: SIOCALIFADDR(with IFLR_PREFIX set) allows prefixlen less than 64. - * this is to accomodate address naming scheme other than RFC2374, - * in the future. - * RFC2373 defines interface id to be 64bit, but it allows non-RFC2374 - * address encoding scheme. (see figure on page 8) - */ -static int -in6_lifaddr_ioctl(struct socket *so, u_long cmd, caddr_t data, - struct ifnet *ifp, struct thread *td) -{ - struct if_laddrreq *iflr = (struct if_laddrreq *)data; - struct ifaddr *ifa; - struct sockaddr *sa; - - /* sanity checks */ - if (!data || !ifp) { - panic("invalid argument to in6_lifaddr_ioctl"); - /* NOTREACHED */ - } - - switch (cmd) { - case SIOCGLIFADDR: - /* address must be specified on GET with IFLR_PREFIX */ - if ((iflr->flags & IFLR_PREFIX) == 0) - break; - /* FALLTHROUGH */ - case SIOCALIFADDR: - case SIOCDLIFADDR: - /* address must be specified on ADD and DELETE */ - sa = (struct sockaddr *)&iflr->addr; - if (sa->sa_family != AF_INET6) - return EINVAL; - if (sa->sa_len != sizeof(struct sockaddr_in6)) - return EINVAL; - /* XXX need improvement */ - sa = (struct sockaddr *)&iflr->dstaddr; - if (sa->sa_family && sa->sa_family != AF_INET6) - return EINVAL; - if (sa->sa_len && sa->sa_len != sizeof(struct sockaddr_in6)) - return EINVAL; - break; - default: /* shouldn't happen */ -#if 0 - panic("invalid cmd to in6_lifaddr_ioctl"); - /* NOTREACHED */ -#else - return EOPNOTSUPP; -#endif - } - if (sizeof(struct in6_addr) * 8 < iflr->prefixlen) - return EINVAL; - - switch (cmd) { - case SIOCALIFADDR: - { - struct in6_aliasreq ifra; - struct in6_addr *hostid = NULL; - int prefixlen; - - ifa = NULL; - if ((iflr->flags & IFLR_PREFIX) != 0) { - struct sockaddr_in6 *sin6; - - /* - * hostid is to fill in the hostid part of the - * address. hostid points to the first link-local - * address attached to the interface. - */ - ifa = (struct ifaddr *)in6ifa_ifpforlinklocal(ifp, 0); - if (!ifa) - return EADDRNOTAVAIL; - hostid = IFA_IN6(ifa); - - /* prefixlen must be <= 64. */ - if (64 < iflr->prefixlen) { - if (ifa != NULL) - ifa_free(ifa); - return EINVAL; - } - prefixlen = iflr->prefixlen; - - /* hostid part must be zero. */ - sin6 = (struct sockaddr_in6 *)&iflr->addr; - if (sin6->sin6_addr.s6_addr32[2] != 0 || - sin6->sin6_addr.s6_addr32[3] != 0) { - if (ifa != NULL) - ifa_free(ifa); - return EINVAL; - } - } else - prefixlen = iflr->prefixlen; - - /* copy args to in6_aliasreq, perform ioctl(SIOCAIFADDR_IN6). */ - bzero(&ifra, sizeof(ifra)); - bcopy(iflr->iflr_name, ifra.ifra_name, sizeof(ifra.ifra_name)); - - bcopy(&iflr->addr, &ifra.ifra_addr, - ((struct sockaddr *)&iflr->addr)->sa_len); - if (hostid) { - /* fill in hostid part */ - ifra.ifra_addr.sin6_addr.s6_addr32[2] = - hostid->s6_addr32[2]; - ifra.ifra_addr.sin6_addr.s6_addr32[3] = - hostid->s6_addr32[3]; - } - - if (((struct sockaddr *)&iflr->dstaddr)->sa_family) { /* XXX */ - bcopy(&iflr->dstaddr, &ifra.ifra_dstaddr, - ((struct sockaddr *)&iflr->dstaddr)->sa_len); - if (hostid) { - ifra.ifra_dstaddr.sin6_addr.s6_addr32[2] = - hostid->s6_addr32[2]; - ifra.ifra_dstaddr.sin6_addr.s6_addr32[3] = - hostid->s6_addr32[3]; - } - } - if (ifa != NULL) - ifa_free(ifa); - - ifra.ifra_prefixmask.sin6_len = sizeof(struct sockaddr_in6); - in6_prefixlen2mask(&ifra.ifra_prefixmask.sin6_addr, prefixlen); - - ifra.ifra_flags = iflr->flags & ~IFLR_PREFIX; - return in6_control(so, SIOCAIFADDR_IN6, (caddr_t)&ifra, ifp, td); - } - case SIOCGLIFADDR: - case SIOCDLIFADDR: - { - struct in6_ifaddr *ia; - struct in6_addr mask, candidate, match; - struct sockaddr_in6 *sin6; - int cmp; - - bzero(&mask, sizeof(mask)); - if (iflr->flags & IFLR_PREFIX) { - /* lookup a prefix rather than address. */ - in6_prefixlen2mask(&mask, iflr->prefixlen); - - sin6 = (struct sockaddr_in6 *)&iflr->addr; - bcopy(&sin6->sin6_addr, &match, sizeof(match)); - match.s6_addr32[0] &= mask.s6_addr32[0]; - match.s6_addr32[1] &= mask.s6_addr32[1]; - match.s6_addr32[2] &= mask.s6_addr32[2]; - match.s6_addr32[3] &= mask.s6_addr32[3]; - - /* if you set extra bits, that's wrong */ - if (bcmp(&match, &sin6->sin6_addr, sizeof(match))) - return EINVAL; - - cmp = 1; - } else { - if (cmd == SIOCGLIFADDR) { - /* on getting an address, take the 1st match */ - cmp = 0; /* XXX */ - } else { - /* on deleting an address, do exact match */ - in6_prefixlen2mask(&mask, 128); - sin6 = (struct sockaddr_in6 *)&iflr->addr; - bcopy(&sin6->sin6_addr, &match, sizeof(match)); - - cmp = 1; - } - } - - IF_ADDR_RLOCK(ifp); - TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { - if (ifa->ifa_addr->sa_family != AF_INET6) - continue; - if (!cmp) - break; - - /* - * XXX: this is adhoc, but is necessary to allow - * a user to specify fe80::/64 (not /10) for a - * link-local address. - */ - bcopy(IFA_IN6(ifa), &candidate, sizeof(candidate)); - in6_clearscope(&candidate); - candidate.s6_addr32[0] &= mask.s6_addr32[0]; - candidate.s6_addr32[1] &= mask.s6_addr32[1]; - candidate.s6_addr32[2] &= mask.s6_addr32[2]; - candidate.s6_addr32[3] &= mask.s6_addr32[3]; - if (IN6_ARE_ADDR_EQUAL(&candidate, &match)) - break; - } - if (ifa != NULL) - ifa_ref(ifa); - IF_ADDR_RUNLOCK(ifp); - if (!ifa) - return EADDRNOTAVAIL; - ia = ifa2ia6(ifa); - - if (cmd == SIOCGLIFADDR) { - int error; - - /* fill in the if_laddrreq structure */ - bcopy(&ia->ia_addr, &iflr->addr, ia->ia_addr.sin6_len); - error = sa6_recoverscope( - (struct sockaddr_in6 *)&iflr->addr); - if (error != 0) { - ifa_free(ifa); - return (error); - } - - if ((ifp->if_flags & IFF_POINTOPOINT) != 0) { - bcopy(&ia->ia_dstaddr, &iflr->dstaddr, - ia->ia_dstaddr.sin6_len); - error = sa6_recoverscope( - (struct sockaddr_in6 *)&iflr->dstaddr); - if (error != 0) { - ifa_free(ifa); - return (error); - } - } else - bzero(&iflr->dstaddr, sizeof(iflr->dstaddr)); - - iflr->prefixlen = - in6_mask2len(&ia->ia_prefixmask.sin6_addr, NULL); - - iflr->flags = ia->ia6_flags; /* XXX */ - ifa_free(ifa); - - return 0; - } else { - struct in6_aliasreq ifra; - - /* fill in6_aliasreq and do ioctl(SIOCDIFADDR_IN6) */ - bzero(&ifra, sizeof(ifra)); - bcopy(iflr->iflr_name, ifra.ifra_name, - sizeof(ifra.ifra_name)); - - bcopy(&ia->ia_addr, &ifra.ifra_addr, - ia->ia_addr.sin6_len); - if ((ifp->if_flags & IFF_POINTOPOINT) != 0) { - bcopy(&ia->ia_dstaddr, &ifra.ifra_dstaddr, - ia->ia_dstaddr.sin6_len); - } else { - bzero(&ifra.ifra_dstaddr, - sizeof(ifra.ifra_dstaddr)); - } - bcopy(&ia->ia_prefixmask, &ifra.ifra_dstaddr, - ia->ia_prefixmask.sin6_len); - - ifra.ifra_flags = ia->ia6_flags; - ifa_free(ifa); - return in6_control(so, SIOCDIFADDR_IN6, (caddr_t)&ifra, - ifp, td); - } - } - } - - return EOPNOTSUPP; /* just for safety */ -} - -/* * Initialize an interface's IPv6 address and routing table entry. */ static int Index: sys/sys/sockio.h =================================================================== --- sys/sys/sockio.h (revision 257696) +++ sys/sys/sockio.h (working copy) @@ -69,9 +69,9 @@ #define SIOCSIFMETRIC _IOW('i', 24, struct ifreq) /* set IF metric */ #define SIOCDIFADDR _IOW('i', 25, struct ifreq) /* delete IF addr */ /* OSIOCAIFADDR _IOW('i', 26, struct oifaliasreq) FreeBSD 9.x */ -#define SIOCALIFADDR _IOW('i', 27, struct if_laddrreq) /* add IF addr */ -#define SIOCGLIFADDR _IOWR('i', 28, struct if_laddrreq) /* get IF addr */ -#define SIOCDLIFADDR _IOW('i', 29, struct if_laddrreq) /* delete IF addr */ +/* SIOCALIFADDR _IOW('i', 27, struct if_laddrreq) KAME */ +/* SIOCGLIFADDR _IOWR('i', 28, struct if_laddrreq) KAME */ +/* SIOCDLIFADDR _IOW('i', 29, struct if_laddrreq) KAME */ #define SIOCSIFCAP _IOW('i', 30, struct ifreq) /* set IF features */ #define SIOCGIFCAP _IOWR('i', 31, struct ifreq) /* get IF features */ #define SIOCGIFINDEX _IOWR('i', 32, struct ifreq) /* get IF index */ @@ -101,8 +101,8 @@ #define SIOCGIFPSRCADDR _IOWR('i', 71, struct ifreq) /* get gif psrc addr */ #define SIOCGIFPDSTADDR _IOWR('i', 72, struct ifreq) /* get gif pdst addr */ #define SIOCDIFPHYADDR _IOW('i', 73, struct ifreq) /* delete gif addrs */ -#define SIOCSLIFPHYADDR _IOW('i', 74, struct if_laddrreq) /* set gif addrs */ -#define SIOCGLIFPHYADDR _IOWR('i', 75, struct if_laddrreq) /* get gif addrs */ +/* SIOCSLIFPHYADDR _IOW('i', 74, struct if_laddrreq) KAME */ +/* SIOCGLIFPHYADDR _IOWR('i', 75, struct if_laddrreq) KAME */ #define SIOCGPRIVATE_0 _IOWR('i', 80, struct ifreq) /* device private 0 */ #define SIOCGPRIVATE_1 _IOWR('i', 81, struct ifreq) /* device private 1 */ --ikeVEW9yuYc//A+q-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 5 17:41:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1D8D0405 for ; Tue, 5 Nov 2013 17:41:52 +0000 (UTC) (envelope-from 176374750-63980-94133-socialdigest@bounces.fanbridge.com) Received: from r226-m4.fanbridge.com (r226-m4.fanbridge.com [174.37.97.226]) by mx1.freebsd.org (Postfix) with ESMTP id DB02828E7 for ; Tue, 5 Nov 2013 17:41:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=p04; d=fanbridge.com; h=From:To:Subject:Message-ID:List-Unsubscribe:Sender:Date:Content-Type:MIME-Version; i=noreply-collection-484984@fanbridge.com; bh=mjrJFd6IwEkp60/PjlNk3LpACAU=; b=lWrdantbEuOfIbniyKDfLEcq/7gMf2Hg2EoNTI/3JPBL4eXOrT9CeqeQhBLgW23qKMFHGusdjzhF wZitAEeEmTvoehLkeZIQ6aymMbQPiJOXYcPk/pLsnfWH3n/f1iQ17xjZIxEQn8vwxfVgiWRKxqRT nm8KGc6piGyFS9dEbh0= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=p04; d=fanbridge.com; b=r5gpCibuZ51gWh6q8wDiU2HUlOPPXHLcs/37Wc8cvJD/OfZ44uWkB2/lkUOdG6rellOSckP7z8RT LH3p0WVg+REaupVvMTnEc1TqvE6aq4IrOs3EEFw0l0hYIHP5HDxyyoQ1SCDivknEcJ3YSiB20by3 oU6E8ZGU6uADVx/wf6w=; Received: from 127.0.0.1 (108.168.153.227) by r226-m4.fanbridge.com id hf4mtu1lrc0c for ; Tue, 5 Nov 2013 12:41:45 -0500 (envelope-from <176374750-63980-94133-socialdigest@bounces.fanbridge.com>) From: "ZOO LIFE ENT." To: freebsd-net@freebsd.org Subject: =?utf-8?Q?ZOO=20LIFE=20ENT.:=20Social=20Digest=20for=20November=205?= Message-ID: <7a5cfdcf398ca9e2380828daf40026f5@fanbridge.com> X-fbridge-collection: collection-484984 X-fbridge-sid: 176374750 X-fbridge-cfc: KbPKbtF1b7tbtFUF9cbd5Xr5B2 X-fbridge-uid: 63980 X-fbridge-sdrid: 94133 X-fbridge-feature: socialdigest X-fbridge-cluster: limonada X-Report-Abuse: Please report abuse here: http://www.fanbridge.com/contact.php?report_abuse Sender: FanBridge Date: Tue, 05 Nov 2013 12:41:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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, 05 Nov 2013 17:41:52 -0000 =20 =09=09Email not displaying correctly? View it in your browser. [1] ZOO LIFE ENT.=20 Social Digest for the week of November 4, 2013 Follow Me: [2] [3] [4] [5] =20 WELCOME TO THIS WEEKS SOCIAL DIGEST! BELOW YOULL FIND A RECAP OF SOME =09 great things that happened over the past week. If you like what you read, just click on it and reply, comment, post or let us know what you think! Thanks for your support. =20 See something you think is hot? Share it with your friends by clicking on the fire icon =09=09 =09=09 [6] =09=09 [7] =20 =09=09Featured Sponsor =09=09 [8] =09=09 [9] =20 =09 NEW "@djvlad: 40 Glocc AKA Yon Ju - "Hate That" (Music Video) (@40GLOCC)=20 http://t.co/jffWqCDUZp border-bottom: none">=20 =09 RT @Vladtv_djwill: 40 Glocc AKA Yon Ju - "Hate That" (Music Video) (@40GLOCC): New music video from Yon Ju Feat. Tya Ma... =20 =09=09 _4 retweets_ [15]=20 =09=09 [16]=20 =09=09via Twitter [17] on 10.30.13 =09=09 [18] =09HAPPY GEE-DAY @50os -ME, FLAVOR FLAV, LEGEND, @crissangel (THE MAGICIAN), @joejudah , @djerocksf1 & POE.. #turntup #TURNUP #TurndownForWhat #40GLOCC #ZOOGANG #COLTON #IE #LA #LASVEGAS #LOSANGELES #YONJU #zoolife #GUNIT #MUSIC #MONEY #WOMEN #LADIES #GIRLS #FFP #FITNESS #GYM #WORKOUT #INLANDEMPIRE #GLOBAL #TIMETRAVELER =20 =09=09 [19]=20 =09=09 [20]=20 =09=09 via Instagram [21] on 11.03.13=20 =09=09 [22] =09=09 [28] =20 =09=09 [30]=20 =09=09 [31]=20 =09=09VIA INSTAGRAM [32] ON 11.03.13 =09=09 [33] =09ME & @locielocc ..YEA FOO.. THIZ THAT MAD AZZ #ZOOGANG I DOES THIS WORLD WIDE.. "DONT NOTHING COME WITH SLEEP, BUT DREAMS"..ILL SLEEP WHEN IM DEAD.. #40GLOCC #YONJU #ZOOLIFE #MUSIC #MONEY #WOMEN #GIRLS #LADIES #TurndownForWhat #TURNUP #GUNIT #INFAMOUS #WESTCOAST #CALIFORNIA #LASVEGAS #INLANDEMPIRE #LOSANGELOS #LOSANGELES #IE #LA #WESTWEST #SOCAL #FOLLOWME... =20 =09=09 [55]=20 =09=09 [56]=20 =09=09 via Instagram [57] on 11.03.13=20 =09=09 [58] =09=09 [59] =20 =09 HAPPY GEE-DAY @omarsamhan -ME, FLAVOR FLAV, LEGEND, @crissangel (THE MAGICIAN), joejudah , @djerocksf1…=20 http://t.co/KIae1nYKgO [60] =20 =09=09 _1 retweet_ [61]=20 =09=09 [62]=20 =09=09via Twitter [63] on 11.04.13 =09=09 [64] =09 *VIDEO* 40 GLOCC border-bottom: none" colspan=3D"5">=20 =09My Cuzin @sun_days be pissin me off with his driving... #40GLOCC #YONJU #ZOOGANG #ZOOLIFE =20 =09=09 [70]=20 =09=09 [71]=20 =09=09 via Instagram [72] on 11.03.13=20 =09=09 [73] =09 If u never heard thus record check it out on I-tunes 40 glocc aka big bad 40 featuring ceelo green… ... =20 =09=09 _1 retweet_ [74]=20 =09=09 [75]=20 =09=09via Twitter [76] on 11.03.13 =09=09 [77] =09 40 Glocc AKA Yon Ju - "Hate That" (Music Video)=20 http://t.co/0jXOFjWA1U [78] via @youtube =20 =09=09 _1 retweet_ [79]=20 =09=09 [80]=20 =09=09via Twitter [81] on 11.03.13 =09=09 [82] =09IF U CAN FIND THIS MIX TAPE ONLINE U WILL HERE NOTHING BUT THST REAL.. ME border-bottom: none">=20 =09 RT @WorldWrap: New Music: @40Glocc - Dedicated=20 =09=09 Unsubscribe [87] | Update Info [88] | Privacy Policy [89]=20 ZOO LIFE ENT. sent this message to freebsd-net@freebsd.org Questions? Contact ZOO LIFE ENT.=20 c/o FanBridge, Inc. - 14525 SW Millikan Way #16910 Beaverton Oregon 97005 United States Powered by: [90] =20 =20 ------ [1][6] http://40GLOCC.fanbridge.com/socialdigest/show.php?sdrid=3D94133&sid=3D1= 76374750 [2] http://facebook.com/125820717478711 [3] http://instagram.com/40glocc [4] https://www.youtube.com/subscription_center?add_user_id=3DRwe0GCrUNFehlS= gGLcy7AQ [5][12][13][16][17][25][26][35][36][40][41][48][49][52][53][62][63][67][= 68][75][76][80][81] http://twitter.com/ [7][8] https://www.spotify.com/?utm_source=3Dspotify_webplayer&utm_medium=3Dmkt= _consumer&utm_campaign=3Dacquisition_magnacarta_email_us&utm_content=3Du= s500616&utm_term=3Demail [9][59] https://play.spotify.com/album/0OTjYdGtP7AbwOwbYsGhyi?utm_source=3Dspoti= fy_webplayer&utm_medium=3Dmkt_consumer&utm_campaign=3Dacquisition_magnac= arta_email_us&utm_content=3Dus500614&utm_term=3Demail [10] http://t.co/jffWqCDUZp" [11][14] https://twitter.com/#!//status/395704971137515520 [15][18] https://twitter.com/#!//status/395672537088016384 [19][22] http://instagram.com/p/gR3RFdlHej/ [20][21][44][45][56][57][71][72][84][85] http://40GLOCC.fanbridge.com [23] http://t.co/dKpODHVfJV [24] https://twitter.com/#!//status/392450945734287361 [27] HTTPS://TWITTER.COM/#!//STATUS/392450945734287361 [28][29] HTTPS://PLAY.SPOTIFY.COM/ALBUM/37UQAKT9DLSLOB7YOMDWY4?UTM_SOURCE=3DSPOTI= FY_WEBPLAYER&UTM_MEDIUM=3DMKT_CONSUMER&UTM_CAMPAIGN=3DACQUISITION_MAGNAC= ARTA_EMAIL_US&UTM_CONTENT=3DUS500615&UTM_TERM=3DEMAIL [30] HTTP://INSTAGRAM.COM/P/GRQCCIFHE-/ [31][32] HTTP://40GLOCC.FANBRIDGE.COM [33] http://instagram.com/p/gRqCcIFHe-/ [34][37] https://twitter.com/#!//status/397189284182368256 [38] http://t.co/guUo4ovLq0 [39][42] https://twitter.com/#!//status/396889479870681089 [43][46] http://instagram.com/p/gRfoZilHQM/ [47][50] https://twitter.com/#!//status/395643818214555648 [51][54] https://twitter.com/#!//status/394997008663986176 [55][58] http://instagram.com/p/gRBUv4lHcG/ [60] http://t.co/KIae1nYKgO [61][64] https://twitter.com/#!//status/397218806839640064 [65] http://t.co/gFDuaB6VGI [66][69] https://twitter.com/#!//status/397203840438521856 [70][73] http://instagram.com/p/gQsYXXlHec/ [74][77] https://twitter.com/#!//status/396862726368423937 [78] http://t.co/0jXOFjWA1U [79][82] https://twitter.com/#!//status/396876286544445440 [83][86] http://instagram.com/p/gPh-DelHQ2/ [87] http://t.co/vdhdRxRsGh Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB0BDAFE; Wed, 6 Nov 2013 15:01:28 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [162.235.35.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 734D42565; Wed, 6 Nov 2013 15:01:28 +0000 (UTC) Received: from dhcp-9726.meeting.ietf.org (dhcp-9726.meeting.ietf.org [31.133.151.38]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id rA6F19ic083966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Nov 2013 10:01:11 -0500 (EST) (envelope-from rrs@lakerest.net) Subject: Re: MQ Patch. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Randall Stewart In-Reply-To: Date: Wed, 6 Nov 2013 07:01:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <13BF1F55-EC13-482B-AF7D-59AE039F877D@lakerest.net> <52701F7E.2060604@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: Luigi Rizzo , Andre Oppermann , "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: Wed, 06 Nov 2013 15:01:28 -0000 The other problem with no software ring is you will have some rough time doing AQM approaches such as Codel. Codel does a head drop, if there is no software ring you must get the hardware to implement the head-drop. Pi on the other hand does tail drop, which is why Cisco is pushing it, = since its much more friendly for both software and hardware queues combined = (which is what Cisco has). Of course Pi has Cisco you can't sue me IPR with it thus the need for a = plugin, but Codel from Van does not have this.. but has that little niggle that it = only works with a queue in software that you can head-drop from . R On Oct 29, 2013, at 2:02 PM, Adrian Chadd wrote: > [snip everything] >=20 > ok, I've reviewed the work. >=20 > TL;DR - it's a clearly correct step in the right direction, but I > think we need to just think it through a tad bit more first. >=20 > There have been queue discipline and queue management discussions in > the past. Randall's work is a good step in that direction. >=20 > I think though that we can take a step back up a little further. >=20 > * In terms of queuing frames into multiple queues - yes, we absolutely > should have an if_transmit() path to the driver that obeys "a" QoS > field in the mbuf and pushes it into the relevant queue - with > randalls work, it's in the driver, but it doesn't _have_ to be; > * In terms of queue servicing and management - we likely need to have > a variety of queue plugins that determine which frame from which queue > gets chosen next to hand to the hardware. The hardware may have > multiple queues! The hardware may have one queue! The application > developer may only want to use one queue! That should be flexible and > easy to plug into things. > * Then we need to support dropping frames during queue and dropping > frames during dequeue (ie, on its way to the hardware). That way we > can implement the currently interesting kinds of queue disciplines (eg > CODEL, etc.) > * Should this be done at the driver layer (ie it's a library that each > driver creates and owns), or as a layer above it, controlling the > network device (ie, the linux queue discipline method.) >=20 > So, my comments: >=20 > * I don't like how it's hard-coding drbr's into the drivers. Yes, the > underlying state should be a drbr for now. But I'd rather we have a > queue discipline plugin API that drivers create an instance of. > * It'll have methods to init/flush the rings, queue a frame into a > ring, dequeue a frame from a ring, be notified of transmit completions > so more work can be done, etc. > * For people who do latency-sensitive things, they can just bypass > this entirely and go straight to the hardware queues without going > through this kind of intermediary queue layer. >=20 > Randall - I think we can take your work and turn it into a net library > that implements your queue management routines. That way we can start > enabling people to tinker with it and replace it if they need to. >=20 > What do you think? > _______________________________________________ > 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" >=20 ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Nov 6 15:59:06 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F24BADEA for ; Wed, 6 Nov 2013 15:59:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57A2A2940 for ; Wed, 6 Nov 2013 15:59:06 +0000 (UTC) Received: (qmail 52291 invoked from network); 6 Nov 2013 16:28:04 -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 2013 16:28:04 -0000 Message-ID: <527A673E.3070705@freebsd.org> Date: Wed, 06 Nov 2013 16:58:54 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Randall Stewart , Adrian Chadd Subject: Re: MQ Patch. References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <13BF1F55-EC13-482B-AF7D-59AE039F877D@lakerest.net> <52701F7E.2060604@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , "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: Wed, 06 Nov 2013 15:59:07 -0000 On 06.11.2013 16:01, Randall Stewart wrote: > The other problem with no software ring is you will > have some rough time doing AQM approaches such as Codel. The idea is to have different modes: when no QoS is configured the packets are going straight into the deep DMA rings. When QoS is configured the queue scheduler or discipline manages a software queue and can select a hardware DMA ring depth. The depth is managed by admitting only a certain amount of packets/data and the hardware doesn't have to shorten the ring itself. The depth probably is defined in microseconds at actual link speed. It won't be perfect and deviate by a few percent to keep the calculations simple (IFG, pre/post-amble, etc). With this the QoS, if enabled, can set the DMA depth to 1000us (1ms) for example to manage its software queues and overall effectiveness. Or it chooses 200us (0.2ms). It does have to balance the available resources though to prevent pipeline bubbling from scheduling latency. > Codel does a head drop, if there is no software ring you must get > the hardware to implement the head-drop. If you enable Codel queuing would happen in software and with a rather shallow DMA ring to make it effective. -- Andre > Pi on the other hand does tail drop, which is why Cisco is pushing it, since > its much more friendly for both software and hardware queues combined (which > is what Cisco has). > > Of course Pi has Cisco you can't sue me IPR with it thus the need for a plugin, but > Codel from Van does not have this.. but has that little niggle that it only > works with a queue in software that you can head-drop from . > > R > On Oct 29, 2013, at 2:02 PM, Adrian Chadd wrote: > >> [snip everything] >> >> ok, I've reviewed the work. >> >> TL;DR - it's a clearly correct step in the right direction, but I >> think we need to just think it through a tad bit more first. >> >> There have been queue discipline and queue management discussions in >> the past. Randall's work is a good step in that direction. >> >> I think though that we can take a step back up a little further. >> >> * In terms of queuing frames into multiple queues - yes, we absolutely >> should have an if_transmit() path to the driver that obeys "a" QoS >> field in the mbuf and pushes it into the relevant queue - with >> randalls work, it's in the driver, but it doesn't _have_ to be; >> * In terms of queue servicing and management - we likely need to have >> a variety of queue plugins that determine which frame from which queue >> gets chosen next to hand to the hardware. The hardware may have >> multiple queues! The hardware may have one queue! The application >> developer may only want to use one queue! That should be flexible and >> easy to plug into things. >> * Then we need to support dropping frames during queue and dropping >> frames during dequeue (ie, on its way to the hardware). That way we >> can implement the currently interesting kinds of queue disciplines (eg >> CODEL, etc.) >> * Should this be done at the driver layer (ie it's a library that each >> driver creates and owns), or as a layer above it, controlling the >> network device (ie, the linux queue discipline method.) >> >> So, my comments: >> >> * I don't like how it's hard-coding drbr's into the drivers. Yes, the >> underlying state should be a drbr for now. But I'd rather we have a >> queue discipline plugin API that drivers create an instance of. >> * It'll have methods to init/flush the rings, queue a frame into a >> ring, dequeue a frame from a ring, be notified of transmit completions >> so more work can be done, etc. >> * For people who do latency-sensitive things, they can just bypass >> this entirely and go straight to the hardware queues without going >> through this kind of intermediary queue layer. >> >> Randall - I think we can take your work and turn it into a net library >> that implements your queue management routines. That way we can start >> enabling people to tinker with it and replace it if they need to. >> >> What do you think? >> _______________________________________________ >> 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" >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > > _______________________________________________ > 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 Wed Nov 6 18:57:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B7F9352D for ; Wed, 6 Nov 2013 18:57:37 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9038824DC for ; Wed, 6 Nov 2013 18:57:37 +0000 (UTC) Received: from dhcp-a3d5.meeting.ietf.org (dhcp-a3d5.meeting.ietf.org [31.133.163.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id C433B6C11 for ; Wed, 6 Nov 2013 13:47:34 -0500 (EST) From: Tom Pusateri Content-Type: multipart/signed; boundary="Apple-Mail=_1E44B464-C99C-4E58-8AD9-4FD3B751224A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: ifa6_flags via routing socket/sysctl Message-Id: <0F75B72B-2FE4-45F3-AC2D-BF892D7B20F3@bangj.com> Date: Wed, 6 Nov 2013 10:47:32 -0800 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) X-Mailer: Apple Mail (2.1812) 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, 06 Nov 2013 18:57:37 -0000 --Apple-Mail=_1E44B464-C99C-4E58-8AD9-4FD3B751224A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a network daemon that reads the interface list via the = NET_RT_IFLIST/PF_ROUTE sysctl and then monitors changes to the = interfaces using the routing socket. I need to detect the interface address without the IN6_IFF_TEMPORARY = flag set to advertise a permanent service. The only way I have been able to figure out how to read the ifa6_flags = is through a separate ioctl: if (ioctl(s6, SIOCGIFAFLAG_IN6, &ifr6) < 0) { perror("ifconfig: ioctl(SIOCGIFAFLAG_IN6)"); close(s6); return; } Have I just missed the flags in the RTM_NEWADDR or RTM_IFINFO messages = or are they not available via the routing socket messages? Thanks, Tom --Apple-Mail=_1E44B464-C99C-4E58-8AD9-4FD3B751224A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSeo7EAAoJEPk0GMVmUuYM4EkH/0TyJ3Fm1TQLiHZbBuWmYnYG XvSyKjxog3IYrnvuGDATr4dXjhYRUiN1LMTL8zM1ZoxQl9a5Mdc6IrenBJcyUmES LD3+d2/ghiBFAnkmEmmrOaxLcQ0TbDcWRq/aX+PanVauZiXSciFZVjIqNJA8YIYP qh3ezWtuxOJZc/91sEQiLbnNHloVpNIQr2bR5X1yHsjJkFcOFdyfQQlpKtcNwJQH HSq688IPKeaZaSO+/gIF3SsRsUdeHYm/fnqi6jr25/z+xgxfD6qu0UmIQ4RQN3fX 7cU28HYydP1eTS5ETsK00Ao8XkF8zcoMuqiPze7gEkRWOswELvFdpwGi1k/l/cw= =6uVl -----END PGP SIGNATURE----- --Apple-Mail=_1E44B464-C99C-4E58-8AD9-4FD3B751224A-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 7 02:48:58 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4AEDA751; Thu, 7 Nov 2013 02:48:58 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E385231D; Thu, 7 Nov 2013 02:48:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA72mvQu061440; Thu, 7 Nov 2013 02:48:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA72mvM2061439; Thu, 7 Nov 2013 02:48:57 GMT (envelope-from linimon) Date: Thu, 7 Nov 2013 02:48:57 GMT Message-Id: <201311070248.rA72mvM2061439@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/182917: [igb] strange out traffic with igb interfaces 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, 07 Nov 2013 02:48:58 -0000 Old Synopsis: strange out traffic with igb interfaces New Synopsis: [igb] strange out traffic with igb interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 7 02:48:47 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=182917 From owner-freebsd-net@FreeBSD.ORG Thu Nov 7 02:50:23 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 68B2484E; Thu, 7 Nov 2013 02:50:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D2C02341; Thu, 7 Nov 2013 02:50:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA72oNrL061604; Thu, 7 Nov 2013 02:50:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA72oNk5061603; Thu, 7 Nov 2013 02:50:23 GMT (envelope-from linimon) Date: Thu, 7 Nov 2013 02:50:23 GMT Message-Id: <201311070250.rA72oNk5061603@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/183732: [igb] igb interface output byte counter double real output bytes on 8.4-RELEASE generic kernel 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, 07 Nov 2013 02:50:23 -0000 Old Synopsis: igb interface output byte counter double real output bytes on 8.4-RELEASE generic kernel New Synopsis: [igb] igb interface output byte counter double real output bytes on 8.4-RELEASE generic kernel Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 7 02:50:14 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=183732 From owner-freebsd-net@FreeBSD.ORG Thu Nov 7 14:10:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 87974E5A for ; Thu, 7 Nov 2013 14:10:51 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47DAC22BB for ; Thu, 7 Nov 2013 14:10:51 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VeQ3f-0008T1-Ct for freebsd-net@freebsd.org; Thu, 07 Nov 2013 14:55:39 +0100 Received: from h87.s239.verisign.com ([216.168.239.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Nov 2013 14:55:39 +0100 Received: from jcharbon by h87.s239.verisign.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Nov 2013 14:55:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: "Julien Charbon" Subject: Re: TCP stack lock contention with short-lived connections Date: Thu, 07 Nov 2013 14:55:22 +0100 Lines: 119 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: h87.s239.verisign.com User-Agent: Opera Mail/1.0 (MacIntel) 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, 07 Nov 2013 14:10:51 -0000 Hi list, On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon wrote: > just a follow-up of vBSDCon discussions about FreeBSD TCP performances > with short-lived connections. In summary: > > I have put technical and how-to-repeat details in below PR: > > kern/183659: TCP stack lock contention with short-lived connections > http://www.freebsd.org/cgi/query-pr.cgi?pr=183659 > > We are currently working on this performance improvement effort; it > will impact only the TCP locking strategy not the TCP stack logic > itself. We will share on freebsd-net the patches we made for reviewing > and improvement propositions; anyway this change might also require > enough eyeballs to avoid tricky race conditions introduction in TCP > stack. Just a follow-up: We are currently removing TCP INP_INFO lock from places it is actually not required in order to mitigate the lock contention. It seems to be a good first step in this effort: Small changes, easy to review, low risk (and small gain... right). Below a first patch that removes INP_INFO lock from tcp_usr_accept(): This changes simply follows the advice made in corresponding code comment: "A better fix would prevent the socket from being placed in the listen queue until all fields are fully initialized." For more technical details, check the comment in related change below: http://svnweb.freebsd.org/base?view=revision&revision=175612 With this patch applied we see no regressions and a performance improvement of ~5% i.e with 9.2 vanilla kernel: 52k TCP Queries Per Second, with 9.2 + joined patch: 55k TCP QPS. Not huge indeed but still an improvement. P.S.: Funny enough it seems that the same change has already been proposed in the past: http://lists.freebsd.org/pipermail/freebsd-net/2013-January/034261.html -- Julien From: Julien Charbon Subject: [PATCH] Add new socket in listen queue only when fully initialized --- sys/netinet/tcp_syncache.c | 4 +++- sys/netinet/tcp_usrreq.c | 9 --------- 2 files changed, 3 insertions(+), 10 deletions(-) diff --git a/sys/netinet/tcp_syncache.c b/sys/netinet/tcp_syncache.c index af1651a..eb73356 100644 --- a/sys/netinet/tcp_syncache.c +++ b/sys/netinet/tcp_syncache.c @@ -660,7 +660,7 @@ syncache_socket(struct syncache *sc, struct socket *lso, struct mbuf *m) * connection when the SYN arrived. If we can't create * the connection, abort it. */ - so = sonewconn(lso, SS_ISCONNECTED); + so = sonewconn(lso, 0); if (so == NULL) { /* * Drop the connection; we will either send a RST or @@ -890,6 +890,8 @@ syncache_socket(struct syncache *sc, struct socket *lso, struct mbuf *m) INP_WUNLOCK(inp); + soisconnected(so); + TCPSTAT_INC(tcps_accepts); return (so); diff --git a/sys/netinet/tcp_usrreq.c b/sys/netinet/tcp_usrreq.c index b83f34a..566cc34 100644 --- a/sys/netinet/tcp_usrreq.c +++ b/sys/netinet/tcp_usrreq.c @@ -609,13 +609,6 @@ out: /* * Accept a connection. Essentially all the work is done at higher levels; * just return the address of the peer, storing through addr. - * - * The rationale for acquiring the tcbinfo lock here is somewhat complicated, - * and is described in detail in the commit log entry for r175612. Acquiring - * it delays an accept(2) racing with sonewconn(), which inserts the socket - * before the inpcb address/port fields are initialized. A better fix would - * prevent the socket from being placed in the listen queue until all fields - * are fully initialized. */ static int tcp_usr_accept(struct socket *so, struct sockaddr **nam) @@ -632,7 +625,6 @@ tcp_usr_accept(struct socket *so, struct sockaddr **nam) inp = sotoinpcb(so); KASSERT(inp != NULL, ("tcp_usr_accept: inp == NULL")); - INP_INFO_RLOCK(&V_tcbinfo); INP_WLOCK(inp); if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) { error = ECONNABORTED; @@ -652,7 +644,6 @@ tcp_usr_accept(struct socket *so, struct sockaddr **nam) out: TCPDEBUG2(PRU_ACCEPT); INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); if (error == 0) *nam = in_sockaddr(port, &addr); return error; From owner-freebsd-net@FreeBSD.ORG Thu Nov 7 15:30:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0E03762 for ; Thu, 7 Nov 2013 15:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE68B27E9 for ; Thu, 7 Nov 2013 15:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA7FU1HS044906 for ; Thu, 7 Nov 2013 15:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA7FU1KI044905; Thu, 7 Nov 2013 15:30:01 GMT (envelope-from gnats) Date: Thu, 7 Nov 2013 15:30:01 GMT Message-Id: <201311071530.rA7FU1KI044905@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: "Julien Charbon" Subject: Re: kern/183659: [tcp] [patch] TCP stack lock contention with short-lived connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Julien Charbon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:30:02 -0000 The following reply was made to PR kern/183659; it has been noted by GNATS. From: "Julien Charbon" To: bug-followup@freebsd.org Cc: Subject: Re: kern/183659: [tcp] [patch] TCP stack lock contention with short-lived connections Date: Thu, 07 Nov 2013 15:09:12 +0100 ------------DUpEMRBHJWbgn0J5PBi2Pu Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Joined a first patch that removes INP_INFO lock from tcp_usr_accept(): This changes simply follows the advice made in corresponding code comment: "A better fix would prevent the socket from being placed in the listen queue until all fields are fully initialized." For more technical details, check the comment in related change below: http://svnweb.freebsd.org/base?view=revision&revision=175612 With this patch applied we see no regressions and a performance improvement of ~5% i.e with 9.2 vanilla kernel: 52k TCP Queries Per Second, with 9.2 + joined patch: 55k TCP QPS. -- Julien ------------DUpEMRBHJWbgn0J5PBi2Pu Content-Disposition: attachment; filename=inp-info-accept.patch Content-Type: application/octet-stream; name=inp-info-accept.patch Content-Transfer-Encoding: Base64 RnJvbTogSnVsaWVuIENoYXJib24gPGpjaGFyYm9uQHZlcmlzaWduLmNvbT4NClN1 YmplY3Q6IFtQQVRDSF0gQWRkIG5ldyBzb2NrZXQgaW4gbGlzdGVuIHF1ZXVlIG9u bHkgd2hlbiBmdWxseSBpbml0aWFsaXNlZA0KDQotLS0NCiBzeXMvbmV0aW5ldC90 Y3Bfc3luY2FjaGUuYyB8IDQgKysrLQ0KIHN5cy9uZXRpbmV0L3RjcF91c3JyZXEu YyAgIHwgOSAtLS0tLS0tLS0NCiAyIGZpbGVzIGNoYW5nZWQsIDMgaW5zZXJ0aW9u cygrKSwgMTAgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9zeXMvbmV0aW5l dC90Y3Bfc3luY2FjaGUuYyBiL3N5cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jDQpp bmRleCBhZjE2NTFhLi5lYjczMzU2IDEwMDY0NA0KLS0tIGEvc3lzL25ldGluZXQv dGNwX3N5bmNhY2hlLmMNCisrKyBiL3N5cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5j DQpAQCAtNjYwLDcgKzY2MCw3IEBAIHN5bmNhY2hlX3NvY2tldChzdHJ1Y3Qgc3lu Y2FjaGUgKnNjLCBzdHJ1Y3Qgc29ja2V0ICpsc28sIHN0cnVjdCBtYnVmICptKQ0K IAkgKiBjb25uZWN0aW9uIHdoZW4gdGhlIFNZTiBhcnJpdmVkLiAgSWYgd2UgY2Fu J3QgY3JlYXRlDQogCSAqIHRoZSBjb25uZWN0aW9uLCBhYm9ydCBpdC4NCiAJICov DQotCXNvID0gc29uZXdjb25uKGxzbywgU1NfSVNDT05ORUNURUQpOw0KKwlzbyA9 IHNvbmV3Y29ubihsc28sIDApOw0KIAlpZiAoc28gPT0gTlVMTCkgew0KIAkJLyoN CiAJCSAqIERyb3AgdGhlIGNvbm5lY3Rpb247IHdlIHdpbGwgZWl0aGVyIHNlbmQg YSBSU1Qgb3INCkBAIC04OTAsNiArODkwLDggQEAgc3luY2FjaGVfc29ja2V0KHN0 cnVjdCBzeW5jYWNoZSAqc2MsIHN0cnVjdCBzb2NrZXQgKmxzbywgc3RydWN0IG1i dWYgKm0pDQogDQogCUlOUF9XVU5MT0NLKGlucCk7DQogDQorCXNvaXNjb25uZWN0 ZWQoc28pOw0KKw0KIAlUQ1BTVEFUX0lOQyh0Y3BzX2FjY2VwdHMpOw0KIAlyZXR1 cm4gKHNvKTsNCiANCmRpZmYgLS1naXQgYS9zeXMvbmV0aW5ldC90Y3BfdXNycmVx LmMgYi9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmMNCmluZGV4IGI4M2YzNGEuLjU2 NmNjMzQgMTAwNjQ0DQotLS0gYS9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmMNCisr KyBiL3N5cy9uZXRpbmV0L3RjcF91c3JyZXEuYw0KQEAgLTYwOSwxMyArNjA5LDYg QEAgb3V0Og0KIC8qDQogICogQWNjZXB0IGEgY29ubmVjdGlvbi4gIEVzc2VudGlh bGx5IGFsbCB0aGUgd29yayBpcyBkb25lIGF0IGhpZ2hlciBsZXZlbHM7DQogICog anVzdCByZXR1cm4gdGhlIGFkZHJlc3Mgb2YgdGhlIHBlZXIsIHN0b3JpbmcgdGhy b3VnaCBhZGRyLg0KLSAqDQotICogVGhlIHJhdGlvbmFsZSBmb3IgYWNxdWlyaW5n IHRoZSB0Y2JpbmZvIGxvY2sgaGVyZSBpcyBzb21ld2hhdCBjb21wbGljYXRlZCwN Ci0gKiBhbmQgaXMgZGVzY3JpYmVkIGluIGRldGFpbCBpbiB0aGUgY29tbWl0IGxv ZyBlbnRyeSBmb3IgcjE3NTYxMi4gIEFjcXVpcmluZw0KLSAqIGl0IGRlbGF5cyBh biBhY2NlcHQoMikgcmFjaW5nIHdpdGggc29uZXdjb25uKCksIHdoaWNoIGluc2Vy dHMgdGhlIHNvY2tldA0KLSAqIGJlZm9yZSB0aGUgaW5wY2IgYWRkcmVzcy9wb3J0 IGZpZWxkcyBhcmUgaW5pdGlhbGl6ZWQuICBBIGJldHRlciBmaXggd291bGQNCi0g KiBwcmV2ZW50IHRoZSBzb2NrZXQgZnJvbSBiZWluZyBwbGFjZWQgaW4gdGhlIGxp c3RlbiBxdWV1ZSB1bnRpbCBhbGwgZmllbGRzDQotICogYXJlIGZ1bGx5IGluaXRp YWxpemVkLg0KICAqLw0KIHN0YXRpYyBpbnQNCiB0Y3BfdXNyX2FjY2VwdChzdHJ1 Y3Qgc29ja2V0ICpzbywgc3RydWN0IHNvY2thZGRyICoqbmFtKQ0KQEAgLTYzMiw3 ICs2MjUsNiBAQCB0Y3BfdXNyX2FjY2VwdChzdHJ1Y3Qgc29ja2V0ICpzbywgc3Ry dWN0IHNvY2thZGRyICoqbmFtKQ0KIA0KIAlpbnAgPSBzb3RvaW5wY2Ioc28pOw0K IAlLQVNTRVJUKGlucCAhPSBOVUxMLCAoInRjcF91c3JfYWNjZXB0OiBpbnAgPT0g TlVMTCIpKTsNCi0JSU5QX0lORk9fUkxPQ0soJlZfdGNiaW5mbyk7DQogCUlOUF9X TE9DSyhpbnApOw0KIAlpZiAoaW5wLT5pbnBfZmxhZ3MgJiAoSU5QX1RJTUVXQUlU IHwgSU5QX0RST1BQRUQpKSB7DQogCQllcnJvciA9IEVDT05OQUJPUlRFRDsNCkBA IC02NTIsNyArNjQ0LDYgQEAgdGNwX3Vzcl9hY2NlcHQoc3RydWN0IHNvY2tldCAq c28sIHN0cnVjdCBzb2NrYWRkciAqKm5hbSkNCiBvdXQ6DQogCVRDUERFQlVHMihQ UlVfQUNDRVBUKTsNCiAJSU5QX1dVTkxPQ0soaW5wKTsNCi0JSU5QX0lORk9fUlVO TE9DSygmVl90Y2JpbmZvKTsNCiAJaWYgKGVycm9yID09IDApDQogCQkqbmFtID0g aW5fc29ja2FkZHIocG9ydCwgJmFkZHIpOw0KIAlyZXR1cm4gZXJyb3I7 ------------DUpEMRBHJWbgn0J5PBi2Pu-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 8 05:42:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8A0359E for ; Fri, 8 Nov 2013 05:42:00 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9BC702EE5 for ; Fri, 8 Nov 2013 05:42:00 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id cy11so1476620qeb.40 for ; Thu, 07 Nov 2013 21:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ieUlvyeHKPCofUgupxP9F9710pQ2LLIi9KJEXEuhFWA=; b=jxe00KQ8mnhmbgRTzW+SL8006mv5+nxdNvpra717agxP5OjTUZDwCpvs+wDvMuER3Z kmlggPompj/iMGn2NekGdjLN9+tlmwmkSM+5cWDm85PXqwdYVq4IqIhbn7Txzsu5sEPX Qv4JCPIbM4k5GxK0+19nGv3rTsq+CXSBxKG4g2TYXtVejcpsFlNrdAIeQ17hwcYSRb+u 5YT6k7V1UYHcjwP85pH3MrvhSdQOl0OynYge27ZqFowMINubULEMse4D7KLThgMtgGQb BxQ1rDW3BQ1uKIvR3UvGiaIOxzBZuCAQ0zSDis/9NGpii1/mprnFiPXtMMXJ5Q4R2xOJ 52hQ== X-Received: by 10.224.88.193 with SMTP id b1mr20944770qam.81.1383889319814; Thu, 07 Nov 2013 21:41:59 -0800 (PST) Received: from [172.16.99.102] (stjhnf0148w-142162172204.dhcp-dynamic.fibreop.nl.bellaliant.net. [142.162.172.204]) by mx.google.com with ESMTPSA id l5sm18564455qac.12.2013.11.07.21.41.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 21:41:59 -0800 (PST) Message-ID: <527C799D.8020208@Gmail.com> Date: Fri, 08 Nov 2013 02:11:49 -0330 From: Bear User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ng_patch and 802.11Q Content-Type: text/plain; charset=UTF-8; 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: Fri, 08 Nov 2013 05:42:00 -0000 Hi all, I want to modify VLAN priority by ng_patch. After reading the manpage of ng_patch(http://www.freebsd.org/cgi/man.cgi?query=ng_patch) and the example it given: > /usr/sbin/ngctl -f- <<-SEQ > mkpeer ipfw: patch 200 in > name ipfw:200 ttl_add > msg ttl_add: setconfig { count=1 csum_flags=1 ops=[ \ > { mode=2 value=3 length=1 offset=8 } ] } > SEQ > /sbin/ipfw add 150 netgraph 200 ip from any to simplex.remote.net It seems ng_patch can only modify IP header. However, the position of VLAN header is before IP header and after Ethernet header. How can I modify it? Thanks in advanced. From owner-freebsd-net@FreeBSD.ORG Fri Nov 8 20:05:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CE08C6EE for ; Fri, 8 Nov 2013 20:05:13 +0000 (UTC) (envelope-from juris.kaminskis@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C2E42E01 for ; Fri, 8 Nov 2013 20:05:13 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t60so2393674wes.26 for ; Fri, 08 Nov 2013 12:05:11 -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=B2IRZN+sWv0mSQHFGMwSetAF+bWxGB77DWiplknJLhg=; b=u0CtZmj4umKsPUGCJRJhSGIsnRQP2zwfZz9Y6fVASlgpvet4W6lB7uZLCLgevZoTSp fFyXwcYwc1ajlp5glm6dauF0ufvcxkDpdFyBQJJ7DGKiDN3LRZJ7uwStZe5tH+XhdJyl 2fQh7WFAT+drMyv2NHEVfezS97QLcWmiT61HYpe0HIVQvb8wXFa+BuJD2DxqmNcOo7cl bGBPG7tg4DuJpivbML6R0pwyE+FJ5+ayowMIKl67T4J49K2iR2gQWGHhjhg15ELNxgaS 7BL3yHnFFDnD+cDVp4L/KSpBLcvHdSJAkPonzE3I9nk8ILk+EqxIK8S9W5jITypKk6K0 i5kQ== MIME-Version: 1.0 X-Received: by 10.194.176.163 with SMTP id cj3mr13510550wjc.8.1383941111798; Fri, 08 Nov 2013 12:05:11 -0800 (PST) Received: by 10.194.185.101 with HTTP; Fri, 8 Nov 2013 12:05:11 -0800 (PST) Date: Fri, 8 Nov 2013 22:05:11 +0200 Message-ID: Subject: Sharing NTFS file system over NFS From: Juris Kaminskis To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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, 08 Nov 2013 20:05:13 -0000 Hello, Maybe you can help, I am trying to solve sharing NTFS file system over NFS, is that possible? See my post on freebsd-questions mailing list http://docs.FreeBSD.org/cgi/mid.cgi?CAKJAkzuqtOMfZC-+bfgKYn8QbG7y22XKpnTGKJMFxs3JfyhQ=g thanks Juris From owner-freebsd-net@FreeBSD.ORG Fri Nov 8 21:52:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 903DC91D for ; Fri, 8 Nov 2013 21:52:13 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15FE422F4 for ; Fri, 8 Nov 2013 21:52:12 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rA8LqAoO031629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Nov 2013 01:52:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rA8LqANf031628; Sat, 9 Nov 2013 01:52:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 9 Nov 2013 01:52:10 +0400 From: Gleb Smirnoff To: Bear Subject: Re: ng_patch and 802.11Q Message-ID: <20131108215210.GH7577@FreeBSD.org> References: <527C799D.8020208@Gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527C799D.8020208@Gmail.com> User-Agent: Mutt/1.5.22 (2013-10-16) 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, 08 Nov 2013 21:52:13 -0000 On Fri, Nov 08, 2013 at 02:11:49AM -0330, Bear wrote: B> Hi all, B> I want to modify VLAN priority by ng_patch. After reading the manpage of B> ng_patch(http://www.freebsd.org/cgi/man.cgi?query=ng_patch) and the B> example it given: B> B> > /usr/sbin/ngctl -f- <<-SEQ B> > mkpeer ipfw: patch 200 in B> > name ipfw:200 ttl_add B> > msg ttl_add: setconfig { count=1 csum_flags=1 ops=[ \ B> > { mode=2 value=3 length=1 offset=8 } ] } B> > SEQ B> > /sbin/ipfw add 150 netgraph 200 ip from any to simplex.remote.net B> B> It seems ng_patch can only modify IP header. However, the position of B> VLAN header is before IP header and after Ethernet header. How can I B> modify it? ipfw allows you to intercept packets at IP layer. Tp modify VLAN header, you need to capture them earlier. May be ng_ether(4) will help you. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Nov 8 22:36:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 34710252 for ; Fri, 8 Nov 2013 22:36:38 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ03.datapipe-corp.net (exfesmq03.datapipe.com [64.27.120.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9A7F24FC for ; Fri, 8 Nov 2013 22:36:37 +0000 (UTC) Received: from nat.myhome (192.168.128.21) by EXFESMQ03.datapipe-corp.net (192.168.128.28) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 8 Nov 2013 17:35:18 -0500 Date: Fri, 8 Nov 2013 16:35:38 -0600 From: "Paul A. Procacci" To: Juris Kaminskis Subject: Re: Sharing NTFS file system over NFS Message-ID: <20131108223538.GB41951@nat.myhome> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.21] Content-Transfer-Encoding: quoted-printable 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, 08 Nov 2013 22:36:38 -0000 By the looks of it you need the -alldirs option. exports(5) has other information you may be interested in. ~Paul On Fri, Nov 08, 2013 at 10:05:11PM +0200, Juris Kaminskis wrote: > Hello, > > Maybe you can help, I am trying to solve sharing NTFS file system over NF= S, > is that possible? > > See my post on freebsd-questions mailing list > http://docs.FreeBSD.org/cgi/mid.cgi?CAKJAkzuqtOMfZC-+bfgKYn8QbG7y22XKpnTG= KJMFxs3JfyhQ=3Dg > > thanks > Juris > _______________________________________________ > 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" ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. Unless otherwise specified in a writt= en agreement, this e-mail neither constitutes an agreement to conduct trans= actions by electronic means nor creates any legally binding contract or enf= orceable agreement. From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 06:27:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 571FB18F for ; Sat, 9 Nov 2013 06:27:14 +0000 (UTC) (envelope-from juris.kaminskis@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E77092C0E for ; Sat, 9 Nov 2013 06:27:13 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id w61so2779943wes.38 for ; Fri, 08 Nov 2013 22:27:12 -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=uaqsJ/dU55nSQiKN0rJ/Fu5AiD23FMp8Gy16fDcYIFw=; b=hVSHf+xB9j5MY+MdGxQPKi+DK5DcrsExoqUYiTcdByoyWcGSuhwLLdmVvCu0EVh+g5 dYkCRHcUcuWIAbXSXzDBLO5ICM88lrKU63vn7Ra2gVmMJI9+wKnjYzJ67fxU4JYeOWM8 FzIX+o/yUHTTdgp0feDBjAtRxA0KQ1X2KmLb3tJQ1NHwKAspa3dEsQxN3M0iCMkSX7k0 mU5URYRckK/0wWG8et9kOZN7bgN/8Ws1njbG6NBRrQdNhq4YLTHNdQVyGPDt0kUsKW0M o2iroj4+FFPX8AI1ghQ6etR//kseXz/NMwUQxZEu4dEhmBVOAp2Bk9O+0SZwBfPoe1M8 tSWQ== MIME-Version: 1.0 X-Received: by 10.194.89.233 with SMTP id br9mr14775972wjb.15.1383978432396; Fri, 08 Nov 2013 22:27:12 -0800 (PST) Received: by 10.194.185.101 with HTTP; Fri, 8 Nov 2013 22:27:12 -0800 (PST) Received: by 10.194.185.101 with HTTP; Fri, 8 Nov 2013 22:27:12 -0800 (PST) In-Reply-To: <20131108223538.GB41951@nat.myhome> References: <20131108223538.GB41951@nat.myhome> Date: Sat, 9 Nov 2013 08:27:12 +0200 Message-ID: Subject: Re: Sharing NTFS file system over NFS From: Juris Kaminskis To: "Paul A. Procacci" Content-Type: text/plain; charset=ISO-8859-13 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Sat, 09 Nov 2013 06:27:14 -0000 2013. gada 9. nov. 00:35, "Paul A. Procacci" rakst=EEja: > > By the looks of it you need the -alldirs option. > > exports(5) has other information you may be interested in. > > ~Paul I have used -alldirs but to no avail, it is something else From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 07:10:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 85A38729; Sat, 9 Nov 2013 07:10:37 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35A482DF9; Sat, 9 Nov 2013 07:10:37 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id w7so2869080qeb.11 for ; Fri, 08 Nov 2013 23:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ihTwXNl6q4wWFQpsPjZ2AIoAqYRRhESZAkKIEYoV/Lg=; b=dtkqHKiLQWeflA4JyxKjshUrmgcF8Z1EQd3gV3xZn1cuMECmCLeDYpoy5nQ4VegSEP NfzNGN7ygJEPg7NUnsRNYZQ+99fDxgwyql4y2gYe1kNWt2/xLdlJPKnwh6RJVy4fm1iY TgE0MBw1uTsMzXezk3FYAo/0iWIOVYr1ykdSrlB1jO81/qT0VYpZwkw8MnSLKu/JsAMi VIH6J3kJvSoCKtDicDNwnk5NZguHYEWEBYr/n/vu9q/J4NUPlUQ6eC1GQHv9qXjHqg8z 43XMAHaPT4Q85iVkw4vCw3Ie3pUACSsJEyGSldKk6jMLFygknC/fD8s200H02BcWJIwF S2tA== X-Received: by 10.224.94.8 with SMTP id x8mr30204460qam.1.1383981036048; Fri, 08 Nov 2013 23:10:36 -0800 (PST) Received: from [172.16.99.107] (stjhnf0148w-142162175108.dhcp-dynamic.fibreop.nl.bellaliant.net. [142.162.175.108]) by mx.google.com with ESMTPSA id v19sm31592176qaw.0.2013.11.08.23.10.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 23:10:35 -0800 (PST) Message-ID: <527DDFEA.9050001@Gmail.com> Date: Sat, 09 Nov 2013 03:40:34 -0330 From: Bear User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: ng_patch and 802.11Q References: <527C799D.8020208@Gmail.com> <20131108215210.GH7577@FreeBSD.org> In-Reply-To: <20131108215210.GH7577@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; 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: Sat, 09 Nov 2013 07:10:37 -0000 Hi, It seems a good idea... Do you have some example working on ng_ether? The manpage of ng_ether seems no example... On 11/8/2013 6:22 PM, Gleb Smirnoff wrote: > On Fri, Nov 08, 2013 at 02:11:49AM -0330, Bear wrote: > B> Hi all, > B> I want to modify VLAN priority by ng_patch. After reading the manpage of > B> ng_patch(http://www.freebsd.org/cgi/man.cgi?query=ng_patch) and the > B> example it given: > B> > B> > /usr/sbin/ngctl -f- <<-SEQ > B> > mkpeer ipfw: patch 200 in > B> > name ipfw:200 ttl_add > B> > msg ttl_add: setconfig { count=1 csum_flags=1 ops=[ \ > B> > { mode=2 value=3 length=1 offset=8 } ] } > B> > SEQ > B> > /sbin/ipfw add 150 netgraph 200 ip from any to simplex.remote.net > B> > B> It seems ng_patch can only modify IP header. However, the position of > B> VLAN header is before IP header and after Ethernet header. How can I > B> modify it? > > ipfw allows you to intercept packets at IP layer. Tp modify VLAN header, > you need to capture them earlier. May be ng_ether(4) will help you. > From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 14:39:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 32C0BFEC; Sat, 9 Nov 2013 14:39:38 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 854902151; Sat, 9 Nov 2013 14:39:37 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id z5so2196430lbh.21 for ; Sat, 09 Nov 2013 06:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding :content-language:thread-index; bh=8SnyJk8licQWMfjcFqSfg6mD9L16WRo6ULQ6eaIAXzc=; b=PPVINpjZslbA0lBEP07h41OSO4cjhKJqExrnj2oWY6WfdTNEGCE9vseRiHV0y/3HWy oSz5NUW6F4nmn+DejqyPNxDKVEbijREvmNK8lS3GKsk1G5C5KQQ1Bkdt5JcJ/YKUzr41 GioULC/I4x+EzM41VwjPAVU8PBXB1s+xAs4veokQVgcuXUJePr+7j4Xemi7n5HYu99Am 8tONs1WC6VWX2XfxO8sEdyjvITFO6XePankTTLxC7sboBnDJOllhg4mnHVoM9mS+x663 ke6NaqBBf0lbwzkq+rsmr0fyy6GZHI/IeTuoSfQplueeYSVbyjSlamJ8rOAeTK8921av wv0A== X-Received: by 10.112.167.3 with SMTP id zk3mr14455142lbb.23.1384007975599; Sat, 09 Nov 2013 06:39:35 -0800 (PST) Received: from rimwks1w7x64 ([176.99.246.90]) by mx.google.com with ESMTPSA id l10sm10047470lbh.13.2013.11.09.06.39.33 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Nov 2013 06:39:34 -0800 (PST) From: rozhuk.im@gmail.com To: "'Bear'" , "'Gleb Smirnoff'" References: <527C799D.8020208@Gmail.com> <20131108215210.GH7577@FreeBSD.org> <527DDFEA.9050001@Gmail.com> In-Reply-To: <527DDFEA.9050001@Gmail.com> Subject: RE: ng_patch and 802.11Q Date: Sat, 9 Nov 2013 18:39:18 +0400 Message-ID: <527e4926.aa1d700a.02d7.fffff457@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru Thread-Index: Ac7dGtARNXnQeAJKSemKlLVltqfpQAAPmYMg Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 14:39:38 -0000 http://www.netlab.linkpc.net/download/software/FreeBSD/mcastbridge/mcastbr2. sh http://www.netlab.linkpc.net/forum/index.php?topic=796.0 > It seems a good idea... Do you have some example working on ng_ether? > The manpage of ng_ether seems no example... > > On 11/8/2013 6:22 PM, Gleb Smirnoff wrote: > > On Fri, Nov 08, 2013 at 02:11:49AM -0330, Bear wrote: > > B> Hi all, > > B> I want to modify VLAN priority by ng_patch. After reading the > > B> manpage of > > B> ng_patch(http://www.freebsd.org/cgi/man.cgi?query=ng_patch) and > the > > B> example it given: > > B> > > B> > /usr/sbin/ngctl -f- <<-SEQ > > B> > mkpeer ipfw: patch 200 in > > B> > name ipfw:200 ttl_add > > B> > msg ttl_add: setconfig { count=1 csum_flags=1 ops=[ \ > > B> > { mode=2 value=3 length=1 offset=8 } ] } > > B> > SEQ > > B> > /sbin/ipfw add 150 netgraph 200 ip from any to > > B> simplex.remote.net > > B> > > B> It seems ng_patch can only modify IP header. However, the position > > B> of VLAN header is before IP header and after Ethernet header. How > > B> can I modify it? > > > > ipfw allows you to intercept packets at IP layer. Tp modify VLAN > > header, you need to capture them earlier. May be ng_ether(4) will > help you. > > From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 17:33:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D777CC8E for ; Sat, 9 Nov 2013 17:33:16 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74A1C2A18 for ; Sat, 9 Nov 2013 17:33:16 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so3075855wgg.28 for ; Sat, 09 Nov 2013 09:33:15 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Erz6NnoCzCTXE0cHEnbSHMi1ZvmK/xtnX59BQF69nUM=; b=s38g+2qeOIl+pdgszgn6zZo7bFvKdmkouucMe9LrD+MTlomY/3BauRvicr4hsFX53G eiOFwwNfuCCQCRM/Iqvro4gbPeFisfcQBn8rlLCmN94rt70RL0U5CxWcQs2v1KIWYjvt oCJUBFxS65ZtoBXRmIVuogi+FsTt+GF1o8Bqz+a9IGx4nchNTrjBtKag0kGrxHpChJF+ EbZB8esUWcGmdvNxGV0hkgQeyphyGmVIYDnwsk1W7dDUzvhZ4OE/w1aaKIxhSb534P7Q v6CXB6kO41QxJe3MQNBuLV/abY6vV2dJdRgPzXv6jgeK50w1vhw4LyhXDezJ7Xiw4vGH POWQ== MIME-Version: 1.0 X-Received: by 10.194.176.163 with SMTP id cj3mr16515944wjc.8.1384018394977; Sat, 09 Nov 2013 09:33:14 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.171.35 with HTTP; Sat, 9 Nov 2013 09:33:14 -0800 (PST) In-Reply-To: References: <20131108223538.GB41951@nat.myhome> Date: Sat, 9 Nov 2013 10:33:14 -0700 X-Google-Sender-Auth: UGpw3W54YW-yCCz6AUpJmRGFFHQ Message-ID: Subject: Re: Sharing NTFS file system over NFS From: Alan Somers To: Juris Kaminskis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, "Paul A. Procacci" 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, 09 Nov 2013 17:33:16 -0000 On Fri, Nov 8, 2013 at 11:27 PM, Juris Kaminskis wrote: > 2013. gada 9. nov. 00:35, "Paul A. Procacci" > rakst=C4=ABja: >> >> By the looks of it you need the -alldirs option. >> >> exports(5) has other information you may be interested in. >> >> ~Paul > > I have used -alldirs but to no avail, it is something else Are you using fuse-ntfs? Somewhere I read that the in-kernel NFS server can't serve FUSE file systems. If that's true, you could try unfs3 (slow but stable) or nfs-ganesha (fast but immature). -Alan From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 19:30:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DFA2F67F; Sat, 9 Nov 2013 19:30:09 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD602EB9; Sat, 9 Nov 2013 19:30:09 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id a11so3156043qen.8 for ; Sat, 09 Nov 2013 11:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xWar/47yALKLGoGj9e5qpfXBjluYdxM0D5P63EVUtag=; b=UXsClFX0htRU93xKtaolq/mihasRyYHp7hVUSJXMV0dxYnqft9DrfouRYTnkzr5nMR EqCJ4UWozb5aHGjNbg4X64GRSNnB+hCRyPM1GPRGOwb4x/iRKuiObn7ng3urr1BzH2UY 7kDFeG6eUNm0kqhbYm+7CesKDz3+rphQa93Lo/Px7sOojceA0Jp1E6nSGUdQipFSIOF4 VpVwWcRGWH5ekrJ70Ln7aIIMBr7MA5u3//tYGzB6mVQBHvMkW8t8uNtFYTjwvyEYa6Wh gos1oCbPBprWm0sRovDWY7j8gfHPUsBb6QsamUfwKn3uMV4PtNiV7aJCVnubn+T64HGH rWuA== X-Received: by 10.229.224.70 with SMTP id in6mr33225894qcb.7.1384025408783; Sat, 09 Nov 2013 11:30:08 -0800 (PST) Received: from [172.16.99.106] (stjhnf0148w-142162175108.dhcp-dynamic.fibreop.nl.bellaliant.net. [142.162.175.108]) by mx.google.com with ESMTPSA id j1sm37484250qaa.6.2013.11.09.11.30.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 11:30:08 -0800 (PST) Message-ID: <527E8D3E.4050907@Gmail.com> Date: Sat, 09 Nov 2013 16:00:06 -0330 From: Bear User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com, 'Gleb Smirnoff' Subject: Re: ng_patch and 802.11Q References: <527C799D.8020208@Gmail.com> <20131108215210.GH7577@FreeBSD.org> <527DDFEA.9050001@Gmail.com> <527e4926.aa1d700a.02d7.fffff457@mx.google.com> In-Reply-To: <527e4926.aa1d700a.02d7.fffff457@mx.google.com> Content-Type: text/plain; charset=UTF-8; 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: Sat, 09 Nov 2013 19:30:09 -0000 Hi Gleb, I read the script you given but still no clue :-( On 2013/11/9 11:09 AM, rozhuk.im@gmail.com wrote: > http://www.netlab.linkpc.net/download/software/FreeBSD/mcastbridge/mcastbr2. > sh > http://www.netlab.linkpc.net/forum/index.php?topic=796.0 > > >> It seems a good idea... Do you have some example working on ng_ether? >> The manpage of ng_ether seems no example... >> >> On 11/8/2013 6:22 PM, Gleb Smirnoff wrote: >>> On Fri, Nov 08, 2013 at 02:11:49AM -0330, Bear wrote: >>> B> Hi all, >>> B> I want to modify VLAN priority by ng_patch. After reading the >>> B> manpage of >>> B> ng_patch(http://www.freebsd.org/cgi/man.cgi?query=ng_patch) and >> the >>> B> example it given: >>> B> >>> B> > /usr/sbin/ngctl -f- <<-SEQ >>> B> > mkpeer ipfw: patch 200 in >>> B> > name ipfw:200 ttl_add >>> B> > msg ttl_add: setconfig { count=1 csum_flags=1 ops=[ \ >>> B> > { mode=2 value=3 length=1 offset=8 } ] } >>> B> > SEQ >>> B> > /sbin/ipfw add 150 netgraph 200 ip from any to >>> B> simplex.remote.net >>> B> >>> B> It seems ng_patch can only modify IP header. However, the position >>> B> of VLAN header is before IP header and after Ethernet header. How >>> B> can I modify it? >>> >>> ipfw allows you to intercept packets at IP layer. Tp modify VLAN >>> header, you need to capture them earlier. May be ng_ether(4) will >> help you. >>> > > > > From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 19:46:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AD14286F for ; Sat, 9 Nov 2013 19:46:21 +0000 (UTC) (envelope-from mom040267@gmail.com) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88C572F5B for ; Sat, 9 Nov 2013 19:46:21 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id p10so3526577pdj.11 for ; Sat, 09 Nov 2013 11:46:20 -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=VEbmfFHwrcYHvKMXI+OQQAtdQWmIvC+UBQhw+vzpIMc=; b=eDallW5znxXl+R1kepE3yWSP0Lve/e0KChN4DDIxxDeFRb3FUqEmkJDGfHBRcqRLRO WHe/xNXhEadh8B5Zaq6L9nd/90PgcIzq00F9SYLW4VL6myuKjCffPpdDt4qanDdMBh4G r7s8U7597Ww42IWTdmLncjAHGqNqVWX9883ohOGq3QnqWqbC7mUB4Y/H9e4RYgZtDYYo 82stbuTRl5vpjYpoJ0CIFwmOohqzwkO3CFELmBYVRx7y/KD+/P1fQ6n327/EIB+lglBE 9tsqipRmC7u2B9eLtFC6WYhKCg8k9hMiYYoTlIANE5EN8EmJNb2T7PAp3CfHptAR6XXi +lNA== MIME-Version: 1.0 X-Received: by 10.66.250.163 with SMTP id zd3mr22278650pac.109.1384026380783; Sat, 09 Nov 2013 11:46:20 -0800 (PST) Received: by 10.68.147.131 with HTTP; Sat, 9 Nov 2013 11:46:20 -0800 (PST) Date: Sat, 9 Nov 2013 11:46:20 -0800 Message-ID: Subject: Question about network stack advancements to be on the same level as Linux kernel 3.9+ From: Oleg Moskalenko To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 09 Nov 2013 19:46:21 -0000 Hi I am a developer of rfc5766-turn-server project. I am using FreeBSD as the main dev platform but I am porting it to everywhere else. I noticed that Linux kernel 3.9+ has some tremendous network stack improvements which can actually help us to achieve the performance goal - the efficient symmetric UDP multithreading server. I tested the kernel 3.11 and indeed it works perfectly: 1) It allows multiple UDP sockets to be bound to the same local address and port; 2) It distributes the incoming traffic "fairly" among the UDP sockets; 3) It preserves the source-destination communication path (persistent path) so that the same socket will always receive the data from the same source. This is an article about the change: https://lwn.net/Articles/542629/ Those features allow very efficient UDP servers to be created. That was not possible with older Linuxes and with current FreeBSD (I use version 9.1). Are there any plans in FreeBSD to adopt the same kind of changes ? With growing media-over-internet use cases, making UDP servers more efficient is getting a high priority task status. Thanks Oleg https://code.google.com/p/rfc5766-turn-server/ From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 20:14:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CEC684A1; Sat, 9 Nov 2013 20:14:12 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C66620E7; Sat, 9 Nov 2013 20:14:12 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id cm18so690137qab.2 for ; Sat, 09 Nov 2013 12:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=46G+SDq1T8KkR0ItUh4kzgZuP63wSZiS/X4XQ+MXBJU=; b=d0/gfcV8m5YqBwQXK/NuofGl8xkKAp3CbdZ2j+kdpnULIXgLUcLoDqmq41Q+WZJaui vQjxUH3cmRykDxb3x4Vm3JJaZlD7GjQJy01aCp8fAndal+MdJLmFsBZKjaSKTi9WdgQW yZQUjsrezIQaoJ2AKqhgfvjBhxxVSUY1Ze/PjmIOd9nMTxwH5DZ5fpAjFzT1N70VdEH0 7AS0EI2r3Wii0Hz0N3PIr9bo//+HtFIYBHxrdTxbgO3WhsoeB9/Z/SQ59w+mHSxBQ8eU wDQ5jAmsiAeqp8EGHc31v6MDwqenJgEbVG/RBuNYeQc9r5iyZePVBgYNzBRvpDuijndX K4SA== X-Received: by 10.49.108.135 with SMTP id hk7mr33460438qeb.33.1384028051619; Sat, 09 Nov 2013 12:14:11 -0800 (PST) Received: from [172.16.99.106] (stjhnf0148w-142162175108.dhcp-dynamic.fibreop.nl.bellaliant.net. [142.162.175.108]) by mx.google.com with ESMTPSA id l5sm37896178qac.12.2013.11.09.12.14.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 12:14:11 -0800 (PST) Message-ID: <527E9791.3070301@Gmail.com> Date: Sat, 09 Nov 2013 16:44:09 -0330 From: Bear User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com, 'Gleb Smirnoff' Subject: Re: ng_patch and 802.11Q References: <527C799D.8020208@Gmail.com> <20131108215210.GH7577@FreeBSD.org> <527DDFEA.9050001@Gmail.com> <527e4926.aa1d700a.02d7.fffff457@mx.google.com> In-Reply-To: <527e4926.aa1d700a.02d7.fffff457@mx.google.com> Content-Type: text/plain; charset=UTF-8; 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: Sat, 09 Nov 2013 20:14:13 -0000 Hi all, I did a test, it seems ng_ether will capture after removing VLAN tag? > sudo nghook -a em0: lower > 0000: xx xx xx xx xx xx yy yy yy yy yy yy 08 00 45 00 .9D...........E. em0 is the parent interface of all VLAN, and data sent from this interface is ALWAYS tagged. If I run tcpdump: > tcpdump -i em0 -e -n -vv > 142.162.175.108.12401 > xxx.xxx.xxx.xxx.14875: [udp sum ok] UDP, length 59 > 09:43:04.576023 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype 802.1Q (0x8100), length 58: vlan 35, p 0, ethertype IPv4, (tos 0x0, ttl 126, id 5184, offset 0, flags [DF], proto TCP (6), length 40) I can see the packet has VLAN tag. How can I obtain raw Ethernet frame with 802.1Q header by netgraph? If I cannot get this, it will become impossible to modify the VLAN priority field. :-( On 2013/11/9 11:09 AM, rozhuk.im@gmail.com wrote: > http://www.netlab.linkpc.net/download/software/FreeBSD/mcastbridge/mcastbr2. > sh > http://www.netlab.linkpc.net/forum/index.php?topic=796.0 > > >> It seems a good idea... Do you have some example working on ng_ether? >> The manpage of ng_ether seems no example... >> >> On 11/8/2013 6:22 PM, Gleb Smirnoff wrote: >>> On Fri, Nov 08, 2013 at 02:11:49AM -0330, Bear wrote: >>> B> Hi all, >>> B> I want to modify VLAN priority by ng_patch. After reading the >>> B> manpage of >>> B> ng_patch(http://www.freebsd.org/cgi/man.cgi?query=ng_patch) and >> the >>> B> example it given: >>> B> >>> B> > /usr/sbin/ngctl -f- <<-SEQ >>> B> > mkpeer ipfw: patch 200 in >>> B> > name ipfw:200 ttl_add >>> B> > msg ttl_add: setconfig { count=1 csum_flags=1 ops=[ \ >>> B> > { mode=2 value=3 length=1 offset=8 } ] } >>> B> > SEQ >>> B> > /sbin/ipfw add 150 netgraph 200 ip from any to >>> B> simplex.remote.net >>> B> >>> B> It seems ng_patch can only modify IP header. However, the position >>> B> of VLAN header is before IP header and after Ethernet header. How >>> B> can I modify it? >>> >>> ipfw allows you to intercept packets at IP layer. Tp modify VLAN >>> header, you need to capture them earlier. May be ng_ether(4) will >> help you. >>> > > > > From owner-freebsd-net@FreeBSD.ORG Sat Nov 9 20:57:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B9AE7198; Sat, 9 Nov 2013 20:57:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6931522E4; Sat, 9 Nov 2013 20:57:14 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id w4so2983330qcr.12 for ; Sat, 09 Nov 2013 12:57:13 -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:message-id:subject :from:to:cc:content-type; bh=eXlpf3jt5WVPI9sazq/AScyRyoDtef1Y9iBnlRvZXeU=; b=NEGLFsougQ4yXnFFa7keEabNznNwK6d4npfeaEHWjwTcu3lnXu0OOF35DrCks5d/6H wNPfIGEsl2VUqJ26jUXfi6fk+2OzMJrp+pWQ6kMeeFDmfAwJKCPDfSYPaSuFPhWrFkJS RzVUq+a+4zrHLozuW/VxjmybcEG/7cuv+SN1OMq3C0wCiXVcUs9XMpfqY3X2IGyRJOn/ mFtiKAZ+Nzb0iusKtyd/mAtKW9lXxyA7UTMRatCy5pbs7m10xug73oRH9xyvMrgVDc1/ w8OrqtAxk+faeOK86ek3bk5zDR1CMFRmo0H1FsmgqRqfZnd9ls/E68LnJuEJ3Y25F3HM PGCA== MIME-Version: 1.0 X-Received: by 10.49.99.98 with SMTP id ep2mr34061651qeb.9.1384030633622; Sat, 09 Nov 2013 12:57:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 12:57:13 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 12:57:13 -0800 X-Google-Sender-Auth: HqhKS0IS9N1LVtDuEq-p2K1uD34 Message-ID: Subject: Re: Question about network stack advancements to be on the same level as Linux kernel 3.9+ From: Adrian Chadd To: Oleg Moskalenko , Gleb Smirnoff 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: Sat, 09 Nov 2013 20:57:14 -0000 This was talked about at bsdcan. Gleb indicated interest in doing it for at least TCP. Gleb - any other comments? -adrian On 9 November 2013 11:46, Oleg Moskalenko wrote: > Hi > > I am a developer of rfc5766-turn-server project. I am using FreeBSD as the > main dev platform but I am porting it to everywhere else. I noticed that > Linux kernel 3.9+ has some tremendous network stack improvements which can > actually help us to achieve the performance goal - the efficient symmetric > UDP multithreading server. I tested the kernel 3.11 and indeed it works > perfectly: > > 1) It allows multiple UDP sockets to be bound to the same local address and > port; > 2) It distributes the incoming traffic "fairly" among the UDP sockets; > 3) It preserves the source-destination communication path (persistent path) > so that the same socket will always receive the data from the same source. > > This is an article about the change: > > https://lwn.net/Articles/542629/ > > Those features allow very efficient UDP servers to be created. That was not > possible with older Linuxes and with current FreeBSD (I use version 9.1). > > Are there any plans in FreeBSD to adopt the same kind of changes ? With > growing media-over-internet use cases, making UDP servers more efficient is > getting a high priority task status. > > Thanks > Oleg > https://code.google.com/p/rfc5766-turn-server/ > _______________________________________________ > 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 Sat Nov 9 21:58:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 71BB763B; Sat, 9 Nov 2013 21:58:26 +0000 (UTC) (envelope-from mom040267@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D0FC2528; Sat, 9 Nov 2013 21:58:26 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id hz1so257894pad.37 for ; Sat, 09 Nov 2013 13:58:25 -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=QFS9WTL4cvHuXLr9ovez0R07jTIaIq/fjIfwd44lvpQ=; b=cnIYYwGplBRjNG0gyjm8xBHTvrYEMmZlmXlb7ly+mXQb/QfqwN2Yma7F+ntQNGPRsV VylhA44vPdE9aY6wqzm+to0rleaHE0lqKXoJitOilFoWQuVHxY4PXAnKz6vgIM9TeqP5 +UYa5GJfo7WBF/oMVHsz8UMyPrTf4ysvldC5ZjQ17K8t6jxu2C2a/FWaLmffrdR6n6rF ie+WUX5MYNxpUCPkyR4KIehhVPZezDbIvStsKigpj3LPJ8P1BPY0T3Yvs/Um7zTLQFCk aGiJbRtJ1RIVDW0T+t5uUTp4azXJvB+9ETlU0ooEoJ7LAiCY2e46zAVQJ92vJKroR+Bx 7czw== MIME-Version: 1.0 X-Received: by 10.66.142.107 with SMTP id rv11mr23239594pab.17.1384034305844; Sat, 09 Nov 2013 13:58:25 -0800 (PST) Received: by 10.68.147.131 with HTTP; Sat, 9 Nov 2013 13:58:25 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 13:58:25 -0800 Message-ID: Subject: Re: Question about network stack advancements to be on the same level as Linux kernel 3.9+ From: Oleg Moskalenko To: Adrian Chadd 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: Sat, 09 Nov 2013 21:58:26 -0000 Those kind of advancements make much more sense for UDP than for TCP. Of course TCP would benefit from them, too, but they are really critical for UDP. TCP stack is already relatively advanced, and the improvements will help in only some really extreme high-load use cases - when the TCP listener is the bottleneck. On the other hand, UDP would benefit from the improvements even in usual ordinary use cases. If I may suggest the priority, it would make much more sense to start improving the stack with the UDP. Thanks Oleg On Sat, Nov 9, 2013 at 12:57 PM, Adrian Chadd wrote: > This was talked about at bsdcan. Gleb indicated interest in doing it > for at least TCP. > > Gleb - any other comments? > > > > -adrian > > > > On 9 November 2013 11:46, Oleg Moskalenko wrote: > > Hi > > > > I am a developer of rfc5766-turn-server project. I am using FreeBSD as > the > > main dev platform but I am porting it to everywhere else. I noticed that > > Linux kernel 3.9+ has some tremendous network stack improvements which > can > > actually help us to achieve the performance goal - the efficient > symmetric > > UDP multithreading server. I tested the kernel 3.11 and indeed it works > > perfectly: > > > > 1) It allows multiple UDP sockets to be bound to the same local address > and > > port; > > 2) It distributes the incoming traffic "fairly" among the UDP sockets; > > 3) It preserves the source-destination communication path (persistent > path) > > so that the same socket will always receive the data from the same > source. > > > > This is an article about the change: > > > > https://lwn.net/Articles/542629/ > > > > Those features allow very efficient UDP servers to be created. That was > not > > possible with older Linuxes and with current FreeBSD (I use version 9.1). > > > > Are there any plans in FreeBSD to adopt the same kind of changes ? With > > growing media-over-internet use cases, making UDP servers more efficient > is > > getting a high priority task status. > > > > Thanks > > Oleg > > https://code.google.com/p/rfc5766-turn-server/ > > _______________________________________________ > > 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 Sat Nov 9 22:24:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A9FCFDF4; Sat, 9 Nov 2013 22:24:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59B0C267A; Sat, 9 Nov 2013 22:24:53 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id e9so3010889qcy.39 for ; Sat, 09 Nov 2013 14:24:52 -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:message-id:subject :from:to:cc:content-type; bh=rcct2NxdTpGBHx+Oz2wAYsFMKgrp/gpXR6SPd4ZyTV0=; b=FKE0Z30rskCBgew2g1F30cCHAs3b+w+MIa9/mQaFaMqyxdSlEeRpFwZ9B0BdApk9BW qLBuBuz0zWPFYOSZxVIMRgd6CFgfhPUGnP9R4FRlWBOb9n3gJtgCogKaA0U/ynv/oAAs nPilHaKom+yKVCi7c3B+4weGP2K1YwJxUfHCd9ENihWndiOh/et9F4O6al+9ogXIvDXe UmZ5+utXc1b2Tq/Hy2GXZ9Ss3rPwiinuhwn4gqZfAuMFrkD2DFnBeS5wxKUZuRrQi1Sw IzrauUze2YlX3YAdaCNfj34lB2GIaz+KP/nk7MIy9nW3onb63xtdwsl00dInt17sA3u1 MqEw== MIME-Version: 1.0 X-Received: by 10.49.35.144 with SMTP id h16mr34132032qej.35.1384035892431; Sat, 09 Nov 2013 14:24:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 14:24:52 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 14:24:52 -0800 X-Google-Sender-Auth: PYrVX0piB78dr8VWU1NknM1hj30 Message-ID: Subject: Re: Question about network stack advancements to be on the same level as Linux kernel 3.9+ From: Adrian Chadd To: Oleg Moskalenko 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: Sat, 09 Nov 2013 22:24:53 -0000 On 9 November 2013 13:58, Oleg Moskalenko wrote: > Those kind of advancements make much more sense for UDP than for TCP. > > Of course TCP would benefit from them, too, but they are really critical for > UDP. > > TCP stack is already relatively advanced, and the improvements will help in > only some really extreme high-load use cases - when the TCP listener is the > bottleneck. On the other hand, UDP would benefit from the improvements even > in usual ordinary use cases. If I may suggest the priority, it would make > much more sense to start improving the stack with the UDP. I don't mind which one gets done, as long as one of them does. :-) I haven't yet written much UDP testing code. I'll be doing it soon. I may even take a stab at the UDP side of things. But I'm still knee deep in mbuf stuff at work (and wifi stuff at home) so I can't make any guarantees. -adrian