From owner-freebsd-net@FreeBSD.ORG Sun Jan 18 19:08: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 216F893B for ; Sun, 18 Jan 2015 19:08:26 +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 097C31D9 for ; Sun, 18 Jan 2015 19:08:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0IJ8PSd049874 for ; Sun, 18 Jan 2015 19:08:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Sun, 18 Jan 2015 19:08: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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@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 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 19:08:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org CC| |hrs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Jan 18 19:15:51 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 355A4BEE for ; Sun, 18 Jan 2015 19:15:51 +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 042692C7 for ; Sun, 18 Jan 2015 19:15:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0IJFoEL092911 for ; Sun, 18 Jan 2015 19:15:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Sun, 18 Jan 2015 19:15: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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 19:15:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 --- Comment #6 from Craig Rodrigues --- Herbert found by creating VNET jails and then stopping them, he could reproduce the problem. Here are the steps he used to reproduce the problem: /etc/rc.conf: hostname="beastie.home.lan" ifconfig_em0="inet 192.168.1.25 netmask 0xffff0000" defaultrouter="192.168.1.255" cloned_interfaces="bridge0" ifconfig_bridge0="inet 10.0.0.1 netmask 0xff000000" sshd_enable="YES" fsck_y_enable="YES" background_fsck="NO" syslogd_flags="-ss" gateway_enable="YES" pf_enable="NO" pflog_enable="NO" jail_enable="NO" jail_list="jail01 jail02 jail03 jail04" devfs_load_rulesets="YES" /etc/jail.conf: jail01 { name = "jail01"; path = /usr/local/jails/jail01; mount.devfs; host.hostname = jail01.home.lan; vnet = "new"; vnet.interface = "epair0b"; persist; exec.prestart = "ifconfig epair0 create"; exec.prestart += "ifconfig bridge0 addm epair0a"; exec.prestart += "ifconfig epair0a up"; exec.start = ""; #exec.start = "/bin/sh /etc/rc"; exec.poststart = "jexec $name ifconfig epair0b 10.0.0.10 netmask 255.0.0.0 up"; exec.poststart += "jexec $name route add default 10.0.0.1"; exec.poststart += "jexec $name sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; exec.poststop = "ifconfig bridge0 deletem epair0a"; exec.poststop += "ifconfig epair0a destroy"; } /etc/rc.conf in jail01: hostname="jail01.home.lan" sshd_enable="YES" sendmail_enable="NONE" Starting jail with "/etc/rc.d/jail onestart jail01" or "jail -c jail01". Stopping jail with "/etc/rc.d/jail onestop jail01" or "jail -r jail01". -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Jan 18 19:25:17 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 0946CCDC for ; Sun, 18 Jan 2015 19:25:17 +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 E4E09395 for ; Sun, 18 Jan 2015 19:25:16 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0IJPG1T006763 for ; Sun, 18 Jan 2015 19:25:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Sun, 18 Jan 2015 19:25:17 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@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: attachments.created 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 19:25:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 --- Comment #7 from Craig Rodrigues --- Created attachment 151803 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=151803&action=edit dump2.txt -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Jan 18 19:37: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 30FE4FA6 for ; Sun, 18 Jan 2015 19:37: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 19033682 for ; Sun, 18 Jan 2015 19:37: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 t0IJbOjF056023 for ; Sun, 18 Jan 2015 19:37:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Sun, 18 Jan 2015 19:37:24 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 19:37:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 --- Comment #8 from Craig Rodrigues --- Herbert provided a traceback from his kernel panic. This looks like the source of the problem: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1814 It looks like after destroying a jail, a mutex is destroyed, but this destroyed mutex is used later on in another jail. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 02:34:12 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 4D09B427 for ; Mon, 19 Jan 2015 02:34:12 +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 3698F15C for ; Mon, 19 Jan 2015 02:34:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0J2YCpv014869 for ; Mon, 19 Jan 2015 02:34:12 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, 19 Jan 2015 02:34:07 +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-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: darius@dons.net.au X-Bugzilla-Status: New X-Bugzilla-Priority: Normal 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 02:34:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 --- Comment #18 from darius@dons.net.au --- Is this going to be MFCd? The 3 commits apply cleanly to stable/10 and seem to work (but I have only tested it lightly so far) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 04:38: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 0295459F for ; Mon, 19 Jan 2015 04:38:03 +0000 (UTC) Received: from mail134-16.atl141.mandrillapp.com (mail134-16.atl141.mandrillapp.com [198.2.134.16]) (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 A8002E83 for ; Mon, 19 Jan 2015 04:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mandrill; d=mail134-16.atl141.mandrillapp.com; h=From:Sender:Subject:To:Message-Id:Date:MIME-Version:Content-Type; i=emma@mail134-16.atl141.mandrillapp.com; bh=ZzrbN2CDgkyBgHlcVqImFu3Bs+Y=; b=BZ60s6TCxrKYO5V1d6ibPCkorTHqxMkc5V92ZSagMO++o68ryR6PsOkqErpEuYEA/4zDp0s1la1Q Qq1/EGuvcGBtJCwowb5iErXXQe7TJ6DXvv0/nrv5scsH8oM5u9CroPHbi8AUeiJITGXAbteHQtQt oma21lbc5XJ9nM+h5Fw= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=mandrill; d=mail134-16.atl141.mandrillapp.com; b=eex8Lvd+Kok8pKjKbisaWDeOH2YniAl1tKY5nNsFcWlKKi+c6Py5pGwpbuKRFBrBygVaFUnc/LRT 1Iiapl4wkmagem4zVxHybwXuGe2h3DPvqXRMBoBT4J380lhqcrIyBbSpEU3FL4A8djsPSogW11Ty b8Lk5YlH3laFRElJwl4=; Received: from pmta14.atl01.mandrillapp.com (127.0.0.1) by mail134-16.atl141.mandrillapp.com id hni52k1sau86 for ; Mon, 19 Jan 2015 04:38:01 +0000 (envelope-from ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; i=@mandrillapp.com; q=dns/txt; s=mandrill; t=1421642281; h=From : Sender : Subject : To : Message-Id : Date : MIME-Version : Content-Type : From : Subject : Date : X-Mandrill-User : List-Unsubscribe; bh=kKWaxKCnjO2aWzIETgdf+L1Zrr6QFUbggl6zMh1bJZU=; b=YESGxTZ/T20uADQXUdtFna1C+h2dSbfkcer7P36T1TOPWlpqmOmGhH2diP+jbbComqzg8v Iv7bSlUP2d4iHkPuO/b7nDZhWMxm7DTF0gpd1gFdYj5ePNE0368Kzn+rixQV9+kHIb8A5uw8 XwmyySAKH8mDXlb3tJihSrQIt8SPE= From: Emma Turing Sender: Emma Turing Subject: Kickstarter Invitation To: Received: from [54.146.80.80] by mandrillapp.com id f1bbc018eaee408ea80c0f21737e86a4; Mon, 19 Jan 2015 04:38:01 +0000 X-Report-Abuse: Please forward a copy of this message, including all headers, to abuse@mandrill.com X-Report-Abuse: You can also report abuse here: http://mandrillapp.com/contact/abuse?id=30485748.f1bbc018eaee408ea80c0f21737e86a4 X-Mandrill-User: md_30485748 Message-Id: <30485748.20150119043801.54bc8a29158b18.76859008@mail134-16.atl141.mandrillapp.com> Date: Mon, 19 Jan 2015 04:38:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 04:38:03 -0000 Hi, I'd like to invite you to back our Kickstarter project - The World's First Personal Robot . We're already 210% funded and the #1 Robot Project on Kickstarter now. PERSONAL ROBOT IS THE WHOLE PACKAGE: - The world's first personal assistant robot that can see, hear, smell, move, and feel - The smartest home automation system (supports both Z-Wave and Zigbee) - A photographer, storyteller, companion, security guard, and more - Powered by Artificial Intelligence algorithms - Open APIs We're been featured by TechCrunch, Mashable, and VentureBeat. Thanks, Emma *If you're not interested, please simply reply "don't email" and we'll stop emailing you immediately.* From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 05:12:24 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 ECCD7A84 for ; Mon, 19 Jan 2015 05:12:24 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BDF2204 for ; Mon, 19 Jan 2015 05:12:24 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ge10so5854937lab.10 for ; Sun, 18 Jan 2015 21:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S1U5keuvIUqW6N3GnLLCd2UC5kWy+mD99Songh+i87Y=; b=kmyMc1nFADszdBmCuV5GLbpDL7AqaN431r/um699icRL0BaKoFUn6I21r4VIM1uZ7e MtcRT7gwuzOHb1cMvH9TFrryk3q1DcbJlNZ/X4iOWPRqMeURzWbi5VBB871s+9o6YpNp GNp/G9XhxbXJXiMB4tUq5eeVtlip/kQ+Po9byxF43qFH9fYFlctY+OfsZELr5WIk2auq CltzTF08jHYZfWUo3mHGTxIsEe47NDGS5caP2JcbkJkO474KucWHelASRqtNFzhiCIrh c4rUfmbKSZ3FhYMuY10r5NfbF9Q+kVBPvzch7bxVQKyOnI+JUJWzPzIoRorFVDrO81i+ N/8A== MIME-Version: 1.0 X-Received: by 10.112.167.136 with SMTP id zo8mr25712214lbb.17.1421644341828; Sun, 18 Jan 2015 21:12:21 -0800 (PST) Received: by 10.112.160.68 with HTTP; Sun, 18 Jan 2015 21:12:21 -0800 (PST) In-Reply-To: <20141117193354.T31139@sola.nimnet.asn.au> References: <20141117193354.T31139@sola.nimnet.asn.au> Date: Mon, 19 Jan 2015 13:12:21 +0800 Message-ID: Subject: Re: dragonflybsd's ipfw From: Sato Kentney To: Ian Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 05:12:25 -0000 Hi, I get below from another email this morning, the ipfw can add dynamic rules according to below email. *You can manually insert a state as below and the state will be maintain by ipfw itself.* *ipfw state add rulenum 100 udp 192.168.1.1:0 8.8.8.8:53 expiry +600* *so you dont need to implement the logic to maintain the IP addresses or configure any crontab to remove..* *different state can have different expiry or "life time"* =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86 =E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7 2014-11-17 17:07 GMT+08:00 Ian Smith : > On Mon, 17 Nov 2014 15:48:13 +0800, Sato Kentney wrote: > > > I saw a email in dragonflybsd email list, someone is doing this! > > http://www.dragonflybsd.org/docs/ipfw2/ > > We've had 'ipfw2' for a very long while. I couldn't help wondering why > DF wouldn't just import our many years of development and experience > rather than using bycn82's 'rewrite'? .. but DF already has ipfw2: > > http://leaf.dragonflybsd.org/cgi/web-man?command=3Dipfw§ion=3DANY > > man page dated October 2008. Before tables, in-kernel NAT, later > dummynet updates and no doubt more. So why not start from there? > > cheers, Ian > From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 15:05: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 953F61FF for ; Mon, 19 Jan 2015 15:05: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 7D4D19C6 for ; Mon, 19 Jan 2015 15:05: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 t0JF5h7x012351 for ; Mon, 19 Jan 2015 15:05:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Mon, 19 Jan 2015 15:05: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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bz@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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:05:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bz@FreeBSD.org --- Comment #9 from Bjoern A. Zeeb --- (In reply to Craig Rodrigues from comment #1) That patch would be bogus as the CURVNET_SET()/RESTORE() would have to be before/after locking as that lack is virtualised as well. But it's also not the real problem. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 15:12:00 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 CA37A426 for ; Mon, 19 Jan 2015 15:12:00 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 850FDAAD for ; Mon, 19 Jan 2015 15:12:00 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id c9so4816915qcz.7 for ; Mon, 19 Jan 2015 07:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rS7Thm1eQiveYyjt4V/yEAGGfj0DqygKbYcoocGXpQs=; b=EGzYaxxxaLtQEVhDeY4CFgF1oPFC2GmhIxIJroIxiQbdlfXM2X0iVKNcVnjvgBiVRR Ca0prT4KDYeRo6QS5zi6q7J3SxwBcOipBimGFvtWP7mNRkZbSeHmmoBxVcXkJLGK0GC5 vXBvEhnmF48W7qdO+Ggy9Ajwdop+cfgrG3bCyy++514M7fteoRMJtj15AqVau0RXAT4p 9K3TdppxWGbVxo1exh39rAS/LHoftrnsfRlhVv9B7zulSDrK5yyn90SGWOYG0b44CrMY lBRgvwf90IncxBgsaLzk2jK3spWu6WbMTB9983rCFH3hSyNfiPnojH0HRrAPrv4j8j9M 53MQ== MIME-Version: 1.0 X-Received: by 10.224.131.4 with SMTP id v4mr22516258qas.99.1421680319685; Mon, 19 Jan 2015 07:11:59 -0800 (PST) Received: by 10.140.41.229 with HTTP; Mon, 19 Jan 2015 07:11:59 -0800 (PST) Date: Mon, 19 Jan 2015 09:11:59 -0600 Message-ID: Subject: netmap example bridge application performance issues From: Colton Chojnacki To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:12:01 -0000 I ask this question about a week ago, but I may have asked on the wrong mailing list. I am trying to compare the performance of the bridge application included in netmap with that of linux kernel bridge application. I have noticed that the performance of netmap bridge application is significantly lower than that of the linux kernel bridge. I am not sure that I am using the netmap bridge application correctly. Looking to be pointed in the right direction. I am running the experiment on a single box using two network namespaces. Here is an overview of my setup: -Linux Kernel 3.14.28 with netmap module loaded -two network namespaces: h0, h1 -two veth pairs: veth0, veth1, veth2, veth3 -one bridge implementation: linux kernel bridge or netmap bridge -Each veth pair is terminated on a network namespace and the bridge implementation that I am testing I am running iperf from network namespace h0 to h1. With the linux kernel bridge iperf is reporting a bandwidth of 24.1 Gbps With the netmap bridge application iperf is reporting a bandwidth of 118Mbps The command I am using to setup the netmap bridge application is: ./bridge -i netmap:veth1 -i netmap:veth3 The result of the experiment (24.1Gbps vs 118Mbps) seems off, no? Also which branch/tag of this repository https://code.google.com/p/netmap/ should I be using for the latest linux version of netmap? Thanks, Colton From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 15:16:54 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 C2DF857E for ; Mon, 19 Jan 2015 15:16:54 +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 A860BAE0 for ; Mon, 19 Jan 2015 15:16:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0JFGstl066799 for ; Mon, 19 Jan 2015 15:16:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Mon, 19 Jan 2015 15:16:54 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@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: bug_severity 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:16:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People --- Comment #10 from Bjoern A. Zeeb --- (In reply to Craig Rodrigues from comment #8) No, it's still used in the same jail. What seems to happen is: (a) the bridges get destroyed (all members detached, etc.), the lock gets destroyed. (b) the loopback interface in the same jail gets destroyed (c) the globally registered eventhandler in if_bridge is called for the interface (lo) disappearing. (d) we get to the point where we try to acquire the lock which we previously destroyed. Either extra checks in bridge_ifdetach() need to be implemented to catch that case (and I think that's not possible without adding extra bandaid information), or proper handling of net cloned interfaces and startup/teardown ordering needs to be implemented "as a whole". With all that the CURVET_SET/RESTORE question from comment #1 remains, as to what happens if bridge_members in the normal case reside in different VNETs (child jails)? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 19:36:57 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 9CEE12F5 for ; Mon, 19 Jan 2015 19:36:57 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 3884FCD2 for ; Mon, 19 Jan 2015 19:36:56 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id em10so327467wid.1 for ; Mon, 19 Jan 2015 11:36:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=jDtN+ncIJ1qq+X57DkaGcKagoPofofMgLHgkDqCFhYg=; b=X52oVj471Cs2mtaBH3TiNe8Vrlzsrj2cV9ECqu45i8OkHbcPPSc67y8v3kSF1kgJWL LU14iDPmyJLCRFBfZnjFnP9TSFBq36WzEbCc9LeF8pF3yvRPfAfV9AOU5GzYo0g2v/HY vx+rEvQtyJCgTcq1W1aWtVow/+v3cZzcIYCTdcxddP7I9z9nSWPcqhl4Z81qSaUNDMnn LEY5ElRxH8Kkmj6VVdBLAI+qvADGdANrVeRY8wiwM4aLN5oVEK0ZwCYJtKTOY2EoEn5E w33s/TH1CgWirE62H8NgTU+m4caItXj3M3ibpB+BBhhqAHkKU05SSkjVJ27/yKPxNq7/ hXuA== X-Gm-Message-State: ALoCoQnlq2q0zdfCwskdkcN5pvcM7m5dM0QAtv51zN22JTCuCrW+7L8xRVp/BPPbmAGJWw/RkZ9O X-Received: by 10.180.74.229 with SMTP id x5mr38603328wiv.1.1421696209130; Mon, 19 Jan 2015 11:36:49 -0800 (PST) Received: from [192.168.0.101] ([90.152.119.35]) by mx.google.com with ESMTPSA id da2sm8267704wjb.21.2015.01.19.11.36.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 11:36:48 -0800 (PST) Message-ID: <54BD5CCF.8080300@linaro.org> Date: Mon, 19 Jan 2015 19:36:47 +0000 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: net@freebsd.org Subject: ixgbe TX desc prefetch Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:36:57 -0000 Hi, I'm using netmap on Ubuntu 14.04 (3.13.0-44 kernel, ixgbe 3.15.1-k), and I can't max out a 10G link with pktgen : Sent 1068122462 packets, 64 bytes each, in 84.29 seconds. Speed: 12.67 Mpps Bandwidth: 6.49 Gbps (raw 8.92 Gbps) The README says "ixgbe tops at about 12.5 Mpps unless the driver prefetches tx descriptors". I've checked the actual driver code, it does a prefetch(tx_desc) in the TX completion interrupt handler, is that what you mean? Top shows ksoftirqd eats up one core while the pktgen process is around 45% My problem gets even worse when I want to use the another port on this same dual port card to do receive back the traffic (I'm sending my packets through a device I want to test for switching performance). The sending performance drops down to 9.39 Mpps (6.61 Gbps), and the receiving goes this much as well. I'm trying to bind the threads to cores with "-a 3" and so, but they don't seem to obey based on top. The TX now uses ca 50% CPU while RX is %20, but they don't seem to run on their assigned CPU. My card is an Intel 82599ES, the CPU is i5-4570 @ 3.2GHz (no HT). Maybe the fact it is a workstation CPU contributes to this problem? All suggestions welcome! Regards, Zoltan Kiss From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 19:37:12 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 2964B381 for ; Mon, 19 Jan 2015 19:37:12 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 B6E5FCE0 for ; Mon, 19 Jan 2015 19:37:11 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id n3so1619272wiv.1 for ; Mon, 19 Jan 2015 11:37:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=jDtN+ncIJ1qq+X57DkaGcKagoPofofMgLHgkDqCFhYg=; b=d5bo/taQhjW24iWXZyTyJ9sAtFd+pTRuUNMA1mS3zR8cfX5YIQ7sWsTnXUuF/rt/8M 9wbiA9KHHZZLm8+J/QFHK/pdhfxv3kS+ryjRLLSZV38i5nvhGuBIiVXucmJ3PlSYM0oT sOee0ubIvxxCIfAN+g03frbxWU26fdCWVjTNP4SfgiTgoiGMgNFe8G+Rx090/JlqZzBV jNPma05E0RN/d2tqSgM7cJU2SXPzq/tEKhsKMH8DNu6n5NZRZH2o4z9DIb0ySSi08k3Y ZnH/inoApfrJS5fNZ/+/B/8cYuD25PT0nDuEBXDQru6JmIlkv0u3fDBnfxlYXRobQdVU LbDg== X-Gm-Message-State: ALoCoQkXY1a/imcE6CY66ka/+bJioGuxDfL2IPziR/OemEA7UnsReT01yXagBQXTyUfjyuV/S/Eq X-Received: by 10.180.95.9 with SMTP id dg9mr8829757wib.1.1421696224473; Mon, 19 Jan 2015 11:37:04 -0800 (PST) Received: from [192.168.0.101] ([90.152.119.35]) by mx.google.com with ESMTPSA id uo6sm18412901wjc.49.2015.01.19.11.37.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 11:37:03 -0800 (PST) Message-ID: <54BD5CDF.20602@linaro.org> Date: Mon, 19 Jan 2015 19:37:03 +0000 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: net@freebsd.org Subject: ixgbe TX desc prefetch Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Holmes , Ciprian Barbu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:37:12 -0000 Hi, I'm using netmap on Ubuntu 14.04 (3.13.0-44 kernel, ixgbe 3.15.1-k), and I can't max out a 10G link with pktgen : Sent 1068122462 packets, 64 bytes each, in 84.29 seconds. Speed: 12.67 Mpps Bandwidth: 6.49 Gbps (raw 8.92 Gbps) The README says "ixgbe tops at about 12.5 Mpps unless the driver prefetches tx descriptors". I've checked the actual driver code, it does a prefetch(tx_desc) in the TX completion interrupt handler, is that what you mean? Top shows ksoftirqd eats up one core while the pktgen process is around 45% My problem gets even worse when I want to use the another port on this same dual port card to do receive back the traffic (I'm sending my packets through a device I want to test for switching performance). The sending performance drops down to 9.39 Mpps (6.61 Gbps), and the receiving goes this much as well. I'm trying to bind the threads to cores with "-a 3" and so, but they don't seem to obey based on top. The TX now uses ca 50% CPU while RX is %20, but they don't seem to run on their assigned CPU. My card is an Intel 82599ES, the CPU is i5-4570 @ 3.2GHz (no HT). Maybe the fact it is a workstation CPU contributes to this problem? All suggestions welcome! Regards, Zoltan Kiss From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 20:22:34 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 32D25AA3 for ; Mon, 19 Jan 2015 20:22:34 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E978B29F for ; Mon, 19 Jan 2015 20:22:33 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 26D657300A; Mon, 19 Jan 2015 21:22:25 +0100 (CET) Date: Mon, 19 Jan 2015 21:22:25 +0100 From: Luigi Rizzo To: Zoltan Kiss Subject: Re: ixgbe TX desc prefetch Message-ID: <20150119202225.GA77414@onelab2.iet.unipi.it> References: <54BD5CDF.20602@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BD5CDF.20602@linaro.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mike Holmes , Ciprian Barbu , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 20:22:34 -0000 On Mon, Jan 19, 2015 at 07:37:03PM +0000, Zoltan Kiss wrote: > Hi, > > I'm using netmap on Ubuntu 14.04 (3.13.0-44 kernel, ixgbe 3.15.1-k), and > I can't max out a 10G link with pktgen : > > Sent 1068122462 packets, 64 bytes each, in 84.29 seconds. > Speed: 12.67 Mpps Bandwidth: 6.49 Gbps (raw 8.92 Gbps) > > The README says "ixgbe tops at about 12.5 Mpps unless the driver > prefetches tx descriptors". I've checked the actual driver code, it does > a prefetch(tx_desc) in the TX completion interrupt handler, is that what > you mean? Top shows ksoftirqd eats up one core while the pktgen process > is around 45% that comment is related to how the TXDCTL register in the NIC is programmed, not the CPU's prefetch, and it applies only to the case where you use only one queue to transmit. With multiple tx queues you should be able to do line rate regardless of that setting. However there are other things you might be hitting: - if you have IOMMU enabled, that adds overhead to the memory mappings and i seem to remember that caused a drop in the tx rate; - try pkt-gen with sizes 60 and 64 (before CRC) to see if there is any difference. Especially on the receive side, if the driver strips the CRC, performance with 60 bytes is worse (and i assume you have disabled flow control on both sender and receiver) Finally, we have seen degradation on recent linux kernels (> 3.5 i would say) and this seems to be due to the driver disabling interrupt moderation if the napi handler reports work has been completed. Since netmap does almost nothing in the NAPI handler, the OS is confused and thinks there is no load so it could as well optimize for low latency. A fix is to hardwire interrupt moderation to some 20-50us (not sure if you can do it with ethtool, we tweaked the driver's code to avoid the changes in moderation). That should deal with the high ksoftirq load. And finally, multiple ports on the same nic contend for PCIe bandwidth so it is well possible that the bus does not have capacity for full traffic on both ports. cheers luigi > My problem gets even worse when I want to use the another port on this > same dual port card to do receive back the traffic (I'm sending my > packets through a device I want to test for switching performance). The > sending performance drops down to 9.39 Mpps (6.61 Gbps), and the > receiving goes this much as well. I'm trying to bind the threads to > cores with "-a 3" and so, but they don't seem to obey based on top. The > TX now uses ca 50% CPU while RX is %20, but they don't seem to run on > their assigned CPU. > My card is an Intel 82599ES, the CPU is i5-4570 @ 3.2GHz (no HT). Maybe > the fact it is a workstation CPU contributes to this problem? > > All suggestions welcome! > > Regards, > > Zoltan Kiss > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jan 20 12:22:26 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 6F47EE8F for ; Tue, 20 Jan 2015 12:22:26 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0658A7C0 for ; Tue, 20 Jan 2015 12:22:25 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id fb4so10320300wid.2 for ; Tue, 20 Jan 2015 04:22:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KnhIbPYahMzHhwXpP+qQVBpOOvP7HnA80NP+wwuPCyA=; b=eXcd2tmEi0ZGj2mgQkm/RRplvBqOmMZHDmZitlbI9n/6fK6Bd/isIvFiFG9uVSiM01 8k3gJrBwkxg4qqmAMumvNHp20/2uhltLK9LQzfOUVadkFK9aY8cR5fBudVRncCECR6ZJ 96kGOh3nSkos2QEtmc/cDHxGv3L+Lib2p44Yn42J0oh3XSnZjaW4D+QpwgpcMOYI9UxT 2pKqMdWTqKOUo0dBfbP9oUkrilGCE0J3D7jMl89FnB1JTk5D1P6NDCD+FScUgQt1piIC Q1oqasvuBAgq9WKcXKxAZT51eewK/lvmV24Fz0RgNCrxkgLGILSyKRANNz8Ksk0cgxLL DudA== X-Gm-Message-State: ALoCoQl7zQLBOHEb4G0wVyRslFr4cFXBr+mkdtQGDkYL8AQSBEqOQbrYajAo343vF2CvmkuOwa2s X-Received: by 10.194.79.226 with SMTP id m2mr69898799wjx.60.1421756537684; Tue, 20 Jan 2015 04:22:17 -0800 (PST) Received: from [192.168.0.101] ([90.152.119.35]) by mx.google.com with ESMTPSA id i20sm7391835wjq.22.2015.01.20.04.22.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 04:22:16 -0800 (PST) Message-ID: <54BE4878.70703@linaro.org> Date: Tue, 20 Jan 2015 12:22:16 +0000 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: ixgbe TX desc prefetch References: <54BD5CDF.20602@linaro.org> <20150119202225.GA77414@onelab2.iet.unipi.it> In-Reply-To: <20150119202225.GA77414@onelab2.iet.unipi.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Holmes , Ciprian Barbu , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 12:22:26 -0000 On 19/01/15 20:22, Luigi Rizzo wrote: > On Mon, Jan 19, 2015 at 07:37:03PM +0000, Zoltan Kiss wrote: >> Hi, >> >> I'm using netmap on Ubuntu 14.04 (3.13.0-44 kernel, ixgbe 3.15.1-k), and >> I can't max out a 10G link with pktgen : >> >> Sent 1068122462 packets, 64 bytes each, in 84.29 seconds. >> Speed: 12.67 Mpps Bandwidth: 6.49 Gbps (raw 8.92 Gbps) >> >> The README says "ixgbe tops at about 12.5 Mpps unless the driver >> prefetches tx descriptors". I've checked the actual driver code, it does >> a prefetch(tx_desc) in the TX completion interrupt handler, is that what >> you mean? Top shows ksoftirqd eats up one core while the pktgen process >> is around 45% > > that comment is related to how the TXDCTL register > in the NIC is programmed, not the CPU's prefetch, and it applies > only to the case where you use only one queue to transmit. > With multiple tx queues you should be able to do line rate > regardless of that setting. > > However there are other things you might be hitting: > - if you have IOMMU enabled, that adds overhead to the memory mappings > and i seem to remember that caused a drop in the tx rate; > - try pkt-gen with sizes 60 and 64 (before CRC) to see if there is any > difference. Especially on the receive side, if the driver strips > the CRC, performance with 60 bytes is worse (and i assume you have > disabled flow control on both sender and receiver) > > Finally, we have seen degradation on recent linux kernels (> 3.5 i would say) > and this seems to be due to the driver disabling interrupt moderation > if the napi handler reports work has been completed. Since netmap > does almost nothing in the NAPI handler, the OS is confused and thinks > there is no load so it could as well optimize for low latency. > > A fix is to hardwire interrupt moderation to some 20-50us (not sure if > you can do it with ethtool, we tweaked the driver's code to avoid > the changes in moderation). That should deal with the high ksoftirq load. > > And finally, multiple ports on the same nic contend for PCIe bandwidth > so it is well possible that the bus does not have capacity > for full traffic on both ports. That was it! This is an HP SFP560+ card, which has a PCIe v2.0 x8 lane connecter. That should do 32 Gbit/s, which is enough for me (although not enough for the 40 Gbit/s dual-port full duplex traffic promised by HP explicitly in their marketing material, unless you take into account the ovehead of 8b/10b, which would be a gross lie ...) My problem was that this card was in a x16 lane slot, which was in practice a x4 lane slot only ... (I'll maybe write a mail to Lenovo that this was a bit mean, and they should mark it with some bigger letters than the usual labeling of the motherboard ...) Now I can receive 10Gbps both direction! Thanks for the tip Regards, Zoltan > > cheers > luigi > >> My problem gets even worse when I want to use the another port on this >> same dual port card to do receive back the traffic (I'm sending my >> packets through a device I want to test for switching performance). The >> sending performance drops down to 9.39 Mpps (6.61 Gbps), and the >> receiving goes this much as well. I'm trying to bind the threads to >> cores with "-a 3" and so, but they don't seem to obey based on top. The >> TX now uses ca 50% CPU while RX is %20, but they don't seem to run on >> their assigned CPU. >> My card is an Intel 82599ES, the CPU is i5-4570 @ 3.2GHz (no HT). Maybe >> the fact it is a workstation CPU contributes to this problem? >> >> All suggestions welcome! >> >> Regards, >> >> Zoltan Kiss >> _______________________________________________ >> 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 Jan 21 14:15: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 763F8F77 for ; Wed, 21 Jan 2015 14:15:01 +0000 (UTC) Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (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 34E28809 for ; Wed, 21 Jan 2015 14:15:00 +0000 (UTC) Received: from [62.232.251.194] (port=8284 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YDvjY-0001f3-Hu for freebsd-net@freebsd.org; Wed, 21 Jan 2015 13:54:14 +0000 From: Sara Dickinson Subject: RE: TCP Fast Open support Message-Id: <443B1306-D12A-463A-BBE7-A13FBAE4A466@sinodun.com> Date: Wed, 21 Jan 2015 13:54:16 +0000 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:15:01 -0000 Hi,=20 I am an application developer and I=E2=80=99m interested in using TCP = Fast Open, which now has an Experimental RFC = (https://datatracker.ietf.org/doc/rfc7413/ = ). IPv4 TFO has been = available in the Linux kernel since 3.7 and is on by default in 3.13, = IPv6 server support is in 3.16. I am trying to find out if TFO is likely = to be supported on FreeBSD? Is there any interest in this? Regards Sara.=20 ------------------------- Sara Dickinson http://sinodun.com From owner-freebsd-net@FreeBSD.ORG Wed Jan 21 14:16:26 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 309B4BF for ; Wed, 21 Jan 2015 14:16:26 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9DBC83F for ; Wed, 21 Jan 2015 14:16:25 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id k11so43393474wes.6 for ; Wed, 21 Jan 2015 06:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=VvT+Ozre3sLuY1DDevVqbYqulbhvVBQA0vu3oU0O00I=; b=ZlB3V0mPfKcOeUC8WWxRPscJbdjJv8HRweCWEcQeOff3zuoumGa8DtwWBlN3dxbUGG wNmj4MtPemqPSBmLGudm0ko5lmIvyW4C7OkSMAi8hIdoMGNM/ljqdzkxFcyeRt9GTM5k UWfwjwyrLVLx4VZa5Zh7rvKD+F/BlBTzM1q2/QpYlLpHtS2YZ6FeR0XMPccQNXIEaShP 93JZk7wSn2TGkbMQQvWr0BJ+NFak5AHUcFTARdA6qPVocVUemQoi8vUdfclvtZHCekdk LNqS8F8waCMxh8336c0oql9HzteDDdR6nZM8azfa1NLFFaRj0Jhl75UnLSW2odQTHCWG 8Aow== X-Received: by 10.180.104.9 with SMTP id ga9mr58211985wib.9.1421849782907; Wed, 21 Jan 2015 06:16:22 -0800 (PST) Received: from t510.bsoft-company.ro (ip5450aabf.adsl-surfen.hetnet.nl. [84.80.170.191]) by mx.google.com with ESMTPSA id dv9sm7460056wib.14.2015.01.21.06.16.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 06:16:22 -0800 (PST) Message-ID: <54BFB4B5.3070705@gmail.com> Date: Wed, 21 Jan 2015 15:16:21 +0100 From: Andrei Brezan User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: net@freebsd.org Subject: IPSEC MTU routing issue Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:16:26 -0000 Weird subject, maybe. I'm running FreeBSD-10.0-RELEASE with PF as firewall and racoon for IPSEC. The IPSEC tunnel is between the FreeBSD box and a Fortinet appliance. The IPSEC tunnel comes up and on a quick test it seems to be working, icmp between networks is ok, you can successfully telnet on services on the other side. However when you need to transfer some data strange things happen. I'm really trying to wrap my head around it and I still don't understand why it happens (http://pastebin.com/NAspcM9w). The packets smaller than 1260 and larger than 1417 are delivered to vlan103, the ones in between are not. If anyone has any idea why this might happen please shed some light. # tcpdump -nttti gif0 00:00:00.000000 IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id 21034, seq 1, length 1108 00:00:43.603248 IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id 22826, seq 1, length 1308 # tcpdump -nttti enc0 00:00:00.000000 (authentic,confidential): SPI 0x0d06e35d: IP 109.235.79.81 > 193.239.202.174: IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id 21034, seq 1, length 1108 (ipip-proto-4) 00:00:00.000139 (authentic,confidential): SPI 0x86741d6b: IP "e.f.g.h" > "a.b.c.d": ICMP echo reply, id 21034, seq 1, length 1108 00:00:00.000006 (authentic,confidential): SPI 0x86741d6b: IP 193.239.202.174 > 109.235.79.81: IP "e.f.g.h" > "a.b.c.d": ICMP echo reply, id 21034, seq 1, length 1108 (ipip-proto-4) 00:00:43.603102 (authentic,confidential): SPI 0x0d06e35d: IP 109.235.79.81 > 193.239.202.174: IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id 22826, seq 1, length 1308 (ipip-proto-4) # tcpdump -nttti vlan103 host "a.b.c.d" 00:00:00.000000 IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id 21034, seq 1, length 1108 00:00:00.000109 IP "e.f.g.h" > "a.b.c.d": ICMP echo reply, id 21034, seq 1, length 1108 Thanks, -- Andrei From owner-freebsd-net@FreeBSD.ORG Wed Jan 21 14:36: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 DA9605D0 for ; Wed, 21 Jan 2015 14:36:25 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69C49A68 for ; Wed, 21 Jan 2015 14:36:25 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so6482396wgg.4 for ; Wed, 21 Jan 2015 06:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:hackerspace:user-agent; bh=9a6YNB+dU39a/VaIEQw+QALG7mL2w4F16dHBNRS3+EU=; b=muAfMlrQFgcID2bRh+Z4ENTFA8pneT1EAlJGSN2RE12lzPEe9KzQ4VyzoqJKG5mBLl Lna+HanXUwy6c+plF7VsC+qB22RUeTMlsBCy70/IVwIy2x46qs1WwmXOCPc4d80xIkvV m8s7ahkoT9lbzgPAsb4cjEP6QLSf4SBMxhXo0r8od5/f/zzlF3xuvd4hSti58W9QbqMx bjTNk9Qq1Y62k4ZG/j41QhTkMpTdAMcr8XNUM9XzzXOBfASiWtOulzsVDlh144dCJTei R4r1ywI3G+drIY214FH2vUFv2cpw2slBL2pDtPHqHcsLWe+uZ79vsQdiHfxkW+XZYt9J gXTw== X-Received: by 10.180.91.201 with SMTP id cg9mr58421190wib.63.1421850983760; Wed, 21 Jan 2015 06:36:23 -0800 (PST) Received: from gmail.com (tom-imac.erg.abdn.ac.uk. [139.133.204.4]) by mx.google.com with ESMTPSA id gi12sm7507858wic.24.2015.01.21.06.36.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 06:36:23 -0800 (PST) Sender: Tom Jones Date: Wed, 21 Jan 2015 14:36:21 +0000 From: Tom Jones To: freebsd-net@freebsd.org Subject: Re: TCP Fast Open support Message-ID: <20150121143620.GC444@gmail.com> References: <443B1306-D12A-463A-BBE7-A13FBAE4A466@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <443B1306-D12A-463A-BBE7-A13FBAE4A466@sinodun.com> Hackerspace: 57North Hacklab User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:36:25 -0000 On Wed, Jan 21, 2015 at 01:54:16PM +0000, Sara Dickinson wrote: > Hi, > > I am an application developer and I’m interested in using TCP Fast Open, > which now has an Experimental RFC (https://datatracker.ietf.org/doc/rfc7413/ > ). IPv4 TFO has been available in > the Linux kernel since 3.7 and is on by default in 3.13, IPv6 server support > is in 3.16. I am trying to find out if TFO is likely to be supported on > FreeBSD? Is there any interest in this? You have voiced interest so that is the first step towards. Depending on how things go in $work in the next month I will start looking at an implementation. There are three experimental TCP modifications (NewCWV[1], PRR[2], TCP Stealth[3]) that have implementations, but have not seen any discussion. These are only the ones I know of, there might be others. These patches didn't really get any discussion, this makes me reluctant to put time into an implementation if it is just going to go stale on the list. [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 [2]: http://freebsd.1045724.n5.nabble.com/Patches-for-RFC6937-and-draft-ietf-tcpm-newcwv-00-td5882835.html [3]: https://gnunet.org/sites/default/files/tcp_stealth_freebsd_10_0_0.diff -- Tom @adventureloop adventurist.me :wq From owner-freebsd-net@FreeBSD.ORG Wed Jan 21 19: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 36944B2E for ; Wed, 21 Jan 2015 19:04:36 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE0C0E0D for ; Wed, 21 Jan 2015 19:04:35 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gf13so41924647lab.7 for ; Wed, 21 Jan 2015 11:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mRU2QlvTlZrLe1aPINziGCHcm+zTOHUB6KDutVnnxHM=; b=Wp3aJCHK5ktCl7DGdse5xRwphSRdCr9A1fOWBrUIAZuFmdPf4kuakE4eaJslm6Mmq1 wSzxgGhT/n5klE3Dlrs4QzTinZ8WPGnXKLwYMXtmL73is7Wj3X7UC8y0axGjHlGJq1Ru 8KX0zsDnxW2IK528Zph2sPTaqPMmoPU5MLM1Nye+mRZxRvCyPTpq6aNUg9Hx0k7qPLRA YrRLI5xTBL9vPZPdmwWB6U3tF41qLmNkTZh3sP5rz44jJXsoCDKc1Pwi6VL/CYBHavWi 241tsvusNHr+S/ItxWcOnWxuxCtLca0or24qJ93/KFrSi8c/rlBX8T2M6TOvUN6MReBD L2oA== MIME-Version: 1.0 X-Received: by 10.112.38.4 with SMTP id c4mr46322905lbk.46.1421867073137; Wed, 21 Jan 2015 11:04:33 -0800 (PST) Received: by 10.114.216.163 with HTTP; Wed, 21 Jan 2015 11:04:33 -0800 (PST) Date: Wed, 21 Jan 2015 11:04:33 -0800 Message-ID: Subject: Tuning net.inet.tcp.sendbuf_max From: javocado To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:04:36 -0000 System: FreeBSD 8.3 amd64 I've been trying to tune my system to a long route (RTT 180ms) and I've made 2 modifications and seeing some results which I cannot explain or understand. 1. kern.ipc.maxsockbuf: 262144 -> 4194304 Speed improves from 85 Mbps -> 100 Mbps I can run the test: iperf -c tserv20.hkg1.ipv6.he.net -t10 -P 10 all day long and consistently get 100Mbps 2. net.inet.tcp.sendbuf_max: 262144 -> 524288 1st run: 156Mbps BUT, on subsequent runs, just moment later, I see the speed drop off quickly with each successive run: 73 ... 50Mbps Simply returning sendbuf_max to the original value of 262144 does not return me to 100Mbps. Why is this? Setting net.inet.tcp.sendbuf_max, net.inet.tcp.recvbuf_max and kern.ipc.maxsockbuf to 4194304 also makes no difference. I noticed that the speed returned to 100Mbps when I set it back to 262144 and re-ran the test ~12hrs later. Is there some kind of buffer that needs to be cleared (or clears with enough time) so these changes have immediate effect when returning these sysctls to original values? From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 02:34: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 A4840A14 for ; Thu, 22 Jan 2015 02:34: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 8B85664E for ; Thu, 22 Jan 2015 02:34: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 t0M2YMCD050307 for ; Thu, 22 Jan 2015 02:34:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 188897] [dc] dc ethernet driver seems to prevent the detection of other NIC chipsets Date: Thu, 22 Jan 2015 02:34: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: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: clif@eugeneweb.com 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 attachments.created 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.18-1 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, 22 Jan 2015 02:34:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188897 clif@eugeneweb.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clif@eugeneweb.com --- Comment #6 from clif@eugeneweb.com --- Created attachment 151998 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=151998&action=edit a verbose dmesg listing with a dc quadport card on the PCI bus Here is dmsg output as requested. I used option 5 then 6 to turn on the verbose flag. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 02:41:06 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 08D6DBED for ; Thu, 22 Jan 2015 02:41:06 +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 E5379777 for ; Thu, 22 Jan 2015 02:41:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0M2f52P058531 for ; Thu, 22 Jan 2015 02:41:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Thu, 22 Jan 2015 02:41:05 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hrs@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: attachments.created 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.18-1 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, 22 Jan 2015 02:41:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 --- Comment #11 from Hiroki Sato --- Created attachment 151999 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=151999&action=edit a patch to fix this panic This patch should fix the panic. As Bjoern pointed out, ifnet_departure event on the lo0 interface calls bridge_ifdetach() when destroying a vnet jail. The problem is that vnet_bridge_uninit() can be called before it. The patch uses the fact that a vnet whose V_bridge_cloner == NULL is tearing down (or not initialized). I think it is safe to ignore this detach handler in that case. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 02:54:54 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 77AC8DD5 for ; Thu, 22 Jan 2015 02:54:54 +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 5F67D884 for ; Thu, 22 Jan 2015 02:54:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0M2ssG9005152 for ; Thu, 22 Jan 2015 02:54:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Thu, 22 Jan 2015 02:54:53 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hrs@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: 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.18-1 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, 22 Jan 2015 02:54:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 Hiroki Sato changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #12 from Hiroki Sato --- (In reply to Bjoern A. Zeeb from comment #10) > With all that the CURVET_SET/RESTORE question from comment #1 remains, > as to what happens if bridge_members in the normal case reside > in different VNETs (child jails)? Is it possible to have bridge members across different vnets? As long as using if_vmove(), member interfaces cannot be moved without detaching from the parent if_bridge(4) interface. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 02:56: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 CE417E7B for ; Thu, 22 Jan 2015 02:56: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 B62D1897 for ; Thu, 22 Jan 2015 02:56: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 t0M2uPgr005880 for ; Thu, 22 Jan 2015 02:56:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195859] Reproduceble panic with VIMAGE + if_bridge Date: Thu, 22 Jan 2015 02:56:26 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hrs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hrs@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.18-1 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, 22 Jan 2015 02:56:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 Hiroki Sato changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |hrs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 18:12:12 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 B83AD753 for ; Thu, 22 Jan 2015 18:12:12 +0000 (UTC) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 59434E76 for ; Thu, 22 Jan 2015 18:12:11 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id l61so3296088wev.8 for ; Thu, 22 Jan 2015 10:12:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dQgH48uzoouZXRuNfoQJCrTqAofKek3ZMRVwSQUvFQA=; b=QcYugda2fDt3eBPGwGyORtzYPvcIdotv9D2x6tgnlt03DmVZV4Bbi8bQcRjAXuDc4/ CkNcDkSBLne2Cxs+ETv+Padke54AS4ZK04+5iK9W1Jsjd8IfxYX77wfbi4uRPzUMDYnW Wg3P70UhwCv+DKrIxIHmM5GjYuUgiuEiaUBTQT9rXMZZFiXU7D15EMmpWqXitFpriCBu 6YMLZoyhBFpwHteU/+GswfN4eDmD7qExB7iReZeAv8oCxFUJUKyqX1hyoYmIBOB6he1R zrG7bCcACPPGtEXtZK9mN5xE/p3Hh2lM6Y2Da6gLiG/ddlMH4Nf6+7Vw2LYv/DxYgXS/ GVHA== X-Gm-Message-State: ALoCoQluqTnnkQbdjdzgiBaa7oKtcgSFCVTnbMDQ7GhaHXCo1pQn/R5j14vE2h0CrOAF5v9mTb8W MIME-Version: 1.0 X-Received: by 10.194.92.114 with SMTP id cl18mr5230973wjb.119.1421950330266; Thu, 22 Jan 2015 10:12:10 -0800 (PST) Received: by 10.180.97.161 with HTTP; Thu, 22 Jan 2015 10:12:10 -0800 (PST) Date: Thu, 22 Jan 2015 20:12:10 +0200 Message-ID: Subject: Netmap mempool From: Ciprian Barbu To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Jan 2015 18:12:12 -0000 Hello, I have some questions related to OpenDataPlane. I have implemented the I/O access using netmap for ODP but currently it's suffering from low performance due to packets being copied between the netmap slots and ODP buffers. I want to create ODP buffer pools on top of netmap memory but I'm concerned with three things: 1. how to keep a buffer for as long as needed without affecting the receive process; I guess I could use the NS_BUF_CHANGED flag in some way 2. the netmap memory may not be large enough to accommodate a complex ODP application 3. the ODP application may occasionally hold on to buffers for longer time Any help will be appreciated. Thank you, /Ciprian From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 19:03:27 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 31D712A3 for ; Thu, 22 Jan 2015 19:03:27 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 A6F5D676 for ; Thu, 22 Jan 2015 19:03:26 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id z12so3263916lbi.7 for ; Thu, 22 Jan 2015 11:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Dlo4EAThH99KhMxjnwUPhJflP0GHfqAVF54u9+JuOqw=; b=ph+2xkM3LLcwOaTBB5j3nvbP80VWXMNvMHRO6dxwit+YaBbNcLOuL0cv7oS25dnMnn Hw8wjR0BVYKS+B+FEfkQxctTQVOiLIGJ4a7yCf0TuaytdpZFKTYiYE6p53jzsAbQqXpp uqbYvujRpUqE9O1PA9tysNvw1PAiBvJ84+82Bc9zgdRLBWvDv2MIP8beugKHa4DNyRx4 APCqve5ZxPBoVcIZkRNkUNtJ58Otohoby6BnbUxn6eYmCNY5IqmRt7l7GqnalMBxNxlM jzv3Hg3yLzG3xyySQd4R4A9EyDyM02hY0G/KvU554ic1IR3fsnzKuUP0Q3oeBLDp31rd hKAQ== MIME-Version: 1.0 X-Received: by 10.112.98.99 with SMTP id eh3mr3174617lbb.32.1421953404749; Thu, 22 Jan 2015 11:03:24 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.10.168 with HTTP; Thu, 22 Jan 2015 11:03:24 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Jan 2015 11:03:24 -0800 X-Google-Sender-Auth: vbiTgRodEktQhy61ttlmxfl7t0w Message-ID: Subject: Re: Netmap mempool From: Luigi Rizzo To: Ciprian Barbu Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Jan 2015 19:03:27 -0000 On Thu, Jan 22, 2015 at 10:12 AM, Ciprian Barbu wrote: > Hello, > > I have some questions related to OpenDataPlane. I have implemented the > I/O access using netmap for ODP but currently it's suffering from low > performance due to packets being copied between the netmap slots and > ODP buffers. > > I want to create ODP buffer pools on top of netmap memory but I'm > concerned with three things: > 1. how to keep a buffer for as long as needed without affecting the > receive process; I guess I could use the NS_BUF_CHANGED flag in some > way > 2. the netmap memory may not be large enough to accommodate a complex > ODP application > 3. the ODP application may occasionally hold on to buffers for longer time > there is a way to hold buffers without returning them to the ring using the 'cur' pointer in the ring, see the netmap manpage how this is implemented and how it works on the tx and rx path. However, before embarking in zero copy i'd like you to elaborate on what you mean for "low performance" (how many pps you see) and what are your expectations. In my experience low performance almost always comes from insufficient batching or other application bottlenecks. Zero copy tricks come with great complications to track who owns what, sometimes with additional hidden overhead (e.g. if you change buffers the driver has to reprogram the IOMMU) and often have a very limited effect in real world applications. Sure the numbers do look good on benchmarks or academic papers, but there people don't worry about robustness and code maintainability. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 19:17:27 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 8478667E for ; Thu, 22 Jan 2015 19:17:27 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (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 47E14801 for ; Thu, 22 Jan 2015 19:17:27 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so20019686igb.0 for ; Thu, 22 Jan 2015 11:17:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=mXvRVa+dt9j5/MHau7LLDjPQK2tXJsEBeCxuK6jfWxk=; b=IfPKICW+h2UsSAbZbigMuZhM/BxilNZCbDjqjweJ2bJiKDoa16sRVSn1ga2mpscHVR BxP0NNLRU3NiIJt3YTpeDBCsESRQkVFVfyHqNYBUeE1ycNWq+/KMTiQPwSWhjo85CorS 75HjCJEhaeynF5h5qgvWfIt7IdE+xdv3i/XGhKxvjKa8SvhPC6Bm4Zdl+g5EcMHRuwJ2 +pRnicYOEliRZ++X1ZGgvwOlID8DgVumsHGLsWUdqDW1NdLIXl6nE1EW2EzogHpIC0KD RvZ1XKeVTAtK74nM25r+QUfwMtdH8xMCYBMNQ2IZwJDqF0kDfBxS7Ka3xTdmnVHUHokO d86g== X-Gm-Message-State: ALoCoQlHBkgepoOW9oFWy3lQ4aG4HlFn52oKoieiMm8K49b/XglvRAgnieXB/xkSbrauQ+BorAIV X-Received: by 10.50.111.10 with SMTP id ie10mr14675779igb.15.1421954245980; Thu, 22 Jan 2015 11:17:25 -0800 (PST) Received: from sol.firepipe.net (c-50-183-92-30.hsd1.co.comcast.net. [50.183.92.30]) by mx.google.com with ESMTPSA id fr4sm3523174igd.4.2015.01.22.11.17.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 11:17:25 -0800 (PST) Date: Thu, 22 Jan 2015 12:17:23 -0700 From: Will Andrews To: freebsd-net@freebsd.org Subject: MFC of if_lagg flowid changes (r272386)? Message-ID: <20150122191722.GB49380@sol.firepipe.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: adrian@freebsd.org, emax@freebsd.org, hrs@freebsd.org, asomers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Jan 2015 19:17:27 -0000 --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Please see: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D272386 This change removes sysctl nodes that were added during lacp_attach(), which causes a lock order reversal (sleepable lock while holding non-sleepable). These sysctl nodes arrived in: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D253687 Here is a bug report about the LOR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D188997 I propose to MFC r272386 to eliminate the bug. However, it also eliminates sysctl nodes that were added to control lagg behavior. My understanding is that these sysctls weren't intended to be publicly used, and consequently they aren't documented anywhere. Any objections? Thanks! --=20 wca --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTBTMEACgkQF47idPgWcsXRFACfc05RH6X5jjKVPZsEAzmOC1YF b/AAn1cBsmXvF2D+jGNlDTYCZiWcmFEW =TdhX -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 23:04:38 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 60BCAED for ; Thu, 22 Jan 2015 23:04:38 +0000 (UTC) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (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 18D2C2AE for ; Thu, 22 Jan 2015 23:04:38 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id f73so1782401yha.4 for ; Thu, 22 Jan 2015 15:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QWQDdqCvcuTP1lDY/ZmzpND9mB6jPY2QfRrCixZm0T8=; b=HV/7L00obERCowRMluFRjyRymT65vGtl6nTVanpnatx3L5dUI1fICKTU7BeAr71zyL rg6akFRQdBJ6rFgwbZOwNGKt9iuBU2UtwA1Nc5vc6XzdtepGirU+i8XTWotCexNOZhfF DEOliRfKsl2Resnh0sVToVnJKZqaeFsL1jc8PMLlLCZe6TXnvDmg5wb6rEHICPqkZP6X lQ+NHSqje62+FqoJ9ConEfyZqJ6jkTO7EPneBZqY5OVDjGpAQqLVItXC+sTctDuuOfsU WE6wN/0J8zECaVfO0wQ9N+Mnlxd0ea4QTcdUam1sIy6WaT8TEgTs9IgWvmOhmhpvGMmR gLHQ== MIME-Version: 1.0 X-Received: by 10.170.44.4 with SMTP id 4mr2193586ykm.101.1421967877317; Thu, 22 Jan 2015 15:04:37 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.70.132 with HTTP; Thu, 22 Jan 2015 15:04:37 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Jan 2015 15:04:37 -0800 X-Google-Sender-Auth: eFVZFDKoTIwwSi8WUJ6l81-EvtA Message-ID: Subject: Re: Tuning net.inet.tcp.sendbuf_max From: "K. Macy" To: javocado Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Jan 2015 23:04:38 -0000 TCP host cache? See netinet/tcp_hostcache.c for any fiddling that needs doing. Let me know if there are any values that should be exported as sysctls. -K SYSCTL_INT(_net_inet_tcp_hostcache, OID_AUTO, expire, CTLFLAG_VNET | CTLFLAG_RW, &VNET_NAME(tcp_hostcache.expire), 0, "Expire time of TCP hostcache entries"); SYSCTL_INT(_net_inet_tcp_hostcache, OID_AUTO, prune, CTLFLAG_VNET | CTLFLAG_RW, &VNET_NAME(tcp_hostcache.prune), 0, "Time between purge runs"); SYSCTL_INT(_net_inet_tcp_hostcache, OID_AUTO, purge, CTLFLAG_VNET | CTLFLAG_RW, &VNET_NAME(tcp_hostcache.purgeall), 0, "Expire all entires on next purge run"); /* * The tcp_hostcache moves the tcp-specific cached metrics from the routing * table to a dedicated structure indexed by the remote IP address. It keeps * information on the measured TCP parameters of past TCP sessions to allow * better initial start values to be used with later connections to/from the * same source. Depending on the network parameters (delay, bandwidth, max * MTU, congestion window) between local and remote sites, this can lead to * significant speed-ups for new TCP connections after the first one. * * Due to the tcp_hostcache, all TCP-specific metrics information in the * routing table have been removed. The inpcb no longer keeps a pointer to * the routing entry, and protocol-initiated route cloning has been removed * as well. With these changes, the routing table has gone back to being * more lightwight and only carries information related to packet forwarding. * * tcp_hostcache is designed for multiple concurrent access in SMP * environments and high contention. All bucket rows have their own lock and * thus multiple lookups and modifies can be done at the same time as long as * they are in different bucket rows. If a request for insertion of a new * record can't be satisfied, it simply returns an empty structure. Nobody * and nothing outside of tcp_hostcache.c will ever point directly to any * entry in the tcp_hostcache. All communication is done in an * object-oriented way and only functions of tcp_hostcache will manipulate * hostcache entries. Otherwise, we are unable to achieve good behaviour in * concurrent access situations. Since tcp_hostcache is only caching * information, there are no fatal consequences if we either can't satisfy * any particular request or have to drop/overwrite an existing entry because * of bucket limit memory constrains. */ On Wed, Jan 21, 2015 at 11:04 AM, javocado wrote: > System: FreeBSD 8.3 amd64 > > I've been trying to tune my system to a long route (RTT 180ms) and I've > made 2 modifications and seeing some results which I cannot explain or > understand. > > 1. kern.ipc.maxsockbuf: 262144 -> 4194304 > > Speed improves from 85 Mbps -> 100 Mbps > > I can run the test: iperf -c tserv20.hkg1.ipv6.he.net -t10 -P 10 > > all day long and consistently get 100Mbps > > > 2. net.inet.tcp.sendbuf_max: 262144 -> 524288 > > 1st run: 156Mbps > > BUT, on subsequent runs, just moment later, I see the speed drop off > quickly with each successive run: > > 73 ... 50Mbps > > > Simply returning sendbuf_max to the original value of 262144 does not > return me to 100Mbps. Why is this? > Setting net.inet.tcp.sendbuf_max, net.inet.tcp.recvbuf_max > and kern.ipc.maxsockbuf to 4194304 also makes no difference. > > I noticed that the speed returned to 100Mbps when I set it back to 262144 > and re-ran the test ~12hrs later. Is there some kind of buffer that needs > to be cleared (or clears with enough time) so these changes have immediate > effect when returning these sysctls to original values? > _______________________________________________ > 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 Jan 22 23:51: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 D640BB3F for ; Thu, 22 Jan 2015 23:51:26 +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 BD9A197B for ; Thu, 22 Jan 2015 23:51:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0MNpQJ4087365 for ; Thu, 22 Jan 2015 23:51:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196788] Log rotation non-existent for opensm; opensm expects SIGUSR1, not SIGHUP Date: Thu, 22 Jan 2015 23:51:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People 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.18-1 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, 22 Jan 2015 23:51:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196788 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Thu Jan 22 23:50:49 UTC 2015 New revision: 277541 URL: https://svnweb.freebsd.org/changeset/base/277541 Log: Add sample log rotation support for opensm Up to 7 archives of the log will be kept (just for consistency with the other log rotation rules) PR: 196788 MFC after: 1 week Reviewed by: hselasky Sponsored by: EMC / Isilon Storage Division Changes: head/etc/Makefile head/etc/newsyslog.conf.d/ head/etc/newsyslog.conf.d/Makefile head/etc/newsyslog.conf.d/opensm.conf -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Jan 22 23:52:00 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 324F8BE0 for ; Thu, 22 Jan 2015 23:52:00 +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 1892F98A for ; Thu, 22 Jan 2015 23:52:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0MNpxNn094625 for ; Thu, 22 Jan 2015 23:51:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196788] Log rotation non-existent for opensm; opensm expects SIGUSR1, not SIGHUP Date: Thu, 22 Jan 2015 23:52:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ngie@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable8- mfc-stable9+ mfc-stable10+ X-Bugzilla-Changed-Fields: bug_status assigned_to flagtypes.name 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.18-1 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, 22 Jan 2015 23:52:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196788 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-net@FreeBSD.org |ngie@FreeBSD.org Flags| |mfc-stable8-, mfc-stable9+, | |mfc-stable10+ -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Jan 23 01:50:54 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 49A44D1D; Fri, 23 Jan 2015 01:50:54 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D1596662; Fri, 23 Jan 2015 01:50:51 +0000 (UTC) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id t0N1n0vQ057578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Jan 2015 09:49:01 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id t0N1mlD0057577; Fri, 23 Jan 2015 09:48:47 +0800 (CST) (envelope-from kevlo) Date: Fri, 23 Jan 2015 09:48:45 +0800 From: Kevin Lo To: Will Andrews Subject: Re: MFC of if_lagg flowid changes (r272386)? Message-ID: <20150123014845.GA57563@ns.kevlo.org> References: <20150122191722.GB49380@sol.firepipe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150122191722.GB49380@sol.firepipe.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, adrian@freebsd.org, hrs@freebsd.org, emax@freebsd.org, asomers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Jan 2015 01:50:54 -0000 On Thu, Jan 22, 2015 at 12:17:23PM -0700, Will Andrews wrote: > Hi, > > Please see: > https://svnweb.freebsd.org/base?view=revision&revision=272386 > > This change removes sysctl nodes that were added during lacp_attach(), which > causes a lock order reversal (sleepable lock while holding non-sleepable). > > These sysctl nodes arrived in: > https://svnweb.freebsd.org/base?view=revision&revision=253687 > > Here is a bug report about the LOR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188997 > > I propose to MFC r272386 to eliminate the bug. However, it also eliminates > sysctl nodes that were added to control lagg behavior. My understanding is > that these sysctls weren't intended to be publicly used, and consequently > they aren't documented anywhere. The strict mode for LACP can be disabled by ifconfig(8): #ifconfig lagg0 -lacp_strict hrs@ told me he would add lacp_strict option to the manual page. > Any objections? No. :-) > Thanks! > -- > wca Kevin From owner-freebsd-net@FreeBSD.ORG Fri Jan 23 10:53:28 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 5CF8CCB9 for ; Fri, 23 Jan 2015 10:53:28 +0000 (UTC) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (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 ED06314D for ; Fri, 23 Jan 2015 10:53:27 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q59so6843172wes.10 for ; Fri, 23 Jan 2015 02:53:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G2qcTnMn9qlZz6GwYbUX4yooocS78za+qXQgOKjEzkw=; b=iBVxSvknyWerH+smqsqAiWfqh5DP0HKhGH3qqqalbl+YmYxTE0SNtYUGuuy6BcWVxb gyGLEFOD5ItY/+cgMBSIah6YgYcIJshnNV5GXNWQEDDneSPYi+gv3pD2sALnJDtEgh2o 1dwc/ZRoaLuYObOXT7WqJxJqswh5zx+04SrCazCt5/+rBXyAcj+aqKJoZ55tFX8Pxuji ZA8bVzbMk091p+UquxYCpypJGXJd2HeNEMrtNP7Ze/fV3mWQ2/6RZOOcSC9I6Bvi0b1f nreY6tqoqpFnA+aOIgqUNMgruhYJCs22wUm4WBSYaqDbMDgKg4TKLSjEmZCurkBtukyi 4qLw== X-Gm-Message-State: ALoCoQll5Eh/P2q2SPCe2bCJ105MAN7q+Ml+ZL4dG7VWY7OCVYvZ234j1BN+IlA2PpObRK4rBZOw MIME-Version: 1.0 X-Received: by 10.181.12.112 with SMTP id ep16mr2603314wid.38.1422010400533; Fri, 23 Jan 2015 02:53:20 -0800 (PST) Received: by 10.180.97.161 with HTTP; Fri, 23 Jan 2015 02:53:20 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 12:53:20 +0200 Message-ID: Subject: Re: Netmap mempool From: Ciprian Barbu To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Jan 2015 10:53:28 -0000 On Thu, Jan 22, 2015 at 9:03 PM, Luigi Rizzo wrote: > On Thu, Jan 22, 2015 at 10:12 AM, Ciprian Barbu > wrote: >> Hello, >> >> I have some questions related to OpenDataPlane. I have implemented the >> I/O access using netmap for ODP but currently it's suffering from low >> performance due to packets being copied between the netmap slots and >> ODP buffers. >> >> I want to create ODP buffer pools on top of netmap memory but I'm >> concerned with three things: >> 1. how to keep a buffer for as long as needed without affecting the >> receive process; I guess I could use the NS_BUF_CHANGED flag in some >> way >> 2. the netmap memory may not be large enough to accommodate a complex >> ODP application >> 3. the ODP application may occasionally hold on to buffers for longer time >> > > there is a way to hold buffers without returning them to the ring > using the 'cur' pointer in the ring, see the netmap manpage how this > is implemented and how it works on the tx and rx path. > > However, before embarking in zero copy i'd like you to elaborate on what > you mean for "low performance" (how many pps you see) and what are > your expectations. In my experience low performance almost always comes > from insufficient batching or other application bottlenecks. I didn't do exact measurements, but there seemed to be a bottleneck somewhere, I will have another look, maybe I missed something. > > Zero copy tricks come with great complications to track who owns what, > sometimes with additional hidden overhead (e.g. if you change buffers the driver > has to reprogram the IOMMU) and often have a very limited effect > in real world applications. > > Sure the numbers do look good on benchmarks or academic papers, but there > people don't worry about robustness and code maintainability. > > cheers > luigi From owner-freebsd-net@FreeBSD.ORG Fri Jan 23 14:19:43 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 1722B307 for ; Fri, 23 Jan 2015 14:19:43 +0000 (UTC) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8357EB65 for ; Fri, 23 Jan 2015 14:19:41 +0000 (UTC) Received: from nono (nono.zen.inc [192.168.1.95]) by smtp.zeninc.net (smtpd) with ESMTP id 119022798C4; Fri, 23 Jan 2015 15:13:38 +0100 (CET) Received: by nono (Postfix, from userid 1000) id E5F93202C4; Fri, 23 Jan 2015 15:13:37 +0100 (CET) Date: Fri, 23 Jan 2015 15:13:37 +0100 From: VANHULLEBUS Yvan To: Andrei Brezan Subject: Re: IPSEC MTU routing issue Message-ID: <20150123141337.GA13989@zeninc.net> References: <54BFB4B5.3070705@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BFB4B5.3070705@gmail.com> User-Agent: All mail clients suck. This one just sucks less. Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Jan 2015 14:19:43 -0000 Hi. On Wed, Jan 21, 2015 at 03:16:21PM +0100, Andrei Brezan wrote: > Weird subject, maybe. > > I'm running FreeBSD-10.0-RELEASE with PF as firewall and racoon for > IPSEC. The IPSEC tunnel is between the FreeBSD box and a Fortinet > appliance. > > The IPSEC tunnel comes up and on a quick test it seems to be > working, icmp between networks is ok, you can successfully telnet on > services on the other side. However when you need to transfer some > data strange things happen. I'm really trying to wrap my head around > it and I still don't understand why it happens > (http://pastebin.com/NAspcM9w). The packets smaller than 1260 and > larger than 1417 are delivered to vlan103, the ones in between are > not. I'm not sure why do you have this strange issue. Having a look at your IPsec/ESP related kernel stats may give a first idea. But I know that, even if you find a fix for this, you'll have very poor performances as soon as packets start to be fragmented, and your data transferts may just stall forever. So, the usual way of solving that is to change the TCPMSS "low enough" on the fly for all IPsec related trafic. 1300 is a common value, low enough to avoid fragmentation, and high enough to keep good throughput. Of course, this will only works for TCP, but most big packets / long flows are done on TCP. Yvan. > If anyone has any idea why this might happen please shed some light. > > # tcpdump -nttti gif0 > > 00:00:00.000000 IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id > 21034, seq 1, length 1108 > 00:00:43.603248 IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id > 22826, seq 1, length 1308 > > # tcpdump -nttti enc0 > > 00:00:00.000000 (authentic,confidential): SPI 0x0d06e35d: IP > 109.235.79.81 > 193.239.202.174: IP "a.b.c.d" > "e.f.g.h": ICMP echo > request, id 21034, seq 1, length 1108 (ipip-proto-4) > 00:00:00.000139 (authentic,confidential): SPI 0x86741d6b: IP > "e.f.g.h" > "a.b.c.d": ICMP echo reply, id 21034, seq 1, length 1108 > 00:00:00.000006 (authentic,confidential): SPI 0x86741d6b: IP > 193.239.202.174 > 109.235.79.81: IP "e.f.g.h" > "a.b.c.d": ICMP echo > reply, id 21034, seq 1, length 1108 (ipip-proto-4) > 00:00:43.603102 (authentic,confidential): SPI 0x0d06e35d: IP > 109.235.79.81 > 193.239.202.174: IP "a.b.c.d" > "e.f.g.h": ICMP echo > request, id 22826, seq 1, length 1308 (ipip-proto-4) > > # tcpdump -nttti vlan103 host "a.b.c.d" > > 00:00:00.000000 IP "a.b.c.d" > "e.f.g.h": ICMP echo request, id > 21034, seq 1, length 1108 > 00:00:00.000109 IP "e.f.g.h" > "a.b.c.d": ICMP echo reply, id 21034, > seq 1, length 1108 > > Thanks, > > -- > Andrei > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jan 23 14:27: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 800B3440 for ; Fri, 23 Jan 2015 14:27:40 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 F3CA8C41 for ; Fri, 23 Jan 2015 14:27:39 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id hs14so1211286lab.9 for ; Fri, 23 Jan 2015 06:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=Z8LyWWS3rW5heIWLIdWQHvElL2WY7yrD/6WmTgJxJr0=; b=qgXacY8PsFtgN9M6gjcrsEJ3MNDxbmLeID00J8kD9lAvgz/ViClNMadNp2Jd6BQ/TO HeiP2Q013lvFz4DJZhHjpGWQmWV8+Bp2X6loPV/NtukcOYNoFz7apLP0UJAS8TtDP7Kq rq4ZCSHnpIHpQdHQZZCkDGVSZI+nxvTXir2pGxCNlrQ82zmHVgd9mwNtenZvor+YupwV uL3tm/53DQmjL3ec+ZBzU8X8EzBzLqrExSywa75BFWPdme1YALGpVKPIWbjp/zCpuYvU Y5xyAHd7tefkZhaxIZSqNWDNA0M5uvV/AAt6vBq8kz/A08NwCS/ffdh752vZYd5ELDJ7 4MlA== X-Received: by 10.112.43.66 with SMTP id u2mr7675712lbl.35.1422023258046; Fri, 23 Jan 2015 06:27:38 -0800 (PST) Received: from ?IPv6:2a02:6b8::408:d925:d61d:c40f:503? ([2a02:6b8:0:408:d925:d61d:c40f:503]) by mx.google.com with ESMTPSA id qr10sm483870lbb.30.2015.01.23.06.27.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 06:27:36 -0800 (PST) From: Dmitry Sivachenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: network locks up with udp traffic Message-Id: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> Date: Fri, 23 Jan 2015 17:27:33 +0300 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Jan 2015 14:27:40 -0000 Hello! I am using FreeBSD-10/stable. We have a program at work that transmits = data via UDP. When I run several instances of this program simultaneously, after a few = seconds network stops working. If I login from console, I see some network daemons like ntpd, snmpd are = in "*udp" state. If I try to deal with network interface (ifconfig igb0 for instance), = ifconfig utility stuck in "L" state (Marks a process that is waiting to = acquire a lock.). I found the only way to fix that: reboot. What can be the cause for such a behaviour? Thanks.= From owner-freebsd-net@FreeBSD.ORG Fri Jan 23 15:45:19 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 39E34987 for ; Fri, 23 Jan 2015 15:45:19 +0000 (UTC) Received: from troll.free.org (troll6.free.org [IPv6:2001:bc8:803:1::58bf:fc8c]) (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 046867E9 for ; Fri, 23 Jan 2015 15:45:18 +0000 (UTC) Received: by troll.free.org (Postfix, from userid 500) id 6053D1E0F2F; Fri, 23 Jan 2015 16:45:08 +0100 (CET) Date: Fri, 23 Jan 2015 16:45:08 +0100 From: Laurent Frigault To: freebsd-net@freebsd.org Subject: BGE IPMI regression Message-ID: <20150123154508.GA58966@troll.free.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline X-Powered-By: UUCP User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Jan 2015 15:45:19 -0000 Hi, I have found a regression in BGE driver under 10.1 . IPMI access is disabled after bge driver is loaded even with hw.bge.allow_asf set to 1 (default ) . I open a bug to describe it under Bug 196944 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196944 Any hint to work arround it ? Regards, -- Laurent Frigault | Free.org From owner-freebsd-net@FreeBSD.ORG Fri Jan 23 18:58:09 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 C05EBEF for ; Fri, 23 Jan 2015 18:58:09 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 8795BC7 for ; Fri, 23 Jan 2015 18:58:09 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hl2so3490942igb.3 for ; Fri, 23 Jan 2015 10:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bvoDhz4ps94o1COIUlY+t45/AtWjZMbTGGV8fk5UWPI=; b=YrWaVrvC6ceoSe0RWuXddMhSjGmBwqQuOvvnOLeeFFarJD44yjmWkz5XyHkudYQclK VMqbw2Yp//OAKvd4PeJfjrpH1GscCXXk//MHxNeOLsr+yhd9/Y0b4Yjee2E/UKxi72WJ YoCAZ4oKu51gFnhsOrWWaayfA5LIJRopOjyqP1av43rpvFemp5jPLqCdfDkYRAD6xEde xF4HaTnvQuWI1y6lAqsrcWqppEw35uZ+TnueHlPwYBjFXBHi6AkJGEM4XnDxaNT/yjwL EqQp6dqyIc0gmBzU64B2brrkxsNkPkfR1x4C+gfL9o+WC0ToGN+fk88tS190xxmCrTZ+ /+hA== MIME-Version: 1.0 X-Received: by 10.107.169.222 with SMTP id f91mr5298156ioj.88.1422039489016; Fri, 23 Jan 2015 10:58:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Fri, 23 Jan 2015 10:58:08 -0800 (PST) In-Reply-To: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> Date: Fri, 23 Jan 2015 10:58:08 -0800 X-Google-Sender-Auth: -9QGIfFkNNEc_kOE0_hfIRmz_88 Message-ID: Subject: Re: network locks up with udp traffic From: Adrian Chadd To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Jan 2015 18:58:09 -0000 Hi, When this next happens, please do this as root: procstat -ka That'll hopefully provide enough information to figure out which processes are blocking where and how they got there. -a On 23 January 2015 at 06:27, Dmitry Sivachenko wrote: > Hello! > > I am using FreeBSD-10/stable. We have a program at work that transmits data via UDP. > When I run several instances of this program simultaneously, after a few seconds network stops working. > If I login from console, I see some network daemons like ntpd, snmpd are in "*udp" state. > > If I try to deal with network interface (ifconfig igb0 for instance), ifconfig utility stuck in "L" state (Marks a process that is waiting to acquire a lock.). > I found the only way to fix that: reboot. > > What can be the cause for such a behaviour? > > Thanks. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 10:14:53 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 3A0F6C3F; Sat, 24 Jan 2015 10:14:53 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E364CEE; Sat, 24 Jan 2015 10:14:52 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id hs14so1364999lab.9; Sat, 24 Jan 2015 02:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=dcRyQ4/MKhGF0uxjWdxwvUt58ZLlR0kuyhRHoGf5WFI=; b=sDWcGzokkhammN1NY1ex4P33Q5kF4xaJpWdJIkRNCQEXII7VWqlQwmxe5OiJIzW4It qUMjXBt5ODnjFBWLwWaVtwyTju7JTnwm2D/l4wbqUAsK43AEuRQXNB4PVHHoE0JyKX6G k+rTVE2emwWWimFp95sqfiKeNTmyCX2xvSB0QrhxNZZbtpELlBtH7RamK8VwGzy2RbFk 5Qt7YjY2gqFA44jvjHu1zfYF2ZP3VeJr0ycQKdStgxw1Sm6uaYlp6aY5n92f0gq01KgS GUr9IG/EKPLDtXuc885weazJJDTyHlwBGRU1Yr0gfGXlOtuPGQntvdE3PBGE8eYwBbWk COjQ== X-Received: by 10.153.7.100 with SMTP id db4mr11752596lad.79.1422094490534; Sat, 24 Jan 2015 02:14:50 -0800 (PST) Received: from [10.0.1.7] (broadband-5-228-253-40.nationalcablenetworks.ru. [5.228.253.40]) by mx.google.com with ESMTPSA id qe1sm1098971lbc.27.2015.01.24.02.14.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 02:14:48 -0800 (PST) Content-Type: multipart/mixed; boundary="Apple-Mail=_79DA52FF-9FBC-4D87-8F73-943E5F2BFA0A" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: network locks up with udp traffic From: Dmitry Sivachenko In-Reply-To: Date: Sat, 24 Jan 2015 13:14:46 +0300 Message-Id: References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 10:14:53 -0000 --Apple-Mail=_79DA52FF-9FBC-4D87-8F73-943E5F2BFA0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 21:58, Adrian Chadd = wrote: >=20 > Hi, >=20 > When this next happens, please do this as root: >=20 > procstat -ka >=20 > That'll hopefully provide enough information to figure out which > processes are blocking where and how they got there. >=20 >=20 Hello, I am attaching procstat -ka output (and top output to see snmpd process = in "*udp" state). ifconfig process was started with "net0" argument (net0 is a renamed = igb0 in my case). --Apple-Mail=_79DA52FF-9FBC-4D87-8F73-943E5F2BFA0A Content-Disposition: attachment; filename=top1.txt Content-Type: text/plain; name="top1.txt" Content-Transfer-Encoding: quoted-printable last pid: 4686; load averages: 0.71, 0.69, 0.68 up 0+03:44:32 = 12:53:43 55 processes: 1 running, 52 sleeping, 2 lock Mem: 4647M Active, 37G Inact, 2293M Wired, 635M Cache, 1655M Buf, 1985M = Free Swap: 49G Total, 29M Used, 49G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 4658 mitya 9 21 0 1099M 521M uwait 3 0:30 0.00% = ngram_m 4656 mitya 9 21 0 843M 566M uwait 15 0:30 0.00% = ngram_m 4660 mitya 9 20 0 1100M 523M uwait 5 0:26 0.00% = ngram_m 4659 mitya 9 21 0 764M 486M uwait 4 0:19 0.00% = ngram_m 4662 mitya 9 20 0 678M 441M uwait 5 0:18 0.00% = ngram_m 4661 mitya 9 21 0 772M 491M uwait 4 0:18 0.00% = ngram_m 4657 mitya 9 20 0 762M 484M uwait 3 0:17 0.00% = ngram_m 4666 mitya 9 20 0 678M 440M uwait 15 0:17 0.00% = ngram_m 4663 mitya 9 20 0 682M 448M uwait 4 0:17 0.00% = ngram_m 4665 mitya 9 20 0 688M 446M uwait 14 0:17 0.00% = ngram_m 4664 mitya 9 20 0 673M 432M uwait 14 0:15 0.00% = ngram_m 830 root 1 20 0 64512K 4244K *udp 3 0:06 0.00% = snmpd 660 root 1 20 0 14508K 1312K select 5 0:00 0.00% = syslogd 912 root 11 20 0 83972K 3616K uwait 7 0:00 0.00% = collect 864 root 2 20 0 123M 24324K select 15 0:00 0.00% = ruby19 810 root 1 20 0 25456K 2220K select 4 0:00 0.00% = ntpd 874 www 1 20 0 28616K 2324K kqread 12 0:00 0.00% = nginx 875 www 1 20 0 28616K 2324K kqread 14 0:00 0.00% = nginx --Apple-Mail=_79DA52FF-9FBC-4D87-8F73-943E5F2BFA0A Content-Disposition: attachment; filename=procstat1.txt Content-Type: text/plain; name="procstat1.txt" Content-Transfer-Encoding: quoted-printable PID TID COMM TDNAME KSTACK = =20 0 100000 kernel swapper mi_switch = sleepq_timedwait _sleep swapper btext=20 0 100055 kernel firmware taskq mi_switch sleepq_wait = _sleep taskqueue_thread_loop fork_exit fork_trampoline=20 0 100059 kernel thread taskq mi_switch sleepq_wait = _sleep taskqueue_thread_loop fork_exit fork_trampoline=20 0 100060 kernel ffs_trim taskq mi_switch sleepq_wait = _sleep taskqueue_thread_loop fork_exit fork_trampoline=20 0 100065 kernel aiod_bio taskq mi_switch sleepq_wait = _sleep taskqueue_thread_loop fork_exit fork_trampoline=20 0 100066 kernel acpi_task_0 mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100067 kernel acpi_task_1 mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100068 kernel acpi_task_2 mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100069 kernel kqueue taskq mi_switch sleepq_wait = _sleep taskqueue_thread_loop fork_exit fork_trampoline=20 0 100087 kernel em0 rxq mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100089 kernel em0 txq mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100092 kernel em1 rxq mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100094 kernel em1 txq mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100136 kernel mca taskq mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100138 kernel dummynet mi_switch sleepq_wait = msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline=20 0 100139 kernel CAM taskq mi_switch sleepq_wait = _sleep taskqueue_thread_loop fork_exit fork_trampoline=20 1 100001 init - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_wait6 sys_wait4 = amd64_syscall Xfast_syscall=20 2 100062 cam doneq0 mi_switch sleepq_wait = _sleep xpt_done_td fork_exit fork_trampoline=20 2 100063 cam doneq1 mi_switch sleepq_wait = _sleep xpt_done_td fork_exit fork_trampoline=20 2 100064 cam doneq2 mi_switch sleepq_wait = _sleep xpt_done_td fork_exit fork_trampoline=20 2 100140 cam scanner mi_switch sleepq_wait = _sleep xpt_scanner_thread fork_exit fork_trampoline=20 3 100137 sctp_iterator - mi_switch sleepq_wait = _sleep sctp_iterator_thread fork_exit fork_trampoline=20 4 100141 ipmi0: kcs - mi_switch sleepq_wait = _cv_wait ipmi_dequeue_request kcs_loop fork_exit fork_trampoline=20 5 100142 enc_daemon0 - mi_switch sleepq_wait = _sleep enc_daemon fork_exit fork_trampoline=20 6 100143 enc_daemon1 - mi_switch sleepq_wait = _sleep enc_daemon fork_exit fork_trampoline=20 7 100144 enc_daemon2 - mi_switch sleepq_wait = _sleep enc_daemon fork_exit fork_trampoline=20 8 100145 g_mirror root - mi_switch sleepq_wait = _sleep g_mirror_worker fork_exit fork_trampoline=20 9 100146 g_mirror var - mi_switch sleepq_wait = _sleep g_mirror_worker fork_exit fork_trampoline=20 10 100002 idle idle: cpu0 = =20 10 100003 idle idle: cpu1 = =20 10 100004 idle idle: cpu2 = =20 10 100005 idle idle: cpu3 = =20 10 100006 idle idle: cpu4 = =20 10 100007 idle idle: cpu5 = =20 10 100008 idle idle: cpu6 = =20 10 100009 idle idle: cpu7 = =20 10 100010 idle idle: cpu8 = =20 10 100011 idle idle: cpu9 = =20 10 100012 idle idle: cpu10 = =20 10 100013 idle idle: cpu11 = =20 10 100014 idle idle: cpu12 = =20 10 100015 idle idle: cpu13 = =20 10 100016 idle idle: cpu14 mi_switch critical_exit = sched_idletd fork_exit fork_trampoline=20 10 100017 idle idle: cpu15 = =20 11 100018 intr swi1: netisr 0 mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100019 intr swi4: clock mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100020 intr swi4: clock = =20 11 100021 intr swi4: clock = =20 11 100022 intr swi4: clock = =20 11 100023 intr swi4: clock = =20 11 100024 intr swi4: clock = =20 11 100025 intr swi4: clock = =20 11 100026 intr swi4: clock = =20 11 100027 intr swi4: clock = =20 11 100028 intr swi4: clock = =20 11 100029 intr swi4: clock = =20 11 100030 intr swi4: clock = =20 11 100031 intr swi4: clock = =20 11 100032 intr swi4: clock = =20 11 100033 intr swi4: clock = =20 11 100034 intr swi4: clock = =20 11 100035 intr swi3: vm = =20 11 100057 intr swi6: task queue mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100058 intr swi6: Giant task mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100061 intr swi5: fast taskq = =20 11 100070 intr irq256: mfi0 mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100071 intr irq16: uhci0 uhc = =20 11 100076 intr irq21: uhci1 = =20 11 100081 intr irq18: ehci0 uhc mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100086 intr irq257: em0:rx 0 = =20 11 100088 intr irq258: em0:tx 0 = =20 11 100090 intr irq259: em0:link = =20 11 100091 intr irq260: em1:rx 0 mi_switch turnstile_wait = __rw_rlock in6_pcblookup_hash udp6_input ip6_input netisr_dispatch_src = ether_demux ether_nh_input netisr_dispatch_src em_rxeof em_msix_rx = intr_event_execute_handlers ithread_loop fork_exit fork_trampoline=20 11 100093 intr irq261: em1:tx 0 mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100095 intr irq262: em1:link mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100096 intr irq23: uhci2 ehc = =20 11 100101 intr irq19: uhci3 = =20 11 100118 intr irq263: ahci0:ch mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100119 intr irq264: ahci0:ch mi_switch ithread_loop = fork_exit fork_trampoline=20 11 100120 intr irq265: ahci0:ch = =20 11 100121 intr irq266: ahci0:ch = =20 11 100122 intr irq267: ahci0:ch = =20 11 100123 intr irq268: ahci0:ch = =20 11 100124 intr irq269: ahci0:6 = =20 11 100125 intr irq270: ahci0:7 = =20 11 100126 intr irq271: ahci0:8 = =20 11 100127 intr irq272: ahci0:9 = =20 11 100128 intr irq273: ahci0:10 = =20 11 100129 intr irq274: ahci0:11 = =20 11 100130 intr irq275: ahci0:12 = =20 11 100131 intr irq276: ahci0:13 = =20 11 100132 intr irq277: ahci0:14 = =20 11 100133 intr irq278: ahci0:15 = =20 11 100134 intr swi0: uart uart = =20 11 100135 intr irq1: atkbd0 = =20 12 100036 ng_queue ng_queue0 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100037 ng_queue ng_queue1 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100038 ng_queue ng_queue2 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100039 ng_queue ng_queue3 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100040 ng_queue ng_queue4 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100041 ng_queue ng_queue5 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100042 ng_queue ng_queue6 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100043 ng_queue ng_queue7 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100044 ng_queue ng_queue8 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100045 ng_queue ng_queue9 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100046 ng_queue ng_queue10 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100047 ng_queue ng_queue11 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100048 ng_queue ng_queue12 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100049 ng_queue ng_queue13 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100050 ng_queue ng_queue14 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 12 100051 ng_queue ng_queue15 mi_switch sleepq_wait = _sleep ngthread fork_exit fork_trampoline=20 13 100052 geom g_event mi_switch sleepq_wait = _sleep g_run_events fork_exit fork_trampoline=20 13 100053 geom g_up mi_switch sleepq_wait = _sleep g_io_schedule_up g_up_procbody fork_exit fork_trampoline=20 13 100054 geom g_down mi_switch sleepq_wait = _sleep g_io_schedule_down g_down_procbody fork_exit fork_trampoline=20 14 100056 rand_harvestq - mi_switch = sleepq_timedwait msleep_spin_sbt random_kthread fork_exit = fork_trampoline=20 15 100072 usb usbus0 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100073 usb usbus0 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100074 usb usbus0 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100075 usb usbus0 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100077 usb usbus1 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100078 usb usbus1 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100079 usb usbus1 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100080 usb usbus1 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100082 usb usbus2 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100083 usb usbus2 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100084 usb usbus2 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100085 usb usbus2 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100097 usb usbus3 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100098 usb usbus3 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100099 usb usbus3 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100100 usb usbus3 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100102 usb usbus4 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100103 usb usbus4 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100104 usb usbus4 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100105 usb usbus4 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100106 usb usbus5 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100107 usb usbus5 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100108 usb usbus5 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100109 usb usbus5 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100110 usb usbus6 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100111 usb usbus6 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100112 usb usbus6 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100113 usb usbus6 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100114 usb usbus7 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100115 usb usbus7 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100116 usb usbus7 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 15 100117 usb usbus7 mi_switch sleepq_wait = _cv_wait usb_process fork_exit fork_trampoline=20 16 100147 g_mirror opt - mi_switch = sleepq_timedwait _sleep g_mirror_worker fork_exit fork_trampoline=20 17 100148 pagedaemon - mi_switch = sleepq_timedwait _sleep vm_pageout fork_exit fork_trampoline=20 18 100149 vmdaemon - mi_switch sleepq_wait = _sleep vm_daemon fork_exit fork_trampoline=20 19 100150 idlepoll - mi_switch = sleepq_timedwait _sleep poll_idle fork_exit fork_trampoline=20 20 100151 pagezero - mi_switch = sleepq_timedwait _sleep vm_pagezero fork_exit fork_trampoline=20 21 100152 bufdaemon - mi_switch = sleepq_timedwait _sleep buf_daemon fork_exit fork_trampoline=20 21 100170 bufdaemon / worker mi_switch = sleepq_timedwait _sleep softdep_flush fork_exit fork_trampoline=20 21 100175 bufdaemon /var worker mi_switch = sleepq_timedwait _sleep softdep_flush fork_exit fork_trampoline=20 21 100176 bufdaemon /opt worker mi_switch = sleepq_timedwait _sleep softdep_flush fork_exit fork_trampoline=20 22 100153 syncer - mi_switch = sleepq_timedwait _cv_timedwait_sbt sched_sync fork_exit fork_trampoline=20= 23 100154 vnlru - mi_switch = sleepq_timedwait _sleep vnlru_proc fork_exit fork_trampoline=20 148 100181 adjkerntz - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 521 100179 moused - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 538 100193 devd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _cv_timedwait_sig_sbt = seltdwait kern_select sys_select amd64_syscall Xfast_syscall=20 660 100212 syslogd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 810 100217 ntpd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 830 100190 snmpd - mi_switch turnstile_wait = __rw_wlock_hard udp_attach socreate sys_socket amd64_syscall = Xfast_syscall=20 834 100202 smartd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_nanosleep = sys_nanosleep amd64_syscall Xfast_syscall=20 842 100222 sendmail - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _cv_timedwait_sig_sbt = seltdwait kern_select sys_select amd64_syscall Xfast_syscall=20 845 100205 sendmail - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 864 100233 ruby19 - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 864 100612 ruby19 - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 870 100238 nginx - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 871 100210 nginx - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 872 100196 nginx - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 874 100195 nginx - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 875 100239 nginx - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 885 100215 collectdmon - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_wait6 sys_wait4 = amd64_syscall Xfast_syscall=20 912 100220 collectd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_nanosleep = sys_nanosleep amd64_syscall Xfast_syscall=20 912 100246 collectd - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100247 collectd - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100248 collectd - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100249 collectd - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100250 collectd - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100251 collectd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100252 collectd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100253 collectd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100254 collectd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 912 100255 collectd - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 915 100243 sshd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 918 100242 cron - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_nanosleep = sys_nanosleep amd64_syscall Xfast_syscall=20 988 100203 inetd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 1008 100155 login - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_wait6 sys_wait4 = amd64_syscall Xfast_syscall=20 1009 100259 getty - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 1010 100266 getty - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 1011 100267 getty - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 1012 100268 getty - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 1013 100269 getty - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 1014 100270 getty - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 1015 100271 getty - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 2184 100341 sshd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_poll = sys_poll amd64_syscall Xfast_syscall=20 2188 100325 sshd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 2189 100365 csh - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 3940 100316 csh - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 3944 100356 sudo - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_poll = sys_poll amd64_syscall Xfast_syscall=20 3945 100257 csh - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 3949 100338 screen - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 3950 100188 screen - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _cv_timedwait_sig_sbt = seltdwait kern_select sys_select amd64_syscall Xfast_syscall=20 3951 100289 csh - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend = sys_sigsuspend amd64_syscall Xfast_syscall=20 4588 100335 sshd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_poll = sys_poll amd64_syscall Xfast_syscall=20 4590 100286 sshd - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select = sys_select amd64_syscall Xfast_syscall=20 4591 100328 csh - mi_switch = sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_read = ttydev_read devfs_read_f dofileread kern_readv sys_read amd64_syscall = Xfast_syscall=20 4654 100315 sh - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep kern_wait6 sys_wait4 = amd64_syscall Xfast_syscall=20 4655 100397 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_sem_wait = __umtx_op_sem_wait amd64_syscall Xfast_syscall=20 4655 100826 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100827 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100828 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100829 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100830 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100831 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100832 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100833 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100834 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100835 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4655 100836 python3.4 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4656 100350 ngram_mr - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4656 100837 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4656 100838 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4656 100839 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4656 100840 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4656 101476 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4656 101477 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4656 101482 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4656 101489 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4657 100319 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4657 101428 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4657 101429 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4657 101430 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4657 101431 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4657 101457 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4657 101462 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4657 101475 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4657 101491 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4658 100366 ngram_mr - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4658 100841 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4658 100842 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4658 100843 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4658 100844 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4658 101465 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4658 101466 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4658 101478 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4658 101488 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4659 100173 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4659 100845 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4659 100846 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4659 101418 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4659 101419 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4659 101455 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4659 101460 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4659 101467 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4659 101487 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4660 100822 ngram_mr - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4660 101420 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4660 101421 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4660 101422 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4660 101423 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4660 101459 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4660 101464 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4660 101469 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4660 101485 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4661 100352 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4661 101424 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4661 101425 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4661 101426 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4661 101427 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4661 101470 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4661 101472 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4661 101481 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4661 101486 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4662 100211 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4662 101440 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4662 101441 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4662 101442 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4662 101443 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4662 101479 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4662 101480 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard in6_pcbnotify udp6_common_ctlinput pfctlinput2 = ip6_output udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4662 101484 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4662 101492 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4663 100159 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4663 101432 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4663 101433 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4663 101434 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4663 101435 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4663 101456 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4663 101461 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4663 101468 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4663 101490 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4664 100290 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4664 101436 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4664 101437 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4664 101438 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4664 101439 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4664 101452 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4664 101453 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4664 101454 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4664 101495 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4665 100294 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4665 101444 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4665 101445 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4665 101446 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4665 101447 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4665 101471 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4665 101473 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4665 101483 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4665 101493 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4666 100262 ngram_mr - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4666 101448 ngram_mr sighandler mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall Xfast_syscall=20 4666 101449 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4666 101450 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_rlock udp_send udp6_send sosend_dgram kern_sendit sendit = sys_sendmsg amd64_syscall Xfast_syscall=20 4666 101451 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4666 101458 ngram_mr nl12_dual_stack mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent sys_kevent = amd64_syscall Xfast_syscall=20 4666 101463 ngram_mr nl6_udp_host mi_switch turnstile_wait = __rw_wlock_hard udp6_send sosend_dgram kern_sendit sendit sys_sendmsg = amd64_syscall Xfast_syscall=20 4666 101474 ngram_mr nl12_udp_host mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4666 101494 ngram_mr queue_writer mi_switch = sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait = __umtx_op_wait_uint_private amd64_syscall Xfast_syscall=20 4677 100165 ifconfig - mi_switch turnstile_wait = __rw_wlock_hard udp_attach socreate sys_socket amd64_syscall = Xfast_syscall=20 4679 100300 procstat - = =20 --Apple-Mail=_79DA52FF-9FBC-4D87-8F73-943E5F2BFA0A-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 10:29: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 B512D6A for ; Sat, 24 Jan 2015 10:29: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 9C7B2E0C for ; Sat, 24 Jan 2015 10:29: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 t0OATVMV003472 for ; Sat, 24 Jan 2015 10:29:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191520] [PATCH] Implementation of draft-ieft-tcpm-newcwv-06 Date: Sat, 24 Jan 2015 10:29: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: 11.0-CURRENT X-Bugzilla-Keywords: feature, needs-qa, patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@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: keywords 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 10:29:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |feature, needs-qa, patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 17:29: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 17214B7A for ; Sat, 24 Jan 2015 17:29:45 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0D8497F for ; Sat, 24 Jan 2015 17:29:44 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id b16so2442820igk.1 for ; Sat, 24 Jan 2015 09:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=s9C1nUE/AqZwuylWON3SkaVJqquOtJiFsIRyKpUa3u4=; b=jxlOkmUZxnu5dDp/JKBEnPTdM/H1AQzfQM9oI9ULZijpR+G6HEKHoqSmX2jf3CXuao b0hlmEvb2gKvhV9dkRPwh1b1rwRo90BPqLPe1lPO+kPL3BjL/doyDZVIQH+SbYT60tZp S3po2JsmaHRVUAXwgiuDzWWTHUj54RrNZIBxbkdg0Gy1CYp5D+V2zQN56gxiJJn5kyvd qhrx4tpt7RkYJXU1SQUn0jzrFpfto3z8rCKTvnSyCs28hPMiloN90Ls6qgc+C8uIa1Yc R2VzEDECVmt8F1kpg1oQPFsMnjr9zGfl887wh+f+pDB52PmLp0WX+a5pJtj9v1KJjadx ljGQ== MIME-Version: 1.0 X-Received: by 10.50.164.227 with SMTP id yt3mr8240227igb.32.1422120584187; Sat, 24 Jan 2015 09:29:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 09:29:44 -0800 (PST) In-Reply-To: References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> Date: Sat, 24 Jan 2015 09:29:44 -0800 X-Google-Sender-Auth: v-QuFU8mAQ1Ivzk7csoK5Wsx9zY Message-ID: Subject: Re: network locks up with udp traffic From: Adrian Chadd To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 17:29:45 -0000 Hi, Can you compile your kernel with WITNESS and repeat this test? It looks like it's stuck in some lock ordering thing between some UDP paths and an inpcb lookup. It should log in dmesg the first time a LOR occurs, regardless of whether it actively causes a hang. (And yes, this is definitely critical enough to be a FreeBSD PR... :) Thanks! -adrian On 24 January 2015 at 02:14, Dmitry Sivachenko wrote: > >> On 23 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 21:58, Adrian Chadd wrote: >> >> Hi, >> >> When this next happens, please do this as root: >> >> procstat -ka >> >> That'll hopefully provide enough information to figure out which >> processes are blocking where and how they got there. >> >> > > > Hello, > > I am attaching procstat -ka output (and top output to see snmpd process i= n "*udp" state). > ifconfig process was started with "net0" argument (net0 is a renamed igb0= in my case). > From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 17:53:32 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 D5ACC346; Sat, 24 Jan 2015 17:53:32 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5431BC18; Sat, 24 Jan 2015 17:53:32 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id b6so2263774lbj.11; Sat, 24 Jan 2015 09:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wtkApJZha50vu09vaYLrpnBs9AmWpti9Nbu3haYv10E=; b=Wj2yE5LGwkgLn3E4208O7ohzodt20tW5/BHvylBl5uL32OhWwaBJnV2jluovjvPABj bQ2+D1E0YFnEKVF6jkY9tdvMr00oDenxt8oJePMEhN2U5exjIrKr9i95LNKd8tzk7gyU kSXD7FVGZAP2tCzIJPGGCJaKTMQJUmWnSqDqmGeXbh7E7EIiFB5t6esBQ6rbKKaKD/PV n6BiEBWnLgC0tiMQhbc/Kf6DwFBZx1vwhYq84tWZwj1JP/QeJBRBUh88gh8kYPBiUWB+ 8rtjr6AGGOGk3ARl9lk7c4kFXSCBIPk221UfXcL4pXVVHoZa/u3mE9r/MQIrt6GHzH5G IFxg== X-Received: by 10.112.167.228 with SMTP id zr4mr13382214lbb.20.1422122010416; Sat, 24 Jan 2015 09:53:30 -0800 (PST) Received: from [10.0.1.7] (broadband-5-228-253-40.nationalcablenetworks.ru. [5.228.253.40]) by mx.google.com with ESMTPSA id p10sm1329078lap.10.2015.01.24.09.53.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 09:53:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: network locks up with udp traffic From: Dmitry Sivachenko In-Reply-To: Date: Sat, 24 Jan 2015 20:53:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 17:53:32 -0000 > On 24 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 20:29, Adrian Chadd = wrote: >=20 > Hi, >=20 > Can you compile your kernel with WITNESS and repeat this test? It > looks like it's stuck in some lock ordering thing between some UDP > paths and an inpcb lookup. >=20 > It should log in dmesg the first time a LOR occurs, regardless of > whether it actively causes a hang. Here is what I got in dmesg just before my net locked up: lock order reversal: 1st 0xffffffff80e79008 pcbinfohash (pcbinfohash) @ = /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0xffffffff80e78fb0 udp (udp) @ = /opt/WRK/src/sys/netinet6/in6_pcb.c:614 lock order reversal: 1st 0xffffffff80e79008 pcbinfohash (pcbinfohash) @ = /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0xffffffff80e78d58 tcp (tcp) @ = /opt/WRK/src/sys/netinet6/in6_pcb.c:614 lock order reversal: 1st 0xffffffff80e79008 pcbinfohash (pcbinfohash) @ = /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0xffffffff80e781c0 rip (rip) @ = /opt/WRK/src/sys/netinet6/in6_pcb.c:614 When I was saving this dmesg output to disk, I got another LOR: lock order reversal: 1st 0xfffffe0baf12fd78 bufwait (bufwait) @ = /opt/WRK/src/sys/kern/vfs_bio.c:3065 2nd 0xfffff80011416c00 dirhash (dirhash) @ = /opt/WRK/src/sys/ufs/ufs/ufs_dirhash.c:284 Please tell me if I can provide more information to help tracking this = down. Thanks!= From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 18:56:20 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 6F6AF1C5 for ; Sat, 24 Jan 2015 18:56:20 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32FB11C7 for ; Sat, 24 Jan 2015 18:56:20 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id y20so2737444ier.1 for ; Sat, 24 Jan 2015 10:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Kw67UXRJq+ZdWtF/1MnJfvcBOheNGlTgQnLrcirCiv8=; b=oV8wzAtKxFMXYMoBLMEpTWzwWPO4hDUgaK43cd5WC5y1NtgqW17e+KD+Sevo1ycr1N UIfXyJLRjd3eaVHIWxSlaaHqEyGOqv8qfaVnwGgTjZC1gySZhBNgAA6eXh7G81K7G1Vv icyg/4u7cGMG6hFp09reaywnqdFKraRF4Du+5Y7++a8kv9Dc29bcCft5pzSwbr8A6594 /ew2891DCg/86/ZGA8/Go9f3JfUCFUXWc4hj0gML4ZM4no0S7K6zxhKPDLzZtDBhhHRK oj/D9p0VGHvj0RlVBQHRS5yUMhLsSoTywKr4VdrMovoSPrRgHdxroVEjX9lKD3kZzaot MtpQ== MIME-Version: 1.0 X-Received: by 10.42.201.78 with SMTP id ez14mr14306975icb.22.1422125779565; Sat, 24 Jan 2015 10:56:19 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 10:56:19 -0800 (PST) In-Reply-To: References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> Date: Sat, 24 Jan 2015 10:56:19 -0800 X-Google-Sender-Auth: XtJUqD3dhwxByp8a_48OMS5swPI Message-ID: Subject: Re: network locks up with udp traffic From: Adrian Chadd To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 18:56:20 -0000 Hi! To be clear: * is your kernel modified in any way; and * did witness give you a full stacktrace as part of the lock order reversal? All of that would be good. Thanks, On 24 January 2015 at 09:53, Dmitry Sivachenko wrote: > >> On 24 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 20:29, Adrian Chadd wrote: >> >> Hi, >> >> Can you compile your kernel with WITNESS and repeat this test? It >> looks like it's stuck in some lock ordering thing between some UDP >> paths and an inpcb lookup. >> >> It should log in dmesg the first time a LOR occurs, regardless of >> whether it actively causes a hang. > > > > Here is what I got in dmesg just before my net locked up: > > lock order reversal: > 1st 0xffffffff80e79008 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/neti= net6/udp6_usrreq.c:1202 > 2nd 0xffffffff80e78fb0 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:6= 14 > lock order reversal: > 1st 0xffffffff80e79008 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/neti= net6/udp6_usrreq.c:1202 > 2nd 0xffffffff80e78d58 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:6= 14 > lock order reversal: > 1st 0xffffffff80e79008 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/neti= net6/udp6_usrreq.c:1202 > 2nd 0xffffffff80e781c0 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:6= 14 > > When I was saving this dmesg output to disk, I got another LOR: > > lock order reversal: > 1st 0xfffffe0baf12fd78 bufwait (bufwait) @ /opt/WRK/src/sys/kern/vfs_bio= .c:3065 > 2nd 0xfffff80011416c00 dirhash (dirhash) @ /opt/WRK/src/sys/ufs/ufs/ufs_= dirhash.c:284 > > > Please tell me if I can provide more information to help tracking this do= wn. > > Thanks! From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 19:46:00 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 E7B7316B; Sat, 24 Jan 2015 19:46:00 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 626358BB; Sat, 24 Jan 2015 19:46:00 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id l4so2466648lbv.13; Sat, 24 Jan 2015 11:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWs7q8+x5++O68fk53H0soK8LtZx6yPo8TcuASh24A8=; b=BaMQvXP8ejrCLwZqjeXJ8B3mPWaEr35586P7hrlCGFAgGiNjWSFBe5qMtgItUkI3et 3CdarN+xKIng/9WpMEIerb+JVTIr8383QmAqAZIBONOx7YRuQYhOwKwcfkDRdXaaLy5/ IKthUM7BHPY8XsNNL3Yx43WCPyD4e3GQSh6t6Jh8g0eZWWP2u3Kxc1HmZZGMaySQqWei 9aEnAFztSpCRJLodvhSogdigbpwbe3wD6A3BPuLcU5LT1GOpuobCbX3tQmZAqje2pxCu KTaC+5aa1Syu0ufKgDbyPiDvavVtpF5sX8eA9ct25hI/poLEPsANEREyJe2qxcmc0EvT QWGw== X-Received: by 10.152.178.197 with SMTP id da5mr11417688lac.87.1422128758187; Sat, 24 Jan 2015 11:45:58 -0800 (PST) Received: from [10.0.1.7] (broadband-5-228-253-40.nationalcablenetworks.ru. [5.228.253.40]) by mx.google.com with ESMTPSA id xq3sm1381084lbb.15.2015.01.24.11.45.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 11:45:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: network locks up with udp traffic From: Dmitry Sivachenko In-Reply-To: Date: Sat, 24 Jan 2015 22:45:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 19:46:01 -0000 > On 24 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 21:56, Adrian Chadd = wrote: >=20 > Hi! >=20 > To be clear: >=20 > * is your kernel modified in any way; and No, it isn't > * did witness give you a full stacktrace as part of the lock order > reversal? All of that would be good. >=20 I provided the full output I saw on console. From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 19:46:34 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 C58C71F9 for ; Sat, 24 Jan 2015 19:46:34 +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 ABC158D0 for ; Sat, 24 Jan 2015 19:46:34 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0OJkYJP027655 for ; Sat, 24 Jan 2015 19:46:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 188897] [dc] dc ethernet driver seems to prevent the detection of other NIC chipsets Date: Sat, 24 Jan 2015 19:46:34 +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.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: clif@eugeneweb.com 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: attachments.created 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 19:46:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188897 --- Comment #7 from clif@eugeneweb.com --- Created attachment 152106 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152106&action=edit This is a verbose dmesg for another dc quadport card, a DFE-570TX -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 20:50: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 D1A45BAE for ; Sat, 24 Jan 2015 20:50: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 B8F02E4A for ; Sat, 24 Jan 2015 20:50: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 t0OKojLh062338 for ; Sat, 24 Jan 2015 20:50:45 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: Sat, 24 Jan 2015 20:50:39 +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-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 20:50:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 --- Comment #19 from Craig Rodrigues --- (In reply to darius from comment #18) I'm OK with merging this to stable/10, but I would like to get some feedback from PF users on the state of things in CURRENT before merging. What is your experience with this patch? Herbert Skuhra has provided good feedback, but getting a few more people to try it and report would be great. Herbert found another bug in CURRENT: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 That is a bug in the bridge code, and not part of the VIMAGE + PF fixes. However, all this stuff is interrelated. It would be nice to get a fix in for PR 195859, so provide a consistent testing environment for VIMAGE in CURRENT. That will make it easier to backport patches to stable/10. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 21:10: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 226EB5BC for ; Sat, 24 Jan 2015 21:10:45 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D86DC73 for ; Sat, 24 Jan 2015 21:10:44 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id tr6so3001560ieb.2 for ; Sat, 24 Jan 2015 13:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8eOMcXwjquUoBGQkwb4n4kp0amTVFTGxlf3BOnNh1es=; b=mdOM91NzorCj6cpR1oOXfN5V8RaeYu5CgUkgVJmpzN92DLHTq9gQXqNtW+eoZQ93FT uwVQ3REl+gccVhmEFtlEIOQdbSnT9giXwlQPUrZ2ZGHMQd4UvI46ZzIwUUlgQnPywUgK azPN6BZlj0QPFz/9IDsx1Zg4ljnbGE9gWAYutCEcinO8uYAgjKGArZmuD8HrJ84mawil imOQa9XqO1JmffdX8YQBzbSmmBB1760SHwnHZQgy7gfemJqxN+rjZAVd7tD98Z5VcQ7W Pobnvc5mjBu05CKW3PfA2Pdk4goqsjoJ1CAzntS1mIx+y+e1eHKlRvblo9Dcs5QqQ3bw OwMw== MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mr8882466igb.49.1422133843966; Sat, 24 Jan 2015 13:10:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 13:10:43 -0800 (PST) In-Reply-To: References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> Date: Sat, 24 Jan 2015 13:10:43 -0800 X-Google-Sender-Auth: 9V170_0MqpRT18bjS-JMnuJHtHM Message-ID: Subject: Re: network locks up with udp traffic From: Adrian Chadd To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 21:10:45 -0000 Ah, try adding STACK to your config? -a On 24 January 2015 at 11:45, Dmitry Sivachenko wrote: > >> On 24 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 21:56, Adrian Chadd wrote: >> >> Hi! >> >> To be clear: >> >> * is your kernel modified in any way; and > > > No, it isn't > > >> * did witness give you a full stacktrace as part of the lock order >> reversal? All of that would be good. >> > > > I provided the full output I saw on console. > From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:43: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 4B4EAC9A for ; Sat, 24 Jan 2015 22:43:50 +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 2DD65B57 for ; Sat, 24 Jan 2015 22:43:50 +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 t0OMhnw3034175 for ; Sat, 24 Jan 2015 22:43:49 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMhn8X034172; Sat, 24 Jan 2015 22:43:49 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:43:49 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 1, 330 lines] D1640: Refactor network stack state separate from VSI state Message-ID: X-Priority: 3 Thread-Topic: D1640: Refactor network stack state separate from VSI state X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: N2JmNDRjOWRkY2RlYmQ2NjRjZDUxYzYxNjBm 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:43:50 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Currently the ixl driver has a struct ixl_vsi that it uses to track both network stack interface state (e.g. the ifnet) and Virtual Station Interface (VSI) state in the hardware. However, when the ixl driver is acting as a PF device for SR-IOV, we will allocate VSIs for the VFs, but won't have any network stack state for those VSIs in the ixl driver itself (instead the ixlv driver will attach to the VF device, which has its own state independent of the PF driver). Fix this by introducing a new structure, ixl_ifx, which will be used to track network stack state. Refactor both the ixl and ixlv drivers to move their network stack state into this new structure, and retain the ixl_vsi structure to track only information related to details of the VSI allocated from the hw. REVISION DETAIL https://reviews.freebsd.org/D1640 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/if_ixlv.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h sys/dev/ixl/ixl_txrx.c sys/dev/ixl/ixlv.h sys/dev/ixl/ixlvc.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:44:36 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 27514D27 for ; Sat, 24 Jan 2015 22:44:36 +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 0AA23B5E for ; Sat, 24 Jan 2015 22:44:36 +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 t0OMiZum034666 for ; Sat, 24 Jan 2015 22:44:35 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMiZRr034665; Sat, 24 Jan 2015 22:44:35 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:44:35 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 226 lines] D1641: Implement PCI SR-IOV initialization methods Message-ID: X-Priority: 3 Thread-Topic: D1641: Implement PCI SR-IOV initialization methods X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ZWFiODdhYWU0YTRhNWFiMzk2YmRlMzA0YTZl 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:44:36 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Implement the two new PCI methods used to initialize and uninitialize SR-IOV on a PF. On initialization, the PF must allocate a VEB, which is a virtual switch instance implemented by the hardware. The PF's interface is made a child of this switch. REVISION DETAIL https://reviews.freebsd.org/D1641 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:44:39 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 B8125DB1 for ; Sat, 24 Jan 2015 22:44:39 +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 98683B62 for ; Sat, 24 Jan 2015 22:44:39 +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 t0OMidwE034679 for ; Sat, 24 Jan 2015 22:44:39 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMid00034678; Sat, 24 Jan 2015 22:44:39 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:44:39 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 118 lines] D1642: Implement PCI SR-IOV method to initialize individual VFs Message-ID: X-Priority: 3 Thread-Topic: D1642: Implement PCI SR-IOV method to initialize individual VFs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ZmZlNzY0OTVkYmNlM2JkOWFhZWQ3MjBhMjA1 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:44:39 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY For each VF that has been allocated, the PF driver must allocate a Virtual Switch Interface (VSI), which is a virtual port on the virtual Fortville switch (VEB). In device_attach() for the PF, we now have to initialize all RX and TX queues instead just those that will be used by the PF, as there is no way of know how many will be allocated at runtime for the VFs. REVISION DETAIL https://reviews.freebsd.org/D1642 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h sys/dev/ixl/ixlv.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22: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 6DB7DE44 for ; Sat, 24 Jan 2015 22:44:50 +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 519E9B6A for ; Sat, 24 Jan 2015 22:44:50 +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 t0OMiohC034831 for ; Sat, 24 Jan 2015 22:44:50 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMio2V034830; Sat, 24 Jan 2015 22:44:50 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:44:50 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 225 lines] D1643: Implement resetting a VF Message-ID: X-Priority: 3 Thread-Topic: D1643: Implement resetting a VF X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: MDJmMjIzMGI5NWVmMGNmNjI3NTcwNmNhOWQ0 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:44:50 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Add the ability to do a full reset of a VF's state. This involves stopping the VF in hardware, releasing all resources, re-allocating a new VSI, and finally allocating the VSI's queue resources. REVISION DETAIL https://reviews.freebsd.org/D1643 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:44: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 32514ED1 for ; Sat, 24 Jan 2015 22:44:57 +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 153F5B73 for ; Sat, 24 Jan 2015 22:44:57 +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 t0OMiuTW034964 for ; Sat, 24 Jan 2015 22:44:56 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMiuQV034963; Sat, 24 Jan 2015 22:44:56 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:44:56 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 152 lines] D1644: Add infrastructure for handling the VC msg channel from VFs Message-ID: X-Priority: 3 Thread-Topic: D1644: Add infrastructure for handling the VC msg channel from VFs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: NWFiMWUzZDU0ODgxNGJiOTVkN2EzZDdiZjI3 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:44:57 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The VF drivers do not have unrestricted access to the hardware. To configure the VF (e.g. set the MAC address), they are required to send a message the PF requesting the configuration. These messages are passed over the "Virtual Channel" (VC). Add the infrastructure required to receive Admin Queue interrupts indicating that a VC message has been received. Also add functions for sending responses back to the VFs. At this stage no VC messages are actually handled. Implementation of individual VC messages will be added in subsequent commits. REVISION DETAIL https://reviews.freebsd.org/D1644 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45:07 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 0406DF61 for ; Sat, 24 Jan 2015 22:45:07 +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 DBC2AB7A for ; Sat, 24 Jan 2015 22:45:06 +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 t0OMj6XS035168 for ; Sat, 24 Jan 2015 22:45:06 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMj64P035166; Sat, 24 Jan 2015 22:45:06 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:45:06 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 21 lines] D1645: Add support for VERSION VC message Message-ID: X-Priority: 3 Thread-Topic: D1645: Add support for VERSION VC message X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: MjYzNzUyNDQxYTA3Y2RhZGM3M2FmMDUwYmQw 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:07 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The VC message format is versioned. Implement the VERSION VC message, which the VF uses to discover the version of the VC protocol implemented by the PF. The VF will not be able to come up if the PF's version is incompatible. REVISION DETAIL https://reviews.freebsd.org/D1645 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45:17 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 63B08FF3 for ; Sat, 24 Jan 2015 22:45:17 +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 46AC3B84 for ; Sat, 24 Jan 2015 22:45:17 +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 t0OMjHud035318 for ; Sat, 24 Jan 2015 22:45:17 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMjHxw035317; Sat, 24 Jan 2015 22:45:17 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:45:16 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 19 lines] D1646: Add support for RESET_VF VC message Message-ID: X-Priority: 3 Thread-Topic: D1646: Add support for RESET_VF VC message X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ZTA1MzIxZDNjN2MzMDRiYzg0ZWYwMDZjYmQw 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:17 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This VC message is used by the VF driver to request a full reset of the VF state. Unlike all other VC messages, no response is sent to the message. REVISION DETAIL https://reviews.freebsd.org/D1646 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45: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 922A4F4 for ; Sat, 24 Jan 2015 22:45:22 +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 758DEB8A for ; Sat, 24 Jan 2015 22:45:22 +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 t0OMjMB8035397 for ; Sat, 24 Jan 2015 22:45:22 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMjMx9035396; Sat, 24 Jan 2015 22:45:22 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:45:22 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 32 lines] D1647: Add support for GET_VF_RESOURCES VC message Message-ID: X-Priority: 3 Thread-Topic: D1647: Add support for GET_VF_RESOURCES VC message X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: YmFkOTJjNjIzYWI1MTUxNDE0ZGM3MmQ2MTc0 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:22 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is sent by the VF driver to discover the capabilities of the VF, like the number of rx/tx queues supported. REVISION DETAIL https://reviews.freebsd.org/D1647 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45:30 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 46A2117E; Sat, 24 Jan 2015 22:45:30 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4E96B8E; Sat, 24 Jan 2015 22:45:29 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id s18so2819940lam.5; Sat, 24 Jan 2015 14:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JH2afC6fDclyzC+NPTQwnxGKshT+KEfPjbZ6R9cUwig=; b=Hi6CC3C9y6ePapFubzx3VHHSNKiaVeEXsm8PIrAJYhNB2ddtyuLBeJUomyJ/nqxmRk Q1STlWQ33qfkQaErXea/Vou+J0UlMx4lDuJhEctWdnDR3pny/axhsCVseF1Qa7dtyjPZ EsL1qPfZwelI/O/qmHj2nz3/s73TRiz76Kg7iEJryVwCCJB/6m042hp0bZRppxdmbd4M hcQzi1TCkb5iaIjvdH+YDpCoVrNIAbMUZi7Cz2F7Hrm2zW0RdU7Kn07PeGbDMKz1dLfQ sEdo3bHWKYd5zQCZ5NgZoBaV0mbTiH/Nm8rCmibv5lhhdsn2e9O8og+A7WQ0g+No6pxN tcsQ== X-Received: by 10.152.45.65 with SMTP id k1mr4240909lam.14.1422139527930; Sat, 24 Jan 2015 14:45:27 -0800 (PST) Received: from [10.0.1.7] (broadband-5-228-253-40.nationalcablenetworks.ru. [5.228.253.40]) by mx.google.com with ESMTPSA id eb8sm175314lbb.28.2015.01.24.14.45.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 14:45:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: network locks up with udp traffic From: Dmitry Sivachenko In-Reply-To: Date: Sun, 25 Jan 2015 01:45:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6B125546-E095-4A4C-9B6B-7E80D1D6E8EF@gmail.com> References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:30 -0000 > On 25 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 0:10, Adrian Chadd = wrote: >=20 > Ah, try adding STACK to your config? >=20 It's already there.= From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45:32 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 B9D821C2 for ; Sat, 24 Jan 2015 22:45:32 +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 98C1FB93 for ; Sat, 24 Jan 2015 22:45:32 +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 t0OMjWMM035487 for ; Sat, 24 Jan 2015 22:45:32 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMjWMk035486; Sat, 24 Jan 2015 22:45:32 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:45:32 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 38 lines] D1648: Add stubs for deprecated VC messages Message-ID: X-Priority: 3 Thread-Topic: D1648: Add stubs for deprecated VC messages X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: Y2MyNjI4YjVjODUwMDVhYzYxNTNkMjEyYzRl 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:32 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY There are a couple of VC message types defined in the enum that seem to have been deprecated early in the Fortville SR-IOV development process. Explicitly implement them to return an error to document that these are intentionally not supported. REVISION DETAIL https://reviews.freebsd.org/D1648 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45: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 0F63E299 for ; Sat, 24 Jan 2015 22:45: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 E62CFB98 for ; Sat, 24 Jan 2015 22:45:42 +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 t0OMjgcu035569 for ; Sat, 24 Jan 2015 22:45:42 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMjg6W035568; Sat, 24 Jan 2015 22:45:42 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:45:42 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 177 lines] D1649: Add support for CONFIG_VSI_QUEUES VC message Message-ID: X-Priority: 3 Thread-Topic: D1649: Add support for CONFIG_VSI_QUEUES VC message X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: NzBjMzdhMjA1NGRjOGJkMTFiY2ViZGYyMDRk 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:43 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is sent by the VF to request that the PF configure its RX and TX queues. The PF is required to validate that the request is sane before applying the configuration. REVISION DETAIL https://reviews.freebsd.org/D1649 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45:49 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 84124326 for ; Sat, 24 Jan 2015 22:45:49 +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 67F70B9F for ; Sat, 24 Jan 2015 22:45:49 +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 t0OMjnts035590 for ; Sat, 24 Jan 2015 22:45:49 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMjn7m035589; Sat, 24 Jan 2015 22:45:49 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:45:49 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 165 lines] D1650: Add support for CONFIG_IRQ_MAP VC message Message-ID: X-Priority: 3 Thread-Topic: D1650: Add support for CONFIG_IRQ_MAP VC message X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: OGIzNWI2MTYxYWRjMTI0NjU4YTJkZTYwY2Q2 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:49 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is used by the VF to request that its RX and TX queues be associated with particular MSI-X vectors. This configuration is performed via a fairly complicated linked-list mechanism in the hardware. The linked list is built up backwards (from the tail to the head) as it turns out to simplify the logic significantly. REVISION DETAIL https://reviews.freebsd.org/D1650 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:45:58 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 965593B9 for ; Sat, 24 Jan 2015 22:45:58 +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 79AD2BAE for ; Sat, 24 Jan 2015 22:45:58 +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 t0OMjwKC035726 for ; Sat, 24 Jan 2015 22:45:58 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMjwaj035725; Sat, 24 Jan 2015 22:45:58 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:45:58 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 68 lines] D1651: Add support for ENABLE/DISABLE_QUEUES VC messages Message-ID: X-Priority: 3 Thread-Topic: D1651: Add support for ENABLE/DISABLE_QUEUES VC messages X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: NzRiMTE2MzFlMGU1Yzg4ZDYyZDE0NWY0ZTZl 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:45:58 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY These messages are sent by the VF to enable or disable packet reception and transmission from its queues. Despite the fact that a bitmask of queues is provided in the message, this is ignored and all queues are either enabled or disabled. This matches the behaviour of the Linux PF driver. REVISION DETAIL https://reviews.freebsd.org/D1651 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:46:05 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 13641448 for ; Sat, 24 Jan 2015 22:46:05 +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 EACEABB6 for ; Sat, 24 Jan 2015 22:46:04 +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 t0OMk4OX035888 for ; Sat, 24 Jan 2015 22:46:04 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMk4g4035885; Sat, 24 Jan 2015 22:46:04 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:46:04 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 161 lines] D1652: Add support for ADD/DEL_ETHER_ADDRESS VC messages Message-ID: X-Priority: 3 Thread-Topic: D1652: Add support for ADD/DEL_ETHER_ADDRESS VC messages X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: MzM5Y2U0ZjQwMTJmYWViOTFkMDMyZmM4NGIz 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:46:05 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The ADD message is sent by the VF to request that a MAC address filter be added to the Fortville switch to direct packets destined to that MAC be routed to the VF's VSI. The DEL message deletes a MAC address filter that was previously established. This has security implications in a VM environment (a VM could listen in on packets that it's not entitled to see), so the VF has to have this capability enabled on it. REVISION DETAIL https://reviews.freebsd.org/D1652 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:46: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 AE1CA4DD for ; Sat, 24 Jan 2015 22:46:15 +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 915DCBC1 for ; Sat, 24 Jan 2015 22:46:15 +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 t0OMkFiF036166 for ; Sat, 24 Jan 2015 22:46:15 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMkFbx036165; Sat, 24 Jan 2015 22:46:15 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:46:15 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 121 lines] D1653: Add support for ADD/DEL_VLAN VC messages Message-ID: X-Priority: 3 Thread-Topic: D1653: Add support for ADD/DEL_VLAN VC messages X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: Y2ZkZmUyNmRjYTBlOGYyYTlmNjY4MTQyOTZl 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:46:15 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY These messages are sent by the PF to change configuration related to the hardware vlan filtering and stripping. If a VF is subscribed to one or more vlans then the vlan header will be stripped by the hardware, and other vlans will be filtered in hardware. REVISION DETAIL https://reviews.freebsd.org/D1653 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:46:26 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 5CFAD56C for ; Sat, 24 Jan 2015 22:46:26 +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 405BCBC7 for ; Sat, 24 Jan 2015 22:46:26 +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 t0OMkPAK036234 for ; Sat, 24 Jan 2015 22:46:25 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMkPTA036233; Sat, 24 Jan 2015 22:46:25 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:46:25 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 49 lines] D1654: Add support for CONFIG_PROMISCUOUS_MODE VC message Message-ID: X-Priority: 3 Thread-Topic: D1654: Add support for CONFIG_PROMISCUOUS_MODE VC message X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ODZlMGNmMmIwNjllNDI3NzNjZDY5MDBlOTFh 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:46:26 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is sent by the VF driver to request that the VSI be placed in or taken out of promiscuous mode. REVISION DETAIL https://reviews.freebsd.org/D1654 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:46:32 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 E2C965F8 for ; Sat, 24 Jan 2015 22:46:32 +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 C5EFABCB for ; Sat, 24 Jan 2015 22:46:32 +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 t0OMkW9u036271 for ; Sat, 24 Jan 2015 22:46:32 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMkWjm036270; Sat, 24 Jan 2015 22:46:32 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:46:32 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 41 lines] D1655: Add support for GET_STATS VC message Message-ID: X-Priority: 3 Thread-Topic: D1655: Add support for GET_STATS VC message X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: M2VlZmI5Nzk5ZGE5MDQ2YzE4OWMyZjdiMDU1 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:46:33 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The Fortville hardware tracks a small number of per-VSI counters, like packet and byte counters. The GET_STATS message is sent by the VF driver to request a copy of the current value of those counters. REVISION DETAIL https://reviews.freebsd.org/D1655 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:46:41 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 7FA3E684 for ; Sat, 24 Jan 2015 22:46:41 +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 61C50BCF for ; Sat, 24 Jan 2015 22:46:41 +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 t0OMkfuG036408 for ; Sat, 24 Jan 2015 22:46:41 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMkfjo036407; Sat, 24 Jan 2015 22:46:41 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:46:41 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 65 lines] D1656: Handle VFLR events from VFs Message-ID: X-Priority: 3 Thread-Topic: D1656: Handle VFLR events from VFs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: MjAxYmVkMTcyNjY3NDZhMmYxYWVkM2NmMGRi 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:46:41 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY If a VF resets itself via a Function Level Reset (FLR) bit, the PF receives an interrupt with a VFLR event. The PF is required to re-initialize the VF state when this happens. REVISION DETAIL https://reviews.freebsd.org/D1656 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:46:49 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 B1559716 for ; Sat, 24 Jan 2015 22:46:49 +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 94C13BD9 for ; Sat, 24 Jan 2015 22:46:49 +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 t0OMknIg036671 for ; Sat, 24 Jan 2015 22:46:49 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMknPa036670; Sat, 24 Jan 2015 22:46:49 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:46:49 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 34 lines] D1657: Allow VFs to run while the PF is admin down Message-ID: X-Priority: 3 Thread-Topic: D1657: Allow VFs to run while the PF is admin down X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: Y2EyNmJlZTU5MWYxMjQxNTNiNmRlMzQzYjQx 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:46:49 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Ensure that the admin queue interrupt stays enabled as long as we have VFs. It is a requirement that the VFs be able to keep running correctly even if the PF ifnet is admin down. REVISION DETAIL https://reviews.freebsd.org/D1657 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:47:00 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 777867AC for ; Sat, 24 Jan 2015 22:47:00 +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 595B1BE0 for ; Sat, 24 Jan 2015 22:47:00 +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 t0OMl0kQ036829 for ; Sat, 24 Jan 2015 22:47:00 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMl0aT036828; Sat, 24 Jan 2015 22:47:00 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:47:00 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 34 lines] D1658: Add sysctls for per-VF hardware counters Message-ID: X-Priority: 3 Thread-Topic: D1658: Add sysctls for per-VF hardware counters X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: OWE0YzQwMmZkYjZmN2FjNjA4MWQ1MGYxZmY1 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:47:00 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY For debugging purposes, add sysctls that reflect the value of each VF's hardware counters. REVISION DETAIL https://reviews.freebsd.org/D1658 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:47:07 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 2003383C for ; Sat, 24 Jan 2015 22:47:07 +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 02991BE8 for ; Sat, 24 Jan 2015 22:47:07 +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 t0OMl6Fv036982 for ; Sat, 24 Jan 2015 22:47:06 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMl6Cg036981; Sat, 24 Jan 2015 22:47:06 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:47:06 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 24 lines] D1659: Register ixl as an SR-IOV-capable driver during attach Message-ID: X-Priority: 3 Thread-Topic: D1659: Register ixl as an SR-IOV-capable driver during attach X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: MWEzYTlmNjM0ZjU1ZjZiMTRhYzdkZDlmYjZk 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:47:07 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Now that the driver's SR-IOV implementation is complete, during attach register the device as being SR-IOV capable. This will cause the SR-IOV infrastructure to create the device node in /dev/iov used to configure SR-IOV on this device, making it possible for the administrator to enable SR-IOV. REVISION DETAIL https://reviews.freebsd.org/D1659 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:47:17 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 B3A658EC for ; Sat, 24 Jan 2015 22:47:17 +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 972DBBF3 for ; Sat, 24 Jan 2015 22:47:17 +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 t0OMlHmi037089 for ; Sat, 24 Jan 2015 22:47:17 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMlHTo037088; Sat, 24 Jan 2015 22:47:17 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:47:17 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 21 lines] D1660: Add support for mac-addr parameter Message-ID: X-Priority: 3 Thread-Topic: D1660: Add support for mac-addr parameter X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ZWE5ZGNjNWRmODc2N2E5NGNhNGQwMTExOWMx 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:47:17 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Implement a mac-addr SR-IOV configuration parameter, which the administrator can specify to force a VF to use a particular MAC address. By default, the VF driver cannot change its MAC address if it has been specified by the administrator. REVISION DETAIL https://reviews.freebsd.org/D1660 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:47:24 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 0B0BF97C for ; Sat, 24 Jan 2015 22:47:24 +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 E2E63BFB for ; Sat, 24 Jan 2015 22:47:23 +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 t0OMlNgJ037136 for ; Sat, 24 Jan 2015 22:47:23 GMT (envelope-from mat@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0OMlNYE037133; Sat, 24 Jan 2015 22:47:23 GMT (envelope-from mat) Date: Sat, 24 Jan 2015 22:47:23 +0000 To: freebsd-net@freebsd.org From: "rstone (Ryan Stone)" Subject: [Differential] [Request, 23 lines] D1661: Add some security-related config parameters Message-ID: X-Priority: 3 Thread-Topic: D1661: Add some security-related config parameters X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: MjUxNWUxN2JmMmRmYzQ5MzQyZmZlNzZlOTY2 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:47:24 -0000 rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Allow the administrator to prevent VFs from sending packets with a source MAC that is not the VF's MAC (anti-spoof). Default this to on. Allow the administrator to give VFs the ability to override the MAC address that was specified at creation time. By default VFs will not be permitted to do this. Allow the administrator to give the VFs the ability to enter promiscuous mode. REVISION DETAIL https://reviews.freebsd.org/D1661 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 22:49: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 CC31AA63 for ; Sat, 24 Jan 2015 22:49:40 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CB46C30 for ; Sat, 24 Jan 2015 22:49:40 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id hn18so3052033igb.2 for ; Sat, 24 Jan 2015 14:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Z8CM/T7ekwHCH7vin74MuGiw9Jqs2S6yf6DL4T6rmmE=; b=sxFdpldtC+Hc/778ED9U+wFbB1ZDzOWe0JVgtKttnzYGiGJBxR2Ye+PVV3fd85MPBR jdk2IHDz8q/cOF2nkK8qP4yqb1A51Hv1cRwDqK0WsZlG430Ac6p8EGlA3phewSxhXvwE 7FbNpb8z5lADapIWAVbG094auXcmFnwU0vMilMbiXhTWvXi87Ny6oUYgBde90/IUKTE9 Qsx1rB5mLDIVvS8gbW0exI42qXSYKM6ey3KgWpxe+PS3IC6ibN5c2aTZzmfezmjWH41p wSouf7t4arPEac24j2oEsM8UHqWkVflFyEiAEuuFxdUtoF+ON+I1oQvN0ZwudDOAC591 EirA== MIME-Version: 1.0 X-Received: by 10.42.54.5 with SMTP id p5mr14673967icg.37.1422139780085; Sat, 24 Jan 2015 14:49:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 14:49:40 -0800 (PST) In-Reply-To: <6B125546-E095-4A4C-9B6B-7E80D1D6E8EF@gmail.com> References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> <6B125546-E095-4A4C-9B6B-7E80D1D6E8EF@gmail.com> Date: Sat, 24 Jan 2015 14:49:40 -0800 X-Google-Sender-Auth: 5vi8tWf-hHWOUF2B2VNfg7QmTug Message-ID: Subject: Re: network locks up with udp traffic From: Adrian Chadd To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 22:49:40 -0000 On 24 January 2015 at 14:45, Dmitry Sivachenko wrote: > >> On 25 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 0:10, Adrian Chadd wrote: >> >> Ah, try adding STACK to your config? >> > > > It's already there. Hm, not sure why you're not getting the full stacks in the witness dump. Maybe try KDB and KDB_TRACE ? -adrian From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 23:07:41 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 39CBBDF1; Sat, 24 Jan 2015 23:07:41 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2E31DE7; Sat, 24 Jan 2015 23:07:40 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id z12so2803296lbi.7; Sat, 24 Jan 2015 15:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ew7sgCS8PWaMaGm0wDV17+3qKqkUe7gw8o6gMsAzm5c=; b=BO2/fqAk/FAgUiswszII0jaBwJg4IMQN3l0HfYeoqbCvwS2MLgbcSNoCNM2O/NXfVR 6/xSEMzayhydRota08dcu/9Uy1HDD2NJOr8c4nzNZiGYuusI+sCy4hA6Y81/aEraIMSK s1m3pHoUoUbHUq2gyn2Mft3y2PhJ0Zqz4hZWlc8fGgwPS6JKbpLw2yyUc6xdyNIzZ8sV OU24msuWnFct2NSQOOuEs+Tep7RKF4Vic1WRGcsgGbspLPNrCA8JBF7IPaFRI/XLgkwJ cGtRpn5kF+tHo9wbzybIMHnQE38Ia3vM5F/U88KSpowpe/OXhKCTPkpILRlIUKxNtF8h hw6Q== X-Received: by 10.152.161.168 with SMTP id xt8mr14232742lab.35.1422140858839; Sat, 24 Jan 2015 15:07:38 -0800 (PST) Received: from [10.0.1.7] (broadband-5-228-253-40.nationalcablenetworks.ru. [5.228.253.40]) by mx.google.com with ESMTPSA id dx2sm1460975lbc.49.2015.01.24.15.07.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 15:07:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: network locks up with udp traffic From: Dmitry Sivachenko In-Reply-To: <6B125546-E095-4A4C-9B6B-7E80D1D6E8EF@gmail.com> Date: Sun, 25 Jan 2015 02:07:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81FCF115-3EE7-4902-9F9A-4852B59348AC@gmail.com> References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> <6B125546-E095-4A4C-9B6B-7E80D1D6E8EF@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 23:07:41 -0000 > On 25 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 1:45, Dmitry Sivachenko = wrote: >=20 >=20 >> On 25 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 0:10, Adrian Chadd = wrote: >>=20 >> Ah, try adding STACK to your config? >>=20 >=20 >=20 > It's already there. Ah, sorry, it is options DDB that was missing. Now we have full stack: lock order reversal: 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ = /opt/WRK/src/sys/netinet6/ud p6_usrreq.c:1202 2nd 0xffffffff80ea5530 udp (udp) @ = /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe0c581c1270 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c1320 witness_checkorder() at witness_checkorder+0xc04/frame = 0xfffffe0c581c13a0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c13e0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c1480 udp6_common_ctlinput() at udp6_common_ctlinput+0x111/frame = 0xfffffe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip =3D 0x803ec5eaa, rsp =3D= 0x7fffdf5f6848, rbp =3D 0x7fffdf5f6880 --- lock order reversal: 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ = /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0xffffffff80ea52d8 tcp (tcp) @ = /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe0c581c1240 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c12f0 witness_checkorder() at witness_checkorder+0xc04/frame = 0xfffffe0c581c1370 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c13b0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c1450 tcp6_ctlinput() at tcp6_ctlinput+0x1a5/frame 0xfffffe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip =3D 0x803ec5eaa, rsp =3D= 0x7fffdf5f6848, rbp =3D 0x7fffdf5f6880 --- lock order reversal: 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ = /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0xffffffff80ea4740 rip (rip) @ = /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe0c581c12b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c1360 witness_checkorder() at witness_checkorder+0xc04/frame = 0xfffffe0c581c13e0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c1420 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c14c0 rip6_ctlinput() at rip6_ctlinput+0x70/frame 0xfffffe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip =3D 0x803ec5eaa, rsp =3D= 0x7fffdf5f6848, rbp =3D 0x7fffdf5f6880 ---= From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 23:11: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 E978AF89 for ; Sat, 24 Jan 2015 23:11:43 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8B5AE97 for ; Sat, 24 Jan 2015 23:11:43 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id rl12so3250097iec.0 for ; Sat, 24 Jan 2015 15:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bvFYCB3BPsUzfpAt+brkKHQ+iOcws3odgafB0D1Cdhg=; b=zoGPGabRl7+ZLXgHADIThHb0vyvMYCNJP07ZVXLY4HGZj5yw8W7BdDDZ/7eaNpgMCd 0Wl6EDVWvbrd5STDV5+HXYhiHUlElHVMq5QGuEUiFbzToofbs6dXP+YrUreOexPR1nZa 1nZlu3Hxki2GsSTSq5n3U70Thraoy4N+hwbSmXQiszAAKZ6nlQqwMlg+8jj+OfAwYWCw nruzjSGcWC0FOtgiJGjIJnY7fImwMOJySlFUawxGdryoGWP7Sg5Z79NdtL5lJxMQW6L9 ue5tbZTCIjH9MfKg9+o3vicdFIex+SmkjrfOMmQpEn/y6QjKVB6kpkhXDjiZfaqzszS8 sMWQ== MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mr9222198igb.49.1422141103050; Sat, 24 Jan 2015 15:11:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 15:11:42 -0800 (PST) In-Reply-To: <81FCF115-3EE7-4902-9F9A-4852B59348AC@gmail.com> References: <5B08402C-67A7-49E7-ADF8-390C94DCF1D7@gmail.com> <6B125546-E095-4A4C-9B6B-7E80D1D6E8EF@gmail.com> <81FCF115-3EE7-4902-9F9A-4852B59348AC@gmail.com> Date: Sat, 24 Jan 2015 15:11:42 -0800 X-Google-Sender-Auth: nytuXNG6ara9zP8rMOVAefS69h4 Message-ID: Subject: Re: network locks up with udp traffic From: Adrian Chadd To: Dmitry Sivachenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 23:11:44 -0000 ok, cool. You definitely have enough for a freebsd bug report. Would you mind adding it? https://bugs.freebsd.org/submit/ -a On 24 January 2015 at 15:07, Dmitry Sivachenko wrote: > >> On 25 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 1:45, Dmitry Sivachenko wrote: >> >> >>> On 25 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., at 0:10, Adrian Chadd wrote: >>> >>> Ah, try adding STACK to your config? >>> >> >> >> It's already there. > > > Ah, sorry, it is options DDB that was missing. Now we have full stack: > > > lock order reversal: > 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/neti= net6/ud > p6_usrreq.c:1202 > 2nd 0xffffffff80ea5530 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:6= 14 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0c581= c1270 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c1320 > witness_checkorder() at witness_checkorder+0xc04/frame 0xfffffe0c581c13a0 > _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c13e0 > in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c1480 > udp6_common_ctlinput() at udp6_common_ctlinput+0x111/frame 0xfffffe0c581c= 14e0 > pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 > ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 > udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 > sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 > kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 > sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 > sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 > amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip =3D 0x803ec5eaa, rsp = =3D 0x7fffdf5f6848, rbp =3D 0x7fffdf5f6880 --- > > > lock order reversal: > 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/neti= net6/udp6_usrreq.c:1202 > 2nd 0xffffffff80ea52d8 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:6= 14 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0c581= c1240 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c12f0 > witness_checkorder() at witness_checkorder+0xc04/frame 0xfffffe0c581c1370 > _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c13b0 > in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c1450 > tcp6_ctlinput() at tcp6_ctlinput+0x1a5/frame 0xfffffe0c581c14e0 > pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 > ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 > udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 > sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 > kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 > sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 > sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 > amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip =3D 0x803ec5eaa, rsp = =3D 0x7fffdf5f6848, rbp =3D 0x7fffdf5f6880 --- > > > > lock order reversal: > 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/neti= net6/udp6_usrreq.c:1202 > 2nd 0xffffffff80ea4740 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:6= 14 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0c581= c12b0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c1360 > witness_checkorder() at witness_checkorder+0xc04/frame 0xfffffe0c581c13e0 > _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c1420 > in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c14c0 > rip6_ctlinput() at rip6_ctlinput+0x70/frame 0xfffffe0c581c14e0 > pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 > ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 > udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 > sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 > kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 > sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 > sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 > amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip =3D 0x803ec5eaa, rsp = =3D 0x7fffdf5f6848, rbp =3D 0x7fffdf5f6880 --- From owner-freebsd-net@FreeBSD.ORG Sat Jan 24 23:16: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 C7EBA128 for ; Sat, 24 Jan 2015 23:16:23 +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 A8BC6ECE for ; Sat, 24 Jan 2015 23:16:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0ONGN2x019423 for ; Sat, 24 Jan 2015 23:16:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197059] network locks up with IPv6 udp traffic Date: Sat, 24 Jan 2015 23:16:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: demon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 23:16:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059 Bug ID: 197059 Summary: network locks up with IPv6 udp traffic Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: demon@FreeBSD.org CC: adrian@freebsd.org, freebsd-net@FreeBSD.org Hello! I am using FreeBSD-10/stable. We have a program at work that transmits data via UDP. When I run several instances of this program simultaneously, after a few seconds network stops working. If I login from console, I see some network daemons like ntpd, snmpd are in "*udp" state. If I try to deal with network interface (ifconfig igb0 for instance), ifconfig utility stuck in "L" state (Marks a process that is waiting to acquire a lock.). I found the only way to fix that: reboot. What can be the cause for such a behaviour? lock order reversal: 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/ud p6_usrreq.c:1202 2nd 0xffffffff80ea5530 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0c581c1270 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c1320 witness_checkorder() at witness_checkorder+0xc04/frame 0xfffffe0c581c13a0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c13e0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c1480 udp6_common_ctlinput() at udp6_common_ctlinput+0x111/frame 0xfffffe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- lock order reversal: 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0xffffffff80ea52d8 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0c581c1240 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c12f0 witness_checkorder() at witness_checkorder+0xc04/frame 0xfffffe0c581c1370 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c13b0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c1450 tcp6_ctlinput() at tcp6_ctlinput+0x1a5/frame 0xfffffe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- lock order reversal: 1st 0xffffffff80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0xffffffff80ea4740 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0c581c12b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0c581c1360 witness_checkorder() at witness_checkorder+0xc04/frame 0xfffffe0c581c13e0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfffffe0c581c1420 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfffffe0c581c14c0 rip6_ctlinput() at rip6_ctlinput+0x70/frame 0xfffffe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfffffe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfffffe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfffffe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfffffe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfffffe0c581c1a30 sendit() at sendit+0x225/frame 0xfffffe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfffffe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfffffe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- -- You are receiving this mail because: You are on the CC list for the bug.