From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 13:52:04 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 B3BEF838 for ; Sun, 18 Aug 2013 13:52:04 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm8-vm3.bullet.mail.ne1.yahoo.com (nm8-vm3.bullet.mail.ne1.yahoo.com [98.138.91.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D6A62869 for ; Sun, 18 Aug 2013 13:52:03 +0000 (UTC) Received: from [98.138.90.52] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 13:48:58 -0000 Received: from [98.138.101.178] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 13:48:58 -0000 Received: from [127.0.0.1] by omp1089.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 13:48:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 905106.27473.bm@omp1089.mail.ne1.yahoo.com Received: (qmail 1785 invoked by uid 60001); 18 Aug 2013 13:48:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376833738; bh=1voKgghZZdQbUirDZCEq5x2KgW0qzT/FJ6zDgNM0CHo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=p4yMfHzR1HIFu2+baV4hgDrj8INbo/b04GGTFJd9vQnAJ7BeyChc7txW5+8tyQIkcV8ymhIm+LpRQqhbwfLwGG2kBOhQFPE//MPY6ETd8zOrkRrMRenwC2Hza44TtQYQ1DLy1eAkXjiUISySJvSjn+EWTv16LxDCiWrVHeKBQYs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ud5jvwCsbHbG3bfRWbZntvBlYGJFQbBGaZrgHcjvTHUg0MWeWoccoWtaA4NOaTJgVWj+9oaDyR+XbKX165yOaays8dKFb8rSdf6q2xBx5H/j3vq6NwG8nX1bWelnFNcMThghipRA1b9MDBKeMhnGCdBxtC54xIK4uATXlOtqors=; X-YMail-OSG: ip1.TD0VM1l6lFAWO_KPGKan41xKsziKW_cwsSXpaua7ZyA A4wXKTqlzrwat6n0y5O8aYnN7RxSwByj8MDkJRnp6mIkhVPhMwMHUZIxckUJ rxYC19Y1JJNAgWynmyR.icImFCIGxk9yhRpgiOKXKHCIW_z3n2Nz7Mu0qTY. 5Ry7L6dBtG3MRNsd0XQdL06WYcLH7WKKRkrHkbZOq5pTFCgwDknyEeqceyUY FAt5qODukQyhlt0DcAcV5q35SGQmr9QuU5MkxFJCh.Voro89Gi0P3tvEHE0T hvQZdZuas2Mz3W06NxdAZYj3TikNW60WCVoFx5f.znBpS1JRIes2daCInAzq veYlewRy_1w585MK4Pjk6svOmBC_0JtIgHEXlNdd2fwmTCezE5_9CSE.odxc cunySPHbGaIpz4qMZCI3GnwHPsM3jVpTrI5lMhA3mxoRucPngPLZqeKwN9jm 6Y9cDdQliHWnsxoVCs01J7PGqWfpWrh704HmOdDu5utfMUSWZTiLvVMwMRe7 CYX4JE_RC3.yPjCc26.2sHpDtFVWRQOsFnfyZKoJwke3ex0AG2rSOGby37JO _ISejDlp4PD.rd5nk6_j0iYcn_qRT0NJELZDSbTvE61qGhW.atf5x408ZM1o UqeZoEHtDj6jae8NTQ0MdWlQeSzQI34qXGDnI Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Sun, 18 Aug 2013 06:48:58 PDT X-Rocket-MIMEInfo: 002.001, CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4KVG86IEJhcm5leSBDb3Jkb2JhIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.IApDYzogTHVpZ2kgUml6em8gPHJpenpvQGlldC51bmlwaS5pdD47IExhd3JlbmNlIFN0ZXdhcnQgPGxzdGV3YXJ0QGZyZWVic2Qub3JnPjsgRnJlZUJTRCBOZXQgPG5ldEBmcmVlYnNkLm9yZz4gClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMTcsIDIwMTMgMTE6NTkgQU0KU3ViamVjdDogUmU6IGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> Message-ID: <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> Date: Sun, 18 Aug 2013 06:48:58 -0700 (PDT) From: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Lawrence Stewart , Luigi Rizzo , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 13:52:04 -0000 =0A=0A=0A=0A________________________________=0A From: Adrian Chadd =0ATo: Barney Cordoba =0ACc: Luigi R= izzo ; Lawrence Stewart ; FreeBSD= Net =0ASent: Saturday, August 17, 2013 11:59 AM=0ASubjec= t: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)= =0A =0A=0A=0A... we get perfectly good throughput without 400k ints a secon= d on the ixgbe driver.=0A=0AAs in, I can easily saturate 2 x 10GE on ixgbe = hardware with a handful of flows. That's not terribly difficult.=0A=0AHowev= er, there's a few interesting problems that need addressing:=0A=0A* There's= lock contention between the transmit side from userland and the TCP timers= , and the receive side with ACK processing. Under very high traffic load a = lot of lock contention stalls things. We (the royal "we", I'm mostly just d= oing tooling at the moment) working on that.=0A* There's lock contention on= the ARP, routing table and PCB lookups. The latter will go away when we've= finally implemented RSS for transmit and receive and then moved things ove= r to using PCB groups on CPUs which have NIC driver threads bound to them.= =0A* There's increasing cache thrashing from a larger workload, causing the= expensive lookups to be even more expensive.=0A* All the list walks suck. = We need to be batching things so we use CPU caches much more efficiently.= =0A=0AThe idea of using TSO on the transmit side and generic LRO on the rec= eive side is to make the per-packet overhead less. I think we can be much m= ore efficient in general in packet processing, but that's a big task. :-) S= o, using at least TSO is a big benefit if purely to avoid decomposing thing= s into smaller mbufs and contending on those locks in a very big way.=0A=0A= I'm working on PMC to make it easier to use to find these bottlenecks and m= ake the code and data more efficient. Then, likely, I'll end up hacking on = generic TSO/LRO, TX/RX RSS queue management and make the PCB group thing de= fault on for SMP machines. I may even take a knife to some of the packet pr= ocessing overhead.=0A=0A-------------------------------=0A=0AThe ints/sec r= eference was based on Luigi's implication that turning off moderation was s= ome sort of performance choice.=0A=0AAgain, you're talking "throughput" and= not efficiency. I could fill a tx queue with 10gb of traffic with =A0yeste= ryear's cpus. It's not an achievement. Being able to bridge=A0=0Areal traff= ic at=A010gb/s with 2 cores is.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 14:25:35 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 09F12B82 for ; Sun, 18 Aug 2013 14:25:35 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C30232998 for ; Sun, 18 Aug 2013 14:25:34 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id n12so4141363oag.25 for ; Sun, 18 Aug 2013 07:25:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=fsJgAmE/V2eOCFdtqy3O2oFz9ZyCN/G62G5aE4U000Y=; b=jAfNuFUtNwMvjUnGgWqz0NMS9HT8rUxfJLt0TIMU6g43X/jqboA+yPWVL5fRfJzS8q g5DBgFXRyo+7JvUWlfeF/2VnMxUBaLddNBAyl/ntM5XWL29jyvExPnjLkHLeBQIru7Vt iDvqTSb3izdwX7TjqIxy5uXzjQpHISviD7uOgp1ZR1c6NhvJSCezIjrD4heEc6x4p6pt Sdguqr25R4Cis121ThK3MjFmE6SbEeGy6MTcqKEPnIosdxMjhrVgh8rzihFJMwWD31is r/fsJSJn6VnkL2JNXrcspD8B7grSCW0tCFpTI2ZuASIxRRcj2Q78/XizOmAD61a/Rqpv QGhg== X-Gm-Message-State: ALoCoQnbv2TlhuVIyrZPyXKuygwE5k82jgz5342zzVZ9WOjpCT4NMNopL0oDBjX3dqH8TFnmfTXT X-Received: by 10.182.81.41 with SMTP id w9mr8046505obx.18.1376835928656; Sun, 18 Aug 2013 07:25:28 -0700 (PDT) Received: from [172.21.0.31] (67-198-60-238.static.grandenetworks.net. [67.198.60.238]) by mx.google.com with ESMTPSA id g1sm8179565oeq.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Aug 2013 07:25:27 -0700 (PDT) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> X-Mailer: iPhone Mail (10B350) From: Jim Thompson Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) Date: Sun, 18 Aug 2013 09:25:27 -0500 To: Barney Cordoba Cc: Lawrence Stewart , Adrian Chadd , Luigi Rizzo , 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: Sun, 18 Aug 2013 14:25:35 -0000 On Aug 18, 2013, at 8:48 AM, Barney Cordoba wrote= : > I could fill a tx queue with 10gb of traffic with yesteryear's cpus. It's= not an achievement. Being able to bridge=20 > real traffic at 10gb/s with 2 cores is Or forward at layer 3.=20 Or filter packets.=20 Or IPSEC.=20 Or...= From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 15:57:56 2013 Return-Path: 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 6B691EFA; Sun, 18 Aug 2013 15:57:56 +0000 (UTC) (envelope-from adrian.chadd@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 C92092DAF; Sun, 18 Aug 2013 15:57:55 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id y10so2738513wgg.28 for ; Sun, 18 Aug 2013 08:57:54 -0700 (PDT) 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=OmhoWmpdPbAD9y8NrjBSZVlXvT9z4y/sSD+UoYo77MQ=; b=AqUTXvSs3EJ1OMJVHQKIXfy9iQvCxaCGwLBYDZK4KElwRqKzCSMOEnB4+IMlDbg+Pu Vt2rSOmcNDbRFg75JWxrbPsD/JbGG/3yIOeTeR5GasMv1gFRhFalGLn7MfkFDOvSrD/I vd9FseQ9hpfSCgynXLXdGE+xEuRFhxXC8Rk4k7cmzJErq/ZwA7mP+vpI2O+bpIHVlWhE V7qrExw9+wWzUV2a9+27Qt5F7wJb8+KavUB/v8XLyKuoK2bKqpVz/j3c9i3fvxLTVzHB dtgW+HyYzpHNLBNgsoX2UUxmeZ/efILgAbF/QFnCT02gKRiI0PDnrLdYb+NJEHHxhPhv 2gww== MIME-Version: 1.0 X-Received: by 10.180.37.16 with SMTP id u16mr5011030wij.46.1376841474194; Sun, 18 Aug 2013 08:57:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sun, 18 Aug 2013 08:57:54 -0700 (PDT) In-Reply-To: <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> Date: Sun, 18 Aug 2013 08:57:54 -0700 X-Google-Sender-Auth: 5Qbl1OoFR_t9vQABXl2X_FeB9_k Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Adrian Chadd To: Jim Thompson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , FreeBSD Net , Luigi Rizzo , Lawrence Stewart 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, 18 Aug 2013 15:57:56 -0000 Right. Well, post some profiling data, let's figure this out sometime. Luigi can do bridging with 2 cores using netmap. So it's technically possible. There's just a lot of kernel gunk in the way of doing it ye olde way. -adrian On 18 August 2013 07:25, Jim Thompson wrote: > > On Aug 18, 2013, at 8:48 AM, Barney Cordoba > wrote: > > > I could fill a tx queue with 10gb of traffic with yesteryear's cpus. > It's not an achievement. Being able to bridge > > real traffic at 10gb/s with 2 cores is > > Or forward at layer 3. > > Or filter packets. > > Or IPSEC. > > Or... From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 18:22:40 2013 Return-Path: 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 BAEFBF3B for ; Sun, 18 Aug 2013 18:22:40 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 795AA24C0 for ; Sun, 18 Aug 2013 18:22:40 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id BCDB7153436 for ; Sun, 18 Aug 2013 20:22:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x81dt0ywePt; Sun, 18 Aug 2013 20:22:35 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:744f:b63f:82fd:33d6] (unknown [IPv6:2001:4cb8:3:1:744f:b63f:82fd:33d6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 931A8153435 for ; Sun, 18 Aug 2013 20:22:35 +0200 (CEST) Message-ID: <521110F9.1000906@digiware.nl> Date: Sun, 18 Aug 2013 20:22:49 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: net@freebsd.org Subject: Getting resets for em0 device 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, 18 Aug 2013 18:22:40 -0000 Hi, I'm sending a zpool from one server to in neighbor. Send size: zfs send -v -R tank@now \ | mbuffer -4 -m 100M -O box:6666 Receive side: mbuffer -4 -m 1000M -I 6666 \ | zfs receive -e -v tank This keep the 1Gbit link between them reasonably full. Most of the time mbuffer reports 110 MiB/sec.... But on the receiver side I'm getting aborts. Log file is below. Now the first question is: Does the switch reset? It's an HP 1800-24G Does FreeBSD reset? Because of the watchdog timeout? Because of too high packet rates? And if it is FreeBSD, what can be done to fix it. Version: FreeBSD box.digiware.nl 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #3 r254428: Fri Aug 16 23:50:28 CEST 2013 Motherboard: System Information Manufacturer: Supermicro Product Name: C2SBX Ehternet controller: em0@pci0:0:25:0: class=0x020000 card=0x10bd15d9 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM-2 Gigabit Network Connection' class = network subclass = ethernet dmesg, dmidecode, kernelconfig, full pciconf on: http://www.tegenbosch28.nl/FreeBSD/Systems/BOX Thanx for any suggestions, --WjW Aug 18 18:24:55 box kernel: em0: Watchdog timeout -- resetting Aug 18 18:24:55 box kernel: em0: Queue(0) tdh = 1688, hw tdt = 1743 Aug 18 18:24:55 box kernel: em0: TX(0) desc avail = 4031,Next TX to Clean = 1678 Aug 18 18:24:55 box kernel: em0: Link is Down Aug 18 18:24:55 box kernel: em0: link state changed to DOWN Aug 18 18:24:57 box kernel: em0: Link is up 1000 Mbps Full Duplex Aug 18 18:24:57 box kernel: em0: link state changed to UP Aug 18 18:32:15 box kernel: em0: Watchdog timeout -- resetting Aug 18 18:32:15 box kernel: em0: Queue(0) tdh = 2402, hw tdt = 2453 Aug 18 18:32:15 box kernel: em0: TX(0) desc avail = 4045,Next TX to Clean = 2402 Aug 18 18:32:15 box kernel: em0: Link is Down Aug 18 18:32:15 box kernel: em0: link state changed to DOWN Aug 18 18:32:17 box kernel: em0: Link is up 1000 Mbps Full Duplex Aug 18 18:32:17 box kernel: em0: link state changed to UP Aug 18 18:33:00 box kernel: Limiting closed port RST response from 856 to 200 packets/sec Aug 18 19:23:29 box kernel: em0: Watchdog timeout -- resetting Aug 18 19:23:29 box kernel: em0: Queue(0) tdh = 613, hw tdt = 616 Aug 18 19:23:29 box kernel: em0: TX(0) desc avail = 4093,Next TX to Clean = 613 Aug 18 19:23:29 box kernel: em0: Link is Down Aug 18 19:23:29 box kernel: em0: link state changed to DOWN Aug 18 19:23:31 box kernel: em0: Link is up 1000 Mbps Full Duplex Aug 18 19:23:31 box kernel: em0: link state changed to UP From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 18:42: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 E23C2440 for ; Sun, 18 Aug 2013 18:42:16 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm27-vm3.bullet.mail.ne1.yahoo.com (nm27-vm3.bullet.mail.ne1.yahoo.com [98.138.91.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FB5225BE for ; Sun, 18 Aug 2013 18:42:16 +0000 (UTC) Received: from [98.138.226.176] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 18:39:13 -0000 Received: from [98.138.89.163] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 18:39:13 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 18:39:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35399.84936.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 3379 invoked by uid 60001); 18 Aug 2013 18:39:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376851152; bh=rIqqUuQBuT+kZJpyuiy3klO6plhWRZ+orxuAqq5wLaI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=v8O9V/iDBQG9gmLBdj5hxMxU9coMyoh2aUrWtstuxD66Dge4+l7ZK75uRhSGiUs9rFUABRHZgziSeIQr1YDM7mpx/NfrL1sTQqGVLb8GsYWXGZUsWQtqRV+wfES8IR6hB3ketgdZz3JjSuWNFFkyxGN+POVEms+wHYQei5gW4gY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mznyS3KJ98fL7s8ltWeIxz9zR6VgymdS7gJvJ+5fbs83bsQ9Wt9l2WFh4Ed1xP8wjARUg0TGOzPUOVbu1QzunKocwN3J1ND3LrzCdDYrxHSriEnYXcmlRgQrIRhTlDgAXV5FPpzt75TziPBJsZ/me6nsOQ3kEWATO5hO26rRlPg=; X-YMail-OSG: w_jyoZwVM1nTkwtSIM.pUPxptPLz6dj7r8JplXkKCVFvRrY ep7aWnNLXsQzYBsL_lnLw85kqXniiI4zbWC9q7zmmv8FtfyKIE9ILd1XB86g Da97A1dwfLEel3_cTUStLAhnXJXx.5o4nZ2htU8b_.FwsBfC9zp5xO3PVEUi XzgZsY3EWTRaNij9l05Zya1X78lOrEo7S8SgzK2BgKMo6I.8PGHIqq5SusRs MsB6vlMKkphWXfU_BeTjPzQokSjpo5Tfa7y21UefiR71uDtkHgCtxrGEiCyB o.oLEQThU9jgiOqcRABKTJhU32loAw045GVqRlshJLuBDwJWlhhB6DQR8Wwn 3MtMXwY4OLqFQewvis.J.qVio21EKX9E.lZyWqCimUqKPDTxkmNAY11F00Wv mNn7.mfiK5xDxgrSunpstxp7NbjHTNXG1_5dFnAz3nBnjAnLELh3J7pdhTOU TqSLRggrXzvSnGd8WM4QgAPwsMHIEq8i7er4cnG2MUTgfTHymFV94NP4FyMu 5dnOkCjL3LFZxp_JFIjGUdcfG55Xkhs6kDQ91XjhBJYFMqHs5h.qZ5djqGzh gyPRUaD.IWUW9ffFlTlMt7b6_o2gfKVDM6f8JKxOGvUz5UWLjKThSMoGFifX DUlF3ilhdwaODPaEqzDxvF5pdr_LTFpL2Vi5. Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Sun, 18 Aug 2013 11:39:12 PDT X-Rocket-MIMEInfo: 002.001, R3JlYXQuIE5ldmVyIGhhcyB0aGUgYmVlbiBhIGJldHRlciBleHBsYW5hdGlvbiBmb3IgdGhlIHdvcmQgS2x1ZGdlIHRoYW4gbmV0bWFwLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4KVG86IEppbSBUaG9tcHNvbiA8amltQG5ldGdhdGUuY29tPiAKQ2M6IEJhcm5leSBDb3Jkb2JhIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.OyBGcmVlQlNEIE5ldCA8bmV0QGZyZWVic2Qub3JnPjsgTHVpZ2kgUml6em8gPHJpenpvQGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> Message-ID: <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> Date: Sun, 18 Aug 2013 11:39:12 -0700 (PDT) From: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 18:42:16 -0000 Great. Never has the been a better explanation for the word Kludge than net= map.=0A=0A=0A________________________________=0A From: Adrian Chadd =0ATo: Jim Thompson =0ACc: Barney Cordoba ; FreeBSD Net ; Luigi Rizzo ; Lawrence Stewart =0ASent: Sunday, Au= gust 18, 2013 11:57 AM=0ASubject: Re: it's the output, not ack coalescing (= Re: TSO and FreeBSD vs Linux)=0A =0A=0ARight. Well, post some profiling dat= a, let's figure this out sometime.=0A=0ALuigi can do bridging with 2 cores = using netmap. So it's technically=0Apossible. There's just a lot of kernel = gunk in the way of doing it ye olde=0Away.=0A=0A=0A=0A-adrian=0A=0A=0AOn 18= August 2013 07:25, Jim Thompson wrote:=0A=0A>=0A> On Aug= 18, 2013, at 8:48 AM, Barney Cordoba =0A> wrote:= =0A>=0A> > I could fill a tx queue with 10gb of traffic with=A0 yesteryear'= s cpus.=0A> It's not an achievement. Being able to bridge=0A> > real traffi= c at 10gb/s with 2 cores is=0A>=0A> Or forward at layer 3.=0A>=0A> Or filte= r packets.=0A>=0A> Or IPSEC.=0A>=0A> Or...=0A______________________________= _________________ From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 19:18: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 08972B9A for ; Sun, 18 Aug 2013 19:18:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D3962739 for ; Sun, 18 Aug 2013 19:18:36 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id e12so2959771wgh.9 for ; Sun, 18 Aug 2013 12:18:34 -0700 (PDT) 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=eDhvPd4JNvPgrVF2aFlH7WoRmqJCI5w7gkx6nODeUy4=; b=W2zVqVlu/sArglET4jknTc1sRBvGAX+K5EnD9GA3ns580rcMJq/KX744umETGSSsO/ kGduWmEfG2P2qO8gq1petSERqK/Z1VPQWHiTfWAAO0h6PIie+3TxUyzoEpZ3FRWPHxqe GLepEuKHz3hFH3QI4xhZ/Gk9Uey8AKQ3uhF9flvYnxo1q+mz0mE7IhnbdE6xyfFlVVdk pQwzSUELkYqXLNBfkj5CpfEDCM8jun+KC2v2qyT7NAbjA84fDQk2kMORWbHNeVnJufZa IDUg3YLKOiZ3j7pZSb5gsKbUALjmpR7BhLU2SzBEBMGealoPwBpK4DemoIlLRLyAFJVS N+3g== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr5470283wij.30.1376853514182; Sun, 18 Aug 2013 12:18:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sun, 18 Aug 2013 12:18:34 -0700 (PDT) In-Reply-To: <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> Date: Sun, 18 Aug 2013 12:18:34 -0700 X-Google-Sender-Auth: -ac0bum_uBW0cJfLWgHjDga6TdQ Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Adrian Chadd To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 18 Aug 2013 19:18:37 -0000 On 18 August 2013 11:39, Barney Cordoba wrote: > Great. Never has the been a better explanation for the word Kludge than > netmap. > Nah. Netmap is a reimplementation of some reasonably well known ways of pushing bits. Luigi just pushed it up to eleven and demonstrated what current hardware is capable of. I have never bought the "We need eleventy cores just to push 10ge of real traffic!" before. Luigi did note down where the per-packet inefficiencies were. What we have to do now is sit down and for each of those, figure out what the root causes are and how to mitigate it. There's some architectural things that need tidying up (read: CPU pinning, queue handling, some locking hilarity) but if they're solved, we'll end up having dual core boxes push line rate packets for routing. So the gauntlet has been thrown. Let's fix this shit up. -adrian From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 19:47:08 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 B76CFC0F; Sun, 18 Aug 2013 19:47:08 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 837172918; Sun, 18 Aug 2013 19:47:08 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id q10so645159pdj.35 for ; Sun, 18 Aug 2013 12:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=X4IGQJOgWYa8hXsAn/AmhQ/Mo6WOFTG8yqxyyVT4kAk=; b=QeaGvfhc+T9RXAyOfARnK+IUK1gesE8McGgPqGXrAar1gpopA9+CueQU/oGvjErKWI c8G30d3QarG8Wtoy+MyWO+yvwzqCPsD1WIEhrfoKqlyE+cTQZhrCigkaAILaxczbTmq7 xicFc6hlt0HAbtBG5tPuQ6aBBCBvvPtvG764nqp/dZ9EToV3AzyZRjhCvjPkKVOKeV9R tE5XaKE/z5wzCEInEaVXesENxGk3ExvhHrFZw2rhdUbkc2XYCKqQ/dWpLA0OkXWn6jTg wUjQ7R1KXY5akT/Az1mbvR0/3HaZAdepaG+PL53Kk7iK0rGsvrmHJEXqw2bWY7EI7zAt VcyQ== X-Received: by 10.68.200.34 with SMTP id jp2mr9397821pbc.53.1376855228251; Sun, 18 Aug 2013 12:47:08 -0700 (PDT) Received: from [10.204.15.4] (mobile-166-137-185-169.mycingular.net. [166.137.185.169]) by mx.google.com with ESMTPSA id xe9sm11078581pab.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Aug 2013 12:47:07 -0700 (PDT) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0E167A7F-092C-429F-9B5A-E05DB6126A96@gmail.com> X-Mailer: iPhone Mail (10B329) From: Vijay Singh Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) Date: Sun, 18 Aug 2013 12:46:59 -0700 To: Barney Cordoba Cc: "freebsd-net@freebsd.org" , Adrian Chadd 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, 18 Aug 2013 19:47:08 -0000 Barney, did you get picked on a lot as a kid? Wonder why you're so caustic a= nd negative all the time? Sent from my iPhone On Aug 18, 2013, at 11:39 AM, Barney Cordoba wrot= e: > Great. Never has the been a better explanation for the word Kludge than ne= tmap. >=20 >=20 > ________________________________ > From: Adrian Chadd > To: Jim Thompson =20 > Cc: Barney Cordoba ; FreeBSD Net ; Luigi Rizzo ; Lawrence Stewart =20 > Sent: Sunday, August 18, 2013 11:57 AM > Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs L= inux) >=20 >=20 > Right. Well, post some profiling data, let's figure this out sometime. >=20 > Luigi can do bridging with 2 cores using netmap. So it's technically > possible. There's just a lot of kernel gunk in the way of doing it ye olde= > way. >=20 >=20 >=20 > -adrian >=20 >=20 > On 18 August 2013 07:25, Jim Thompson wrote: >=20 >>=20 >> On Aug 18, 2013, at 8:48 AM, Barney Cordoba >> wrote: >>=20 >>> I could fill a tx queue with 10gb of traffic with yesteryear's cpus. >> It's not an achievement. Being able to bridge >>> real traffic at 10gb/s with 2 cores is >>=20 >> Or forward at layer 3. >>=20 >> Or filter packets. >>=20 >> Or IPSEC. >>=20 >> Or... > _______________________________________________ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 21:02:04 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 ADAF32EA for ; Sun, 18 Aug 2013 21:02:04 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm20-vm3.bullet.mail.ne1.yahoo.com (nm20-vm3.bullet.mail.ne1.yahoo.com [98.138.91.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 441492CC7 for ; Sun, 18 Aug 2013 21:02:04 +0000 (UTC) Received: from [98.138.101.130] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 21:01:57 -0000 Received: from [98.138.89.173] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 21:01:57 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 21:01:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 555768.76669.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 26153 invoked by uid 60001); 18 Aug 2013 21:01:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376859717; bh=4TTP0jtNmzj5ueyxcmHzEfQ8ABeQ77a8YX7EeLjyGjg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bdMEaPSQ1lsk7dVc7oJRgEtYuuO8+lLUqg+k65W8Dp2Ri6ru5aBklCQGIGqGn4VAkXhQZSXffII/aoDZIV9Tfp3LoFQUjqKjWPOI5kg1b9BHaJfIliHIs0+LMVbgtEXmsO05RATEiRosaQXu5H2mO2EBLmci/EzVoHVfDdiYNH0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Clb0qAKxMd0yG+TP31Q7o03DrOkRuZZUmY0GbxwZdFwTa0/VJ52DMDGm9jBjyhtbz/Hd0x36DU90yQEvJdv/tYHjVAfAVuc3pG3GgQklEdUjKLH2q27loELBu6TAutshRZnvr9EDYgC1b1ecdzzW9bQEjXK77dZZcbVXyk9Yq2c=; X-YMail-OSG: cYbY2h4VM1lA_uPHrjFy4_Pj_VeKBy_rs_LxR.ksIfYxShj dNZpkcSzbe.jDLVPloLtJ253NTFrgweuPEHFKSEs_XTdRiT3z.zqkN4nj..d y.J7hGIcX5bvnWa2RVN8Er0ck9SK6SQMfGak7uPVd6JOkVw.7iGIr_bcPgMv f.m4_7SLeBnD6aE2b3N2PPRxnwcThSM6uHqJCxeB6wuwvoDg_qEKvdQfdbjw sZG3.C806cu8SP7O9YscxqXM5vdGCWCk81hjR1vM.1Nu3nzPhd8mKjk2_0PR JNOhaRviPBUcAqxka2kBghZeex56gKcBiUDOmbLbAAKhtT4xK8IT1xbauEfh lrlVfn8uXvGHeJOUdEsCRxPiq_FbFJpxMa5.LeTMBAlT0ac9Uk6xyzZvnCBK gE7Y7beSH9iAByuI1Te1SF2b_gykxF1eZWRx_FnGnnPqQrP0PtMpgqDkU1Ps REIxVRTzsvyc_Ai5bzBCsByZVsPIsJime3jbHM23__Vw_VIgnKv4i8QijIQw dovXjkSI1w2jr_J8d2jPruZUG9iaL_Wv2Lji2RUlA5Mw0LvrMVeriv6ztn_I SZs_uYrg8yJ3RGxJPwPdcDNgcQSigm5eqF2UP4Ur.YrzEhCg- Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Sun, 18 Aug 2013 14:01:57 PDT X-Rocket-MIMEInfo: 002.001, VGhhdCdzIGZpbmUsIGl0J3MgYSB0ZXN0IHRvb2wsIG5vdCBhIHNvbHV0aW9uLiBJdCBqdXN0IHNlZW1zIHRoYXQgaXQgZ2V0cyBwdXNoZWQgYXMgaWYgaXQncyBzb21lIHNvcnQgb2YgcmVhbAp3b3JsZCBzb2x1dGlvbiwgd2hpY2ggaXQncyBub3QuIFRoZSBpZGVhIHRoYXQgYnJpbmdpbmcgcGFja2V0cyBpbnRvIHVzZXIgc3BhY2UgdG8gZm9yd2FyZCB0aGVtIHJhdGhlcgp0aGFuIGp1c3QgcmVwbGFjaW5nIHRoZSBicmlkZ2UgbW9kdWxlIHdpdGggc29tZXRoaW5nIG1vcmUgZWZmaWNpZW50IGlzIGp1c3Qgc2kBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> Message-ID: <1376859717.20232.YahooMailNeo@web121605.mail.ne1.yahoo.com> Date: Sun, 18 Aug 2013 14:01:57 -0700 (PDT) From: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 21:02:04 -0000 That's fine, it's a test tool, not a solution. It just seems that it gets pushed as if it's some sort of real world solution, which it's not. The idea that bringing packets into user space to forward them rather than just replacing the bridge module with something more efficient is just silliness. If "pushing packets" was a useful task, the solution would be easy. Unfortunately you need to do something useful with the packets in between. Reminds me of polling. The problem is that over time, people actually view it as a solution, when it was never more than a kludge in the first place. BC ________________________________ From: Adrian Chadd To: Barney Cordoba Cc: "freebsd-net@freebsd.org" Sent: Sunday, August 18, 2013 3:18 PM Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) On 18 August 2013 11:39, Barney Cordoba wrote: Great. Never has the been a better explanation for the word Kludge than netmap. Nah. Netmap is a reimplementation of some reasonably well known ways of pushing bits. Luigi just pushed it up to eleven and demonstrated what current hardware is capable of. I have never bought the "We need eleventy cores just to push 10ge of real traffic!" before. Luigi did note down where the per-packet inefficiencies were. What we have to do now is sit down and for each of those, figure out what the root causes are and how to mitigate it. There's some architectural things that need tidying up (read: CPU pinning, queue handling, some locking hilarity) but if they're solved, we'll end up having dual core boxes push line rate packets for routing. So the gauntlet has been thrown. Let's fix this shit up. -adrian From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 21:03:35 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 01141396 for ; Sun, 18 Aug 2013 21:03:34 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm24-vm4.bullet.mail.ne1.yahoo.com (nm24-vm4.bullet.mail.ne1.yahoo.com [98.138.91.184]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1AB92CDE for ; Sun, 18 Aug 2013 21:03:34 +0000 (UTC) Received: from [98.138.101.131] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 21:03:27 -0000 Received: from [98.138.226.165] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 21:03:27 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 18 Aug 2013 21:03:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 660521.76344.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 11356 invoked by uid 60001); 18 Aug 2013 21:03:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376859807; bh=fXT1nexAUr16FvMCAHv5UU7/bwMq76/1imph4sLPDEY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KWiIiPbOtMkwHCmx/zu054fRksf3vYKTCa6KbxYTaqNo6zPNcon5ErRUhM47B/Cfa4jGYV+1bP33D4Am3U403Aji8/HEooAYPvCa6TXDWrbcXt28iMJsA1et/dA39Zrtk7wNTr3+Yu3GQ+DYUQJYfiYjxSyu7VcgMuPThjZDDf8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ihehRRbY4slVcYI1OMAOHAnt41bYzXc3QgcGT7aVr/p67sP7wyZsSwSaWJ9O7qc3sCf0obCuhf4EG6j7gITwGbbk4hq/nS0GRTGfYXGvc3IlP3hMzEz0DhHM2HFUpS+GK8/2KJdmq6A/faZGmxz0BlrO74hdzHAJ1MytBdzp7lU=; X-YMail-OSG: e.kET7gVM1nIfviteMoDG7426ulQcJHH.eEUK1MQs52h7yj Mox45zqQjWFxAhEP2vQu5qKHJBa0OT9gY_ceDKpC4k1DExwB4qmQn4Qtqayf kEwNt27cD0sAf8zD_VAFgNir3Dxp8b24OJNkM9KMLOF9aTdAJwDnEXFFzxno __v3U80pjtXmaBoP_Rtu5CM3xunWWMaQu6pBekxgU6delHFS37OgEQnqchQR j_x4vAgS8klZkdEgRWwqKeWUpWLcPO82NYAFQz_O9MQxxlgM.CpiOMEC7zL1 M0jNpMaXt9N0Lh.NddVqNvM9tzxnXvD4WhTMcjLdfgqTE.F8ZCHg7.B7kgvh 3n.MH255NzFhB3z3a_jWTH7Ek_..knNiB8LSpMZLHAYU50WMQeF4Xh0gWKQf 0uEzV9x3238x5LzX6F2PKnAXRTIOExVU51s_HqGcP1H88zePmDiLWOFcb0.Y CKgM0i7D8nZMuXCZI9crQZbSOu637TpxD2Vp.aCXZ_niG.2Zgw.HCTh19cDC RqEbgjafJHLI4YZPYSOOaZvglsOHNJ989ORUi8tysx8RP86JpXfwFthFLToc s0VbnaMKZ33zwXujd7PLbZmALGHQW_9F9ladV2NBKz_nzp32gpDvIy9B8Oe. bAxV5XDh2fdzQQe4sTmFRYpVS4yiXeNdYbZjkikD3Gg-- Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Sun, 18 Aug 2013 14:03:27 PDT X-Rocket-MIMEInfo: 002.001, Q3JpdGljaXNtIGlzIHRoZSBiZWRyb2NrIG9mIGlubm92YXRpb24uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IFZpamF5IFNpbmdoIDx2aWpqdS5zaW5naEBnbWFpbC5jb20.ClRvOiBCYXJuZXkgQ29yZG9iYSA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPiAKQ2M6IEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPjsgImZyZWVic2QtbmV0QGZyZWVic2Qub3JnIiA8ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc.IApTZW50OiBTdW5kYXksIEF1Z3VzdCAxOCwgMjAxMyAzOjQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> <0E167A7F-092C-429F-9B5A-E05DB6126A96@gmail.com> Message-ID: <1376859807.11113.YahooMailNeo@web121606.mail.ne1.yahoo.com> Date: Sun, 18 Aug 2013 14:03:27 -0700 (PDT) From: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) To: Vijay Singh In-Reply-To: <0E167A7F-092C-429F-9B5A-E05DB6126A96@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 21:03:35 -0000 Criticism is the bedrock of innovation.=0A=0A=0A___________________________= _____=0A From: Vijay Singh =0ATo: Barney Cordoba =0ACc: Adrian Chadd ; "freebsd-= net@freebsd.org" =0ASent: Sunday, August 18, 2013= 3:46 PM=0ASubject: Re: it's the output, not ack coalescing (Re: TSO and Fr= eeBSD vs Linux)=0A =0A=0ABarney, did you get picked on a lot as a kid? Wond= er why you're so caustic and negative all the time?=0A=0ASent from my iPhon= e=0A=0AOn Aug 18, 2013, at 11:39 AM, Barney Cordoba wrote:=0A=0A> Great. Never has the been a better explanation for the wo= rd Kludge than netmap.=0A> =0A> =0A> ________________________________=0A> F= rom: Adrian Chadd =0A> To: Jim Thompson =0A> Cc: Barney Cordoba ; FreeBSD Net ; Luigi Rizzo ; Lawrence Stewart =0A> Sent: Sunday, August 18, 2013 11:57 AM=0A> Subject: Re: it's= the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)=0A> =0A> =0A= > Right. Well, post some profiling data, let's figure this out sometime.=0A= > =0A> Luigi can do bridging with 2 cores using netmap. So it's technically= =0A> possible. There's just a lot of kernel gunk in the way of doing it ye = olde=0A> way.=0A> =0A> =0A> =0A> -adrian=0A> =0A> =0A> On 18 August 2013 07= :25, Jim Thompson wrote:=0A> =0A>> =0A>> On Aug 18, 2013,= at 8:48 AM, Barney Cordoba =0A>> wrote:=0A>> =0A= >>> I could fill a tx queue with 10gb of traffic with=A0 yesteryear's cpus.= =0A>> It's not an achievement. Being able to bridge=0A>>> real traffic at 1= 0gb/s with 2 cores is=0A>> =0A>> Or forward at layer 3.=0A>> =0A>> Or filte= r packets.=0A>> =0A>> Or IPSEC.=0A>> =0A>> Or...=0A> ______________________= _________________________=0A> _____________________________________________= __=0A> freebsd-net@freebsd.org mailing list=0A> http://lists.freebsd.org/ma= ilman/listinfo/freebsd-net=0A> To unsubscribe, send any mail to "freebsd-ne= t-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 21:16: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 E73285D2; Sun, 18 Aug 2013 21:16:38 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22E0B2D5C; Sun, 18 Aug 2013 21:16:37 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ev20so2747031lab.25 for ; Sun, 18 Aug 2013 14:16:36 -0700 (PDT) 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=7iXdMvxF4jSTV2c+RJu5MXCx1wl/+tIjeunknIs0zos=; b=U34pMmN1mgnjp0tDqFhogHsygZe8FBriVNeBTA+1RUFt5S5eLzhxWRZprjucNo92OZ FAKepcu0fe0ArAc/i2VdGBaP6+caEUpSZ3pKINLhyHWdYqYqQyjktvr0IAFMRjO0f6ZD 5iwnsFO8B/S4vAzll6xmROOVTc0jclgRX8Je+/HMotyVjKVWeUswt5bPJ5KYAJJCKqrW r+c3hUSIXkNQgBqaexrzHqxlwE3J6SKbA29Oo9P83OJojD84SwAQf0mVjgScrIsc6z8r VmuAjoFtPWADrLxeSNhhRBVRULTiQTkCwAWNTAYlr7HYkixMEEkAs2H+ghNuEZiVJwTR 62dA== MIME-Version: 1.0 X-Received: by 10.112.33.205 with SMTP id t13mr12763835lbi.22.1376860595872; Sun, 18 Aug 2013 14:16:35 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Sun, 18 Aug 2013 14:16:35 -0700 (PDT) In-Reply-To: <1376859717.20232.YahooMailNeo@web121605.mail.ne1.yahoo.com> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376859717.20232.YahooMailNeo@web121605.mail.ne1.yahoo.com> Date: Sun, 18 Aug 2013 23:16:35 +0200 X-Google-Sender-Auth: RD-M6p02drs4aT4QN-F_27u-WdE Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Luigi Rizzo To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Adrian Chadd 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, 18 Aug 2013 21:16:39 -0000 On Sun, Aug 18, 2013 at 11:01 PM, Barney Cordoba wrote: > That's fine, it's a test tool, not a solution. It just seems that it gets > pushed as if it's some sort of real > world solution, which it's not. The idea that bringing packets into user > space to forward them rather > than just replacing the bridge module with something more efficient is > just silliness. > you might want to have a look at the VALE switch http://info.iet.unipi.it/~luigi/vale/ the upcoming version can attach physical interfaces to the switch and keep all the processing within the kernel. > If "pushing packets" was a useful task, the solution would be easy. > Unfortunately you need to do > something useful with the packets in between. > > there are different definitions of what is "useful": sources, sinks, forwarding, dropping (anti DoS), logging, ids, are all useful for different people. The mistake, i think, is to expect that there is one magic solution to handle all the useful cases. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 21:54:37 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 6E7A8B80 for ; Sun, 18 Aug 2013 21:54:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E478C2EF7 for ; Sun, 18 Aug 2013 21:54:36 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi8so2395300wib.9 for ; Sun, 18 Aug 2013 14:54:35 -0700 (PDT) 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=5IJ1LckSABAWarGj34CjBWncY6lBKDVY3WehV401YSY=; b=Xvq/akqVFrJIzbutis3hEuNTN2TPxlw4Dp4r94p0H163NCn2rjulyrYZCztDvTxdn5 KxFLI+Vocle/EdlgHrarPEkZZ/c/kHslYA+Ds8d8KKBUzpiV7CGX8FRaIfck2xfY0T0U TSqq2wZyeYq8lexcGGMqzZNSVJ6TvN0CdROxl/8ajaNM0gkGY/6BENcCX+a3nmXBsrAD tY5YxvJLgx8qwaWaM8k92vexAHKUnxDTfmebqONDBOGnJr5Hhgc7KcfhlYiupXccnBqz gO9mLSTC1Z5y4LNCrULSQLZqg88Dq6nhCprBFf3JWqknhNp+o0H+uOn4V7WddjnokwXT 1a1w== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr5797725wij.30.1376862875180; Sun, 18 Aug 2013 14:54:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sun, 18 Aug 2013 14:54:35 -0700 (PDT) In-Reply-To: References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376859717.20232.YahooMailNeo@web121605.mail.ne1.yahoo.com> Date: Sun, 18 Aug 2013 14:54:35 -0700 X-Google-Sender-Auth: 4CoomC8rr7PtLsvRhP93XRR7MD0 Message-ID: Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Cordoba , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 21:54:37 -0000 Hi, I think the "UNIX architecture" is a bit broken for anything other than the occasional (for various traffic levels defining "occasional!") traffic connection. It's serving us well purely through the sheer force of will of modern CPU power but I think we can do a lot better. _I_ think the correct model is a netmap model - batched packet handling, lightweight drivers pushing and pulling batches of things, with some lightweight plugins to service that inside the kernel and/or push into the netmap ring buffer in userland. Interfacing into the ethernet and socket layer should be something that bolts on the side, kind of netgraph style. It would likely look a lot more like a switching backplane with socket IO being one of many processing possibilities. If socket IO stays packet at a time than great; but that's messing up the ability to do a lot of other interesting things. That's why I'm (more) interested in what you've done architecture wise than just saying "dump it in userland and be done with it." I think the VALE kernel stuff is very interesting from an architectural perspective. The questions (to me!) are: * how do we implement this in the current framework? (That's not too scary though; we'd just have the existing ethernet input/output path be one of many processing modules, and VALE would be another; netmap-userland would be another; etc, etc); * how do we make it a compile time fallback to the traditional model, for platforms that continue to be memory and/or cache constrained? (read: everything that's embedded) * ... and not simply have lots of #Ifdef NETMAP everywhere, but make the fallback be something sane and fall out of the API design? I'll try to rope some more ideas into that design at the cambridge and euro BSD developer summits. I'll try to post some kind of work roadmap to the list(s) for comments and potential code hacking. Anyway. I'll continue waving hands and hacking on code until I have something that works. Luigi - when are you next at a BSD developer summit / conference? Will you be at Malta? -adrian From owner-freebsd-net@FreeBSD.ORG Sun Aug 18 22:56:37 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 5F923D06 for ; Sun, 18 Aug 2013 22:56:37 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2051821C6 for ; Sun, 18 Aug 2013 22:56:36 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i4so4765143oah.9 for ; Sun, 18 Aug 2013 15:56:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=sE4glVZZBRMRNYmYt+uAyGEwVbRKNK+l89FDilMfMzc=; b=OQawc+hgk4rG4KTTOqcyMcT1uo1xwGhZ8uVEAgsuuaHW4QEC3CI1LDH5feI8q5K0sS 2ku9ZGhPi5QtR+/7b5WkMpbJHSonM03emY1oDnHOLGb42eLzV5emxlNOPqecqIG61xdm spptdvWZxTcVf30iPCh4q8SV0Ig5+Nk216e863sc9c+nfTzsj0wwg2WHCN5naNKeHDSi Mb2wJOid3NPFS8Kranp5vA6rstZN5xu3zVWx+mWB2yK0wXXLOwDFI5YNBFXh5QcVaP+9 QxeqxlzPc1QIDiPBu835PyUipui08wtByP8CdKGJomeWtIIK0K7fZ8lM/A4mj1PXCYSW 0zHQ== X-Gm-Message-State: ALoCoQkVmq0mHaq5R055GcrV0+KQZeGuyFmErtxFk8zHAfHGEWRUj/+X5mfAnr2U4Eat7rXk6usR X-Received: by 10.60.33.74 with SMTP id p10mr9804508oei.18.1376866589879; Sun, 18 Aug 2013 15:56:29 -0700 (PDT) Received: from [29.133.39.131] (66-87-121-131.pools.spcsdns.net. [66.87.121.131]) by mx.google.com with ESMTPSA id fk3sm11638214obb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Aug 2013 15:56:29 -0700 (PDT) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376859717.20232.YahooMailNeo@web121605.mail.ne1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B350) From: Jim Thompson Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) Date: Sun, 18 Aug 2013 17:55:51 -0500 To: Luigi Rizzo Cc: Barney Cordoba , Adrian Chadd , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 22:56:37 -0000 On Aug 18, 2013, at 4:16 PM, Luigi Rizzo wrote: > The mistake, i think, > is to expect that there is one magic solution to handle all the useful > cases. AKA: not all the world is Yahoo. From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 00:59:59 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 A6273C2A; Mon, 19 Aug 2013 00:59:59 +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 77AB02665; Mon, 19 Aug 2013 00:59:59 +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 r7J0xx4O067731; Mon, 19 Aug 2013 00:59:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7J0xxNu067730; Mon, 19 Aug 2013 00:59:59 GMT (envelope-from linimon) Date: Mon, 19 Aug 2013 00:59:59 GMT Message-Id: <201308190059.r7J0xxNu067730@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181388: [route] Routes not updated on mtu change 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, 19 Aug 2013 00:59:59 -0000 Old Synopsis: Routes not updated on mtu change New Synopsis: [route] Routes not updated on mtu change Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 19 00:59:13 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181388 From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 04:25:54 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 50D4FDE5; Mon, 19 Aug 2013 04:25:54 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B63602052; Mon, 19 Aug 2013 04:25:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r7J4NhI7018656; Mon, 19 Aug 2013 14:23:43 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 19 Aug 2013 14:23:43 +1000 (EST) From: Ian Smith To: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) In-Reply-To: <1376859807.11113.YahooMailNeo@web121606.mail.ne1.yahoo.com> Message-ID: <20130819140400.E85171@sola.nimnet.asn.au> References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> <0E167A7F-092C-429F-9B5A-E05DB6126A96@gmail.com> <1376859807.11113.YahooMailNeo@web121606.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Vijay Singh 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, 19 Aug 2013 04:25:54 -0000 On Sun, 18 Aug 2013 14:03:27 -0700, Barney Cordoba wrote: > Criticism is the bedrock of innovation. Constructive criticism, with clear design even without code, can be. Relentless negativity achieves nothing, and fails to compile. Ian From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 07:00:02 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 30453723 for ; Mon, 19 Aug 2013 07:00:02 +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 1D9BA268C for ; Mon, 19 Aug 2013 07:00:02 +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 r7J701jU045666 for ; Mon, 19 Aug 2013 07:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7J701I9045665; Mon, 19 Aug 2013 07:00:01 GMT (envelope-from gnats) Date: Mon, 19 Aug 2013 07:00:01 GMT Message-Id: <201308190700.r7J701I9045665@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Julian Elischer Subject: Re: kern/181388: [route] Routes not updated on mtu change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Julian Elischer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 07:00:02 -0000 The following reply was made to PR kern/181388; it has been noted by GNATS. From: Julian Elischer To: bug-followup@FreeBSD.org, joe@rewt.org.uk Cc: Subject: Re: kern/181388: [route] Routes not updated on mtu change Date: Mon, 19 Aug 2013 14:57:22 +0800 The problem is that this is not as simple as it seems. The route MTU MIGHT have been set by something other than the interface MTU in the first place. The interface MTU is a default for the route MTU but is not the only source. This actuall bit me a couple of days ago when I was wonderign why my interface was not sending 9K packets.. turns out you need to do 'ifconfig_xn0="DHCP mtu 9000"' in order to have your dncp configured interface routes have the right size. so, I'm agreeing with you , but noticing that there are complications. From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 08:32:22 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 EE6EE6FF for ; Mon, 19 Aug 2013 08:32:22 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id B63E82AE6 for ; Mon, 19 Aug 2013 08:32:21 +0000 (UTC) Received: from [192.168.1.54] (staff-ns50-3.as25178.net [212.9.98.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3cJT041rDyzN7 for ; Mon, 19 Aug 2013 09:32:20 +0100 (BST) Message-ID: <5211D812.5070308@rewt.org.uk> Date: Mon, 19 Aug 2013 09:32:18 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: kern/181388: [route] Routes not updated on mtu change References: <201308190700.r7J701I9045665@freefall.freebsd.org> In-Reply-To: <201308190700.r7J701I9045665@freefall.freebsd.org> 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, 19 Aug 2013 08:32:23 -0000 Hm, I hadn't considered that... how do other OSes and vendors handle this? (eg Linux?) Just changing the connected route would probably suffice, or maybe if any routes not added with default interface mtu could/are be flagged, then those could be changed or not depending on what added them? Perhaps need someone with more experience of the network stack to wade in here... Cheers, Joe On 19/08/2013 08:00, Julian Elischer wrote: > The following reply was made to PR kern/181388; it has been noted by GNATS. > > From: Julian Elischer > To: bug-followup@FreeBSD.org, joe@rewt.org.uk > Cc: > Subject: Re: kern/181388: [route] Routes not updated on mtu change > Date: Mon, 19 Aug 2013 14:57:22 +0800 > > The problem is that this is not as simple as it seems. > The route MTU MIGHT have been set by something other than the > interface MTU > in the first place. > The interface MTU is a default for the route MTU but is not the only > source. > This actuall bit me a couple of days ago when I was wonderign why my > interface was not sending 9K packets.. turns out you need to do > 'ifconfig_xn0="DHCP mtu 9000"' in order to have your dncp > configured interface routes have the right size. > > so, I'm agreeing with you , but noticing that there are complications. > > > _______________________________________________ > 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 Mon Aug 19 11:06:47 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 C375DD9F for ; Mon, 19 Aug 2013 11:06:47 +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 AFCCF251C for ; Mon, 19 Aug 2013 11:06:47 +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 r7JB6l8N006092 for ; Mon, 19 Aug 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7JB6l68006090 for freebsd-net@FreeBSD.org; Mon, 19 Aug 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Aug 2013 11:06:47 GMT Message-Id: <201308191106.r7JB6l68006090@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, 19 Aug 2013 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181388 net [route] Routes not updated on mtu change 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/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/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf 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 bin/175974 net ppp(8): logic issue 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 o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/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/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/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 461 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 11:13:06 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 0216491A for ; Mon, 19 Aug 2013 11:13:06 +0000 (UTC) (envelope-from return-t-user2user1x130818-freebsd-net=freebsd.org@mailer.photobucket.com) Received: from bounce122.photobucket.com (bounce122.photobucket.com [66.11.51.122]) by mx1.freebsd.org (Postfix) with SMTP id BF0AC26FC for ; Mon, 19 Aug 2013 11:13:05 +0000 (UTC) Received: (qmail 7337 invoked from network); 19 Aug 2013 11:12:09 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=photobucket.com; s=default; h=Comment:DomainKey-Signature: Received:Received:To:Subject:MIME-Version:Content-Type:From: Message-Id:Date; bh=KnPCmHA2hQfzI3eb65JGRKm4TWY=; b=HMl/juIT4ujx Olhubp3pQcxOXnjxHudSOUTw/HLRO0hDx0agsnMg/yFle7jjSXHpvYyeVGyLhWqO xrMOnSyigtrmMkuToK0dyEVWekd08WWQx2IKgk1HuU8dtF4teQ2sHaCM52YNkeCF qGmam/2iAvSf+h2lIChBYkwZTQDxY3k= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=photobucket.com; b=RsLspBCAJflx7A/BRaB6igRqhgXETV6yYF2tfDg/9K8iLHIVigX1oEg1eGLY//TRYWNTh10KpoiKQ/glhoVL65ee9B67zFSjH9uiLRSujgaMCPOUAdzBcEv92z//EJ36uIpgUdGMshVh6bNfuGOFRZL5sxUVDdHA8nLxi7Ch2us= ; X-Mailer-Info: BQR4ZQZknmSypzMbZzIlMztfqTIvYaSzo3WlMKANM3WuYKSzo3WlMKZfMj Received: from unknown (HELO den2tools01.photobucket.com) (10.2.24.106) by mailer.photobucket.com with SMTP; 19 Aug 2013 11:12:09 -0000 Received: by den2tools01.photobucket.com (Postfix, from userid 99) id 315BF73552; Mon, 19 Aug 2013 05:12:09 -0600 (MDT) To: freebsd-net@freebsd.org Subject: ib.rowa01@yahoo.com shared a photo with you on Photobucket MIME-Version: 1.0 From: updates@photobucket.com X-PBContext: 2 Message-Id: <20130819111209.315BF73552@den2tools01.photobucket.com> Date: Mon, 19 Aug 2013 05:12:09 -0600 (MDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 11:13:06 -0000 Hello! Good news! ib.rowa01@yahoo.com wants to share a Photobucket photo with you: "Good day,=20 Nice to meet you, my name is Rowa, I found your contact and I picked intere= st to contact you via this medium. I've something very important which I wo= uld love to share with you therefore, I would appreciate if you respond bac= k to me through this E-mail ib.rowa01@yahoo.com, & I'll write you back = with my full details. I am waiting anxiously for your response.=20 Truly yours,=20 Rowa." http://s273.photobucket.com/user/yarimartinez/media/lolz023.jpg.html?evt=3D= email_share ____________________________________________ Photobucket.com - http://.photobucket.com= From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 11:20:38 2013 Return-Path: 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 C1C02B65; Mon, 19 Aug 2013 11:20:38 +0000 (UTC) (envelope-from melifaro@yandex-team.ru) Received: from forward-corp1e.mail.yandex.net (forward-corp1e.mail.yandex.net [IPv6:2a02:6b8:0:202::10]) by mx1.freebsd.org (Postfix) with ESMTP id 4CDD7274C; Mon, 19 Aug 2013 11:20:38 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id AB663640CD1; Mon, 19 Aug 2013 15:20:35 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 907562C00D9; Mon, 19 Aug 2013 15:20:35 +0400 (MSK) Received: from dhcp170-36-red.yandex.net (dhcp170-36-red.yandex.net [95.108.170.36]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id GghtcFiAId-KZxS3VtY; Mon, 19 Aug 2013 15:20:35 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1376911235; bh=+SIyAFm+OOkyUqRQhL7dQ7HAHvlTgwstk1arhxAfChY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=a16oI5f5lLpv1t91MgOuXYoIuFGFOZMq3+lOiz/7cZ7IEK7t25yBM+Z8MKr42+QGH XkvImWDPUyl4KXoKcL6tUmgyoTwzE7YioJlCl/Wr0WSJlVzb6I4wEuZMfJXZWy4mFU z/pgVUj9qkOwvWfO09Tu9okZAXphxnBfmHL4jN3c= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <5211FF0C.6020104@yandex-team.ru> Date: Mon, 19 Aug 2013 15:18:36 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <587579055.20130814154713@serebryakov.spb.ru> <20130814120551.GA64260@onelab2.iet.unipi.it> <520B74DD.1060102@ipfw.ru> <20130814124024.GA64548@onelab2.iet.unipi.it> <520B7F91.2080209@ipfw.ru> <20130814140013.GA65049@onelab2.iet.unipi.it> In-Reply-To: <20130814140013.GA65049@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , Lev Serebryakov , 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: Mon, 19 Aug 2013 11:20:38 -0000 On 14.08.2013 18:00, Luigi Rizzo wrote: > On Wed, Aug 14, 2013 at 05:01:05PM +0400, Alexander V. Chernikov wrote: >> On 14.08.2013 16:40, Luigi Rizzo wrote: > ... >>>> You can save rte&arp, however doing this >>>> gives you perfect chance to crash your kernel if egress interface is >>>> destroyed (like vlan or ng or tun). >>> I hope I learned not to follow a stale ifp pointer :) >> Well, currently we have no locks (or other means) to ensure all other >> cores has "current" pointer to ifp or its fields (or am I wrong?) > This i don't know -- but in case, we should fix the race anyways > (another timescale, but still dangerous). > >>> anyways ARP is really just the mac address so there is no >>> dandling pointer issue. >>> >>> For the ifp associated to the route, >>> i do not see a huge problem in marking the route/ifp as >>> zombie and destroy it when the last reference goes away. >> Yes, but references requires some synchronization primitives. One > Again, we should protect against ifp destruction anyways. Surely > we should try and make the protection mechanism cheap (in my proposal, > going through the refcount once per millisecond instead of every Sorry, I still can't get this. Are we talking about egress interface refcounts? Where are refcounts incremented/decremented? Btw, currently interface destroying is usually synchronous so 1ms-waiting can effectively reduce interface creation/destroying rate in BRAS scenarios (mpd with ng*, Juniper case..) > single packet; there might be better ways, and i am all ears on > that); surely, we cannot dismiss something because "we run without > seatbelts now so anything else is more expensive". > > We had a related discussion regarding races in interfaces between > the datapath (if_transmit() and *_rxeof() ) and the control path > (ioctls, watchdog etc.). > > The reason I am raising this issue is because i want to fix the > races that emerged when we moved to SMP, not because I want to "make > hacks" and cut corners in unsafe ways. That's great! I want this fixed, too :) > > cheers > luigi > >> possible solution is using pcpu counters, but it does not play well on >> !amd64. >>> Not that the current way is any better -- you need to lock/unlock >>> the rte while you do the lookup, and hold a refcount to the ifp >>> until the packet is queued. So how does my suggestion make >>> things worse ? >>> >>> cheers >>> luigi >>> >>> >>>>> Considering that each lookup takes between 100..300ns if you are >>>>> lucky (not many misses, relatively empty table etc.), one could >>>>> reasonably do the lookup at most once per millisecond or so (just >>>>> reading 'ticks', no need for a nanotime() if you have a slow clock), >>>>> or whenever we get an error related to the socket, either in the >>>>> forward path (e.g. ifp points to an interface that is down) or in >>>>> the reverse path (e.g. a dupack because we sent a packet to the >>>>> wrong place). >>>> This sounds like "Hey, the kernel lookup is slow (which is true), let's >>>> make a hack and don't bother lookups". >>>> This approach gives us mtx-locked rte refcounts which are used (misused) >>>> in many places making things worse and decreasing the ability to fix the >>>> things up.. >>>>> cheers >>>>> luigi >>>>> _______________________________________________ >>>>> 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 Mon Aug 19 11:30:50 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 A0602FC1; Mon, 19 Aug 2013 11:30:50 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 387EE27FF; Mon, 19 Aug 2013 11:30:49 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VBJvI-000B5J-4I; Mon, 19 Aug 2013 11:30:44 +0400 Message-ID: <5212016E.8040609@ipfw.ru> Date: Mon, 19 Aug 2013 15:28:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: Marko Zec Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) References: <520A6D07.5080106@freebsd.org> <520B74DD.1060102@ipfw.ru> <20130814124024.GA64548@onelab2.iet.unipi.it> <201308141740.28779.zec@fer.hr> In-Reply-To: <201308141740.28779.zec@fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Lev Serebryakov , Luigi Rizzo , FreeBSD Net , Lawrence Stewart 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, 19 Aug 2013 11:30:50 -0000 On 14.08.2013 19:40, Marko Zec wrote: > On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote: >> On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote: >>> On 14.08.2013 16:05, Luigi Rizzo wrote: >>>> On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote: >>>>> Hello, Luigi. >>>>> You wrote 14 ?????????????? 2013 ??., 14:21:09: >>>>> >>>>> LR> Then the problem remains that we should keep a copy of route and >>>>> LR> arp information in the socket instead of redoing the lookups on >>>>> LR> every single transmission, as they consume some 25% of the time >>>>> of LR> a sendto(), and probably even more when it comes to large tcp >>>>> LR> segments, sendfile() and the like. >>>>> And we should invalidate this info on ARP/route changes, or >>>>> connection will be lost in such cases, am I right?.. So, on each >>>>> such event code should look into all sockets and check, if >>>>> routing/ARP information is still valid for them. Or we should store >>>>> lists of sockets in routing and ARP tables... I don't know, what is >>>>> worse. >>>> I think we should start by acknowledging that routing and ARP >>>> information is inherently stale, and changes unfrequently. >>>> So it is not a disaster if we have incorrect information for some >>>> short amount of time (milliseconds) because in the end the remote >>>> party that decides to change it and inform us may take much longer >>>> than that to distribute the update. >>> You can save rte&arp, however doing this >>> gives you perfect chance to crash your kernel if egress interface is >>> destroyed (like vlan or ng or tun). >> I hope I learned not to follow a stale ifp pointer :) >> anyways ARP is really just the mac address so there is no >> dandling pointer issue. >> >> For the ifp associated to the route, >> i do not see a huge problem in marking the route/ifp as >> zombie and destroy it when the last reference goes away. > FWIW, apparently we already have that infrastrucure in place - if_rele() > calls if_free_internal() only when the last reference to the ifnet is > dropped, so with little care this should be usable for caching ifp pointers > w/o fears for kernel crashes mentioned above. There are several different approaches for interface pointers like delayed GC with refcount. However, the problem is a bit deeper: think of virtual interface like vlan saving some state to underlying physical interface. While we have valid if_vlan structure, drivers like ixgbe (or lagg) already destroys given state which can lead to possible crashes. I'm not sure if this can happen with current code (I've observed some strange crashes on 8.x) but this is definitely the thing we should keep in mind. > > Marko > >> Not that the current way is any better -- you need to lock/unlock >> the rte while you do the lookup, and hold a refcount to the ifp >> until the packet is queued. So how does my suggestion make >> things worse ? >> >> cheers >> luigi >> >>>> Considering that each lookup takes between 100..300ns if you are >>>> lucky (not many misses, relatively empty table etc.), one could >>>> reasonably do the lookup at most once per millisecond or so (just >>>> reading 'ticks', no need for a nanotime() if you have a slow clock), >>>> or whenever we get an error related to the socket, either in the >>>> forward path (e.g. ifp points to an interface that is down) or in >>>> the reverse path (e.g. a dupack because we sent a packet to the >>>> wrong place). >>> This sounds like "Hey, the kernel lookup is slow (which is true), let's >>> make a hack and don't bother lookups". >>> This approach gives us mtx-locked rte refcounts which are used >>> (misused) in many places making things worse and decreasing the ability >>> to fix the things up.. >>> >>>> cheers >>>> luigi >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to >>>> "freebsd-net-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 11:44:36 2013 Return-Path: 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 114294AA; Mon, 19 Aug 2013 11:44:36 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C5F3228A1; Mon, 19 Aug 2013 11:44:35 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VBK8d-000BBv-7A; Mon, 19 Aug 2013 11:44:31 +0400 Message-ID: <521204A9.7080607@ipfw.ru> Date: Mon, 19 Aug 2013 15:42:33 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: route/arp lifetime (Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)) References: <520A6D07.5080106@freebsd.org> <520B74DD.1060102@ipfw.ru> <20130814124024.GA64548@onelab2.iet.unipi.it> <201308141740.28779.zec@fer.hr> <20130814154853.GA66341@onelab2.iet.unipi.it> In-Reply-To: <20130814154853.GA66341@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Lev Serebryakov , FreeBSD Net , Marko Zec , Lawrence Stewart 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, 19 Aug 2013 11:44:36 -0000 On 14.08.2013 19:48, Luigi Rizzo wrote: > On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote: >> On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote: >>> On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote: > ... >> FWIW, apparently we already have that infrastrucure in place - if_rele() >> calls if_free_internal() only when the last reference to the ifnet is >> dropped, so with little care this should be usable for caching ifp pointers >> w/o fears for kernel crashes mentioned above. > maybe Alexander was referring to holding references to the rte entries > returned as a result of the lookup. The rte holds a reference to the ifp. Yes. Since there is the only refcount which is protected (and is also a huge performance killer). Btw, there is a picture describing IPv4 packet flow from my still-not-written post related network stack performance, maybe it can be useful: http://static.ipfw.ru/images/freebsd_ipv4_flow.png > > cheers > luigi > From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 16:18: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 60F34AD9 for ; Mon, 19 Aug 2013 16:18:53 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm13-vm3.bullet.mail.ne1.yahoo.com (nm13-vm3.bullet.mail.ne1.yahoo.com [98.138.91.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C48C2890 for ; Mon, 19 Aug 2013 16:18:50 +0000 (UTC) Received: from [98.138.226.177] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2013 16:16:02 -0000 Received: from [98.138.226.166] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2013 16:16:02 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 19 Aug 2013 16:16:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 67626.38422.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 28706 invoked by uid 60001); 19 Aug 2013 16:16:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376928961; bh=CWfzcBO3jiDRJZPFUAqUscyPzQKBJP1isyPTtOgfpS0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=julMZlvR78UjSkl4lbhe7egI5P5yYDxO/Ny+DWYLiazMSYWuhYKI+DvroEniqIZWirb0ItZ6Lw129+5E9Fq78JWKoenzkBZuiwHdFK61uIFBXm4HmxlNHCqJQ0K3DfwqFGGl4DnwfsoclANhhTtjJ3TmbJJJU32OUt57kh1JpMY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TbRFM2WWYtKlolWcLyWhVickXaF8JWhSL+h6fUu/Js6HwmElOrh33xipS7yxxTv1FRyjWMzYW9qQtJOJY+cfkdRSDRqgVy0sV1lYNzjNVzYgtZ0Ao/wHGEAAVID0CAKr5aFMf9FRxOVaj/QwM6YrWyh36sY5zyhH/sibPILVD8E=; X-YMail-OSG: 8MqeI2cVM1kIupX2xl4YRdTDrhZEa20WPUW6xMeIDmm3Xua 4J7QGZ3OEZKcmyEpxznSMm6kibZrq24YLYQoLmpvLfrNsws0dzPiyrqYDCys LJFYVmQJjf.yyaLlW4gVXDZO.BHLtJu2ExzF3gRKs9YXvqQFc7KMinL0Wbh8 n2eEXEjwqSHFfE3BWy8HnXPlsv5lEu7IebZ._eGV7XsiB7TSzlI6nNuhLdT1 .453xJTP1reI2qSGuOc7yKISPlcSPRwvzH6fYjdAJ7FJEp6_UIyQe0UvPQLo 9WSDCuEriE0eyXjHyoRFpRfVNoYN3DjMTJ3X_iRnMjcSj9XboWcC723j8YQj HA4_a85nr6cKYMK.69M6IPxa1Bm2FLzbI.7ZHgi1tv.lnZybsODvhNnyMw0A Idf6UdICBlwkKfN.yM.bdQ9b4mouAF8UbVr4tEqDkGDas68QKh5E3r_k8aX. z9L9V74NKGjjimG5855Q9_SHNAm23t0qEnqIRsCzfobYZER5QHarxQ8Ol2Yc W3BKvcV.snE5nQys_mFojbkMIkboQsjlY0bPzWixt7ceEJrUFij.sL6CGyOq yio5vQlMRfDPu3xPIZ0pF75N4iJReVj_UzGkqBtlgsA-- Received: from [98.203.118.124] by web121602.mail.ne1.yahoo.com via HTTP; Mon, 19 Aug 2013 09:16:01 PDT X-Rocket-MIMEInfo: 002.001, CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBMdWlnaSBSaXp6byA8cml6em9AaWV0LnVuaXBpLml0PgpUbzogQmFybmV5IENvcmRvYmEgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4gCkNjOiAiZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmciIDxmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZz47IEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPiAKU2VudDogU3VuZGF5LCBBdWd1c3QgMTgsIDIwMTMgNToxNiBQTQpTdWJqZWN0OiBSZTogaXQncyB0aGUgb3V0cHV0LCBub3QgYWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <520A6D07.5080106@freebsd.org> <520AFBE8.1090109@freebsd.org> <520B24A0.4000706@freebsd.org> <520B3056.1000804@freebsd.org> <20130814102109.GA63246@onelab2.iet.unipi.it> <1376745244.6575.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376748170.66110.YahooMailNeo@web121601.mail.ne1.yahoo.com> <1376833738.94737.YahooMailNeo@web121605.mail.ne1.yahoo.com> <71EA3DFB-B410-432D-98E0-B6341556BE6D@netgate.com> <1376851152.3322.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1376859717.20232.YahooMailNeo@web121605.mail.ne1.yahoo.com> Message-ID: <1376928961.25340.YahooMailNeo@web121602.mail.ne1.yahoo.com> Date: Mon, 19 Aug 2013 09:16:01 -0700 (PDT) From: Barney Cordoba Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux) To: Luigi Rizzo In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:18:53 -0000 =0A=0A=0A=0A________________________________=0A From: Luigi Rizzo =0ATo: Barney Cordoba =0ACc: "freebsd= -net@freebsd.org" ; Adrian Chadd =0ASent: Sunday, August 18, 2013 5:16 PM=0ASubject: Re: it's the output= , not ack coalescing (Re: TSO and FreeBSD vs Linux)=0A =0A=0AOn Sun, Aug 18= , 2013 at 11:01 PM, Barney Cordoba=0Awrote:=0A=0A= > That's fine, it's a test tool, not a solution. It just seems that it gets= =0A> pushed as if it's some sort of real=0A> world solution, which it's not= . The idea that bringing packets into user=0A> space to forward them rather= =0A> than just replacing the bridge module with something more efficient is= =0A> just silliness.=0A>=0A=0Ayou might want to have a look at the VALE swi= tch=0A=0Ahttp://info.iet.unipi.it/~luigi/vale/=0A=0Athe upcoming version ca= n attach physical interfaces to the switch and keep=0Aall the processing wi= thin the kernel.=0A=0A=0A> If "pushing packets" was a useful task, the solu= tion would be easy.=0A> Unfortunately you need to do=0A> something useful w= ith the packets in between.=0A>=0A>=0Athere are different definitions of wh= at is "useful":=0Asources, sinks, forwarding, dropping (anti DoS), logging,= ids,=0Aare all useful for different people. The mistake, i think,=0Ais to = expect that there is one magic solution to handle all the useful=0Acases.= =0A=0Acheers=0Aluigi=0A_______________________________________________=0A= =0A=0A=0ANobody claimed that there was a magic solution. But when so much t= ime and brainpower=0Ais spent working on kludges (instead of doing things t= hat have mainstream usefulness), it=0Aresults in either 1) fewer people usi= ng it or 2) the kludges become accepted solutions, simply=0Abecause someone= did it. Polling, dummynet, netgraph, flowtable and buf_ring=0Aare all good= examples.=A0=0A=0AIt's the big negative of open source, particularly for t= he bigger projects. Once someone has=0Adone "something", it not worth the e= ffort in most cases to do it in a more correct way; and=A0=0Athe something = becomes all that's available.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Mon Aug 19 22:38: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 7D622CDB; Mon, 19 Aug 2013 22:38:18 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1252D71; Mon, 19 Aug 2013 22:38:17 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 81EF611E4C; Tue, 20 Aug 2013 08:38:16 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BOB63025 (AUTH peterg@ptree32.com.au); Tue, 20 Aug 2013 08:38:15 +1000 Message-ID: <52129E55.30803@freebsd.org> Date: Mon, 19 Aug 2013 15:38:13 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann Subject: M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys) References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org> <52128937.1010407@freebsd.org> In-Reply-To: <52128937.1010407@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, Navdeep Parhar 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, 19 Aug 2013 22:38:18 -0000 Hi Andre, (moving to the more appropriate freebsd-net) > I'm sorry for ambushing but this stuff has to be done. I have provided > an alternative way of handling it and I'm happy to help you with your > use case to make it good for you and to prevent the mbuf system from > getting bloated and hackish again. Sure. I'm not really upset since my code wasn't too far along, but with any API, you never know who consumers might be so it's always worth being proactive about announcing it's removal. > Can you please describe your intended use of M_NOFREE to better understand > the shortcomings of the current mbuf systems and the additional advantages > of the M_NOFREE case? I was looking at something similar to Linux's vhost-net, where a guest's virtio ring would be processed in-kernel. An mbuf chain with external buffers would be used to pass guest tx buffer/len segments directly into FreeBSD drivers. The intent of M_NOFREE was to avoid small mbuf allocations/frees in what is a hot path. This code was intended to run at 10/40G. Note this code isn't really generic - it would require interfaces to be 'owned' by the guest, except that direct PCI-level pass-through wouldn't be needed. If there's an alternative to M_NOFREE, I'd be more than happy to use that. later, Peter. From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 01:09:17 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 561473BD; Tue, 20 Aug 2013 01:09:17 +0000 (UTC) (envelope-from jmg@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 2A3362467; Tue, 20 Aug 2013 01:09:17 +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 r7K19H4b081512; Tue, 20 Aug 2013 01:09:17 GMT (envelope-from jmg@freefall.freebsd.org) Received: (from jmg@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7K19F4k081511; Tue, 20 Aug 2013 01:09:15 GMT (envelope-from jmg) Date: Tue, 20 Aug 2013 01:09:15 GMT Message-Id: <201308200109.r7K19F4k081511@freefall.freebsd.org> To: joe@rewt.org.uk, jmg@FreeBSD.org, freebsd-net@FreeBSD.org From: jmg@FreeBSD.org Subject: Re: kern/181388: [route] Routes not updated on mtu change 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, 20 Aug 2013 01:09:17 -0000 Synopsis: [route] Routes not updated on mtu change State-Changed-From-To: open->closed State-Changed-By: jmg State-Changed-When: Tue Aug 20 01:07:27 UTC 2013 State-Changed-Why: per response on mailing list, this is as designed so that the person running the box can control the MTU to specific hosts on the network... http://www.freebsd.org/cgi/query-pr.cgi?pr=181388 From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 01:12:56 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 2C3BC51B for ; Tue, 20 Aug 2013 01:12:56 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E50E324C4 for ; Tue, 20 Aug 2013 01:12:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7K1CtwI037872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 18:12:55 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7K1CsYn037871; Mon, 19 Aug 2013 18:12:54 -0700 (PDT) (envelope-from jmg) Date: Mon, 19 Aug 2013 18:12:54 -0700 From: John-Mark Gurney To: Joe Holden Subject: Re: kern/181388: [route] Routes not updated on mtu change Message-ID: <20130820011254.GZ94127@funkthat.com> Mail-Followup-To: Joe Holden , freebsd-net@freebsd.org References: <201308190700.r7J701I9045665@freefall.freebsd.org> <5211D812.5070308@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5211D812.5070308@rewt.org.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 19 Aug 2013 18:12:55 -0700 (PDT) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 01:12:56 -0000 Joe Holden wrote this message on Mon, Aug 19, 2013 at 09:32 +0100: > Hm, I hadn't considered that... how do other OSes and vendors handle > this? (eg Linux?) > > Just changing the connected route would probably suffice, or maybe if > any routes not added with default interface mtu could/are be flagged, > then those could be changed or not depending on what added them? How do you know which routes are which? I believe that FreeBSD will automaticly reduce the MTU if you decrease it, but it won't increase it.. How do you know the difference between someone increasing the MTU on the interface to allow a specific host to talk at the larger MTU and wanting the rest of the hosts to talk at the larger MTU... At a previous work place, we used this feature so that we could use MTU 9k to other FreeBSD boxes to get better NFS performance, and but keep the other windows boxes which didn't have MTU 9k compatible interfaces talking on the same LAN... > Perhaps need someone with more experience of the network stack to wade > in here... > > Cheers, > Joe > > On 19/08/2013 08:00, Julian Elischer wrote: > >The following reply was made to PR kern/181388; it has been noted by GNATS. > > > >From: Julian Elischer > >To: bug-followup@FreeBSD.org, joe@rewt.org.uk > >Cc: > >Subject: Re: kern/181388: [route] Routes not updated on mtu change > >Date: Mon, 19 Aug 2013 14:57:22 +0800 > > > > The problem is that this is not as simple as it seems. > > The route MTU MIGHT have been set by something other than the > > interface MTU > > in the first place. > > The interface MTU is a default for the route MTU but is not the only > > source. > > This actuall bit me a couple of days ago when I was wonderign why my > > interface was not sending 9K packets.. turns out you need to do > > 'ifconfig_xn0="DHCP mtu 9000"' in order to have your dncp > > configured interface routes have the right size. > > > > so, I'm agreeing with you , but noticing that there are complications. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 01:14: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 1807471F for ; Tue, 20 Aug 2013 01:14:52 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED19124E3 for ; Tue, 20 Aug 2013 01:14:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7K0wmtH037642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 17:58:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7K0wl1e037641; Mon, 19 Aug 2013 17:58:47 -0700 (PDT) (envelope-from jmg) Date: Mon, 19 Aug 2013 17:58:47 -0700 From: John-Mark Gurney To: Joe Holden Subject: Re: Updating route MTU when interface changes Message-ID: <20130820005847.GY94127@funkthat.com> Mail-Followup-To: Joe Holden , freebsd-net@freebsd.org References: <520B8694.1050407@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520B8694.1050407@rewt.org.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 19 Aug 2013 17:58:48 -0700 (PDT) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 01:14:52 -0000 Joe Holden wrote this message on Wed, Aug 14, 2013 at 14:31 +0100: > I noticed this some years ago but I just checked and its still there - > when the mtu of an interface is changed, any routes (eg connected route) > using that interface aren't updated until the interface is shut/unshut - > is this by design or is it an oversight? Having to down/up remote > machine interfaces that are potentially forwarding traffic just to > change the mtu seems silly. FreeBSD used to have code that would automaticly increase a route's MTU to the largest that the interface provided... This is an issue if you want to support a mixed MTU lan... You can no longer administrivally restirct the size of packets being sent out... The other option is to simply delete all the host routes for that interface and change the net route, and things will be what you expect.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 03:13:54 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 5271FD3A; Tue, 20 Aug 2013 03:13:54 +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 06FEC2A67; Tue, 20 Aug 2013 03:13:53 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7K3Dn7N003398 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 20:13:51 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5212DEE7.6060804@freebsd.org> Date: Tue, 20 Aug 2013 11:13:43 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Grehan Subject: Re: M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys) References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org> <52128937.1010407@freebsd.org> <52129E55.30803@freebsd.org> In-Reply-To: <52129E55.30803@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, Andre Oppermann , Navdeep Parhar 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, 20 Aug 2013 03:13:54 -0000 On 8/20/13 6:38 AM, Peter Grehan wrote: > Hi Andre, > > (moving to the more appropriate freebsd-net) > >> I'm sorry for ambushing but this stuff has to be done. I have >> provided >> an alternative way of handling it and I'm happy to help you with your >> use case to make it good for you and to prevent the mbuf system from >> getting bloated and hackish again. > > Sure. I'm not really upset since my code wasn't too far along, but > with any API, you never know who consumers might be so it's always > worth being proactive about announcing it's removal. > >> Can you please describe your intended use of M_NOFREE to better >> understand >> the shortcomings of the current mbuf systems and the additional >> advantages >> of the M_NOFREE case? > > I was looking at something similar to Linux's vhost-net, where a > guest's virtio ring would be processed in-kernel. An mbuf chain with > external buffers would be used to pass guest tx buffer/len segments > directly into FreeBSD drivers. > > The intent of M_NOFREE was to avoid small mbuf allocations/frees in > what is a hot path. This code was intended to run at 10/40G. > > Note this code isn't really generic - it would require interfaces > to be 'owned' by the guest, except that direct PCI-level > pass-through wouldn't be needed. > > If there's an alternative to M_NOFREE, I'd be more than happy to > use that. I think an alternative would be a reference counted version. we used to have that and NetBSD had a quite sophisticated mbuf system where there were multiple owners of mbufs.. they wouldn't be freed until the last one freed it but I don't remember the details. > > later, > > Peter. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 08:25: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 B33E2E73 for ; Tue, 20 Aug 2013 08:25:26 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA7D2C2C for ; Tue, 20 Aug 2013 08:25:25 +0000 (UTC) Received: from [192.168.1.54] (staff-ns50-3.as25178.net [212.9.98.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3cK4nV1mQGzY7 for ; Tue, 20 Aug 2013 09:25:18 +0100 (BST) Message-ID: <521327EB.6010407@rewt.org.uk> Date: Tue, 20 Aug 2013 09:25:15 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: kern/181388: [route] Routes not updated on mtu change References: <201308190700.r7J701I9045665@freefall.freebsd.org> <5211D812.5070308@rewt.org.uk> <20130820011254.GZ94127@funkthat.com> In-Reply-To: <20130820011254.GZ94127@funkthat.com> 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: Tue, 20 Aug 2013 08:25:26 -0000 On 20/08/2013 02:12, John-Mark Gurney wrote: > Joe Holden wrote this message on Mon, Aug 19, 2013 at 09:32 +0100: >> Hm, I hadn't considered that... how do other OSes and vendors handle >> this? (eg Linux?) >> >> Just changing the connected route would probably suffice, or maybe if >> any routes not added with default interface mtu could/are be flagged, >> then those could be changed or not depending on what added them? > > How do you know which routes are which? I believe that FreeBSD will > automaticly reduce the MTU if you decrease it, but it won't increase > it.. How do you know the difference between someone increasing the MTU > on the interface to allow a specific host to talk at the larger MTU and > wanting the rest of the hosts to talk at the larger MTU... > connected route is the one that should be changed, not others as you are right in that regard, there may be routes that shouldn't be changed like the default gateway or other hosts. Make it a tunable exposed via sysctl or something, job done. > At a previous work place, we used this feature so that we could use > MTU 9k to other FreeBSD boxes to get better NFS performance, and but > keep the other windows boxes which didn't have MTU 9k compatible > interfaces talking on the same LAN... > vlan interfaces achieve the same thing without having to mess about with mtus on routes and also give you an interface to work with, a much nicer method comparatively. >> Perhaps need someone with more experience of the network stack to wade >> in here... How difficult would it be to have ifconfig do it? As in, when MTU is changed on an interface, if there is a prefix configured, update the MTU as an rtsock message? >> >> Cheers, >> Joe >> >> On 19/08/2013 08:00, Julian Elischer wrote: >>> The following reply was made to PR kern/181388; it has been noted by GNATS. >>> >>> From: Julian Elischer >>> To: bug-followup@FreeBSD.org, joe@rewt.org.uk >>> Cc: >>> Subject: Re: kern/181388: [route] Routes not updated on mtu change >>> Date: Mon, 19 Aug 2013 14:57:22 +0800 >>> >>> The problem is that this is not as simple as it seems. >>> The route MTU MIGHT have been set by something other than the >>> interface MTU >>> in the first place. >>> The interface MTU is a default for the route MTU but is not the only >>> source. >>> This actuall bit me a couple of days ago when I was wonderign why my >>> interface was not sending 9K packets.. turns out you need to do >>> 'ifconfig_xn0="DHCP mtu 9000"' in order to have your dncp >>> configured interface routes have the right size. >>> >>> so, I'm agreeing with you , but noticing that there are complications. > From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 08:46:42 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 427E32FC for ; Tue, 20 Aug 2013 08:46:42 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 03B782DCF for ; Tue, 20 Aug 2013 08:46:41 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e82a:4e48:57ff:b6e3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id DDFB04AC31; Tue, 20 Aug 2013 12:46:34 +0400 (MSK) Date: Tue, 20 Aug 2013 12:46:33 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <162512031.20130820124633@serebryakov.spb.ru> To: Joe Holden Subject: Re: kern/181388: [route] Routes not updated on mtu change In-Reply-To: <521327EB.6010407@rewt.org.uk> References: <201308190700.r7J701I9045665@freefall.freebsd.org> <5211D812.5070308@rewt.org.uk> <20130820011254.GZ94127@funkthat.com> <521327EB.6010407@rewt.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 08:46:42 -0000 Hello, Joe. You wrote 20 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 12:25= :15: JH> vlan interfaces achieve the same thing without having to mess about with JH> mtus on routes and also give you an interface to work with, a much nice= r=20 JH> method comparatively. But it could put huge load on routing between these two segments and/or requires managed switches. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 14:21:29 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 17FD5199; Tue, 20 Aug 2013 14:21:29 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id D3A372348; Tue, 20 Aug 2013 14:21:28 +0000 (UTC) Received: from [192.168.1.218] (staff-ns50-3.as25178.net [212.9.98.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3cKDhM3kQRzZq; Tue, 20 Aug 2013 15:21:23 +0100 (BST) Message-ID: <52137B62.3000405@rewt.org.uk> Date: Tue, 20 Aug 2013 15:21:22 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: lev@FreeBSD.org Subject: Re: kern/181388: [route] Routes not updated on mtu change References: <201308190700.r7J701I9045665@freefall.freebsd.org> <5211D812.5070308@rewt.org.uk> <20130820011254.GZ94127@funkthat.com> <521327EB.6010407@rewt.org.uk> <162512031.20130820124633@serebryakov.spb.ru> In-Reply-To: <162512031.20130820124633@serebryakov.spb.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 14:21:29 -0000 On 20/08/2013 09:46, Lev Serebryakov wrote: > Hello, Joe. > You wrote 20 авгуÑта 2013 г., 12:25:15: > > JH> vlan interfaces achieve the same thing without having to mess about with > JH> mtus on routes and also give you an interface to work with, a much nicer > JH> method comparatively. > But it could put huge load on routing between these two segments and/or > requires managed switches. > Neither really, don't need a managed switch to use dot1q and if you're routing between segments with a box, then you shouldn't be using multiple ranges in the same broadcast domain anyway. Networking 101 From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 15:01:10 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 166456C for ; Tue, 20 Aug 2013 15:01:10 +0000 (UTC) (envelope-from flavio@dcc.ufrj.br) Received: from ilha.dcc.ufrj.br (ilha.dcc.ufrj.br [146.164.41.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A85E260C for ; Tue, 20 Aug 2013 15:01:09 +0000 (UTC) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (Authenticated sender: flavio) by ilha.dcc.ufrj.br (Postfix) with ESMTP id 799FD480004A for ; Tue, 20 Aug 2013 11:41:28 -0300 (BRT) Received: by mail-wg0-f43.google.com with SMTP id z12so461047wgg.22 for ; Tue, 20 Aug 2013 07:41:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=T3B7I5G1cFZ2mE3rCOh1iYmavwyQ8+/I30W2Pyez9OM=; b=PlsSEfdl63YHLwe0/HfzwfhzEHwuGOqcmDeYQthxg0U6hJyeL2nJs8ZGZEyxp6hshq fMah4zv3ibmmot5PDQJQLwHefwhC3wG1+7UFb26JGZMn2kuXRMmISn6bugD2RYq3cGeQ zDHCTtXOSwx/UuPCTS06LPQ6eDPSfOo+m4J+gQlvU+rHpTVheBQ8MLsGEMrdpcfq2GOO SwlRK8oWrWwPPTuuclI1a2P0uKO0wSWTHLqtDEzWcIIppMfKAQtOrlDevX8n2HCfIW/m Qj7tThY1Fpo7ERO9V+5aRsNMPWCbIm7WZVCz98OK+UputJd1xdx4K+Q+/4eSz72GGf68 MbCA== MIME-Version: 1.0 X-Received: by 10.180.198.44 with SMTP id iz12mr1581578wic.32.1377009686742; Tue, 20 Aug 2013 07:41:26 -0700 (PDT) Received: by 10.216.181.9 with HTTP; Tue, 20 Aug 2013 07:41:26 -0700 (PDT) Date: Tue, 20 Aug 2013 11:41:26 -0300 Message-ID: Subject: mpd5, PPPoE, STABLE-9, kernel panics From: =?UTF-8?Q?Fl=C3=A1vio?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 20 Aug 2013 15:01:10 -0000 (Apologies because of my poor english, it's not my first language. Corrections are welcome. It's also my first post to this mailing-list) I'm having some issues running a KVM-virtualized FreeBSD 9-STABLE (somewhat 4 weeks old, so it has the latest netgraph code). I'm also running a 7.4-RELEASE (also virtualized) system on the same machine which has a way better stability record, although not stellar, but I think it would be way more interesting to find out what is keeping my 9-STABLE from being rock solid instead of relying on FreeBSD 7.4. Right now it serves a 4000 clients network as a PPPoE server. There's also another 6 servers (non-virtualized), all running 7.4-RELEASE, serving the same network, so I can experiment with my 9-STABLE installation. I will copy the stack trace from one of the four core.txt files I currently have. If requested I can copy more info, recompile my kernel with debugging flags to test etc. Just ask. panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: processor eflags = interrupt enabled, resume, IOPL = 0 current process = 32079 (mpd5) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff804b0c86 at kdb_backtrace+0x66 #1 0xffffffff80476bee at panic+0x1ce #2 0xffffffff806fbc30 at trap_fatal+0x290 #3 0xffffffff806fbf91 at trap_pfault+0x211 #4 0xffffffff806fc544 at trap+0x344 #5 0xffffffff806e5873 at calltrap+0x8 #6 0xffffffff80553e47 at ng_add_hook+0xb7 #7 0xffffffff8055598f at ng_apply_item+0x3bf #8 0xffffffff80554934 at ng_snd_item+0x3b4 #9 0xffffffff8056400f at ngc_send+0x1df #10 0xffffffff804e71c6 at sosend_generic+0x3f6 #11 0xffffffff804eaaa3 at kern_sendit+0x1a3 #12 0xffffffff804ead5c at sendit+0xdc #13 0xffffffff804eae4d at sys_sendto+0x4d #14 0xffffffff806fb3da at amd64_syscall+0x5ea #15 0xffffffff806e5b57 at Xfast_syscall+0xf7 Uptime: 3h42m8s Dumping 118 out of 1011 MB:..14%..27%..41%..54%..68%..81%..95% #0 doadump (textdump=) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:234 #1 0xffffffff804766c6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff80476bc7 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff806fbc30 in trap_fatal (frame=0xc, eva=) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff806fbf91 in trap_pfault (frame=0xffffff80003c7610, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff806fc544 in trap (frame=0xffffff80003c7610) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff806e5873 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff80556f86 in ng_bpf_newhook (node=, hook=0xfffffe0001b9c380, name=0xfffffe0011e71258 "0-0-m") at /usr/src/sys/netgraph/ng_bpf.c:249 #8 0xffffffff80553e47 in ng_add_hook (node=0xfffffe0026021100, name=0xfffffe0011e71258 "0-0-m", hookp=0xffffff80003c7808) at /usr/src/sys/netgraph/ng_base.c:1092 #9 0xffffffff8055598f in ng_apply_item (node=0xfffffe0026021100, item=0xfffffe0011d90980, rw=1) at /usr/src/sys/netgraph/ng_base.c:1544 #10 0xffffffff80554934 in ng_snd_item (item=, flags=0) at /usr/src/sys/netgraph/ng_base.c:2314 #11 0xffffffff8056400f in ngc_send (so=, flags=, m=0xfffffe0011c36000, addr=, control=, td=) at /usr/src/sys/netgraph/ng_socket.c:317 #12 0xffffffff804e71c6 in sosend_generic (so=0xfffffe0001982000, addr=0xfffffe002602fa20, uio=0xffffff80003c7a00, top=0xfffffe0011c36000, control=0x0, flags=, td=0xfffffe00018ba000) at /usr/src/sys/kern/uipc_socket.c:1367 #13 0xffffffff804eaaa3 in kern_sendit (td=0xfffffe00018ba000, s=5, mp=0xffffff80003c7ad0, flags=0, control=0x0, segflg=) at /usr/src/sys/kern/uipc_syscalls.c:811 #14 0xffffffff804ead5c in sendit (td=0xfffffe00018ba000, s=5, mp=0xffffff80003c7ad0, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:739 #15 0xffffffff804eae4d in sys_sendto (td=, uap=) at /usr/src/sys/kern/uipc_syscalls.c:863 #16 0xffffffff806fb3da in amd64_syscall (td=0xfffffe00018ba000, traced=0) at subr_syscall.c:135 #17 0xffffffff806e5b57 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #18 0x000000080225adcc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Thanks. Any help will be greatly appreciated. From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 18:10:01 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 5D24E413 for ; Tue, 20 Aug 2013 18:10: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 4991F217A for ; Tue, 20 Aug 2013 18:10: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 r7KIA16K099099 for ; Tue, 20 Aug 2013 18:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7KIA1Vu099098; Tue, 20 Aug 2013 18:10:01 GMT (envelope-from gnats) Date: Tue, 20 Aug 2013 18:10:01 GMT Message-Id: <201308201810.r7KIA1Vu099098@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/181225: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:10:01 -0000 The following reply was made to PR kern/181225; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/181225: commit references a PR Date: Tue, 20 Aug 2013 18:08:15 +0000 (UTC) Author: jhb Date: Tue Aug 20 18:08:06 2013 New Revision: 254576 URL: http://svnweb.freebsd.org/changeset/base/254576 Log: Stop an ipoib interface before detaching it. PR: kern/181225 Submitted by: Shahar Klein Obtained from: Mellanox MFC after: 1 week Modified: head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c Modified: head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c ============================================================================== --- head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c Tue Aug 20 18:06:18 2013 (r254575) +++ head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c Tue Aug 20 18:08:06 2013 (r254576) @@ -1073,6 +1073,8 @@ ipoib_remove_one(struct ib_device *devic if (rdma_port_get_link_layer(device, priv->port) != IB_LINK_LAYER_INFINIBAND) continue; + ipoib_stop(priv); + ib_unregister_event_handler(&priv->event_handler); /* dev_change_flags(priv->dev, priv->dev->flags & ~IFF_UP); */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 22:06:40 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 0FFAE410 for ; Tue, 20 Aug 2013 22:06:40 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C7F2E2059 for ; Tue, 20 Aug 2013 22:06:39 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e82a:4e48:57ff:b6e3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 4F5D94AC2D; Wed, 21 Aug 2013 02:06:34 +0400 (MSK) Date: Wed, 21 Aug 2013 02:06:31 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <648062544.20130821020631@serebryakov.spb.ru> To: Joe Holden Subject: Re: kern/181388: [route] Routes not updated on mtu change In-Reply-To: <52137B62.3000405@rewt.org.uk> References: <201308190700.r7J701I9045665@freefall.freebsd.org> <5211D812.5070308@rewt.org.uk> <20130820011254.GZ94127@funkthat.com> <521327EB.6010407@rewt.org.uk> <162512031.20130820124633@serebryakov.spb.ru> <52137B62.3000405@rewt.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 22:06:40 -0000 Hello, Joe. You wrote 20 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 18:21= :22: >> JH> vlan interfaces achieve the same thing without having to mess about = with >> JH> mtus on routes and also give you an interface to work with, a much n= icer >> JH> method comparatively. >> But it could put huge load on routing between these two segments and/or >> requires managed switches. >> JH> Neither really, don't need a managed switch to use dot1q and if you're= =20 JH> routing between segments with a box, then you shouldn't be using=20 JH> multiple ranges in the same broadcast domain anyway. Networking 101 (1) As far as I know, Windows works very badly with VLANs, it depends on drivers and Windows doesn't have unified VLAN management/support, opposite to UNIX systems. My desktop adapter (Atheros AR8121), for example, supports VLANs on hardware level and it works with FreeBSD, but "desktop windows" (= not Windows Server) drivers doesn't provide any way to set VLAN. So, to put any Windows system, driver- and adapter-independent, to VLAN, you need to assign VLAN at switch on per-port basis. You need managed switch. Maybe, something was changed in Windows 8, I don't know, but Windows 7 (even Ultimate edition) doesn't have any VLAN management. (2) As far as I understand, "topicstarter" has Windows and FreeBSD machines in one segment (with different MTUs) and you suggest to put them in different segments (via VLANs), so there WAS NO routing at all, and now it is two segments, which needs routing between them. But, maybe, I understood John-Mark Gurney wrong, and they had two broadcast domains on one network (and double-addressed interface in router). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Aug 20 22:24: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 A71FE6F1; Tue, 20 Aug 2013 22:24:00 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9D62135; Tue, 20 Aug 2013 22:23:58 +0000 (UTC) Received: from jwhlaptop (unknown [91.208.177.70]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3cKRP80DT3zdr; Tue, 20 Aug 2013 23:23:55 +0100 (BST) From: "Joe Holden" To: References: <201308190700.r7J701I9045665@freefall.freebsd.org> <5211D812.5070308@rewt.org.uk> <20130820011254.GZ94127@funkthat.com> <521327EB.6010407@rewt.org.uk> <162512031.20130820124633@serebryakov.spb.ru> <52137B62.3000405@rewt.org.uk> <648062544.20130821020631@serebryakov.spb.ru> In-Reply-To: <648062544.20130821020631@serebryakov.spb.ru> Subject: RE: kern/181388: [route] Routes not updated on mtu change Date: Tue, 20 Aug 2013 23:23:49 +0100 Message-ID: <17fb01ce9df3$f2cc6ba0$d86542e0$@rewt.org.uk> X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJP8AXG1yGQWVh/gFlhKY93jfPlgAF8lD13AdiHrE0CosAU4QJ3WUG+AhW17pgCQOJ1wJg12Urw Content-Language: en-gb Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 22:24:00 -0000 You have a good point wrt VLANs on Windows but everyone uses Intel nics.... right? :P > -----Original Message----- > From: Lev Serebryakov [mailto:lev@FreeBSD.org] > Sent: 20 August 2013 23:07 > To: Joe Holden > Cc: freebsd-net@freebsd.org > Subject: Re: kern/181388: [route] Routes not updated on mtu change > > Hello, Joe. > You wrote 20 ??????? 2013 ?., 18:21:22: > > >> JH> vlan interfaces achieve the same thing without having to mess > >> JH> about with mtus on routes and also give you an interface to work > >> JH> with, a much nicer method comparatively. > >> But it could put huge load on routing between these two segments > >> and/or requires managed switches. > >> > JH> Neither really, don't need a managed switch to use dot1q and if > JH> you're routing between segments with a box, then you shouldn't be > JH> using multiple ranges in the same broadcast domain anyway. > JH> Networking 101 > > (1) As far as I know, Windows works very badly with VLANs, it depends on > drivers and Windows doesn't have unified VLAN management/support, > opposite to UNIX systems. My desktop adapter (Atheros AR8121), for > example, supports VLANs on hardware level and it works with FreeBSD, but > "desktop windows" (not Windows Server) drivers doesn't provide any way > to set VLAN. So, to put any Windows system, driver- and adapter- > independent, to VLAN, you need to assign VLAN at switch on per-port basis. > You need managed switch. Maybe, something was changed in Windows 8, I > don't know, but Windows 7 (even Ultimate edition) doesn't have any VLAN > management. > > (2) As far as I understand, "topicstarter" has Windows and FreeBSD > machines in one segment (with different MTUs) and you suggest to put > them in different segments (via VLANs), so there WAS NO routing at all, and > now it is two segments, which needs routing between them. But, maybe, I > understood John-Mark Gurney wrong, and they had two broadcast domains > on one network (and double-addressed interface in router). > > > -- > // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Aug 21 05:00:17 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 4C9A49D; Wed, 21 Aug 2013 05:00:17 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F174D246F; Wed, 21 Aug 2013 05:00:16 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id o19so187295qap.0 for ; Tue, 20 Aug 2013 22:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=J1HPrLgQ8fQjbrHFM0ua/vcLKtp92r1grSvk1DL8vPs=; b=dGYKNu2tml+M04HzChzYSYMQUls5jZcrGik8IPb0CX31LD/PzTHCEN5jzcGAm8J+gk Gh5HY6Zl0lVUjgmTY9E25Upc3vHbwJpLSaI+vqCchPoDZqysUCnznuGOE2NM2I3yQBoN BiD/BpGNE272P9TbRBx0nj0CN5h7w6lpALwYSxIQRIbx4tpqDG0+5fp8nORwRRZxT16L zRy1MMhRKtF6/qttbjPXYHZUbbZAy9D7YptnVWYjGUlyse/JIe59/h3HrSQoQ4cnFbAL HtPqjMtQFfCUxNwnFOi+/fTaIHfg1TFcsoRka6et4soeJ+foVBsdGvTYpoAiT5m/ziqf mk7A== X-Received: by 10.224.80.9 with SMTP id r9mr6255880qak.89.1377061215755; Tue, 20 Aug 2013 22:00:15 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id m8sm8861411qay.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 22:00:15 -0700 (PDT) Sender: Mark Johnston Date: Wed, 21 Aug 2013 01:00:10 -0400 From: Mark Johnston To: freebsd-net@freebsd.org, freebsd-dtrace@freebsd.org Subject: DTrace network providers Message-ID: <20130821045926.GA17196@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 21 Aug 2013 05:00:17 -0000 Hello! I've ported the ip, tcp and udp DTrace providers to FreeBSD, following the Solaris documentation here: https://wikis.oracle.com/display/DTrace/ip+Provider https://wikis.oracle.com/display/DTrace/tcp+Provider https://wikis.oracle.com/display/DTrace/udp+Provider My implementation of these providers makes use of dynamic translators, for which FreeBSD support was added in r254468; this patch won't compile with earlier revisions. The use of dynamic translators means that existing DTrace scripts which use these providers will just work when run on FreeBSD - no modifications needed. In particular, all of the examples in the links above will work properly on FreeBSD with my diff. I've collected a bunch of example scripts for these providers and placed them here: http://people.freebsd.org/~markj/dtrace/network-providers/ To run one you just need to execute "dtrace -s