From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 07:08:24 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34867C73 for ; Sun, 26 Apr 2015 07:08:24 +0000 (UTC) Received: from asmtp01.netarrest.com (asmtp01.netarrest.com [67.228.24.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11DC41FA2 for ; Sun, 26 Apr 2015 07:08:24 +0000 (UTC) Received: from Dell-Admin (p5B077667.dip0.t-ipconnect.de [91.7.118.103]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp01.netarrest.com (Postfix) with ESMTPSA id 8E490990050 for ; Sun, 26 Apr 2015 02:08:20 -0500 (CDT) Reply-To: nights@sunrise.ch Message-ID: <58fa521e8d56748fda6b8c810013e4f0@sunrise.ch> From: "Midsommar Festival 2015" To: Subject: Are you a DJ ? Date: Sun, 26 Apr 2015 09:05:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Apr 2015 07:08:24 -0000 If you have trouble reading this email, turn on the images, or [1]click here to read it online. [2][CDc4LAiWEAIEcWc.jpg] [3]Midsommar Festival returns to Switzerland for the 5th year and we are searching the planet for the best talented DJ to join the festival for a spotlight performance on this edition in Lucerne. If you think you have what it takes, then upload your best 30 minutes DJ set via Mixcloud or SoundCloud. One talented and lucky winner will get the chance to perform at the Midsommar Festival, with some of the most relevant and talented acts coming from many different countries. The Midsommar Team will cover roundtrip flights and accommodation in Lucerne, Switzerland. The final line-up will be announced soon and maybe with your name on the roster?! This is a unique chance to be part of an incredible festival with artists coming from all around the world. [4][CDc7yZfWAAAmKQ7.jpg] How to Enter: The competition is open to European residents only. * Open a SoundCloud or MixCloud account in case you don't have one. * Upload a mix of no more than 30 minutes. * Title the mix Midsommar Recruits [Your DJ Name] * Tag your mix Midsommar Recruits if you fail to tag it correctly, your mix may be missed * Include the competition cover-art, provided [5]here. * Spread it around and share it to your friends and fans to collect likes. Judging: * The top 20 most 'liked' mixes that are uploaded on Mixcloud or SoundCloud and tagged with 'Midsommar Recruits' will get shortlisted. * Only the mixes with at least 50 plays by the deadline date can qualify in the top 20. * The artists of the Festival and the Midsommar Crew will review each of these 20 mixes and select the 10 finalists. * The finalists will publish the mix or cover of the festival in their own facebook accounts and will collect as much likes, shares and comments they can. The mix or cover with more activity will perform at the Midsommar Festival 2015, with some of the most important artists of the industry. If you dont want to receive our newsletters anymore, please [6]click here This e-mail including any attachments is confidential and may be legally privileged. If you have received it in error please advise the sender immediately. The unauthorised use, distribution, copying or alteration of this email is strictly forbidden. Su dirección de email ha sido recopilada de fuentes de público acceso en Internet. Conforme a la Directiva Europea 2002/58/EC y la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones, vd. tiene el derecho a oponerse a que sus datos personales se utilicen para fines publicitarios y de marketing. Si este es su deseo, le rogamos pulse [7]darse de baja y automaticamente dejará de recibir comunicaciones publicitarias por nuestra parte. CONFIDENCIALIDAD: La información contenida en este mensaje y/o archivo(s) adjunto(s) es confidencial/privilegiada y está destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el destinatario señalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicación por error, le informamos que está totalmente prohibida, y puede ser ilegal, cualquier divulgación, distribución o reproducción de esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la dirección arriba mencionada. Gracias. VIRUS: Aunque hemos tomado las medidas para asegurarnos que este correo electrónico y sus ficheros adjuntos están libres de virus, le recomendamos que a efectos de mantener buenas prácticas de seguridad, el receptor debe asegurarse que este correo y sus ficheros adjuntos están libres de virus. References 1. http://t.co/wgiYtRQ00V 2. http://t.co/wgiYtRQ00V 3. http://t.co/wgiYtRQ00V 4. http://t.co/wgiYtRQ00V 5. http://pbs.twimg.com/media/CDc4LAiWEAIEcWc.jpg:large 6. http://iTiny.net/852727 7. http://iTiny.net/852727 From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 15:45:59 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 387BA27C for ; Sun, 26 Apr 2015 15:45:59 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22E321380 for ; Sun, 26 Apr 2015 15:45:59 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3QFjx5N027174 for ; Sun, 26 Apr 2015 15:45:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Sun, 26 Apr 2015 15:45:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: david.keller@litchis.fr X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Apr 2015 15:45:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #7 from david.keller@litchis.fr --- I disabled TSO4 and VLAN_HWTSO 16 days ago when I saw your reply. The card used to hung specially when I was watching crappy movies. Hence I watched Fast And Furious 1 to 7 since to stress the chip. No hung so far. So yes, it seems related to HWTSO. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 15:48:46 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F27A40C for ; Sun, 26 Apr 2015 15:48:46 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A09613A0 for ; Sun, 26 Apr 2015 15:48:46 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3QFmkuO029208 for ; Sun, 26 Apr 2015 15:48:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Sun, 26 Apr 2015 15:48:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: david.keller@litchis.fr X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Apr 2015 15:48:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #8 from david.keller@litchis.fr --- Note that current driver does'nt increment adapter->rx_overruns in em_msix_link(). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 17:44:50 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E10ECE9A for ; Sun, 26 Apr 2015 17:44:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC2501EEB for ; Sun, 26 Apr 2015 17:44:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3QHiojB013028 for ; Sun, 26 Apr 2015 17:44:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Sun, 26 Apr 2015 17:44:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Apr 2015 17:44:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hiren@FreeBSD.org --- Comment #9 from Hiren Panchasara --- (In reply to david.keller from comment #8) Can you please open a separate issue and cc me, jfv@freebsd.org and erj@freebsd.org if you feel that can cause lesser rx_overruns errors to be reported? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Apr 26 21:00:45 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE8D0EA9 for ; Sun, 26 Apr 2015 21:00:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87C7F1150 for ; Sun, 26 Apr 2015 21:00:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3QL0jd9093954 for ; Sun, 26 Apr 2015 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201504262100.t3QL0jd9093954@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 26 Apr 2015 21:00:45 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 26 Apr 2015 21:00:45 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w Open | 199136 | [if_tap] Added down_on_close sysctl variable to t 2 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 02:02:50 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB6B0BDF for ; Mon, 27 Apr 2015 02:02:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5FAD1CF1 for ; Mon, 27 Apr 2015 02:02:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3R22o8Y028584 for ; Mon, 27 Apr 2015 02:02:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199670] [patch] memory leak in netpfil Date: Mon, 27 Apr 2015 02:02:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 02:02:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199670 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 05:35:41 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AED3475B for ; Mon, 27 Apr 2015 05:35:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98ED2105B for ; Mon, 27 Apr 2015 05:35:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3R5ZfbF059731 for ; Mon, 27 Apr 2015 05:35:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage Date: Mon, 27 Apr 2015 05:35:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 05:35:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 --- Comment #22 from Craig Rodrigues --- The commits done under https://svnweb.freebsd.org/changeset/base/276756 were backed out in https://svnweb.freebsd.org/changeset/base/277519 . Nikos is working on another patch https://reviews.freebsd.org/D1944 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 05:41:26 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5B53957 for ; Mon, 27 Apr 2015 05:41:26 +0000 (UTC) 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)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 820C410B1 for ; Mon, 27 Apr 2015 05:41:26 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3R5fHp0038048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 26 Apr 2015 22:41:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553DCBF9.1010705@freebsd.org> Date: Mon, 27 Apr 2015 13:41:13 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: wishmaster , nvass@gmx.com CC: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 References: <553A7350.40607@gmx.com> <1429894130.217124945.cx0dr7rv@frv34.fwdcdn.com> In-Reply-To: <1429894130.217124945.cx0dr7rv@frv34.fwdcdn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 05:41:26 -0000 On 4/25/15 12:53 AM, wishmaster wrote: > Hi, > > --- Original Message --- > From: "Nikos Vassiliadis" > Date: 24 April 2015, 19:46:42 > > > >> Hi, >> >> Just saw this. Can somebody re-produce this? >> >>> root@m4fh2:~ # sysctl net.inet.ip.forwarding >>> net.inet.ip.forwarding: 1 >>> root@m4fh2:~ # ifconfig bridge0 create >>> root@m4fh2:~ # sysctl net.inet.ip.forwarding >>> net.inet.ip.forwarding: 0 Basically all the setup scripts in /etc/rc.d (andaother setup scripts in /etc and /usr/local/etc) all source /etc/rc.conf and it's friends (defaults etc.) if any of thse scripts gets called (for example by devd when it notices a new interface), then the entire chain of dependencies related to that chain will be run **according to how the config files tell it to run* * and not how the current sysctls are set. if you think about it, this must be the case as htey need to change the sysctls as part of their operation. maybe we should have a script to do what you want and also uses sysrc(8) to make it permanent. >> That's on GENERIC 10-STABLE from the day before yesterday. >> > Put > gateway_enable=YES > into rc.conf and try again. > > Cheers, > Vitaliy > > _______________________________________________ > 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 Apr 27 05:44:25 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 579A5C9C for ; Mon, 27 Apr 2015 05:44:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 422891174 for ; Mon, 27 Apr 2015 05:44:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3R5iPXl071390 for ; Mon, 27 Apr 2015 05:44:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199670] [patch] memory leak in netpfil Date: Mon, 27 Apr 2015 05:44:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 05:44:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199670 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: glebius Date: Mon Apr 27 05:44:10 UTC 2015 New revision: 282051 URL: https://svnweb.freebsd.org/changeset/base/282051 Log: Fix memory leak. PR: 199670 Reviewed by: ae Changes: head/sys/netpfil/ipfw/ip_fw_nat.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 05:45:15 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A619D38 for ; Mon, 27 Apr 2015 05:45:15 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74E8B1187 for ; Mon, 27 Apr 2015 05:45:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3R5jFMZ072020 for ; Mon, 27 Apr 2015 05:45:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199670] [patch] memory leak in netpfil Date: Mon, 27 Apr 2015 05:45:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 05:45:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199670 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |glebius@FreeBSD.org Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 05:50:31 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99728F42 for ; Mon, 27 Apr 2015 05:50:31 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25C8811BB for ; Mon, 27 Apr 2015 05:50:30 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t3R5oLPs099347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Apr 2015 08:50:21 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t3R5oKbc099346; Mon, 27 Apr 2015 08:50:20 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 27 Apr 2015 08:50:20 +0300 From: Gleb Smirnoff To: John-Mark Gurney Cc: freebsd-net@FreeBSD.org, Poul-Henning Kamp Subject: Re: should m_copyback possibly throw data away? Message-ID: <20150427055020.GC883@FreeBSD.org> References: <20150424181158.GJ37063@funkthat.com> <20150424182308.GK37063@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150424182308.GK37063@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 05:50:31 -0000 On Fri, Apr 24, 2015 at 11:23:08AM -0700, John-Mark Gurney wrote: J> John-Mark Gurney wrote this message on Fri, Apr 24, 2015 at 11:11 -0700: J> > I would also be fine w/ documenting this behavior, though I'm sure J> > it'd be surprising to many that you'd have to check to make sure your J> > data was properly copied. J> J> Should have reviewed the m_copyback function before sending this J> email... J> J> It gets worse.. If the m_get to extend it fails, there is no J> notification that your data didn't get copyied into the mbuf.. and no J> warning in the man page that this function is unsafe and may cause J> data loss... J> J> Comments? My suggestion is: 1) make it return int 2) change first check to KASSERT 3) add wait parameter 4) while here change relic of c_caddr_t to const char * Yes, this requires some time. You can also look at OpenBSD/NetBSD. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 09:22:43 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12982E38 for ; Mon, 27 Apr 2015 09:22:43 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00C2618A7 for ; Mon, 27 Apr 2015 09:22:42 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 822F410DBFD; Mon, 27 Apr 2015 02:22:36 -0700 (PDT) Date: Mon, 27 Apr 2015 02:22:36 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Cc: nitroboost@gmail.com Subject: Re: Idle connections via accept_filter(9) Message-ID: <20150427092236.GV28632@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K6Vt3zCKtaqyTnPU" Content-Disposition: inline In-Reply-To: <20150410040834.GG61327@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 09:22:43 -0000 --K6Vt3zCKtaqyTnPU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Wanted to see if someone with understanding of accept_filter can comment. cheers, Hiren On 04/09/15 at 09:08P, hiren panchasara wrote: > If a connections comes on a socket with accf_data(9) (for example) but > never sends any data, it'll occupy resources via staying forever in > listen queue of partial unaccepted connections (socket->so_incomp) which > can be seen as incqlen in 'netstat -Lan'. > Kernel will never pass this connection down to the application as > the filter criteria hasn't been met (no data) and application > would never know about this connection. >=20 > What I am not sure is what would be the state of the connection > and state of the socket when in this situation. We do come here after > finishing 3WHS but before handing this over to the application i.e. > before the accept(). >=20 > From uipc_socket.c: >=20 > * From the passive side, a socket is created with two queues of sockets: > * so_incomp for connections in progress and so_comp for connections alre= ady > * made and awaiting user acceptance. As a protocol is preparing incoming > * connections, it creates a socket structure queued on so_incomp by call= ing > * sonewconn(). When the connection is established, soisconnected() is > * called, and transfers the socket structure to so_comp, making it avail= able > * to accept(). >=20 > So, it looks like the connection would be in ESTABLISHED state but > socket would be stuck in the so_incomp queue. Other than this special > condition of accpet_filter, can such a situation occur? >=20 > Any insight/help into understanding this scenario and a way to cleanup > these connections would be great. >=20 > (I know tcp doesn't care/worry about idle sitting connections; we have > keepalives to check the health of the connection but that's it, afaik) >=20 > Cheers, > Hiren --K6Vt3zCKtaqyTnPU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVPf/bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lDg0H/3wZxqnfBDQGqWUuZTPzj7ZE /Vzbfm1v481TcqcHDKEV4333czTB3Y2YmIzBMLGjEJvq9yE+4YDlJqfG7Yj0ZscD rKq3xhh3Uuqd1zZTO5yrI/vJIAyUVQ9Bfq3hyx+KK5Z2B+pVGU6b2Z1ecuuFsfC+ 5tJcALqZcHnPsxmIuDYyg7N0DIWOELQrSjt5RfuARmVy3rnebJ18j65GOz8HoJ1D pYyqj290p02ZhCiEeeRXHmrMIo8yRr6Dfhul/l2jE9VAslBAEoqbNpF/Pgi9JuFy l4U7ZLVNCz6OvE1mJxRlIo5u4junXlbmJmAkjGeCigntBr9vPHC+LaXzCqZP40E= =a1ui -----END PGP SIGNATURE----- --K6Vt3zCKtaqyTnPU-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 10:01:10 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F294372 for ; Mon, 27 Apr 2015 10:01:10 +0000 (UTC) Received: from smtp2.mail.clearhost.co.uk (smtp2.mail.clearhost.co.uk [IPv6:2001:1420::25:102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.mail.clearhost.co.uk", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50F311CBA for ; Mon, 27 Apr 2015 10:01:10 +0000 (UTC) Received: from [2001:1420:a:105:c62c:3ff:fe2f:bf] (port=52085 helo=parsnip.heronsbrook.org.uk) by smtp2.mail.clearhost.co.uk with esmtpa (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Ymfqb-000EBb-SD for freebsd-net@freebsd.org; Mon, 27 Apr 2015 10:01:05 +0000 Message-ID: <553E0980.6090005@prt.org> Date: Mon, 27 Apr 2015 11:03:44 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 References: <553A7350.40607@gmx.com> <1429894130.217124945.cx0dr7rv@frv34.fwdcdn.com> <553DCBF9.1010705@freebsd.org> In-Reply-To: <553DCBF9.1010705@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 10:01:10 -0000 Hi On 27/04/2015 06:41, Julian Elischer wrote: > Basically all the setup scripts in /etc/rc.d (andaother setup scripts in > /etc and /usr/local/etc) > all source /etc/rc.conf and it's friends (defaults etc.) > if any of thse scripts gets called (for example by devd when it notices > a new interface), > then the entire chain of dependencies related to that chain will be run > **according to how the config files tell it to run* * > and not how the current sysctls are set. > if you think about it, this must be the case as htey need to change the > sysctls as part of > their operation. > > maybe we should have a script to do what you want and also uses sysrc(8) > to make it permanent. I don't think this is a major problem to be honest. The issue I had back in January is that the behaviour changed with an upgrade to 10.1 from 8.something as the interaction with devd wasn't well known. I don't know how this can be dealt with unless we have a load of special-cases that log warnings when, for example, forwarding is enabled in sysctl.conf but there isn't a gateway_enable in rc.conf. That sounds like a messy solution to be honest. Paul. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:10:57 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A6FECF0 for ; Mon, 27 Apr 2015 16:10:57 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E951B18AF for ; Mon, 27 Apr 2015 16:10:56 +0000 (UTC) Received: by igbhj9 with SMTP id hj9so66127842igb.1 for ; Mon, 27 Apr 2015 09:10:56 -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=MTm/d7H9AwOaQQ8HD3DxjCldHayCventGf1GQ0PQbMc=; b=RGNV+JRxcFIc4l5kWO3UF89/xQFBAaAieTf+gNOYiqldptPK0NkzxWSuxyrs1Ju0Vd hTqKQXvC4Slqd0vpU0iYPq/6TKJtE7LghRJHfHV04vR4sniyNzM25pJjAGmCojse9Zrr a6qvch1YTvZUd/sYgbzzA0vsnmUfPNFW96ctLzek8il1FRAlqWTSo/5qLZt4acMa1cmH w4Pfja/sWbWmFMcP2tutw9E04GphhL/WHZAb+H85cJyNIZFgfJIOmmCiV7eoeIx+fMaE ITt6QfeK4a3QGmyLQShUhmo3A/T8vC6V+ow7foviecmU1sWL8hq65Kbi4+vhO8M70Jj+ YPng== MIME-Version: 1.0 X-Received: by 10.107.46.39 with SMTP id i39mr14821119ioo.8.1430151056198; Mon, 27 Apr 2015 09:10:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Mon, 27 Apr 2015 09:10:56 -0700 (PDT) In-Reply-To: <20150427092236.GV28632@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info> <20150427092236.GV28632@strugglingcoder.info> Date: Mon, 27 Apr 2015 09:10:56 -0700 X-Google-Sender-Auth: KTO4wPOspuGJZRo2X2YNvDvzMOw Message-ID: Subject: Re: Idle connections via accept_filter(9) From: Adrian Chadd To: hiren panchasara Cc: FreeBSD Net , Jason Wolfe Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 16:10:57 -0000 ask alfred? :) -a On 27 April 2015 at 02:22, hiren panchasara wrote: > Wanted to see if someone with understanding of accept_filter can > comment. > > cheers, > Hiren > On 04/09/15 at 09:08P, hiren panchasara wrote: >> If a connections comes on a socket with accf_data(9) (for example) but >> never sends any data, it'll occupy resources via staying forever in >> listen queue of partial unaccepted connections (socket->so_incomp) which >> can be seen as incqlen in 'netstat -Lan'. >> Kernel will never pass this connection down to the application as >> the filter criteria hasn't been met (no data) and application >> would never know about this connection. >> >> What I am not sure is what would be the state of the connection >> and state of the socket when in this situation. We do come here after >> finishing 3WHS but before handing this over to the application i.e. >> before the accept(). >> >> From uipc_socket.c: >> >> * From the passive side, a socket is created with two queues of sockets: >> * so_incomp for connections in progress and so_comp for connections already >> * made and awaiting user acceptance. As a protocol is preparing incoming >> * connections, it creates a socket structure queued on so_incomp by calling >> * sonewconn(). When the connection is established, soisconnected() is >> * called, and transfers the socket structure to so_comp, making it available >> * to accept(). >> >> So, it looks like the connection would be in ESTABLISHED state but >> socket would be stuck in the so_incomp queue. Other than this special >> condition of accpet_filter, can such a situation occur? >> >> Any insight/help into understanding this scenario and a way to cleanup >> these connections would be great. >> >> (I know tcp doesn't care/worry about idle sitting connections; we have >> keepalives to check the health of the connection but that's it, afaik) >> >> Cheers, >> Hiren From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:19:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 897B1E7; Mon, 27 Apr 2015 16:19:33 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B1EC19D8; Mon, 27 Apr 2015 16:19:33 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 7DAE3104837; Mon, 27 Apr 2015 09:19:32 -0700 (PDT) Date: Mon, 27 Apr 2015 09:19:32 -0700 From: hiren panchasara To: Adrian Chadd Cc: FreeBSD Net , Jason Wolfe , alfred@FreeBSD.org Subject: Re: Idle connections via accept_filter(9) Message-ID: <20150427161932.GW28632@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info> <20150427092236.GV28632@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="63tCqOYFH7xKgZE5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 16:19:33 -0000 --63tCqOYFH7xKgZE5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/27/15 at 09:10P, Adrian Chadd wrote: > ask alfred? :) Thanks! CCing him. >=20 >=20 > -a >=20 >=20 > On 27 April 2015 at 02:22, hiren panchasara = wrote: > > Wanted to see if someone with understanding of accept_filter can > > comment. > > > > cheers, > > Hiren > > On 04/09/15 at 09:08P, hiren panchasara wrote: > >> If a connections comes on a socket with accf_data(9) (for example) but > >> never sends any data, it'll occupy resources via staying forever in > >> listen queue of partial unaccepted connections (socket->so_incomp) whi= ch > >> can be seen as incqlen in 'netstat -Lan'. > >> Kernel will never pass this connection down to the application as > >> the filter criteria hasn't been met (no data) and application > >> would never know about this connection. > >> > >> What I am not sure is what would be the state of the connection > >> and state of the socket when in this situation. We do come here after > >> finishing 3WHS but before handing this over to the application i.e. > >> before the accept(). > >> > >> From uipc_socket.c: > >> > >> * From the passive side, a socket is created with two queues of socke= ts: > >> * so_incomp for connections in progress and so_comp for connections a= lready > >> * made and awaiting user acceptance. As a protocol is preparing inco= ming > >> * connections, it creates a socket structure queued on so_incomp by c= alling > >> * sonewconn(). When the connection is established, soisconnected() is > >> * called, and transfers the socket structure to so_comp, making it av= ailable > >> * to accept(). > >> > >> So, it looks like the connection would be in ESTABLISHED state but > >> socket would be stuck in the so_incomp queue. Other than this special > >> condition of accpet_filter, can such a situation occur? > >> > >> Any insight/help into understanding this scenario and a way to cleanup > >> these connections would be great. > >> > >> (I know tcp doesn't care/worry about idle sitting connections; we have > >> keepalives to check the health of the connection but that's it, afaik) > >> > >> Cheers, > >> Hiren > _______________________________________________ > 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" --63tCqOYFH7xKgZE5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVPmGUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/luncH/iEfBcL0GJ1DgC/mUnYeyLys FX/fSLs+SGE/BxXxRbg9kAg5om1QwtbyDMP2/RIfU6OmyXKS/DwxlpL2G46hlhCr 3P9kgOuJbcQI9ivIoozbN2fCSHWFiEClAJMlb8QjEIgqrr7rjDQ5Q/UZJle7WywY 7L1PYTfPg0AnN5Cl7X8kbrs3xeQdNfhGlJFqMMNdnFRLWFJakNWg8OrxL/WHGcQj EoLglgxIkhxMNFnG40lgLSA3OetIIAGoUBZGhinR0qjCopHrg+ATZzwMCvg2vJTP dY8uvEKJ41u7m7rFlx0f4soU6El2FzIPzfai7z6DWhXvlZ8tOEzvn32cMJVy7NE= =HJ12 -----END PGP SIGNATURE----- --63tCqOYFH7xKgZE5-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:33:22 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDB762A0 for ; Mon, 27 Apr 2015 16:33:22 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D89221BBF for ; Mon, 27 Apr 2015 16:33:22 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3RGXMiO006049 for ; Mon, 27 Apr 2015 16:33:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 180065] [netinet6] [patch] Multicast loopback to own host broken Date: Mon, 27 Apr 2015 16:33:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: feld@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 16:33:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180065 Mark Felder changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org, | |feld@FreeBSD.org, | |glebius@FreeBSD.org --- Comment #2 from Mark Felder --- ae, glebius -- you seem to be active in IPv6 / multicast somewhat recently I was alerted via Twitter that a user has been applying this patch for a few years. Is it still relevant? If so, can you help get this into the tree? It doesn't seem to apply cleanly to head a the moment -- perhaps due to your recent multicast work Thanks!! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:39:41 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B88973F7; Mon, 27 Apr 2015 16:39:41 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id A6D621C24; Mon, 27 Apr 2015 16:39:41 +0000 (UTC) Received: from [10.0.1.109] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 27F95341F868; Mon, 27 Apr 2015 09:39:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Idle connections via accept_filter(9) From: Alfred Perlstein X-Mailer: iPhone Mail (12F70) In-Reply-To: <20150427161932.GW28632@strugglingcoder.info> Date: Mon, 27 Apr 2015 09:39:40 -0700 Cc: Adrian Chadd , FreeBSD Net , "alfred@FreeBSD.org" , Jason Wolfe Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150410040834.GG61327@strugglingcoder.info> <20150427092236.GV28632@strugglingcoder.info> <20150427161932.GW28632@strugglingcoder.info> To: hiren panchasara X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 16:39:41 -0000 This is over 15 years old. I currently don't know of a great solution to thi= s problem. Might make sense to create a timer that runs and refs the socket t= hat will occasionally fire and cleanse out the old connections.=20 Shouldn't be that hard to do.=20 Sent from my iPhone > On Apr 27, 2015, at 9:19 AM, hiren panchasara = wrote: >=20 >> On 04/27/15 at 09:10P, Adrian Chadd wrote: >> ask alfred? :) >=20 > Thanks! CCing him. >>=20 >>=20 >> -a >>=20 >>=20 >>> On 27 April 2015 at 02:22, hiren panchasara = wrote: >>> Wanted to see if someone with understanding of accept_filter can >>> comment. >>>=20 >>> cheers, >>> Hiren >>>> On 04/09/15 at 09:08P, hiren panchasara wrote: >>>> If a connections comes on a socket with accf_data(9) (for example) but >>>> never sends any data, it'll occupy resources via staying forever in >>>> listen queue of partial unaccepted connections (socket->so_incomp) whic= h >>>> can be seen as incqlen in 'netstat -Lan'. >>>> Kernel will never pass this connection down to the application as >>>> the filter criteria hasn't been met (no data) and application >>>> would never know about this connection. >>>>=20 >>>> What I am not sure is what would be the state of the connection >>>> and state of the socket when in this situation. We do come here after >>>> finishing 3WHS but before handing this over to the application i.e. >>>> before the accept(). >>>>=20 >>>> =46rom uipc_socket.c: >>>>=20 >>>> * =46rom the passive side, a socket is created with two queues of socke= ts: >>>> * so_incomp for connections in progress and so_comp for connections alr= eady >>>> * made and awaiting user acceptance. As a protocol is preparing incomi= ng >>>> * connections, it creates a socket structure queued on so_incomp by cal= ling >>>> * sonewconn(). When the connection is established, soisconnected() is >>>> * called, and transfers the socket structure to so_comp, making it avai= lable >>>> * to accept(). >>>>=20 >>>> So, it looks like the connection would be in ESTABLISHED state but >>>> socket would be stuck in the so_incomp queue. Other than this special >>>> condition of accpet_filter, can such a situation occur? >>>>=20 >>>> Any insight/help into understanding this scenario and a way to cleanup >>>> these connections would be great. >>>>=20 >>>> (I know tcp doesn't care/worry about idle sitting connections; we have >>>> keepalives to check the health of the connection but that's it, afaik) >>>>=20 >>>> Cheers, >>>> Hiren >> _______________________________________________ >> 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 Apr 27 17:19:31 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2FFF134; Mon, 27 Apr 2015 17:19:31 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD05510EE; Mon, 27 Apr 2015 17:19:31 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 0B0AF104CD0; Mon, 27 Apr 2015 10:19:29 -0700 (PDT) Date: Mon, 27 Apr 2015 10:19:29 -0700 From: hiren panchasara To: Alfred Perlstein Cc: FreeBSD Net , Adrian Chadd , "alfred@FreeBSD.org" , Jason Wolfe Subject: Re: Idle connections via accept_filter(9) Message-ID: <20150427171929.GX28632@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info> <20150427092236.GV28632@strugglingcoder.info> <20150427161932.GW28632@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VxBmi9VgMIlnmxn8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 17:19:31 -0000 --VxBmi9VgMIlnmxn8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/27/15 at 09:39P, Alfred Perlstein wrote: > This is over 15 years old. I currently don't know of a great solution to = this problem. Might make sense to create a timer that runs and refs the soc= ket that will occasionally fire and cleanse out the old connections.=20 >=20 > Shouldn't be that hard to do.=20 Yeah, just wanted to make sure I wasn't missing anything obvious. Thanks fo= r your input. :-) Cheers, Hiren --VxBmi9VgMIlnmxn8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVPm+hXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lRmwH/iJqfQkl1/aceIuh3+KoZTZp u45RguqXskqDaqLtenuPwHhMnQOzozHTsEt0nCPEGFkg5YWXw+ddW2WVi08cziM2 +PKkm5MYowX9KlI9YNCSseZ4/Cpl6QdBhYm1wza2YBsBaie88aiXk5wWoOSd5RW1 lQJEml442DzsiRSBqGt19CbDNJJRA/h/lQ1TYlLsOu7nSSR6MvLIiusjrPzGmwdH 6nWC0T6fzvbQa1sl0P+7OnA8QJ1SbqSlyG9DNjIO0RgXzzzbZCLokgjCx61xvq9g 1ttx7lI/TYsv6Z4RnhV/T9rRAhYyea/hDcMiAgS/5wOkgu0Q8ApIL/JgC3GIWEc= =YKRs -----END PGP SIGNATURE----- --VxBmi9VgMIlnmxn8-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 17:43:40 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FB6199C for ; Mon, 27 Apr 2015 17:43:40 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 297DB145D for ; Mon, 27 Apr 2015 17:43:40 +0000 (UTC) Received: by labbd9 with SMTP id bd9so85720554lab.2 for ; Mon, 27 Apr 2015 10:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Alzxp+Uk6QFWT1F6IGvhLy/5QvE93muEC2EjUkbT/HM=; b=VSlJx9DDoDJh9t9lBjWBdl+STo6AjnNgo05AdRyb7Ufobo1+GFWCMHSY7Pay5JPw9l lVIod3qhNzUDahWcSz1cR0hoXG70P+NAS59iCbqWsvcYtjso0rzJU1t07yTtKNvELfec AuFh0ZgAwyBMuPkTtl0m38gJklYxHRwS3/Y/yiYtHW1ZD+eWzClwY/g1K40k/r19H8Oe t7UAGhDAfWEzPlZO4RD92LLK87lshrIf5Up/JzwQxAJEc+SXLiAY7VrzwZWwL4v4uk3p Yyxrmdj9aQla3TYCChz34H+vgPpZ4BCTnEXxoQQQXwWyYTaTke/FhdZcdGZm2ILZILqI UW4A== MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr11012287lab.82.1430156617103; Mon, 27 Apr 2015 10:43:37 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Mon, 27 Apr 2015 10:43:37 -0700 (PDT) Date: Mon, 27 Apr 2015 20:43:37 +0300 Message-ID: Subject: Calculating ACK arrival time From: Karlis Laivins To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 17:43:40 -0000 Hello, What would be the best (and easiest) way to calculate the arrival time (the time period that the ACK travels from receiver to sender of the ACK'ed data) for a NewReno ACK message? Can the h_ertt module be used to do it? Thank you in advance! Best Regards, Karlis From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 17:47:43 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96628B88 for ; Mon, 27 Apr 2015 17:47:43 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80C0D149B for ; Mon, 27 Apr 2015 17:47:43 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3RHlhQf012249 for ; Mon, 27 Apr 2015 17:47:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 180065] [netinet6] [patch] Multicast loopback to own host broken Date: Mon, 27 Apr 2015 17:47:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 27 Apr 2015 17:47:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180065 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org --- Comment #3 from Andrey V. Elsukov --- I'll take a look. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 00:51:31 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9526B40A for ; Tue, 28 Apr 2015 00:51:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8022B1707 for ; Tue, 28 Apr 2015 00:51:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3S0pVWT055918 for ; Tue, 28 Apr 2015 00:51:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199716] em doesn't increment adapter->rx_overruns in msix mode Date: Tue, 28 Apr 2015 00:51:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Apr 2015 00:51:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 09:18:12 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 453AE79E for ; Tue, 28 Apr 2015 09:18:12 +0000 (UTC) Received: from kerio.tuxis.nl (alcyone.saas.tuxis.net [31.3.111.19]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B899F1F0B for ; Tue, 28 Apr 2015 09:18:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:subject:date:message-id:to:mime-version:content-type; bh=x6+ydwUD6uXZn+DyVH3PMNjuNCvVg4NSjahWV3SNjuc=; b=EjIkDSDQnAPSNhjsEPwqeRs7hw9nQdxgceTCb6HtZsZdQlF2stnR/r6g6LQpioSbxVYPonro6BRUt D/wyQGTxZWDmFpLtl7LN5/UHWE+klmk6wEcACKQ15XqS9vr5d+GYuzKsSYB+nsykRib1nXSmXVKm7i 730aN59BlXAAmnHs2IBrPgD95vLWULr/6sgW218fAvpbFLDxbwxOE/R3Gx7Q6es3Beg6chA4uwfK58 ubQdJcZatffZq+hcwTqKfy9YuPkFKFco2bWHTeTbSE0Z52C1HnyKRt0D8Kod45XdGJJQCCiwpYKuVY 9A2EPN40NIt1D7jJmU+qdokau0MqgTg== X-Footer: dHV4aXMubmw= Received: from [31.3.104.222] ([31.3.104.222]) by kerio.tuxis.nl (Kerio Connect 8.5.0 beta 2) for freebsd-net@FreeBSD.org; Tue, 28 Apr 2015 10:47:56 +0200 Date: Tue, 28 Apr 2015 10:47:56 +0200 Subject: Frequent hickups on the networking layer X-Mailer: Kerio Connect 8.5.0 beta 2/Kerio Connect Client X-User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 Message-ID: <4281350517-9417@kerio.tuxis.nl> X-Priority: 3 Importance: Normal MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 From: Mark Schouten To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="=-bsmaSdRL1xgBlm7R8HAU" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Apr 2015 09:18:12 -0000 --=-bsmaSdRL1xgBlm7R8HAU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I've got a FreeBSD 10.1-RELEASE box running with iscsi on top of ZFS. I've = had some major issues with it where it would stop processing traffic for a = minute or two, but that's 'fixed' by disabling TSO. I do have frequent iscs= i errors, which are luckily fixed on the iscsi layer, but they do cause an = occasional errormessage on both the iscsi client and server. Also, I see in= put errors on the FreeBSD server, but I'm unable to find out what those are= . I do see a relation between iscsi-errormessages and the number of etherne= t inputerrors on the server. I saw this message [1] which made me have a look at `vmstat -z`, and that s= hows me the following: vmstat -z | head -n 1; vmstat -z | sort -k 6 -t , | tail -10 ITEM = SIZE LIMIT USED FREE REQ FAIL SLEEP zio_data_buf_942= 08: 94208, 0, 162, 5, 135632, 0, 0 zio_data_buf_98304= : 98304, 0, 118, 9, 101606, 0, 0 zio_link_cache: = 48, 0, 6, 30870,24853549414, 0, 0 8 Bucket: = 64, 0, 145, 2831,148672720, 11, 0 32 Bucket: = 256, 0, 859, 731,231513474, 52, 0 mbuf_jumbo_9k: = 9216, 604528, 7230, 2002,11764806459,108298123, 0 64 Bucket: = 512, 0, 808, 352,147120342,16375582, 0 256 Bucket: = 2048, 0, 500, 50,307051808,189685088, 0 vmem bta= g: 56, 0, 1671605, 1291509,198933250,36431, 0 128 Buck= et: 1024, 0, 410, 106,65267164,772374, 0=20 I am using jumboframes. Could it be that the inputerrors AND my frequent hi= ckups come from all those failures to allocate 9k jumbo mbufs? And can I in= crease the in [1] mentioned sysctls at will? Thanks [1]: https://lists.freebsd.org/pipermail/freebsd-questions/2013-August/2528= 27.html Met vriendelijke groeten, --=C2=A0 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl= --=-bsmaSdRL1xgBlm7R8HAU Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: Electronic Signature S/MIME Content-Transfer-Encoding: base64 MIIRwQYJKoZIhvcNAQcCoIIRsjCCEa4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDt4w ggUbMIIEA6ADAgECAhAsv+VdGX6YsSHI/WRu2j2JMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE0MDcwMTAwMDAwMFoXDTE1MDcwMTIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNbWFya0B0dXhpcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANHu3SxlMZOG5GA0/mqtRXR1QmWwhUXzmCIprI0IPtSBWSA31YBJ5qcmXRhLzaiTB3Fr UpIGkW5aAZnDms9DD64kasF3oZE00Fvfnj/BDGbw098px1PukKfg4hasbTaELAjQTSUj8xRSHzKk VVynvLA/YmyRT/+u3ueK4wdaxcej241xH6mNfZeiKMAvbkv6Tm9vdup0BtqqbRSKcnc01KKrspun Eh73jLIUhP21uJv8vuOTxS1I9zJSlhIcMCEapjBQ+26cQl+s+qBuAs/LP3UPVytSbxvicdhDxtqH npN2h3jJ/+J86zGfQi8bG7EamsULTGHkbgIJL9AdKZRgAKECAwEAAaOCAd0wggHZMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR+dMZE22X/SMCyTxYzIP+NMZBNXTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+BDW1hcmtA dHV4aXMubmwwDQYJKoZIhvcNAQEFBQADggEBAIB8FhqaML1EzfvgNwwHDC3k0ICeMerOncgee6uJ KLxwU2mstttX5jtAmgK9RuDOu+TrMkkpF2yxYMTPpSM8nL7r+N/kdogu5Bustol8WTsW1e5vs+Nh hJYFORk113ouur1kSjXuHF8TWy+/PjFJBS/xm/H+/fkghppRU+4Dj2IReUBvlexAPYr4VDxjV7AD xPOXqTQkP15LWGvhTz2YVbJ3IAVOyUNkRhr9QwzToUxXa9k/QAOpXMuvS74AT2RBV/YCEEx7ebRD MAR6lZcbYiV8sXv1ASbnMdO3Fh2F98g+5rJn5PfFH8qLpapsZx0I2/axtSG09QMDJqXd3Ab6NpEw ggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hf ZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrh o/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0 mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MP bXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRc WzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwu dXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwu Y3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29t L1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ 9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1 ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B 080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAg TmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5 MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p 1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K 2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bU MSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjK aJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0 tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDeg NYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUG CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1 ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj 2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTGCAqswggKnAgEBMIGo MIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAsv+VdGX6YsSHI/WRu2j2JMAkG BSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw NDI4MDg0NzU2WjAjBgkqhkiG9w0BCQQxFgQUGdIwd6hK6gbumiIVPbwpeV0uqBMweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAS9xePyeja/v7pON5QTZLZOhTuUP8oTG2cZJfMkv5IHrTJE627D/+ YuzN6MPqSDYL/xxkgTfpoS2SuFeToVnx2DRkszvhwNKTLi4AQ5+4zt9B3V3LSMB0HQHVF8C/dg7i B/2vhvdDI0WnQ9oWmfRJKPZwPdZY9/y3NlhJUNy07JcZeEsYKkoSa25NzENTbUlYwcHnn0fS9c05 yezlug7HdvvmismieUW8KJpAl25psjVh1IPwbagGc0iPjMi5HcB/mdT1NHSDRUjsXUui0n/eb2DU lLmSbdO7ZOZKg56XZerdk0I21uANUQWoc4jHiggzlIJd7JR9oajwRKyMUbFmAw== --=-bsmaSdRL1xgBlm7R8HAU-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 12:19:47 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61CDDE0E for ; Tue, 28 Apr 2015 12:19:47 +0000 (UTC) Received: from kerio.tuxis.nl (alcyone.saas.tuxis.net [31.3.111.19]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D32B514AF for ; Tue, 28 Apr 2015 12:19:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to; bh=719STld2F1N+GMoqctQpcGBo/Et8GRVn5mnCLebUzf4=; b=r2G49DYRm4QUuuQNUZamRC6SdrS+3IkLnE69dHfFiAY6O1ZMtamwm3mdLGpmshjh2mivvS65DkuFH QqKt9S/nSDgLrZ+Z4NxSsLe9VWHsG26QLsEyeR8Twvq+vrpZKpOQpTp1Y5h8tVRucvSKwviRHW9oUR xpu3Sth6nzHL9rBU9i1ABYq/1Bnlfg25ADPCzGnSkJFKDacvmiMt8TQadGjpMiCB/aKZhQO6vATt2a vf7tHqwIBywkya0kUjP8dEOn26ISXzAuVz0afne5dixTxP7T5D0aQSJqNHv7PnsLlIljwLMWsyvJmD sh+kVm9c2MoaugyQ79oX4zyXRJ+CMgA== X-Footer: dHV4aXMubmw= Received: from [31.3.104.222] ([31.3.104.222]) by kerio.tuxis.nl (Kerio Connect 8.5.0 beta 2) for cforgeron@acsi.ca; Tue, 28 Apr 2015 14:19:34 +0200 Date: Tue, 28 Apr 2015 14:19:34 +0200 Subject: Re: Frequent hickups on the networking layer X-Mailer: Kerio Connect 8.5.0 beta 2/Kerio Connect Client X-User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 Message-ID: <4294293883-7795@kerio.tuxis.nl> X-Priority: 3 Importance: Normal In-Reply-To: <46D80686C389884BB0C047851038EC4501C98541EB@AA-EX0.acsi.ca> MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 From: Mark Schouten To: Chris Forgeron , "freebsd-net@FreeBSD.org" MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="=-0J1G8JZsM31y1lJuUDfE" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Apr 2015 12:19:47 -0000 --=-0J1G8JZsM31y1lJuUDfE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've disabled TSO a while ago, after my networking stopped working complete= ly, with `ifconfig em0 -tso`. em0: flags=3D8843 metric 0 mtu 9000 options=3D4209b ether 00:25:90:dc:0f:a2 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active nfsv212: flags=3D8843 metric 0 mtu = 1500 options=3D3 ether 00:25:90:dc:0f:a2 inet6 fe80::225:90ff:fedc:fa2%nfsv212 prefixlen 64 scopeid 0x6=C2=A0 inet6 fd::212:31:3:111:fffe prefixlen 64=C2=A0 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active vlan: 212 parent interface: em0 nfsv308: flags=3D8843 metric 0 mtu = 9000 options=3D3 ether 00:25:90:dc:0f:a2 inet 10.38.0.253 netmask 0xffffff00 broadcast 10.38.0.255=C2=A0 inet6 fe80::225:90ff:fedc:fa2%nfsv308 prefixlen 64 scopeid 0x8=C2=A0 inet6 fd:308::30 prefixlen 64=C2=A0 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active vlan: 308 parent interface: em0 Or should I disable VLAN_HWTSO as well. If so, how? Met vriendelijke groeten, --=C2=A0 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl Van: Chris Forgeron =20 Aan: Mark Schouten , "freebsd-net@FreeBSD.org" =20 Verzonden: 28-4-2015 13:58=20 Onderwerp: RE: Frequent hickups on the networking layer=20 What network care are you using?=20 =20 There have been a few reports of issues with TSO, if you check the list. I = had some myself a while ago, but are now resolved thanks to a few helpful f= olk here.=20 =20 You could increase your mbufs, but if the problem is a leak/error in the st= ack, then you're just delaying the behaviour. =20 =20 -----Original Message-----=20 From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Mark Schouten=20 Sent: Tuesday, April 28, 2015 5:48 AM=20 To: freebsd-net@FreeBSD.org=20 Subject: Frequent hickups on the networking layer=20 =20 Hi,=20 =20 =20 I've got a FreeBSD 10.1-RELEASE box running with iscsi on top of ZFS. I've = had some major issues with it where it would stop processing traffic for a = minute or two, but that's 'fixed' by disabling TSO. I do have frequent iscs= i errors, which are luckily fixed on the iscsi layer, but they do cause an = occasional errormessage on both the iscsi client and server. Also, I see in= put errors on the FreeBSD server, but I'm unable to find out what those are= . I do see a relation between iscsi-errormessages and the number of etherne= t inputerrors on the server.=20 =20 =20 I saw this message [1] which made me have a look at `vmstat -z`, and that s= hows me the following:=20 =20 =20 vmstat -z | head -n 1; vmstat -z | sort -k 6 -t , | tail -10 ITEM =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SIZE =C2=A0LIMIT = =C2=A0 =C2=A0 USED =C2=A0 =C2=A0 FREE =C2=A0 =C2=A0 =C2=A0REQ FAIL SLEEP zi= o_data_buf_94208: =C2=A0 94208, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0 162, = =C2=A0 =C2=A0 =C2=A0 5, =C2=A0135632, =C2=A0 0, =C2=A0 0 zio_data_buf_98304= : =C2=A0 98304, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0 118, =C2=A0 =C2=A0 =C2= =A0 9, =C2=A0101606, =C2=A0 0, =C2=A0 0 zio_link_cache: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A048, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0 =C2=A0 6, =C2=A0 = 30870,24853549414, =C2=A0 0, =C2=A0 0 8 Bucket: =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A064, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0 145, = =C2=A0 =C2=A02831,148672720, =C2=A011, =C2=A0 0 32 Bucket: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0256, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0= 859, =C2=A0 =C2=A0 731,231513474, =C2=A052, =C2=A0 0 mbuf_jumbo_9k: =C2=A0= =C2=A0 =C2=A0 =C2=A0 9216, 604528, =C2=A0 =C2=A07230, =C2=A0 =C2=A02002,11= 764806459,108298123, =C2=A0 0 64 Bucket: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0512, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0 808, =C2=A0 =C2=A0 = 352,147120342,16375582, =C2=A0 0 256 Bucket: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A02048, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0 500, =C2=A0 =C2=A0 = =C2=A050,307051808,189685088, =C2=A0 0 vmem btag: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 56, =C2=A0 =C2=A0 =C2=A00, 1671605, 1291509,198933= 250,36431, =C2=A0 0 128 Bucket: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010= 24, =C2=A0 =C2=A0 =C2=A00, =C2=A0 =C2=A0 410, =C2=A0 =C2=A0 106,65267164,77= 2374, =C2=A0 0 =20 =20 =20 I am using jumboframes. Could it be that the inputerrors AND my frequent hi= ckups come from all those failures to allocate 9k jumbo mbufs? And can I in= crease the in [1] mentioned sysctls at will?=20 =20 =20 Thanks=20 =20 =20 =20 =20 =20 =20 [1]: https://lists.freebsd.org/pipermail/freebsd-questions/2013-August/2528= 27.html=20 =20 =20 Met vriendelijke groeten,=20 =20 --=C2=A0=20 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/=20 Mark Schouten =C2=A0| Tuxis Internet Engineering=20 KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/=20 T: 0318 200208 | info@tuxis.nl=20 = --=-0J1G8JZsM31y1lJuUDfE Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: Electronic Signature S/MIME Content-Transfer-Encoding: base64 MIIRwQYJKoZIhvcNAQcCoIIRsjCCEa4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDt4w ggUbMIIEA6ADAgECAhAsv+VdGX6YsSHI/WRu2j2JMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE0MDcwMTAwMDAwMFoXDTE1MDcwMTIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNbWFya0B0dXhpcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANHu3SxlMZOG5GA0/mqtRXR1QmWwhUXzmCIprI0IPtSBWSA31YBJ5qcmXRhLzaiTB3Fr UpIGkW5aAZnDms9DD64kasF3oZE00Fvfnj/BDGbw098px1PukKfg4hasbTaELAjQTSUj8xRSHzKk VVynvLA/YmyRT/+u3ueK4wdaxcej241xH6mNfZeiKMAvbkv6Tm9vdup0BtqqbRSKcnc01KKrspun Eh73jLIUhP21uJv8vuOTxS1I9zJSlhIcMCEapjBQ+26cQl+s+qBuAs/LP3UPVytSbxvicdhDxtqH npN2h3jJ/+J86zGfQi8bG7EamsULTGHkbgIJL9AdKZRgAKECAwEAAaOCAd0wggHZMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR+dMZE22X/SMCyTxYzIP+NMZBNXTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+BDW1hcmtA dHV4aXMubmwwDQYJKoZIhvcNAQEFBQADggEBAIB8FhqaML1EzfvgNwwHDC3k0ICeMerOncgee6uJ KLxwU2mstttX5jtAmgK9RuDOu+TrMkkpF2yxYMTPpSM8nL7r+N/kdogu5Bustol8WTsW1e5vs+Nh hJYFORk113ouur1kSjXuHF8TWy+/PjFJBS/xm/H+/fkghppRU+4Dj2IReUBvlexAPYr4VDxjV7AD xPOXqTQkP15LWGvhTz2YVbJ3IAVOyUNkRhr9QwzToUxXa9k/QAOpXMuvS74AT2RBV/YCEEx7ebRD MAR6lZcbYiV8sXv1ASbnMdO3Fh2F98g+5rJn5PfFH8qLpapsZx0I2/axtSG09QMDJqXd3Ab6NpEw ggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hf ZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrh o/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0 mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MP bXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRc WzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwu dXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwu Y3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29t L1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ 9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1 ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B 080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAg TmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5 MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p 1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K 2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bU MSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjK aJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0 tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDeg NYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUG CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1 ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj 2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTGCAqswggKnAgEBMIGo MIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAsv+VdGX6YsSHI/WRu2j2JMAkG BSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw NDI4MTIxOTM0WjAjBgkqhkiG9w0BCQQxFgQUf6rnm6ptwBbG18Tr2mA2o9HBOBgweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAk/ungwBOWatVqg79H0PSLGfgCNDk5Lh2FzRpMpqJlfyq+MBBCywd X8uN6CUWWa6D8qMXDVjA8O1ta3D2OlX2LqTVa2XGl9vRJNos1Vf4tNSUMZ4coEKrMfl00fproSVq 2sp2LqeDgfR4GOyqc1ViYPM5MdFc/xXfQcldIfF/g+1DYHQS4ba2oeB9r0R56cpAmWxOGzOUX3Kd JzJ45K8E+hmItVWYHj6g1CyVvoYup2tXr1XJw38g/nKyBp+jqTkmRDmGztz0wJfoopVF8wryBele HQsWE0XhXRFkaRH1lDkVpMuJvojvZVj/37OymdZY9Qr2V4wV/hJV1fQEmezlyQ== --=-0J1G8JZsM31y1lJuUDfE-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 21:06:10 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9C645DB; Tue, 28 Apr 2015 21:06:10 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 61D1916C8; Tue, 28 Apr 2015 21:06:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CWBwBj9T9V/95baINcg19cBYMVxVMMgjGDUQKBdxEBAQEBAQEBgQqEIAEBAQMBAQIgTwcFFhgCAg0ZAiovBhOIIwgNsz6UBQEBAQEBAQEDAQEBAQEBAQEagSGKF4QiCwYBBhcBMweCLTsSgTMFlWmEC1+CdJB5g1AjgWWCKyIxAYECCBcigQEBAQE X-IronPort-AV: E=Sophos;i="5.11,666,1422939600"; d="scan'208";a="208465198" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 28 Apr 2015 17:06:02 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6493DB3F94; Tue, 28 Apr 2015 17:06:02 -0400 (EDT) Date: Tue, 28 Apr 2015 17:06:02 -0400 (EDT) From: Rick Macklem To: Mark Schouten Cc: freebsd-net@FreeBSD.org, Garrett Wollman Message-ID: <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> In-Reply-To: <4281350517-9417@kerio.tuxis.nl> Subject: Re: Frequent hickups on the networking layer MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 28 Apr 2015 21:06:10 -0000 Mark Schouten wrote: > Hi, >=20 >=20 > I've got a FreeBSD 10.1-RELEASE box running with iscsi on top of ZFS. > I've had some major issues with it where it would stop processing > traffic for a minute or two, but that's 'fixed' by disabling TSO. I > do have frequent iscsi errors, which are luckily fixed on the iscsi > layer, but they do cause an occasional errormessage on both the > iscsi client and server. Also, I see input errors on the FreeBSD > server, but I'm unable to find out what those are. I do see a > relation between iscsi-errormessages and the number of ethernet > inputerrors on the server. >=20 >=20 > I saw this message [1] which made me have a look at `vmstat -z`, and > that shows me the following: >=20 >=20 > vmstat -z | head -n 1; vmstat -z | sort -k 6 -t , | tail -10 ITEM > SIZE LIMIT USED FREE REQ FAIL SLEEP > zio_data_buf_94208: 94208, 0, 162, 5, 135632, 0, > 0 zio_data_buf_98304: 98304, 0, 118, 9, 101606, > 0, 0 zio_link_cache: 48, 0, 6, > 30870,24853549414, 0, 0 8 Bucket: 64, 0, > 145, 2831,148672720, 11, 0 32 Bucket: 256, > 0, 859, 731,231513474, 52, 0 mbuf_jumbo_9k: > 9216, 604528, 7230, 2002,11764806459,108298123, 0 64 > Bucket: 512, 0, 808, > 352,147120342,16375582, 0 256 Bucket: 2048, 0, > 500, 50,307051808,189685088, 0 vmem btag: > 56, 0, 1671605, 1291509,198933250,36431, 0 128 > Bucket: 1024, 0, 410, 106,65267164,772374, > 0 >=20 >=20 > I am using jumboframes. Could it be that the inputerrors AND my > frequent hickups come from all those failures to allocate 9k jumbo > mbufs? There have been email list threads discussing how allocating 9K jumbo mbufs will fragment the KVM (kernel virtual memory) used for mbuf cluster allocation and cause grief. If your net device driver is one that allocates 9K jumbo mbufs for receive instead of using a list of smaller mbuf clusters, I'd guess this is what is biting you. As far as I know (just from email discussion, never used them myself), you can either stop using jumbo packets or switch to a different net interface that doesn't allocate 9K jumbo mbufs (doing the receives of jumbo packets into a list of smaller mbuf clusters). I remember Garrett Wollman arguing that 9K mbuf clusters shouldn't ever be used. I've cc'd him, in case he wants to comment. I don't know how to increase the KVM that the allocator can use for 9K mbuf clusters nor do I know if that can be used as a work around. rick > And can I increase the in [1] mentioned sysctls at will? >=20 >=20 > Thanks >=20 >=20 >=20 >=20 >=20 >=20 > [1]: > https://lists.freebsd.org/pipermail/freebsd-questions/2013-August/252827.= html >=20 >=20 > Met vriendelijke groeten, >=20 > -- > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > Mark Schouten | Tuxis Internet Engineering > KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ > T: 0318 200208 | info@tuxis.nl From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 05:08:04 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAA56441 for ; Wed, 29 Apr 2015 05:08:04 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 687D317C8 for ; Wed, 29 Apr 2015 05:08:04 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id t3T581RE047109; Wed, 29 Apr 2015 01:08:01 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id t3T580cr047106; Wed, 29 Apr 2015 01:08:00 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21824.26416.855441.21454@hergotha.csail.mit.edu> Date: Wed, 29 Apr 2015 01:08:00 -0400 From: Garrett Wollman To: Rick Macklem Cc: Mark Schouten , freebsd-net@FreeBSD.org Subject: Re: Frequent hickups on the networking layer In-Reply-To: <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> References: <4281350517-9417@kerio.tuxis.nl> <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 29 Apr 2015 01:08:01 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 05:08:04 -0000 < said: > There have been email list threads discussing how allocating 9K jumbo > mbufs will fragment the KVM (kernel virtual memory) used for mbuf > cluster allocation and cause grief. The problem is not KVA fragmentation -- the clusters come from a separate map which should prevent that -- it's that clusters have to be physically contiguous, and an active machine is going to have trouble with that. The fact that 9k is a goofy size (two pages plus a little bit) doesn't help matters. The other side, as Neel and others have pointed out, is that it's beneficial for the hardware to have a big chunk of physically contiguous memory to dump packets into, especially with various kinds of receive-side offloading. I see two solutions to this, but don't have the time or resources (or, frankly, the need) to implement them (and both are probably required for different situations): 1) Reserve a big chunk of physical memory early on for big clusters. How much this needs to be will depend on the application and the particular network interface hardware, but you should be thinking in terms of megabytes or (on a big server) gigabytes. Big enough to be mapped as superpages on hardware where that's beneficial. If you have aggressive LRO, "big clusters" might be 64k or larger in size. 2) Use the IOMMU -- if it's available, which it won't be when running under a hypervisor that's already using it for passthrough -- to obviate the need for physically contiguous pages; then the problem reduces to KVA fragmentation, which is easier to avoid in the allocator. > As far as I know (just from email discussion, never used them myself), > you can either stop using jumbo packets or switch to a different net > interface that doesn't allocate 9K jumbo mbufs (doing the receives of > jumbo packets into a list of smaller mbuf clusters). Or just hack the driver to not use them. For the Intel drivers this is easy, and at least for the hardware I have there's no benefit to using 9k clusters over 4k; for Chelsio it's quite a bit harder. -GAWollman From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 05:17:11 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B534A561 for ; Wed, 29 Apr 2015 05:17:11 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8496818BC for ; Wed, 29 Apr 2015 05:17:11 +0000 (UTC) Received: by pdbqd1 with SMTP id qd1so17542762pdb.2 for ; Tue, 28 Apr 2015 22:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=bP0amH/KpEeruTjsNlv9BIv78kCP+53WG6GJkPPcEnQ=; b=U6bTUTAiQJVeUBNrXAn5YZ7AKkRXVFNPTuI5okDogD9pQDXH6U6GgVVZTMIVyJcBK4 aXdpDErfSDgtZU8DVzQ/4VhGPz1+nKCSfOi1OAEoWMydjrfOdo/4rXRkngwa3I3K8dYN i50UCLSLpLyposQE7CuO4NTwf7EkWqbY27MCOtK5POGm0b+OHxz6tWubm7/MqnZN7KC6 4rgRBjQ54cNz8fH9PwSoCDixNUIyBzzPGChx5q8ETgGERAPQrHGV2qJaeidsgkQf5sAD 735dVgJR2IGp/tTu5oanZLObOxZzRpIAyhlhrJzNKJPQAN3f/8mGR9HlOp2Aci7G/Pb3 zT6w== X-Received: by 10.68.125.130 with SMTP id mq2mr38054133pbb.121.1430284631081; Tue, 28 Apr 2015 22:17:11 -0700 (PDT) Received: from nparhar-pc (c-24-6-44-228.hsd1.ca.comcast.net. [24.6.44.228]) by mx.google.com with ESMTPSA id ho10sm16348016pbc.27.2015.04.28.22.17.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 22:17:09 -0700 (PDT) Date: Tue, 28 Apr 2015 22:16:59 -0700 From: Navdeep Parhar To: Garrett Wollman Cc: Rick Macklem , freebsd-net@FreeBSD.org, Mark Schouten Subject: Re: Frequent hickups on the networking layer Message-ID: <20150429051659.GA2180@nparhar-pc> Mail-Followup-To: Garrett Wollman , Rick Macklem , freebsd-net@FreeBSD.org, Mark Schouten References: <4281350517-9417@kerio.tuxis.nl> <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> <21824.26416.855441.21454@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21824.26416.855441.21454@hergotha.csail.mit.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 05:17:11 -0000 On Wed, Apr 29, 2015 at 01:08:00AM -0400, Garrett Wollman wrote: > < said: ... > > As far as I know (just from email discussion, never used them myself), > > you can either stop using jumbo packets or switch to a different net > > interface that doesn't allocate 9K jumbo mbufs (doing the receives of > > jumbo packets into a list of smaller mbuf clusters). > > Or just hack the driver to not use them. For the Intel drivers this > is easy, and at least for the hardware I have there's no benefit to > using 9k clusters over 4k; for Chelsio it's quite a bit harder. Quite a bit harder, and entirely unnecessary these days. Recent versions of the Chelsio driver will fall back to 4K clusters automatically (and on the fly) if the system is short of 9K clusters. There are even tunables that will let you set 4K as the only cluster size that the driver should allocate. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 06:27:46 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 031D51BC for ; Wed, 29 Apr 2015 06:27:46 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6FB21FC0 for ; Wed, 29 Apr 2015 06:27:45 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t3T6RSOC001752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 23:27:28 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t3T6RSCL001751; Tue, 28 Apr 2015 23:27:28 -0700 (PDT) (envelope-from jmg) Date: Tue, 28 Apr 2015 23:27:28 -0700 From: John-Mark Gurney To: Garrett Wollman , Rick Macklem , freebsd-net@FreeBSD.org, Mark Schouten Subject: Re: Frequent hickups on the networking layer Message-ID: <20150429062728.GI37063@funkthat.com> References: <4281350517-9417@kerio.tuxis.nl> <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> <21824.26416.855441.21454@hergotha.csail.mit.edu> <20150429051659.GA2180@nparhar-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150429051659.GA2180@nparhar-pc> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 28 Apr 2015 23:27:29 -0700 (PDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 06:27:46 -0000 Navdeep Parhar wrote this message on Tue, Apr 28, 2015 at 22:16 -0700: > On Wed, Apr 29, 2015 at 01:08:00AM -0400, Garrett Wollman wrote: > > < said: > ... > > > As far as I know (just from email discussion, never used them myself), > > > you can either stop using jumbo packets or switch to a different net > > > interface that doesn't allocate 9K jumbo mbufs (doing the receives of > > > jumbo packets into a list of smaller mbuf clusters). > > > > Or just hack the driver to not use them. For the Intel drivers this > > is easy, and at least for the hardware I have there's no benefit to > > using 9k clusters over 4k; for Chelsio it's quite a bit harder. > > Quite a bit harder, and entirely unnecessary these days. Recent > versions of the Chelsio driver will fall back to 4K clusters > automatically (and on the fly) if the system is short of 9K clusters. > There are even tunables that will let you set 4K as the only cluster > size that the driver should allocate. Can we get this to be the default? and included in more drivers too? -- 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 Wed Apr 29 06:37:23 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 867DF49C for ; Wed, 29 Apr 2015 06:37:23 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F51D10B4 for ; Wed, 29 Apr 2015 06:37:23 +0000 (UTC) Received: by igblo3 with SMTP id lo3so39828227igb.0 for ; Tue, 28 Apr 2015 23:37:22 -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=pfoRuQjHnb7EJ9LTM59QPJwrdcAe9Vq3zrH5v98z2bY=; b=VfV6Hp1zNIjZUFAWvBnHqcKGzLykYEMIS2K3n78bR2uSAgS00aK5p6WAmM5Swzrcxj lTErwcTmoRKKcCTLgaTwaPKJWfV/kmD603kB4AWk+27SN/4guE+HVvRCuktFHAg8BRR0 TVGoJGquEREt/amWggX6CN5b9VeuDQsIOwjN+BC7/ndXGaPsjXCeUPYrt//u4AtRnnqb esWm2peaHfP9gACoj0SF9fBz8asarZOpQDuiMzBaw6KF5ef7VWWYqO9NC9pw3FjhUrq8 yJ2ddNyVp5iyQyk7KF3kxrOoOxxPmBr23gV6Kkpg8Sne7cHPahYg7/ZAjpeW4sxXCYwX kEUw== MIME-Version: 1.0 X-Received: by 10.42.20.197 with SMTP id h5mr1833898icb.22.1430289442740; Tue, 28 Apr 2015 23:37:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Tue, 28 Apr 2015 23:37:22 -0700 (PDT) In-Reply-To: <21824.26416.855441.21454@hergotha.csail.mit.edu> References: <4281350517-9417@kerio.tuxis.nl> <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> <21824.26416.855441.21454@hergotha.csail.mit.edu> Date: Tue, 28 Apr 2015 23:37:22 -0700 X-Google-Sender-Auth: 9xv6cnHIUaOHWW4RFjcbckj3RXY Message-ID: Subject: Re: Frequent hickups on the networking layer From: Adrian Chadd To: Garrett Wollman Cc: Rick Macklem , FreeBSD Net , Mark Schouten Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 06:37:23 -0000 I've spoken to more than one company about this stuff and their answers are all the same: "we ignore the freebsd allocator, allocate a very large chunk of memory at boot, tell the VM it plainly just doesn't exist, and abuse it via the direct map." That gets around a lot of things, including the "oh how can we get 9k allocations if we can't find contiguous memory/KVA/either" problem - you just treat it as an array of 9k pages (or I'm guessing much larger - as you said, like ~ 64k), and allocate that way. That way there's no fragmentation to worry about - everything's just using a custom slab allocator for these large allocation sizes. It's kind of tempting to suggest freebsd support such a thing, as I can see increasing requirements for specialised applications that want this. One of the things that makes netmap so nice is it 100% avoids the allocators in the hot path - it grabs a big chunk of memory and allocates slots out of that via a bitmap and index values. -adrian From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 07:30:41 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57FD8FAA; Wed, 29 Apr 2015 07:30:41 +0000 (UTC) Received: from kerio.tuxis.nl (alcyone.saas.tuxis.net [31.3.111.19]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B739016C1; Wed, 29 Apr 2015 07:30:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=/9G5XxzKWELeo+I+7Y0pFQQmIraoAli5Il6LEYnjnTY=; b=R6/FC0hm/7dKCdVwvT4/ldYU3laEj0Tcksu3tHBtQqSTVi7Zdae0INYpuhe2ytVbefS1xkwhZz1Y1 ltG8mWZx38NeKJvcgbkbzbRcdcyo0RcZimGW4b0wYb2sNXd1Hl9adbVLOP8lMB4pDmVwegnzuE0ZVn 5O1pKvGWNmRxk1eO8pEwX/QYq0pjzyaXvxO924q5jTFo5ZLxdGSYZ0XvQkpMWja9dKjlR94AphYNHt esq45Lw4EVJQkwibvHNEcp53B49eUbWFJG1akUq6CBE3sqmrqQZQuT+01GnQ9lJhXbQ+uxCzFtiuPc xKYI3fTToTQO0bYyxWHzwBEWiebuxfA== X-Footer: dHV4aXMubmw= Received: from [31.3.104.222] ([31.3.104.222]) (authenticated user mark@tuxis.nl) by kerio.tuxis.nl (Kerio Connect 8.5.0 beta 2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Wed, 29 Apr 2015 09:30:34 +0200 Message-ID: <5540889A.5030904@tuxis.nl> Date: Wed, 29 Apr 2015 09:30:34 +0200 From: Mark Schouten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Rick Macklem CC: freebsd-net@FreeBSD.org, Garrett Wollman Subject: Re: Frequent hickups on the networking layer References: <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> In-Reply-To: <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 07:30:41 -0000 Hi, On 04/28/2015 11:06 PM, Rick Macklem wrote: > There have been email list threads discussing how allocating 9K jumbo > mbufs will fragment the KVM (kernel virtual memory) used for mbuf > cluster allocation and cause grief. If your > net device driver is one that allocates 9K jumbo mbufs for receive > instead of using a list of smaller mbuf clusters, I'd guess this is > what is biting you. I'm not really (or really not) comfortable with hacking and recompiling stuff. I'd rather not change anything in the kernel. So would it help in my case to lower my MTU from 9000 to 4000? If I understand correctly, this would need to allocate chunks of 4k, which is far more logical from a memory point of view? Mark From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 09:52:00 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C894E09 for ; Wed, 29 Apr 2015 09:52:00 +0000 (UTC) Received: from SNT004-OMC4S4.hotmail.com (snt004-omc4s4.hotmail.com [65.55.90.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED27C1771 for ; Wed, 29 Apr 2015 09:51:59 +0000 (UTC) Received: from SNT148-W50 ([65.55.90.199]) by SNT004-OMC4S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 29 Apr 2015 02:50:53 -0700 X-TMN: [q8h4H74C1lUjk+igZN5v+ohDfT7K3Hsg] X-Originating-Email: [ch.xd@live.cn] Message-ID: From: ChenXiaodong To: "net@freebsd.org" Subject: netmap: Does netmap support linux kernel 2.6.32 ? Date: Wed, 29 Apr 2015 17:50:53 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2015 09:50:53.0482 (UTC) FILETIME=[FB6408A0:01D08261] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 09:52:00 -0000 SGksIA0KDQpJIGNhbm5vdCByZWNlaXZlIHBhY2tldHMgdXNpbmcgbmV0bWFwIGNvbXBsaWVkIGZv ciBsaW51eCBrZXJuZWwgMi42LjMyLnh4eC4gSSB0cmllZCBvbiBDZW50T1MgNi41LCBSZWRoYXQg YW5kIERlYmlhbiwgYm90aCBvZiB3aGljaCBhcmUgYmFzZWQgb24gbGludXgga2VybmVsIDIuNi4z Mi54eHguIE5vbmUgb2YgdGhlbSB3b3Jrcy4gSXMgTGludXggMi42LjMyIHRvbyBvbGQgdG8gbmV0 bWFwID8NCg0KDQpUaGlzIGlzIHRoZSB0ZXN0IGNvZGUgSSB1c2VkIC4gSXQgaXMgY29waWVkIGZy b20gbmV0bWFwJ3MgbWFuIHBhZ2UuIFRoZSBwcm9ncmFtIHN0b3BzIGF0IHRoZSBjYWxsIHRvICdw b2xsJyBhbmQgbmV2ZXIgcmV0dXJuLg0KDQppbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3Yp DQp7DQogICAgKHZvaWQpIGFyZ2M7DQogICAgKHZvaWQpIGFyZ3Y7DQoNCiAgICBzdHJ1Y3Qgbm1f ZGVzYyAqZDsNCiAgICBzdHJ1Y3QgcG9sbGZkIGZkczsNCiAgICB1X2NoYXIgKmJ1ZjsNCiAgICBz dHJ1Y3Qgbm1fcGt0aGRyIGg7DQogICAgZCA9IG5tX29wZW4oIm5ldG1hcDpldGgwIiwgTlVMTCwg MCwgMCk7DQogICAgZmRzLmZkID0gTkVUTUFQX0ZEKGQpOw0KICAgIGZkcy5ldmVudHMgPSBQT0xM SU47DQogICAgZm9yICg7Oykgew0KICAgICAgICBwb2xsKCZmZHMsIDEsIC0xKTsNCiAgICAgICAg d2hpbGUgKCAoYnVmID0gbm1fbmV4dHBrdChkLCAmaCkpICkgew0KICAgICAgICAgICAgcHJpbnRm KCJwYWNrZXQgJWRcbiIsIGgubGVuKTsNCiAgICAgICAgICAgIHByaW50ZigiICBkbWFjOiAlMDJ4 OiUwMng6JTAyeDolMDJ4OiUwMng6JTAyeCIsDQogICAgICAgICAgICAgICAgICAgIGJ1ZlswXSwg YnVmWzFdLCBidWZbMl0sIGJ1ZlszXSwgYnVmWzRdLCBidWZbNV0pOw0KICAgICAgICAgICAgYnVm ICs9IDY7DQogICAgICAgICAgICBwcmludGYoIiA8LSBzbWFjOiAlMDJ4OiUwMng6JTAyeDolMDJ4 OiUwMng6JTAyeFxuIiwNCiAgICAgICAgICAgICAgICAgICAgYnVmWzBdLCBidWZbMV0sIGJ1Zlsy XSwgYnVmWzNdLCBidWZbNF0sIGJ1Zls1XSk7DQogICAgICAgIH0NCiAgICB9DQogICAgbm1fY2xv c2UoZCk7DQogICAgcmV0dXJuIDA7DQp9DQoNClRoYW5rcyEgSSBkbyBhcHByZWNpYXRlIHlvdXIg cmVwbHkhDQoNCi9DaGVuWGlhb2RvbmcNCiAJCSAJICAgCQkgIA== From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 09:52:02 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96901E0A for ; Wed, 29 Apr 2015 09:52:02 +0000 (UTC) Received: from smtp2.mail.clearhost.co.uk (smtp2.mail.clearhost.co.uk [IPv6:2001:1420::25:102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.mail.clearhost.co.uk", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 612401772 for ; Wed, 29 Apr 2015 09:52:02 +0000 (UTC) Received: from [2001:1420:a:104::1:35] (port=52028) by smtp2.mail.clearhost.co.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1YnOet-000D4N-K4 for freebsd-net@freebsd.org; Wed, 29 Apr 2015 09:51:59 +0000 Message-ID: <5540A9BF.2090003@prt.org> Date: Wed, 29 Apr 2015 10:51:59 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Frequent hickups on the networking layer References: <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> In-Reply-To: <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 09:52:02 -0000 Hi, On 28/04/2015 22:06, Rick Macklem wrote: > ... If your > net device driver is one that allocates 9K jumbo mbufs for receive > instead of using a list of smaller mbuf clusters, I'd guess this is > what is biting you. Apologies for the thread drift, but is there a list anywhere of what drivers might have this issue? I've certainly seen performance decrease in the past between two machines with igb interfaces when the MTU was raised to use 9k frames. Paul. From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 12:39:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 209E1915 for ; Wed, 29 Apr 2015 12:39:47 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D682219BD for ; Wed, 29 Apr 2015 12:39:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBADGz0BV/95baINcg19cBYMVwm+BSQqFNk4CgXwTAQEBAQEBAYEKhCABAQEDAQEBASArIAsFFg4KAgINGQIpAQkmBggHBAEcBIgCCA2yfpQbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiheEMwEBHDQHgmiBRQWVc4QPg1M9kEiDUCOCBxyBbSIxB4EEOYEBAQEB X-IronPort-AV: E=Sophos;i="5.11,671,1422939600"; d="scan'208";a="208541945" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 29 Apr 2015 08:39:43 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C7EC5B3F7E; Wed, 29 Apr 2015 08:39:43 -0400 (EDT) Date: Wed, 29 Apr 2015 08:39:43 -0400 (EDT) From: Rick Macklem To: Paul Thornton Cc: freebsd-net@freebsd.org Message-ID: <27489106.27851938.1430311183809.JavaMail.root@uoguelph.ca> In-Reply-To: <5540A9BF.2090003@prt.org> Subject: Re: Frequent hickups on the networking layer MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 12:39:47 -0000 Paul Thornton wrote: > Hi, > > On 28/04/2015 22:06, Rick Macklem wrote: > > ... If your > > net device driver is one that allocates 9K jumbo mbufs for receive > > instead of using a list of smaller mbuf clusters, I'd guess this is > > what is biting you. > > Apologies for the thread drift, but is there a list anywhere of what > drivers might have this issue? > If you: # cd /usr/src/sys/dev # find . -name "*.c" -exec fgrep -l MJUM9BYTES {} \; you will get a hint w.r.t. which ones might have a problem. Then I think you'll have to dig into the driver sources to see what it is actually doing. (As you've seen on the thread Chelsio sounds like it handles things and allows you to disable use of 9K via a tunable.) rick ps: Long ago (1970s) a CS prof. I had said "the sources are the only real documentation". I think he was correct. > I've certainly seen performance decrease in the past between two > machines with igb interfaces when the MTU was raised to use 9k > frames. > > Paul. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 14:03:51 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78B2E297; Wed, 29 Apr 2015 14:03:51 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36A5F139A; Wed, 29 Apr 2015 14:03:50 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id t3TE3htS052996; Wed, 29 Apr 2015 10:03:44 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id t3TE3h4U052993; Wed, 29 Apr 2015 10:03:43 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21824.58559.694680.131913@hergotha.csail.mit.edu> Date: Wed, 29 Apr 2015 10:03:43 -0400 From: Garrett Wollman To: Adrian Chadd Cc: FreeBSD Net Subject: Re: Frequent hickups on the networking layer In-Reply-To: References: <4281350517-9417@kerio.tuxis.nl> <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> <21824.26416.855441.21454@hergotha.csail.mit.edu> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 29 Apr 2015 10:03:44 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 14:03:51 -0000 < said: > - as you said, like ~ 64k), and allocate that way. That way there's no > fragmentation to worry about - everything's just using a custom slab > allocator for these large allocation sizes. > It's kind of tempting to suggest freebsd support such a thing, as I > can see increasing requirements for specialised applications that want > this. I think this would be an Extremely Good Thing if someone has the cycles to implement it, and teach some of the popular network interfaces to use it. -GAWollman From owner-freebsd-net@FreeBSD.ORG Wed Apr 29 14:07:02 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 230253BA for ; Wed, 29 Apr 2015 14:07:02 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4DAE13C4 for ; Wed, 29 Apr 2015 14:07:01 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id t3TE6wrg053062; Wed, 29 Apr 2015 10:06:58 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id t3TE6wmV053059; Wed, 29 Apr 2015 10:06:58 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21824.58754.452182.195043@hergotha.csail.mit.edu> Date: Wed, 29 Apr 2015 10:06:58 -0400 From: Garrett Wollman To: Mark Schouten Cc: freebsd-net@FreeBSD.org Subject: Re: Frequent hickups on the networking layer In-Reply-To: <5540889A.5030904@tuxis.nl> References: <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> <5540889A.5030904@tuxis.nl> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 29 Apr 2015 10:06:58 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 29 Apr 2015 14:07:02 -0000 < said: > I'm not really (or really not) comfortable with hacking and recompiling > stuff. I'd rather not change anything in the kernel. So would it help in > my case to lower my MTU from 9000 to 4000? If I understand correctly, > this would need to allocate chunks of 4k, which is far more logical from > a memory point of view? If you're using one of the drivers that has this problem, then yes, keeping your layer-2 MTU/MRU below 4096 will probably cause it to use 4k (page-sized) clusters instead, which are perfectly safe. As a side note, at least on the hardware I have to support, Infiniband is limited to 4k MTU -- so I have one "jumbo" network with 4k frames (that's bridged to IB) and one with 9k frames (that everything else uses). -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 01:03:43 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF148FF for ; Thu, 30 Apr 2015 01:03:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4FA81174 for ; Thu, 30 Apr 2015 01:03:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t3U13hQt034661 for ; Thu, 30 Apr 2015 01:03:43 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t3U13hjB034660; Thu, 30 Apr 2015 01:03:43 GMT (envelope-from daemon-user) Date: Thu, 30 Apr 2015 01:03:43 +0000 To: freebsd-net@freebsd.org From: "eadler (Eitan Adler)" Subject: [Differential] [Updated] D1438: FreeBSD callout rewrite and cleanup Message-ID: <1e1b066dc465975345ddf8ad01a429de@localhost.localdomain> X-Priority: 3 Thread-Topic: D1438: FreeBSD callout rewrite / cleanup X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: YzU3ODk0MGM0Y2E4NmE3NjY4YjJlZmFkM2UyIFVBf28= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 01:03:43 -0000 eadler removed a reviewer: Doc Committers. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1438 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn, rrs, kostikbel, delphij, neel, erj Cc: avg, jch, wblock, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 12:52:01 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1824D9CC for ; Thu, 30 Apr 2015 12:52:01 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3FB814FD for ; Thu, 30 Apr 2015 12:52:00 +0000 (UTC) Received: from global-1-26.nat.csx.cam.ac.uk ([131.111.184.26]:25945 helo=[172.17.158.255]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Ynnwc-0004y7-U4; Thu, 30 Apr 2015 08:51:59 -0400 From: "George Neville-Neil" To: "Karlis Laivins" Cc: "grenville armitage" , freebsd-net@freebsd.org Subject: Re: Congestion Control Modification Date: Thu, 30 Apr 2015 13:51:58 +0100 Message-ID: In-Reply-To: References: <5535945F.90504@swin.edu.au> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 12:52:01 -0000 Are you planning to put the source to this up on a repo (github) or send along patches? It would be good to get a look at this new algorithm. Thanks, George On 21 Apr 2015, at 5:30, Karlis Laivins wrote: > Hi, > > Thank you very much for such a comprehensive description of how to > properly > create a loadable Kernel module, this does the trick - I was able to > create > the module successfully, load it into Kernel and set it as the > congestion > control algorithm used via sysctl net.inet.tcp.cc.algorithm=new (new - > the > name of my test module). > > Best Regards, > Karlis > > On Tue, Apr 21, 2015 at 3:05 AM, grenville armitage > > wrote: > >> Hi, >> >> >> On 04/18/2015 16:59, Karlis Laivins wrote: >> >>> Hello, >>> >>> I have read an interesting publication about a proposed modification >>> of >>> TCP >>> Congestion Control algorithm that would allow to improve it (the CC) >>> by >>> dynamic bandwidth estimation. The idea seems so interesting that I >>> would >>> like to try to implement it by modifying the NewReno code. >>> >>> Do I understand correctly that to do the above stated, I would >>> create a >>> copy of source file (in my case - cc_newreno.c) located in >>> /usr/src/sys/ >>> and rename it to, for example, cc_newreno_test.c and make changes to >>> it? >>> How would I then compile it, and how would I create a >>> newreno_test.ko file >>> that can be loaded into Kernel and tested? >>> >>> Thank you in advance for your answers! >>> >> >> In case this helps shed some (probably incomplete) light, here are >> the >> steps >> I took late last year to make a modified version of NewReno: >> >> I start with copying the newreno module under >> sys/netinet/cc/cc_newreno.c >> as a template. The new source file will be called newrenoVarBeta.c >> >> /usr/src/sys/netinet/cc % cp cc_newreno.c cc_newrenoVarBeta.c >> /usr/src/sys/netinet/cc % >> >> Then create a modules definition based on >> /usr/src/sys/modules/cc/cc_cubic >> (because there isn't one for newreno per se) >> >> /usr/src/sys/netinet/cc % cd /usr/src/sys/modules/cc >> /usr/src/sys/modules/cc % mkdir cc_newrenoVarBeta >> /usr/src/sys/modules/cc % cp cc_cubic/Makefile cc_newrenoVarBeta/ >> /usr/src/sys/modules/cc % >> >> Tweak the cc_newrenoVarBeta/Makefile to say: >> >> KMOD= cc_newrenoVarBeta >> SRCS= cc_newrenoVarBeta.c >> >> Made my changes to cc_newrenoVarBeta.c (including changing the >> module's >> name from 'newreno' to something else) >> >> Then built/installed the new module with: >> >> /usr/src/sys/netinet/cc % cd >> /usr/src/sys/modules/cc/cc_newrenoVarBeta >> /usr/src/sys/modules/cc % make clean && make && make install >> [..build and install output..] >> /usr/src/sys/modules/cc % >> >> All being well, cc_newrenoVarBeta.ko should now exist under >> /boot/kernel >> >> Then use 'kldload cc_newrenoVarBeta.ko' to load your new CC algorithm >> >> If all goes well, your new module will appear (with whatever name you >> gave >> it) in the sysctl net.inet.tcp.cc.available list. Don't forget to >> actually >> select your new module with sysctl net.inet.tcp.cc.algorithm when >> running >> experiments. >> >> cheers, >> gja >> >> >> >> _______________________________________________ >> 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 Thu Apr 30 12:58:50 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF44DD50 for ; Thu, 30 Apr 2015 12:58:50 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABCF61593 for ; Thu, 30 Apr 2015 12:58:50 +0000 (UTC) Received: from global-1-26.nat.csx.cam.ac.uk ([131.111.184.26]:10892 helo=[172.16.33.1]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Yno3F-0005kA-FD for net@freebsd.org; Thu, 30 Apr 2015 08:58:49 -0400 From: "George Neville-Neil" To: net@freebsd.org Subject: SIFTR and DTrace Date: Thu, 30 Apr 2015 13:58:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 12:58:50 -0000 Howdy, I have added support for a DTrace SDT to the SIFTR module in HEAD. What this means is that you can now get SIFTR data filtered out of the kernel directly. I also added a simple script (share/dtrace/siftr) to show how this works. The test script is very wordy and only an example of how to use this. In order to use SIFTR with DTrace either load the modules, dtraceall and siftr, or compile them into the kernel. Here is some example output: sudo ./siftr direction in state state-established local 22 remote 55907 snd_cwnd 22978 snd_wnd 131008 rcv_wnd 66608 snd_bwnd 0 snd_ssthresh 1073725440 max_seg_size 1448 smoothed_rtt 11 sack_enabled 1 snd_scale 5 rcv_scale 6 flags 0x3e4 rxt_length 230 snd_buf_hiwater 33304 snd_buf_cc 0 rcv_buf_hiwater 66608 rcv_buf_cc 0 sent_inflight_bytes 0 t_segqlen 0 flowid 0 flowtype 0 Using a DTrace predicate you can select a particular flow based on, for instance, the local and remote ports. I have not put in the IP address reporting as yet nor have I added the ability to pull out the timeval recorded by SIFTR. Since the trace point is in the code where the trace is taken it is possible to use DTrace timestamps natively. Best, George From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 13:04:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC71EFDA for ; Thu, 30 Apr 2015 13:04:40 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BBBA16BC for ; Thu, 30 Apr 2015 13:04:40 +0000 (UTC) Received: by lbbzk7 with SMTP id zk7so44027040lbb.0 for ; Thu, 30 Apr 2015 06:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0weHlHhyBeV4WPMnH92qUfvCSeb0Flv5i2CqUjS0lpk=; b=OcPRJA+2QexcqrhK5jiHEd3wxF8gsbb3WNCOZydRgvkXIwKQg0pkOPRNKxoIfaAKuv btp4eOIoxBvBcD9XwbtIuBXsSCJ/T/00fuc4hlnBguVZ6ol7Kn9HkxktTIFt1prLUA4q 3DwZNsS8kvV3BwhtXc5DcPB/G2XMqoHP4evuiTscSt7LzvdTFLlVpOCYOWbJUdKPYdKi U6e8ihlBqPAHqiCBn7k1woBavNsVA3sv6yvBWAPldZ9E3bu2ofJHH0H8OkljuPSYbpkX 9jmhtqrDp96NAoLCMi2PhxPJRVc3jJUS7/QVGcB6co9dDXtOdl92eDEHTvzjFAz9jqd3 sb/w== MIME-Version: 1.0 X-Received: by 10.152.37.201 with SMTP id a9mr3665336lak.120.1430399078160; Thu, 30 Apr 2015 06:04:38 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Thu, 30 Apr 2015 06:04:38 -0700 (PDT) In-Reply-To: References: <5535945F.90504@swin.edu.au> Date: Thu, 30 Apr 2015 16:04:38 +0300 Message-ID: Subject: Re: Congestion Control Modification From: Karlis Laivins To: George Neville-Neil Cc: grenville armitage , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:04:40 -0000 Hello, If I will be able to implement the idea described in the publication correctly, I will share the source code. At the moment, though, I am still far away from the implementation, since I have yet to solve the issue of how to get the One Way Delay for the ACK message (the time it takes ACK to arrive from receiver of the ACK'ed data sender) correctly. Best Regards, Karlis On Thu, Apr 30, 2015 at 3:51 PM, George Neville-Neil wrote: > Are you planning to put the source to this up on a repo (github) or send > along patches? > It would be good to get a look at this new algorithm. > > Thanks, > George > > > > On 21 Apr 2015, at 5:30, Karlis Laivins wrote: > > Hi, >> >> Thank you very much for such a comprehensive description of how to >> properly >> create a loadable Kernel module, this does the trick - I was able to >> create >> the module successfully, load it into Kernel and set it as the congestion >> control algorithm used via sysctl net.inet.tcp.cc.algorithm=new (new - the >> name of my test module). >> >> Best Regards, >> Karlis >> >> On Tue, Apr 21, 2015 at 3:05 AM, grenville armitage < >> garmitage@swin.edu.au> >> wrote: >> >> Hi, >>> >>> >>> On 04/18/2015 16:59, Karlis Laivins wrote: >>> >>> Hello, >>>> >>>> I have read an interesting publication about a proposed modification of >>>> TCP >>>> Congestion Control algorithm that would allow to improve it (the CC) by >>>> dynamic bandwidth estimation. The idea seems so interesting that I would >>>> like to try to implement it by modifying the NewReno code. >>>> >>>> Do I understand correctly that to do the above stated, I would create a >>>> copy of source file (in my case - cc_newreno.c) located in /usr/src/sys/ >>>> and rename it to, for example, cc_newreno_test.c and make changes to it? >>>> How would I then compile it, and how would I create a newreno_test.ko >>>> file >>>> that can be loaded into Kernel and tested? >>>> >>>> Thank you in advance for your answers! >>>> >>>> >>> In case this helps shed some (probably incomplete) light, here are the >>> steps >>> I took late last year to make a modified version of NewReno: >>> >>> I start with copying the newreno module under sys/netinet/cc/cc_newreno.c >>> as a template. The new source file will be called newrenoVarBeta.c >>> >>> /usr/src/sys/netinet/cc % cp cc_newreno.c cc_newrenoVarBeta.c >>> /usr/src/sys/netinet/cc % >>> >>> Then create a modules definition based on >>> /usr/src/sys/modules/cc/cc_cubic >>> (because there isn't one for newreno per se) >>> >>> /usr/src/sys/netinet/cc % cd /usr/src/sys/modules/cc >>> /usr/src/sys/modules/cc % mkdir cc_newrenoVarBeta >>> /usr/src/sys/modules/cc % cp cc_cubic/Makefile cc_newrenoVarBeta/ >>> /usr/src/sys/modules/cc % >>> >>> Tweak the cc_newrenoVarBeta/Makefile to say: >>> >>> KMOD= cc_newrenoVarBeta >>> SRCS= cc_newrenoVarBeta.c >>> >>> Made my changes to cc_newrenoVarBeta.c (including changing the module's >>> name from 'newreno' to something else) >>> >>> Then built/installed the new module with: >>> >>> /usr/src/sys/netinet/cc % cd /usr/src/sys/modules/cc/cc_newrenoVarBeta >>> /usr/src/sys/modules/cc % make clean && make && make install >>> [..build and install output..] >>> /usr/src/sys/modules/cc % >>> >>> All being well, cc_newrenoVarBeta.ko should now exist under /boot/kernel >>> >>> Then use 'kldload cc_newrenoVarBeta.ko' to load your new CC algorithm >>> >>> If all goes well, your new module will appear (with whatever name you >>> gave >>> it) in the sysctl net.inet.tcp.cc.available list. Don't forget to >>> actually >>> select your new module with sysctl net.inet.tcp.cc.algorithm when running >>> experiments. >>> >>> cheers, >>> gja >>> >>> >>> >>> _______________________________________________ >>> 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 Thu Apr 30 13:20:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCC725F3 for ; Thu, 30 Apr 2015 13:20:28 +0000 (UTC) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx141.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B1ECE1860 for ; Thu, 30 Apr 2015 13:20:27 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,677,1422950400"; d="scan'208";a="40231441" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx141-out.netapp.com with ESMTP; 30 Apr 2015 06:19:38 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 30 Apr 2015 06:19:38 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f07f:691d:89d:53b7%21]) with mapi id 15.00.0995.031; Thu, 30 Apr 2015 06:19:38 -0700 From: "Eggert, Lars" To: Karlis Laivins CC: George Neville-Neil , "freebsd-net@freebsd.org" , grenville armitage Subject: Re: Congestion Control Modification Thread-Topic: Congestion Control Modification Thread-Index: AQHQeaU33IcUV8/cd0qlR1H1jM0AGJ1XD+mAgABJ8QCADrEXAIAAA4oAgAAELYA= Date: Thu, 30 Apr 2015 13:19:37 +0000 Message-ID: <98E7D40A-EC37-413D-85CE-2A6012811E08@netapp.com> References: <5535945F.90504@swin.edu.au> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:20:29 -0000 On 2015-4-30, at 15:04, Karlis Laivins wrote: > I have yet to solve the issue of > how to get the One Way Delay for the ACK message (the time it takes ACK t= o > arrive from receiver of the ACK'ed data sender) correctly. That won't work without synchronized clocks, which you can't really assume = to be present. Lars= From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 13:48:41 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AAC8C8C for ; Thu, 30 Apr 2015 13:48:41 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CE571BE4 for ; Thu, 30 Apr 2015 13:48:41 +0000 (UTC) Received: by lbbuc2 with SMTP id uc2so44913299lbb.2 for ; Thu, 30 Apr 2015 06:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wft8pBGhAeHic+fpXdV+yHPdz5LK8KAkUHMJDzJ6rZo=; b=gIChdJ1DbBPDLAgSFDVAEWFu7iO1g/fceaicvmKwYHx3tqWUOj0iePrqwQ4vnWNlfR lf1mSgo/EB66v3B1qzutVqisdwrenhzD0SYqgRdxFLppyOkK6GTsjvkGbpYtzwhRRdbS RgtW4BLqb/s7Gp14XiQamRt7uC94ShCS3hdVs0lHevAmVGLNKlKMnIOsRCSktcHiFcnO 3uPZc6/PYGT7z3c3kT6FekbxQjHu1vetQcJzWC9/t5j5tOkbsyUcnxT3eIRJiYoJMMXq f8hN6niEq4lq9f6G9S0Gc/sNSeaJBkxh6sBItcDnBVmGkHeldzGVpW8VjBrKaVmQhRY1 r8PQ== MIME-Version: 1.0 X-Received: by 10.112.29.180 with SMTP id l20mr3740813lbh.95.1430401719247; Thu, 30 Apr 2015 06:48:39 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Thu, 30 Apr 2015 06:48:39 -0700 (PDT) In-Reply-To: <98E7D40A-EC37-413D-85CE-2A6012811E08@netapp.com> References: <5535945F.90504@swin.edu.au> <98E7D40A-EC37-413D-85CE-2A6012811E08@netapp.com> Date: Thu, 30 Apr 2015 16:48:39 +0300 Message-ID: Subject: Re: Congestion Control Modification From: Karlis Laivins To: "Eggert, Lars" Cc: George Neville-Neil , "freebsd-net@freebsd.org" , grenville armitage Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:48:41 -0000 Yes, you are correct, I meant to write "relative OWD". As David Hayes put it - "Relative OWD measurements are easier, and clock drift is not usually a problem over the time it takes to send and receive an ACK". Thank you for the correction! On Thu, Apr 30, 2015 at 4:19 PM, Eggert, Lars wrote: > On 2015-4-30, at 15:04, Karlis Laivins wrote: > > I have yet to solve the issue of > > how to get the One Way Delay for the ACK message (the time it takes ACK > to > > arrive from receiver of the ACK'ed data sender) correctly. > > That won't work without synchronized clocks, which you can't really assume > to be present. > > Lars From owner-freebsd-net@FreeBSD.ORG Thu Apr 30 21:07:16 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED2DDDBF for ; Thu, 30 Apr 2015 21:07:16 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1EF81D10 for ; Thu, 30 Apr 2015 21:07:16 +0000 (UTC) Received: from 82-69-116-12.dsl.in-addr.zen.co.uk ([82.69.116.12]:58432 helo=[172.16.33.1]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Ynvfo-00045P-CL; Thu, 30 Apr 2015 17:07:09 -0400 From: "George Neville-Neil" To: "Karlis Laivins" Cc: "Eggert, Lars" , "freebsd-net@freebsd.org" , "grenville armitage" Subject: Re: Congestion Control Modification Date: Thu, 30 Apr 2015 22:06:58 +0100 Message-ID: <8D3AEF2A-1413-4C44-9E5C-66900847F18A@neville-neil.com> In-Reply-To: References: <5535945F.90504@swin.edu.au> <98E7D40A-EC37-413D-85CE-2A6012811E08@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 21:07:17 -0000 If you want to run some experiments, though, you could look at running PTPd on 3 servers (master, and two slaves) which will get you decent synchronization among the three. Where decent is less than the typical RTT of a TCP packet on a 1Gbps LAN. Best, George On 30 Apr 2015, at 14:48, Karlis Laivins wrote: > Yes, you are correct, I meant to write "relative OWD". As David Hayes > put > it - "Relative OWD measurements are easier, and clock drift is not > usually > a problem over the time it takes to send and receive an ACK". > > Thank you for the correction! > > On Thu, Apr 30, 2015 at 4:19 PM, Eggert, Lars wrote: > >> On 2015-4-30, at 15:04, Karlis Laivins >> wrote: >>> I have yet to solve the issue of >>> how to get the One Way Delay for the ACK message (the time it takes >>> ACK >> to >>> arrive from receiver of the ACK'ed data sender) correctly. >> >> That won't work without synchronized clocks, which you can't really >> assume >> to be present. >> >> Lars From owner-freebsd-net@FreeBSD.ORG Fri May 1 03:59:38 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B1D8682 for ; Fri, 1 May 2015 03:59:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3562417DB for ; Fri, 1 May 2015 03:59:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t413xcwh007928 for ; Fri, 1 May 2015 03:59:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199754] [bge] BCM5720 is not working Date: Fri, 01 May 2015 03:59:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 03:59:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199754 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 1 05:21:23 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09AC6675 for ; Fri, 1 May 2015 05:21:23 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F20516C6 for ; Fri, 1 May 2015 05:21:22 +0000 (UTC) Received: by lbbuc2 with SMTP id uc2so59333401lbb.2 for ; Thu, 30 Apr 2015 22:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rxDkQ19ZtGr4s08dGbLOYmyL2uYcrtkRi9JrzM8hfXw=; b=QIb8lI0cJUSejMf6ZoVWaX0CmBY/19UDc38wBIezuoUDB5beXxoCGE6UVFYn0cE8gc +ONcae8vNLsLjOijBcbP2/WzTEQluugupBZ04YbLtEc3P+xiui6ktRwBVwiRyOw7f33n uYFpe1vDMl/9ZlRW4r3Rfbvqq7UKl6I4s0RhmKYzGw0nC2HHlebL6Uw6x5d+il8cr/5l bTP6THnfxrvNYsRllHylg0S+sZN+cspLTchBj9/OYacdC0M8dcShkVbdvi8xiBBlgddD OfRjLG0crjowcZBkRVF3vTc0hpdpFGnW5pW4E2vrcbpDKwP0RuqlNQs4wk2pku+F3Uf3 yLxA== MIME-Version: 1.0 X-Received: by 10.112.29.180 with SMTP id l20mr6553240lbh.95.1430457680645; Thu, 30 Apr 2015 22:21:20 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Thu, 30 Apr 2015 22:21:20 -0700 (PDT) In-Reply-To: <8D3AEF2A-1413-4C44-9E5C-66900847F18A@neville-neil.com> References: <5535945F.90504@swin.edu.au> <98E7D40A-EC37-413D-85CE-2A6012811E08@netapp.com> <8D3AEF2A-1413-4C44-9E5C-66900847F18A@neville-neil.com> Date: Fri, 1 May 2015 08:21:20 +0300 Message-ID: Subject: Re: Congestion Control Modification From: Karlis Laivins To: George Neville-Neil Cc: "Eggert, Lars" , "freebsd-net@freebsd.org" , grenville armitage Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 05:21:23 -0000 Hello George, Thank you for the tip! I have set up a virtual test environment with IMUNES (interesting tool, by the way) and now I am running validation tests, to see, if the results there are at least similar to those that can be achieved on a physical testbed. I will let you know if and when the implementation will be done as I will certainly need objective feedback. BR, Karlis On Fri, May 1, 2015 at 12:06 AM, George Neville-Neil wrote: > If you want to run some experiments, though, you could look at running PTPd > on 3 servers (master, and two slaves) which will get you decent > synchronization > among the three. Where decent is less than the typical RTT of a TCP > packet on a > 1Gbps LAN. > > Best, > George > > > On 30 Apr 2015, at 14:48, Karlis Laivins wrote: > > Yes, you are correct, I meant to write "relative OWD". As David Hayes put >> it - "Relative OWD measurements are easier, and clock drift is not usually >> a problem over the time it takes to send and receive an ACK". >> >> Thank you for the correction! >> >> On Thu, Apr 30, 2015 at 4:19 PM, Eggert, Lars wrote: >> >> On 2015-4-30, at 15:04, Karlis Laivins wrote: >>> >>>> I have yet to solve the issue of >>>> how to get the One Way Delay for the ACK message (the time it takes ACK >>>> >>> to >>> >>>> arrive from receiver of the ACK'ed data sender) correctly. >>>> >>> >>> That won't work without synchronized clocks, which you can't really >>> assume >>> to be present. >>> >>> Lars >>> >> From owner-freebsd-net@FreeBSD.ORG Fri May 1 19:02:21 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52E48ABA for ; Fri, 1 May 2015 19:02:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D07D1F55 for ; Fri, 1 May 2015 19:02:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t41J2Lau090055 for ; Fri, 1 May 2015 19:02:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199716] em doesn't increment adapter->rx_overruns in msix mode Date: Fri, 01 May 2015 19:02:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 19:02:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbruno@FreeBSD.org Status|New |In Progress --- Comment #1 from Sean Bruno --- I'm deep into the 82574L now. I'll take this for review. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 1 19:25:44 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDEC637D for ; Fri, 1 May 2015 19:25:44 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B892311BC for ; Fri, 1 May 2015 19:25:44 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t41JPiXX010472 for ; Fri, 1 May 2015 19:25:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199716] em doesn't increment adapter->rx_overruns in msix mode Date: Fri, 01 May 2015 19:25:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 19:25:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 --- Comment #2 from Sean Bruno --- Index: if_em.c =================================================================== --- if_em.c (revision 282317) +++ if_em.c (working copy) @@ -1609,6 +1609,9 @@ ++adapter->link_irq; reg_icr = E1000_READ_REG(&adapter->hw, E1000_ICR); + if (reg_icr & E1000_ICR_RXO) + adapter->rx_overruns++; + if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { adapter->hw.mac.get_link_status = 1; em_handle_link(adapter, 0); Should DTRT -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 1 20:04:36 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFAB9B5E for ; Fri, 1 May 2015 20:04:36 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA15A1639 for ; Fri, 1 May 2015 20:04:36 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t41K4arG078807 for ; Fri, 1 May 2015 20:04:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199716] em doesn't increment adapter->rx_overruns in msix mode Date: Fri, 01 May 2015 20:04:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 20:04:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hiren@FreeBSD.org --- Comment #3 from Hiren Panchasara --- (In reply to Sean Bruno from comment #2) I think so. Also, nice catch, David. This *may* explain a behavior when we were setting a bunch of missed_packets on RX side with very less rx_overruns reported. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 1 22:22:03 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B1DC751 for ; Fri, 1 May 2015 22:22:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F13221519 for ; Fri, 1 May 2015 22:22:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t41MM2ZP016976 for ; Fri, 1 May 2015 22:22:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Fri, 01 May 2015 22:22:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: david.keller@litchis.fr X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 22:22:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #10 from david.keller@litchis.fr --- Intel device Errata 17 (http://www.intel.fr/content/dam/www/public/us/en/documents/specification-updates/82574-gbe-controller-spec-update.pdf) says: > When using TSO, a situation can occur where a PCIe MRd request is repeated with > the same address, resulting in data corruption. At the end of the TCP packet, > the Tx DMA hangs because the length doesn't match. This can only occur when > the following are true: > * The first buffer of the packet is larger than [3 * (max_read_request - 4)]. > * There is a 4 KB boundary within 64 bytes following the end of the header bytes in > the buffer On my device, PCIe max_read_request is 512. Hence first buffer has to be <= 1524. Interface mtu is 9000. Hence it seems to me that the first buffer can be greater than the 1524 if the FreeBSD stack doesn't split header into a dedicated mbuf The dma alignement requirement is not met on bus_dma_tag_create() where alignement argument is 1. (https://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?view=markup#l3260). Maybe bus_dma_tag_create() should use an alignement of 128 bytes as explained in errata: > The alignment of the buffer containing the headers should be such that there is no > 4 KB boundary within 64 bytes following the end of the header bytes. Assuming > standard > Ethernet/IP/TCP headers of 54 bytes, this means that the buffer should > not start 54-118 bytes before a 4 KB boundary. For example, 128-byte alignment > for this buffer could be used to fulfill this condition -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 1 23:02:15 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD616117 for ; Fri, 1 May 2015 23:02:15 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 99DAA192B for ; Fri, 1 May 2015 23:02:15 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t41N2Etr091910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 1 May 2015 16:02:14 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <554405F5.2050400@rawbw.com> Date: Fri, 01 May 2015 16:02:13 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "net@freebsd.org" Subject: Re: resolvconf(8) always leaves original DNS server in the list, allowing DNS requests to leak References: <5532F439.8070506@rawbw.com> In-Reply-To: <5532F439.8070506@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 23:02:15 -0000 On 04/18/2015 17:18, Yuri wrote: > > I would like to suggest the new option: > > -x Make the new DNS server exclusive. > With this option resolvconf(8) will replace the old server with the > new one. Followup to this: This feature has been implemented and released by the openresolv project (upstream), many thanks Roy Marples for this. I submitted the patch for this to be included: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199854 Yuri