From owner-freebsd-net@freebsd.org Sun Dec 4 00:49:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC252C5783B for ; Sun, 4 Dec 2016 00:49:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 BB7CF1699 for ; Sun, 4 Dec 2016 00:49:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB40nHwS018509 for ; Sun, 4 Dec 2016 00:49:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 209682] [panic] [netinet] arptimer race Date: Sun, 04 Dec 2016 00:49: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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avos@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity see_also cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 00:49:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209682 Andriy Voskoboinyk changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 150 | |25 CC| |avos@freebsd.org --- Comment #3 from Andriy Voskoboinyk --- > _rw_wlock_cookie Was seen on r309481 (only once, ifconfig(8) was not touched). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 4 08:36:45 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A85B1C66075 for ; Sun, 4 Dec 2016 08:36:45 +0000 (UTC) (envelope-from orjan.tonder@gmail.com) Received: from mail-wj0-x229.google.com (mail-wj0-x229.google.com [IPv6:2a00:1450:400c:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4143D1C2D for ; Sun, 4 Dec 2016 08:36:45 +0000 (UTC) (envelope-from orjan.tonder@gmail.com) Received: by mail-wj0-x229.google.com with SMTP id v7so265486266wjy.2 for ; Sun, 04 Dec 2016 00:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=MSRIvxEZzeMk33Cmkohj7qACVfLIzDgeyNTmnsOa4B0=; b=Vl5Wpzdrjp8ffBFI7oqyBVgiPgA+Bu3DrlT2FoZzLtuF5pxJd3UDcVFtSz4BGDx8Ge VQ0W0qQQr8Hu0dR0IJdUXWshJSi9zgeyuL4bsJ36+sGqMAHfMw9OSIjNPTCObh9gv3kw afeg0L552QeP2T45ezD4kLQPQMB/AnKrbiOfVzDUuFYppQ5uRwIjeDdCDYWxINMjkUUt NsHVSbAL0YuDK3MzcfWdMjayvrRqVQbh9NWLkZ1iCwnBh5PmkbpOzMRd+TQ5RXX687iw BRv6Wwg2iigOrcycmpVNd+x8sseSt0/e4pS+SFsJ+6IUc8KcXvMBnJJGKMOWNmCCwMYa YwFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MSRIvxEZzeMk33Cmkohj7qACVfLIzDgeyNTmnsOa4B0=; b=Cu8m8XQiwgbHMAHJRXLhnncwiRsdAaqkmWjV4TjmoUBegg3jWPdr3o2YZ66Pbh/7B6 l6BbaumX4f+2NM+lVituMMZ8H2xdQ6Khr/N6wbw5OmoJoQDbVxejTMiDwG7Si5C7jZN0 Q9A0q51yUb42/W7oQVhDBqNp6JbUFvF5wMDI8kNQGIqoG+BZ8tEZfhNQhN5inaY3mp8O uCDppetfRUxxtWS7Qao35QDPWDM9RdZ25Syc5Q+9Dpko7nPk6C8ZSZGPIWLn7OvKKMP2 u2fu5WK8IzuQJJ3BIOrNhEE2A2nUyBa1iutE6edfruHFSJZMSjxtQkMpz7D8RYiNcz/q RdQA== X-Gm-Message-State: AKaTC03vvY3sy+3YD8vUa27+sOFKAxJCkyv15BQb1FPyoaT00HMqE6IVkkiv2fXAIDxf/tMwePKOArL4S+d2vA== X-Received: by 10.194.89.132 with SMTP id bo4mr20904856wjb.177.1480840603047; Sun, 04 Dec 2016 00:36:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.222.214 with HTTP; Sun, 4 Dec 2016 00:36:42 -0800 (PST) From: =?UTF-8?B?w5hyamFuIFTDuG5kZXI=?= Date: Sun, 4 Dec 2016 09:36:42 +0100 Message-ID: Subject: freebsd openvpn setup To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 08:36:45 -0000 I have successful setup a openvpn network all clients can reach outside and lan, but the server cant reach the clients. network setup 10.8.1.0/24 server 10.8.1.1/24 clients 10.8.1.2-130/24 The routing table from the server: root@charon:/usr/local/etc/openvpn # netstat -r Routing tables Internet: Destination Gateway Flags Netif Expire default static.1.31.4.46.c UGS re0 10.8.1.0/24 link#5 U tap0 10.8.1.1 link#5 UHS lo0 10.8.2.1 link#3 UH lo1 10.8.2.3 link#3 UH lo1 46.4.31.0/26 link#1 U re0 tuxlab.no link#1 UHS lo0 localhost link#2 UH lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 localhost UGRS lo0 localhost link#2 UH lo0 ::ffff:0.0.0.0/96 localhost UGRS lo0 fe80::/10 localhost UGRS lo0 fe80::%re0/64 link#1 U re0 fe80::6e62:6dff:fe link#1 UHS lo0 fe80::%lo0/64 link#2 U lo0 fe80::1%lo0 link#2 UHS lo0 fe80::%tap0/64 link#5 U tap0 fe80::2bd:6fff:fe3 link#5 UHS lo0 ff02::/16 localhost UGRS lo0 what am i missing ? -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQENBFUByQgBCAChgKlX3wlCovKXZG//oGdpVCFxiC8X6kSWC2pvdfcxgII/corC o2ndED6Zp9AEzBjT46ilzbwJkxPWB+Qq4oucj5zLSUrWb0pIszCWksFhOKEqJ87D lR0UXBpR5a9+SYqydVgRsyZmHGDAyWnneKvcp6MlYcsqYogC9xYJjK2K0r91f9pn vsQmiLJcNMPVWxQ+w7pEQFtntoHcKbZ0LaEG/hhEN2fOA8SNa3FYQ2bexLVtgFhR q+5VYyO89XWHH20ovoltRUOR7XvXNAY4GT6jMwi7QJ9FTTPFy7v1uGrBJbuDZ2fM gegRMbykNBtadztATpGAw9+be4879Cfzt6d7ABEBAAG0N8OYcmphbiBUw7huZGVy IChyZWFsIG5hbWUga2V5KSA8b3JqYW4udG9uZGVyQGdtYWlsLmNvbT6JATgEEwEC ACIFAlUByQgCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJVR+IZRCu10 wuMH/2INhf+aLPTdH0xD9DLNQJXlxofhkKZtWxBLeHCcl0lHFjHDC65OQ/pyuqQZ KyevSdRo21uXv72YcAPLuCqxsuIOvpNoUpS36Cat8K8wK0zLS3XQlZI/wvP6qWse W/OYGM2VGuG7Sn5Mjx8BcSiUiAItfNTy+Ao1LIldywOtjHIaKDK5y+Ml4PWkSk1q H77XoIS/6QKDmAQzpOYoNgnR4R4pucHVrriCWW5A3vWktK4prcO8SI3Ci88JmL5v imDITMOFwlNBQD4j7e3T/qwBZ5DGsnQ4s4fe8Xd1sFx4UYRompH485RrUAWLJ+wS 65hEUQ9jx9w/68iDSr5PXI6Peaw= =1oDp -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-net@freebsd.org Sun Dec 4 10:24:04 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F201CC660F5 for ; Sun, 4 Dec 2016 10:24:04 +0000 (UTC) (envelope-from cs@innolan.dk) Received: from avril.innolan.net (ntp2.innolan.net [90.184.222.115]) (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 B70AFB8D for ; Sun, 4 Dec 2016 10:24:04 +0000 (UTC) (envelope-from cs@innolan.dk) Received: from [192.168.10.60] (unknown [192.168.10.60]) by avril.innolan.net (Postfix) with ESMTP id CABDC61F909; Sun, 4 Dec 2016 11:14:47 +0100 (CET) Subject: Re: freebsd openvpn setup To: =?UTF-8?B?w5hyamFuIFTDuG5kZXI=?= , freebsd-net@freebsd.org References: From: Carsten Larsen Message-ID: <5e81070e-a28c-bf12-1d6a-e8028a274a35@innolan.dk> Date: Sun, 4 Dec 2016 11:14:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 10:24:05 -0000 Hi Ørjan Den 04-12-2016 kl. 09:36 skrev Ørjan Tønder: > I have successful setup a openvpn network all clients can reach outside and > lan, > but the server cant reach the clients. > > network setup > 10.8.1.0/24 > server 10.8.1.1/24 > clients 10.8.1.2-130/24 > > The routing table from the server: > root@charon:/usr/local/etc/openvpn # netstat -r > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default static.1.31.4.46.c UGS re0 > 10.8.1.0/24 link#5 U tap0 > 10.8.1.1 link#5 UHS lo0 > 10.8.2.1 link#3 UH lo1 > 10.8.2.3 link#3 UH lo1 > 46.4.31.0/26 link#1 U re0 > tuxlab.no link#1 UHS lo0 > localhost link#2 UH lo0 > > Internet6: > Destination Gateway Flags Netif Expire > ::/96 localhost UGRS lo0 > localhost link#2 UH lo0 > ::ffff:0.0.0.0/96 localhost UGRS lo0 > fe80::/10 localhost UGRS lo0 > fe80::%re0/64 link#1 U re0 > fe80::6e62:6dff:fe link#1 UHS lo0 > fe80::%lo0/64 link#2 U lo0 > fe80::1%lo0 link#2 UHS lo0 > fe80::%tap0/64 link#5 U tap0 > fe80::2bd:6fff:fe3 link#5 UHS lo0 > ff02::/16 localhost UGRS lo0 > > > what am i missing ? > > > You need to add an iroute in the client config. Kind regards Carsten Larsen From owner-freebsd-net@freebsd.org Sun Dec 4 11:21:40 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D407AC66490 for ; Sun, 4 Dec 2016 11:21:40 +0000 (UTC) (envelope-from rodrigo@bebik.net) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (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 9AD3ACB8 for ; Sun, 4 Dec 2016 11:21:40 +0000 (UTC) (envelope-from rodrigo@bebik.net) Received: from [192.168.1.32] (unknown [78.194.61.125]) by smtp1-g21.free.fr (Postfix) with ESMTP id D3C69B0054B for ; Sun, 4 Dec 2016 12:21:36 +0100 (CET) To: freebsd-net@freebsd.org From: Rodrigo OSORIO Subject: =?UTF-8?Q?BSD_Devroom_CFP_@_Frosdem'17_=e2=80=93_call_for_participa?= =?UTF-8?Q?tion_extended?= Message-ID: Date: Sun, 4 Dec 2016 13:21:53 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 11:21:40 -0000 Hi, The BSD devroom move the submission deadline to Dec 10th. There's still time to submit a talk ! Regards, - rodrigo On behalf of the BSD devroom Fosdem 2017 BSD devroom Call for Participation ============================================== Important dates -------------------- * Conference date : 4 & 5 February 2017 in Brussels, Belgium * Devroom date : Sunday 5 February 2016 * Submission deadline : Sunday 27 November 2016 * Speaker notified : Sunday 4 December 2016 The topic of the devroom includes all BSD operating systems and every talk is welcome from hacker discussions to real-word examples and presentations about new and shiny features. Practical -------------------- * The default duration for talks will be 45 minutes including discussion. Feel free to ask if you want to have a longer or a shorter slot. * Presentations can be recorded and streamed, sending your proposal implies giving permission to be recorded. However, exceptions can be made for exceptional circumstances. To submit your proposal, visit : https://penta.fosdem.org/submission/FOSDEM17 Account creation ---------------------- If you already have a Pentabarf account, please*don't* recreate a new one. If you forgot your password, reset it. If not, follow the instructions to create an account. Submit a talk --------------------- Create an “event” and click on "Show all" in the top right corner to display the full form. Your submission must include the following information * The title and subtitle of your talk (please be descriptive, as titles will be listed with ~500 from other projects) * select “BSD devroom” as the track. * A short abstract of one paragraph * A longer description if you wish to do so * Links to related websites/blogs etc. - Rodrigo Osorio On behalf of the BSD Devroom _______________________________________________ FOSDEM mailing list FOSDEM@lists.fosdem.org https://lists.fosdem.org/listinfo/fosdem From owner-freebsd-net@freebsd.org Sun Dec 4 19:55:14 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9921DC67CDD for ; Sun, 4 Dec 2016 19:55:14 +0000 (UTC) (envelope-from vicepresjoebiden@gmail.com) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 541BD183A for ; Sun, 4 Dec 2016 19:55:14 +0000 (UTC) (envelope-from vicepresjoebiden@gmail.com) Received: by mail-ua0-x233.google.com with SMTP id 12so330240623uas.2 for ; Sun, 04 Dec 2016 11:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1DRfb77MYetDHoLjPYzw3voutRXE1wvE5SZTb+Yf2JA=; b=rMLnufBzBZYLJSa2tAfp0zqDS2dt28wvNHxg+iupLID8l08XLW83htyVqBXbep0ddZ z4z/OtdJgWUSPMFjU/dYDVCpC0yFlsWA2idga7aPml+NrGejcgiasT38/sHGmdSm65FH dpPnu00LbFaF3lCVpnqRKSi0uVyXKSo4Ssn7xYvqIaqYG5OL4Y3mENQhSDMpSRR/PzRY izKZa3/CLUcBzju5VEpy2/10SC59ceCIbNn0P94Ow3ji1F+CDpbYQM3ym6VDV14MlhD1 51ss9XFzrvwjm0sSswKtHjYFcDLIgYMQ0Ip4VVQ+g+/MKVbMu4GH6mFGznrUnTwUZGDR 8BZQ== 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:from:date :message-id:subject:to; bh=1DRfb77MYetDHoLjPYzw3voutRXE1wvE5SZTb+Yf2JA=; b=lmX5NejticMIgQ7wt1aK1ikPEgFPJzXa/SNzKEwxK8GgQDHo6awGfZ85jpCL6MnFRU 89UnWNi0fzG/cjb2gUyr0/mVn8boi0eHJzBReJmuA3oHltcpW0EigYeXxq/f90FvNoFP Q5c9rcfVerwKUKwlV4rICR86SOn4OfJhcxhOss8pgL4DkskajIkow8I51cfw+2ASlzSl 52wPATTJsCfJQXkGP3PoI7FIG02jn+9k/VVN5v/IJSFMtgCbw4v33r0bIy7vASohvQ1H NWCgV5wTFhMsLvMSXy2mmJ1tM5pdnHM/OUDIu4JCuP2wdLXr10/S2Py8xF9EXDueCA0v VnLw== X-Gm-Message-State: AKaTC01HpZgPdwmYcVc72qY0KwsiNhZA4RpS6CPFp+wGcrvMQaJiWNFOedQFdAF7Gaq4jdfseu53nDCG+Ot56w== X-Received: by 10.176.80.195 with SMTP id d3mr41907362uaa.125.1480881313202; Sun, 04 Dec 2016 11:55:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.0.103 with HTTP; Sun, 4 Dec 2016 11:55:12 -0800 (PST) In-Reply-To: References: From: Jordan Ladora Date: Sun, 4 Dec 2016 12:55:12 -0700 Message-ID: Subject: Re: File duplication on NFSv4 exported ZFS filesystems to centos client To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 19:55:14 -0000 Ahh!! Thank you! Previously, I tried exporting just the top-level zfs, but then couldn't access the zfs filesystems inside from the client, but listing *all* of them in /etc/exports and only mounting the top-level zfs works perfectly. Just wondering, by the way, if you knew why 'echo' doesn't work on NFS shares? I've not tried it with any other version besides NFSv4, but every other command I've tried on the NFSv4 share works (e.g. cp, rm, cat, nano, rsync, mv, tar) but, for some reason, when I try to 'echo >> ' it does not work. Again, thanks for your help. On Fri, Dec 2, 2016 at 3:04 PM, Rick Macklem wrote: > Jordan Ladora wrote: > >Curious phenomenon of file pseudo-dup with exported ZFS filesystems on > >FreeBSD 10.3-REL NFSv4 export to a centos7 client. > > > > > >*FreeBSD server-* > > > >zpool create zpool_nfsv4 ... > > > >zfs create zpool_nfsv4/zfs2 > > > >zfs create zpool_nfsv4/zfs3 > > > > > >/etc/exports- > > > >V4: / > > > >/zpool_nfsv4 > > > >/zpool_nfsv4/zfs2 > > > >/zpool_nfsv4/zfs3 > > > > > >zfs unshare -a > > > > > >*Centos client-* > > > >mkdir /zpool_nfsv4 > > > >mkdir /zpool_nfsv4_zfs2 > > > >mkdir /zpool_nfsv4_zfs3 > > > >mount -t nfs4 -o rw,intr,hard,proto=tcp,nodev,noexec,nosuid > >10.0.100.100:/zpool_nfsv4 > >/zpool_nfsv4 > > > - I'll call this mount #2. > >mount -t nfs4 -o rw,intr,hard,proto=tcp,nodev,noexec,nosuid > >10.0.100.100:/zpool_nfsv4/zfs2 > >/zpool_nfsv4_zfs2 > - I'll call this mount #3. > >mount -t nfs4 -o rw,intr,hard,proto=tcp,nodev,noexec,nosuid > >10.0.100.100:/zpool_nfsv4/zfs3 > >/zpool_nfsv4_zfs3 > By default (unlike NFSv3) NFSv4 mounts the entire tree of file systems > under the mount point and not just the file system being mounted. > You have two choices: > 1 - Don't do mount #2 or mount #3. The first mount should allow you to > access /zpool_nfsv4/zfs2 and /zpool_nfsv4/zfs3 with the addition > mounts. > OR > 2 - Turn of the "whole tree" behaviour on the server via: > # sysctl vfs.nfsd.mirrormnt=0 > on the FreeBSD server. > (I know, mirrormnt is a weird name for it, but that is what Linux used, > so... > I guess it means "mirror the tree of mounted file systems on the server > to the clients".) > [stuff snipped] > >This seems similar to this (https://serverfault.com/quest > >ions/535318/creating-two-nfs-shares-from-same-server-but- > >when-mounted-both-point-to-same-d) thread with NFSv4 exports on a centos > >server, but I cannot find anything similar to what I see here with a > >FreeBSD NFSv4 server. > What you did definitely had the same file systems mounted multiple times, > so I suspect that is what caused this behaviour. > > rick > > > From owner-freebsd-net@freebsd.org Sun Dec 4 21:00:27 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AADC4C67E59 for ; Sun, 4 Dec 2016 21:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 9EFF218ED for ; Sun, 4 Dec 2016 21:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB4L01BO021875 for ; Sun, 4 Dec 2016 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201612042100.uB4L01BO021875@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 04 Dec 2016 21:00:27 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 21:00:27 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic New | 213410 | [carp] service netif restart causes hang only whe Open | 148807 | [panic] "panic: sbdrop" and "panic: sbsndptr: soc Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211031 | [panic] in ng_uncallout when argument is NULL Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ Open | 212018 | Enable IPSEC_NAT_T in GENERIC kernel configuratio 16 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Dec 5 07:23:01 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57C0DC5FB20 for ; Mon, 5 Dec 2016 07:23:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 3C38C1774 for ; Mon, 5 Dec 2016 07:23:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB57N0w0056174 for ; Mon, 5 Dec 2016 07:23:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable. Date: Mon, 05 Dec 2016 07:23:01 +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: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: franco@opnsense.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 07:23:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211219 --- Comment #8 from Franco Fichtner --- Hi all, Last time we checked this also affected 11.0. Unfortunately, there multiple issues at play here: The FreeBSD em(4) driver under 10.3+ has this bug, and the Intel 7.6.2 driv= er fixes this on 10.3. But the Intel driver does not fully work under 11.0 --= it has issues with netmap(4) (e.g. using Suricata) there. The link issue in particular also manifests in several VM deployments that = we heard of through OPNsense, where widespread emulation of e1000 is an integr= al part of daily operation and required to be reliable. The only fix there wa= s to install the Intel driver, but obviously this doesn't fully work on 11.0 anymore. So we were hoping to see some progress in either: Getting the FreeBSD 10.3+ regression ironed out, and/or Seeing an Intel driver bump for reliable netmap(4) operation under 11.0. Bottom line is can we help in any way to speed this up? Thanks, Franco --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Dec 5 15:00:51 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2CE4C68831; Mon, 5 Dec 2016 15:00:51 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:11::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6749C105B; Mon, 5 Dec 2016 15:00:51 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPSA id uB5F0g7w064708 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Dec 2016 10:00:49 -0500 (EST) (envelope-from cross+freebsd@distal.com) Received: from [IPv6:2001:420:2710:1330:1c50:4fac:e56a:5aab] ([IPv6:2001:420:2710:1330:1c50:4fac:e56a:5aab]) (authenticated bits=0) by mail.distal.com (8.15.2/8.15.2) with ESMTPSA id uB5F0cfU044602 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2016 10:00:39 -0500 (EST) (envelope-from cross+freebsd@distal.com) From: Chris Ross Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Problems with FreeBSD (amd64 stable/11) router Date: Mon, 5 Dec 2016 10:00:33 -0500 Message-Id: <619F01C2-5A20-4E25-AB0B-4064B598239D@distal.com> Cc: Chris Ross To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 15:00:51 -0000 Hello all. I recently replaced my router with a FreeBSD/11 box = (stable/11 r308579). I am running a lagg device across two bce=E2=80=99s,= and 802.1q vlan interfaces atop lagg0. I=E2=80=99m using pf to = NAT/filter out through a single outside IP address. I=E2=80=99m having the following problem. Some devices appear to be = having trouble passing traffic. Of course, I first assumed I was doing = something wrong with my pf filters, but I believe now that=E2=80=99s not = the problem. One client machine (a TiVo Roamio) that produces a failure = reliably, so I=E2=80=99ve been using it for testing, is showing that = during a TCP session, which starts up fine, in the middle of a POST = operation to an outside server, there are 1500 byte packets. These = packets have the DF bit in the IP header, and then never show up on the = external interface (vlan0). Smaller packets in the same TCP stream do. = But, I=E2=80=99m also not seeing the ICMP from the router back to the = client telling it that it cannot send the packet. I have tried all sorts of changes to my pf rules, including now = allowing all ICMP unconditionally on all interfaces (pass out log quick = inet proto icmp all). I have packet traces during the failed = communication across pflog0, vlan0 (external network) and vlan7 = (internal network). I=E2=80=99d be happy to answer any questions, or = provide the traces off-list. Does anyone have any idea what I=E2=80=99ve missed? Thank you very = much for your help. - Chris From owner-freebsd-net@freebsd.org Mon Dec 5 16:36:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A4EAC687BD for ; Mon, 5 Dec 2016 16:36:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 EE7E9173F for ; Mon, 5 Dec 2016 16:36:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB5Ga2fS002913 for ; Mon, 5 Dec 2016 16:36:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213257] Crash in IGB driver with ALTQ Date: Mon, 05 Dec 2016 16:36:02 +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.3-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emz@norma.perm.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 16:36:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213257 emz@norma.perm.ru changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emz@norma.perm.ru --- Comment #11 from emz@norma.perm.ru --- I have two machines, both with igb(4), ALTQ and panics after an upgrade to 11.0-RELEASE. kern/213832, reported by me, may be related to this issue. Is anyone looking into this ? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Dec 5 16:59:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 584DBC680E2; Mon, 5 Dec 2016 16:59:17 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 29B863E8; Mon, 5 Dec 2016 16:59:17 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-io0-x236.google.com with SMTP id j65so605906637iof.0; Mon, 05 Dec 2016 08:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=McL7ihSJ0qfpWq7Zytf76208JOByI5ajsc5yqvIH3eI=; b=G6GNDOT65JEuU5FUrvRBdlGHC3/1+ayQwU2+5g+7zxk0Kz+/Hw5rQDXLJAx5SnGLTL ZzY/IHH6oj9OUVWPXpEws8FTC2OSMp25CmQIN1lJErXEdgnHTxdLWXTMhZFJJ/06NQ/X 6I2xDg3pBcW68joGV2gNOQ1yWC3DTDFHig+Xc+b6J25h/7EK2iQWPCnO5Vb8abQqsWtl yG/DH9zCmuQyD0T+DXtEubdc9IaCAUVEjhGOGKv9ZJRF6q6IqyJGHXqsF6GzkrVxZC7X lSkBESMd6nrDIH0/EJxxmuH1jxtUEMC+73zcvXPMyceygl2eIDR/DyNiB2InfklOqjbu fN7w== 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:from:date :message-id:subject:to:cc; bh=McL7ihSJ0qfpWq7Zytf76208JOByI5ajsc5yqvIH3eI=; b=IXsDJM5uz72hqULBJQLFVgrSQny3UuDtWsqeX9M1JoshpkpBNjeXGAGZdoiWflwhf+ dFE1R6Yf9JpRQe2oxduaxQwI9bqdHpds1onyea/35KClF/N/ynqE+IZNRQl5EcLOP4Z7 p6+F9VXJ9LFkvV0rbT1emgOI9RN5chTfYZXVQ3GC4fURVlE8uqTWbu+zmMvjC7l6Ehuc dbSsF4oib3AsxAk7t8u8WYsSOKVYUXkO2aD0i7pLllEPwD1wsdIAnoE77sdwum5pVTed BFu4AhQHvzIhdxnPM+y11qUQIitKq/R+X2MeLEO12AwSX40s+UW6ga6Y3bxNecZKXjET HMBw== X-Gm-Message-State: AKaTC02a2GhdF+h7LCYBK/mg+778cXC3ZeP871VRI7XlWZT5ItlqUQoG5QLgdZv4avNjr9CoIO4Vv4FQXJpO1w== X-Received: by 10.36.178.81 with SMTP id h17mr9204844iti.98.1480957156623; Mon, 05 Dec 2016 08:59:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.144.84 with HTTP; Mon, 5 Dec 2016 08:59:16 -0800 (PST) In-Reply-To: <619F01C2-5A20-4E25-AB0B-4064B598239D@distal.com> References: <619F01C2-5A20-4E25-AB0B-4064B598239D@distal.com> From: Ryan Stone Date: Mon, 5 Dec 2016 11:59:16 -0500 Message-ID: Subject: Re: Problems with FreeBSD (amd64 stable/11) router To: Chris Ross Cc: freebsd-net , freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 16:59:17 -0000 What's the MTU on the bce and vlan interfaces? Does the bce interface show VLAN_MTU option set (in ifconfig)? On Mon, Dec 5, 2016 at 10:00 AM, Chris Ross wrote: > > Hello all. I recently replaced my router with a FreeBSD/11 box > (stable/11 r308579). I am running a lagg device across two bce=E2=80=99s= , and > 802.1q vlan interfaces atop lagg0. I=E2=80=99m using pf to NAT/filter ou= t through > a single outside IP address. > > I=E2=80=99m having the following problem. Some devices appear to be hav= ing > trouble passing traffic. Of course, I first assumed I was doing somethin= g > wrong with my pf filters, but I believe now that=E2=80=99s not the proble= m. One > client machine (a TiVo Roamio) that produces a failure reliably, so I=E2= =80=99ve > been using it for testing, is showing that during a TCP session, which > starts up fine, in the middle of a POST operation to an outside server, > there are 1500 byte packets. These packets have the DF bit in the IP > header, and then never show up on the external interface (vlan0). Smalle= r > packets in the same TCP stream do. But, I=E2=80=99m also not seeing the = ICMP from > the router back to the client telling it that it cannot send the packet. > > I have tried all sorts of changes to my pf rules, including now allowing > all ICMP unconditionally on all interfaces (pass out log quick inet proto > icmp all). I have packet traces during the failed communication across > pflog0, vlan0 (external network) and vlan7 (internal network). I=E2=80= =99d be > happy to answer any questions, or provide the traces off-list. > > Does anyone have any idea what I=E2=80=99ve missed? Thank you very much= for your > help. > > - Chris > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Mon Dec 5 17:50:25 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 069CFC683A7 for ; Mon, 5 Dec 2016 17:50:25 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id D8D6E924 for ; Mon, 5 Dec 2016 17:50:24 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 388082AB8; Mon, 5 Dec 2016 17:50:24 +0000 (UTC) Date: Mon, 5 Dec 2016 17:50:24 +0000 To: freebsd-net@freebsd.org From: "alc (Alan Cox)" Reply-to: D8637+325+4a3b3c6133fb39c2@reviews.freebsd.org Subject: [Differential] D8637: buf_ring.h: fix memory order issues. Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , Thread-Topic: D8637: buf_ring.h: fix memory order issues. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: MTU4NzczNmYxMjUyY2VhODkxYTIyZGM3NmJiIFhFqOA= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 17:50:25 -0000 YWxjIGFkZGVkIGEgY29tbWVudC4KCgogIEhhdmUgeW91IGxvb2tlZCBhdCBodHRwczovL3Jldmll d3MuZnJlZWJzZC5vcmcvRDE5NDUsIGluIHBhcnRpY3VsYXIsIHRoZSBtb3N0IHJlY2VudCBwb3N0 aW5ncyBieSBzYmFocmFfcmVwbm9wLm9yZz8gIEl0J3Mgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhl c2UgY2hhbmdlcyB3aWxsIGFkZHJlc3MgdGhlIHByb2JsZW0gZGVzY3JpYmVkIGluIHNiYWhyYV9y ZXBub3Aub3JnJ3MgcG9zdGluZ3MuICBUaGF0IHNhaWQsIHlvdXIgcHJvcG9zZWQgY2hhbmdlcyBk byBjb3JyZWN0IHRoZSBtb3N0IG9idmlvdXMgcmVtYWluaW5nIGlzc3VlcyB3aXRoIHRoZSB1c2Ug b2YgYWNxdWlyZXMgYW5kIHJlbGVhc2VzIGluIHRoaXMgY29kZS4KCklOTElORSBDT01NRU5UUwoK PiBidWZfcmluZy5oOjc4Cj4gIAlkbyB7Cj4gKwkJY29uc190YWlsID0gYXRvbWljX2xvYWRfYWNx XzMyKCZici0+YnJfY29uc190YWlsKTsKPiAgCQlwcm9kX2hlYWQgPSBici0+YnJfcHJvZF9oZWFk OwoKV2FzIHRoZXJlIGEgcmVhc29uIGZvciBtb3ZpbmcgdGhpcyBsb2FkPwoKPiBidWZfcmluZy5o Ojk4Cj4gIAkgKi8gICAKPiAgCXdoaWxlIChici0+YnJfcHJvZF90YWlsICE9IHByb2RfaGVhZCkK PiAgCQljcHVfc3BpbndhaXQoKTsKCllvdSBtYXkgbmVlZCB0byB1c2UgYSBsb2FkIGFjcXVpcmUg b24gYnJfcHJvZF90YWlsIGhlcmUgdG8gZXN0YWJsaXNoIGFuIHVuYnJva2VuIHN5bmNocm9uaXpl cy13aXRoIGNoYWluIGJldHdlZW4gdGhlIHRocmVhZCB0aGF0IGVucXVldWVzIGFuIGl0ZW0gWCBh bmQgdGhlIHRocmVhZCB0aGF0IGxhdGVyIGRlcXVldWVzIGl0IGlmIHRoZXJlIGFyZSBvdGhlciBj b25jdXJyZW50IGVucXVldWVzLgoKPiBidWZfcmluZy5oOjExNwo+ICAJZG8gewo+ICsJCXByb2Rf dGFpbCA9IGF0b21pY19sb2FkX2FjcV8zMigmYnItPmJyX3Byb2RfdGFpbCk7Cj4gIAkJY29uc19o ZWFkID0gYnItPmJyX2NvbnNfaGVhZDsKCldhcyB0aGVyZSBhIHJlYXNvbiBmb3IgbW92aW5nIHRo aXMgbG9hZD8KCj4gYnVmX3JpbmcuaDoxNTkKPiAgCXByb2RfdGFpbCA9IGF0b21pY19sb2FkX2Fj cV8zMigmYnItPmJyX3Byb2RfdGFpbCk7Cj4gLQkKPiAtCWNvbnNfbmV4dCA9IChjb25zX2hlYWQg KyAxKSAmIGJyLT5icl9jb25zX21hc2s7Cj4gLSNpZmRlZiBQUkVGRVRDSF9ERUZJTkVECj4gLQlj b25zX25leHRfbmV4dCA9IChjb25zX2hlYWQgKyAyKSAmIGJyLT5icl9jb25zX21hc2s7Cj4gLSNl bmRpZgo+ICsJY29uc19oZWFkID0gYnItPmJyX2NvbnNfaGVhZDsKPiAgCQoKV2FzIHRoZXJlIGEg cmVhc29uIGZvciBzd2FwcGluZyB0aGUgb3JkZXIgb2YgdGhlIHByZWNlZGluZyBsb2Fkcz8KCj4g YnVmX3JpbmcuaDoxNzQKPiAgCWJ1ZiA9IGJyLT5icl9yaW5nW2NvbnNfaGVhZF07Cj4gKwlici0+ YnJfY29uc19oZWFkID0gY29uc19uZXh0Owo+ICAKCldhcyB0aGVyZSBhIHJlYXNvbiBmb3Igc3dh cHBpbmcgdGhlIG9yZGVyIG9mIHRoZSBwcmVjZWRpbmcgbG9hZHM/CgpSRVZJU0lPTiBERVRBSUwK ICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDg2MzcKCkVNQUlMIFBSRUZFUkVOQ0VTCiAg aHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5j ZXMvCgpUbzogb2xlZywga21hY3ksIGtpYiwgYWxjCkNjOiBlbWFzdGUsIGZyZWVic2QtbmV0LWxp c3QK From owner-freebsd-net@freebsd.org Mon Dec 5 19:10:34 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B856C67B31; Mon, 5 Dec 2016 19:10:34 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:11::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27F3A13D4; Mon, 5 Dec 2016 19:10:34 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPSA id uB5JAPuP071545 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Dec 2016 14:10:33 -0500 (EST) (envelope-from cross+freebsd@distal.com) Received: from [IPv6:2001:420:2710:1330:b88b:3986:94f1:729] ([IPv6:2001:420:2710:1330:b88b:3986:94f1:729]) (authenticated bits=0) by mail.distal.com (8.15.2/8.15.2) with ESMTPSA id uB5JAMK6046088 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2016 14:10:22 -0500 (EST) (envelope-from cross+freebsd@distal.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Problems with FreeBSD (amd64 stable/11) router From: Chris Ross In-Reply-To: Date: Mon, 5 Dec 2016 14:10:17 -0500 Cc: freebsd-net , freebsd-pf@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C636365-DD9D-4375-9418-D540D8D13C56@distal.com> References: <619F01C2-5A20-4E25-AB0B-4064B598239D@distal.com> To: Ryan Stone X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 19:10:34 -0000 > On Dec 5, 2016, at 11:59, Ryan Stone wrote: >=20 > What's the MTU on the bce and vlan interfaces? Does the bce interface = show VLAN_MTU option set (in ifconfig)? I had manually set these to try to work out the problem earlier in my = experimentation, but am now back (unless I missed something) to the = natural MTUs on all interfaces. The vlan=E2=80=99s all show 1496, and = the bee=E2=80=99s (and lagg0) show 1500. The options on each of the = bce=E2=80=99s show VLAN_MTU, and a few other VLAN_ options. - Chris > On Mon, Dec 5, 2016 at 10:00 AM, Chris Ross = wrote: >=20 > Hello all. I recently replaced my router with a FreeBSD/11 box = (stable/11 r308579). I am running a lagg device across two bce=E2=80=99s,= and 802.1q vlan interfaces atop lagg0. I=E2=80=99m using pf to = NAT/filter out through a single outside IP address. >=20 > I=E2=80=99m having the following problem. Some devices appear to be = having trouble passing traffic. Of course, I first assumed I was doing = something wrong with my pf filters, but I believe now that=E2=80=99s not = the problem. One client machine (a TiVo Roamio) that produces a failure = reliably, so I=E2=80=99ve been using it for testing, is showing that = during a TCP session, which starts up fine, in the middle of a POST = operation to an outside server, there are 1500 byte packets. These = packets have the DF bit in the IP header, and then never show up on the = external interface (vlan0). Smaller packets in the same TCP stream do. = But, I=E2=80=99m also not seeing the ICMP from the router back to the = client telling it that it cannot send the packet. >=20 > I have tried all sorts of changes to my pf rules, including now = allowing all ICMP unconditionally on all interfaces (pass out log quick = inet proto icmp all). I have packet traces during the failed = communication across pflog0, vlan0 (external network) and vlan7 = (internal network). I=E2=80=99d be happy to answer any questions, or = provide the traces off-list. >=20 > Does anyone have any idea what I=E2=80=99ve missed? Thank you very = much for your help. >=20 > - Chris >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@freebsd.org Mon Dec 5 19:42:40 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B689BC68A8E for ; Mon, 5 Dec 2016 19:42:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 A67958B2 for ; Mon, 5 Dec 2016 19:42:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB5JgdKB057877 for ; Mon, 5 Dec 2016 19:42:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213257] Crash in IGB driver with ALTQ Date: Mon, 05 Dec 2016 19:42: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.3-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 19:42:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213257 --- Comment #12 from ncrogers@gmail.com --- If you're not actually using ALTQ (i.e., in a loaded PF configuration), I w= ould suggest simply removing ALTQ from your kernel config and building a new kernel. If you ARE utilizing altq with an igb interface, try setting hw.igb.num_queues=3D1 in loader.conf. ALTQ isn't able to utilize more than = one interface queue anyways. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Dec 5 19:45:59 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0F75C68B41 for ; Mon, 5 Dec 2016 19:45:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 8D4B19D8 for ; Mon, 5 Dec 2016 19:45:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB5JjxRK062223 for ; Mon, 5 Dec 2016 19:45:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213257] Crash in IGB driver with ALTQ Date: Mon, 05 Dec 2016 19:45:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 19:45:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213257 --- Comment #13 from ncrogers@gmail.com --- This issue is also discussed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208409 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Dec 5 21:52:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 979F5C687BF for ; Mon, 5 Dec 2016 21:52:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 8760C1AB6 for ; Mon, 5 Dec 2016 21:52:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB5LqHdO047820 for ; Mon, 5 Dec 2016 21:52:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 214832] if_pflog subrulenr incorrectly set Date: Mon, 05 Dec 2016 21:52: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-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 21:52:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214832 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Mon Dec 5 21:52:11 UTC 2016 New revision: 309563 URL: https://svnweb.freebsd.org/changeset/base/309563 Log: pflog: Correctly initialise subrulenr subrulenr is considered unset if it's set to -1, not if it's set to 1. See contrib/tcpdump/print-pflog.c pflog_print() for a user. This caused incorrect pflog output (tcpdump -n -e -ttt -i pflog0): rule 0..16777216(match) instead of the correct output of rule 0/0(match) PR: 214832 Submitted by: andywhite@gmail.com Changes: head/sys/netpfil/pf/if_pflog.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Dec 5 23:10:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77E02C68785 for ; Mon, 5 Dec 2016 23:10:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0093.outbound.protection.outlook.com [157.56.110.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2384512B8 for ; Mon, 5 Dec 2016 23:10:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Mon, 5 Dec 2016 22:54:19 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0761.016; Mon, 5 Dec 2016 22:54:19 +0000 From: Rick Macklem To: Jordan Ladora , "freebsd-net@freebsd.org" Subject: Re: File duplication on NFSv4 exported ZFS filesystems to centos client Thread-Topic: File duplication on NFSv4 exported ZFS filesystems to centos client Thread-Index: AQHSTNGLvid/pn4fzkGYDop7p0LBoKD1MwKFgAMEAACAAcK/Qg== Date: Mon, 5 Dec 2016 22:54:19 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: b4756085-bc0f-417e-cf3a-08d41d61a5c8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:Rqh3xLCwsFh5xep/POb3YxOgz+RsRm1rJ+SHolEDBhCjvNaCUcXfc1aEmG4jtj72E1cGc4rhraUNUtToo9RsRPcIUXXmr1VOIhkOMuP4yHOizrC4F0MFK+eJ0Y8D2Ca6c2ljsrL1PyD+hOQUCFpxibBMeizfhlO45E+o3knPFwMaGLU9DV3XtnChKMDkyxo4z8UYw1HtjckStV1wDgEkcZHVilNhSIsctHF3mN2lao8dfnZ53beVmJmXixeL5I9R4MyUxef5FT2wbReYCG7GZAGvuqJrxTG9ZXLv8/EQ+r9X99K199VQpkrN24NznQZSnG/JrRh/P8FgJQKVYxvOHlaoOIeSw12PBvdOp7DLOGrkyMk2qP3uiVjWJEvI6vJYU9shvgu+fM3rIAcuibqIfYgA70Mo0r4D547D4XPbt2kIRS7iDbe/VQPh23oIgMTNihbkxTxDPLIym805z6pfjw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(24454002)(122556002)(74482002)(6506006)(38730400001)(39060400001)(33656002)(3280700002)(2906002)(5001770100001)(86362001)(97736004)(229853002)(107886002)(74316002)(2900100001)(5890100001)(3660700001)(77096006)(2501003)(39450400002)(105586002)(106116001)(189998001)(106356001)(102836003)(7846002)(50986999)(9686002)(54356999)(76176999)(8936002)(8676002)(81156014)(81166006)(92566002)(68736007)(7696004)(305945005)(101416001)(5660300001)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 22:54:19.4114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:10:26 -0000 Jordan Ladora wrote: >Ahh!! Thank you! > >Previously, I tried exporting just the top-level zfs, but then couldn't >access the zfs filesystems inside from the client, but listing *all* of >them in /etc/exports and only mounting the top-level zfs works perfectly. > >Just wondering, by the way, if you knew why 'echo' doesn't work on NFS shares? How does it "not work?". I did a trivial test with the FreeBSD client and i= t seemed to work. If you run a test of "echo" while running the following on the FreeBSD serv= er and then email me the out.pcap file as an attachment, I can take a look at it. # tcpdump -s 0 -w out.pcap host rick From owner-freebsd-net@freebsd.org Tue Dec 6 00:54:15 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D7DCC59BFD for ; Tue, 6 Dec 2016 00:54:15 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 2C01B8EF for ; Tue, 6 Dec 2016 00:54:15 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 92A361447; Tue, 6 Dec 2016 00:54:14 +0000 (UTC) Date: Tue, 6 Dec 2016 00:54:14 +0000 To: freebsd-net@freebsd.org From: "oleg (Oleg Bulyzhin)" Reply-to: D8637+325+4a3b3c6133fb39c2@reviews.freebsd.org Subject: [Differential] D8637: buf_ring.h: fix memory order issues. Message-ID: <24dce39a56da9a22a2bfcb1677195ff8@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D8637: buf_ring.h: fix memory order issues. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: MTU4NzczNmYxMjUyY2VhODkxYTIyZGM3NmJiIFhGDDY= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 00:54:15 -0000 b2xlZyBhZGRlZCBhIGNvbW1lbnQuCgoKICBJbiBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcv RDg2MzcjMTgwNjI1LCBAYWxjIHdyb3RlOgogIAogID4gSGF2ZSB5b3UgbG9va2VkIGF0IGh0dHBz Oi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EMTk0NSwgaW4gcGFydGljdWxhciwgdGhlIG1vc3QgcmVj ZW50IHBvc3RpbmdzIGJ5IHNiYWhyYV9yZXBub3Aub3JnPyAgSXQncyBub3QgY2xlYXIgdG8gbWUg dGhhdCB0aGVzZSBjaGFuZ2VzIHdpbGwgYWRkcmVzcyB0aGUgcHJvYmxlbSBkZXNjcmliZWQgaW4g c2JhaHJhX3JlcG5vcC5vcmcncyBwb3N0aW5ncy4gIFRoYXQgc2FpZCwgeW91ciBwcm9wb3NlZCBj aGFuZ2VzIGRvIGNvcnJlY3QgdGhlIG1vc3Qgb2J2aW91cyByZW1haW5pbmcgaXNzdWVzIHdpdGgg dGhlIHVzZSBvZiBhY3F1aXJlcyBhbmQgcmVsZWFzZXMgaW4gdGhpcyBjb2RlLgogIAogIAogIFll cywgaSd2ZSBsb29rZWQgYXQgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QxOTQ1IGJ1dCBz b21laG93IGkndmUgbWlzc2VkIHNiYWhyYV9yZXBub3Aub3JnJ3MgY29tbWVudHMuIFNpbmNlIGkg d2FzIHRyeWluZyB0byBmaXggZGlmZmVyZW50IGlzc3VlIChodHRwczovL2xpc3RzLmZyZWVic2Qu b3JnL3BpcGVybWFpbC9mcmVlYnNkLW5ldC8yMDEzLURlY2VtYmVyLzAzNzI2NS5odG1sKSBhbmQg cmVtb3ZlIG15IG93biBybWIoKSBoYWNrIHRoZSBwcm9ibGVtIGRlc2NyaWJlZCBieSBzYmFocmFf cmVwbm9wLm9yZyBpcyBzdGlsbCBoZXJlLiBJJ2xsIHBvc3QgdXBkYXRlZCBkaWZmIHRvbW9ycm93 LgoKSU5MSU5FIENPTU1FTlRTCgo+IGFsYyB3cm90ZSBpbiBidWZfcmluZy5oOjk4Cj4gWW91IG1h eSBuZWVkIHRvIHVzZSBhIGxvYWQgYWNxdWlyZSBvbiBicl9wcm9kX3RhaWwgaGVyZSB0byBlc3Rh Ymxpc2ggYW4gdW5icm9rZW4gc3luY2hyb25pemVzLXdpdGggY2hhaW4gYmV0d2VlbiB0aGUgdGhy ZWFkIHRoYXQgZW5xdWV1ZXMgYW4gaXRlbSBYIGFuZCB0aGUgdGhyZWFkIHRoYXQgbGF0ZXIgZGVx dWV1ZXMgaXQgaWYgdGhlcmUgYXJlIG90aGVyIGNvbmN1cnJlbnQgZW5xdWV1ZXMuCgpBRkFJSyAn c3luY2hyb25pemVzLXdpdGggY2hhaW5zJyBhcmUgYWJvdXQgUk1XIG9wZXJhdGlvbnMgaW4gYmV0 d2VlbiBsb2FkX2FjcS9zdG9yZV9yZWwgc2VxdWVuY2UuIENhbiB5b3UgZXhwbGFpbiB3aHkgbG9h ZF9hY3EgaXMgbmVjZXNzYXJ5IGhlcmU/IEkgdGhpbmsgcHJvZHVjZXIgc2hvdWxkIG5vdCBjYXJl IGFib3V0IHZpc2liaWxpdHkgb2YgYnItPmJyX3JpbmdbcHJvZF9oZWFkXSBzdG9yZXMgb2Ygb3Ro ZXIgcHJvZHVjZXJzLgpDb3JyZWN0IG9yZGVyIG9mIG91ciBvd24gc3RvcmVzIGd1YXJhbnRlZWQg Ynkgc3RvcmVfcmVsKCZici0+YnJfcHJvZF90YWlsKSAoYW5kIGxvYWRfYWNxKCkgaW4gY29uc3Vt ZXIpLgoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q4NjM3 CgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9zZXR0aW5n cy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IG9sZWcsIGttYWN5LCBraWIsIGFsYwpDYzog ZW1hc3RlLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Tue Dec 6 04:21:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25C2FC696AD for ; Tue, 6 Dec 2016 04:21:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 14F9B12F for ; Tue, 6 Dec 2016 04:21:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB64L93T037760 for ; Tue, 6 Dec 2016 04:21:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213257] Crash in IGB driver with ALTQ Date: Tue, 06 Dec 2016 04:21:09 +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.3-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: see_also flagtypes.name keywords bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 04:21:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213257 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 084 | |09 Flags| |mfc-stable9?, | |mfc-stable10?, | |mfc-stable11? Keywords|IntelNetworking |crash, needs-qa Status|New |Open --- Comment #14 from Kubilay Kocak --- For anyone who is experiencing this crash/panic, please include as a single plaintext file attachment (not as a comment): - Crash backtrace (gdb -> bt) - Full version (uname -a) of the system - pciconf -lv output --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 6 04:21:15 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07FF3C696C0 for ; Tue, 6 Dec 2016 04:21:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 EB8D4151 for ; Tue, 6 Dec 2016 04:21:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB64L93p037760 for ; Tue, 6 Dec 2016 04:21:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208409] [PATCH] igb and ALTQ Date: Tue, 06 Dec 2016 04:21:09 +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.3-BETA2 X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 04:21:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208409 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 132 | |57 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 6 04:22:45 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60DCBC699F8 for ; Tue, 6 Dec 2016 04:22:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 B4DBB916 for ; Tue, 6 Dec 2016 04:22:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB64MiBR048277 for ; Tue, 6 Dec 2016 04:22:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 214832] if_pflog subrulenr incorrectly set Date: Tue, 06 Dec 2016 04:22:44 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kp@freebsd.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: flagtypes.name assigned_to bug_file_loc bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 04:22:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214832 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |maintainer-feedback?(kp@fre | |ebsd.org), mfc-stable9?, | |mfc-stable10?, | |mfc-stable11? Assignee|freebsd-net@FreeBSD.org |kp@freebsd.org URL| |https://svnweb.freebsd.org/ | |base/releng/11.0/sys/netpfi | |l/pf/if_pflog.c?view=3Dmar= kup | |#l224 Status|New |In Progress CC| |freebsd-net@FreeBSD.org --- Comment #4 from Kubilay Kocak --- Assign to committer resolving. Are stable/{11,10,9} affected? --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 6 09:01:27 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8796AC693EA for ; Tue, 6 Dec 2016 09:01:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 6FCF0182F for ; Tue, 6 Dec 2016 09:01:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB691R5b079980 for ; Tue, 6 Dec 2016 09:01:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 214832] if_pflog subrulenr incorrectly set Date: Tue, 06 Dec 2016 09:01:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kp@freebsd.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 09:01:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214832 --- Comment #5 from Kristof Provost --- I believe this affects everything. The bug seems to have been introduced wi= th a merge from OpenBSD about five years ago. Considering the low severity, the proximity of the EOL date and the pain of merging pf fixes back to it I'm not planning to merge this back to stable/9. MFC to stable/10 and stable/11 will be done in a week or so. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Dec 6 13:26:59 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EAD1C63074 for ; Tue, 6 Dec 2016 13:26:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 26E5490F for ; Tue, 6 Dec 2016 13:26:59 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 60B0A1B2B; Tue, 6 Dec 2016 13:26:58 +0000 (UTC) Date: Tue, 6 Dec 2016 13:26:58 +0000 To: freebsd-net@freebsd.org From: "oleg (Oleg Bulyzhin)" Reply-to: D8637+325+4a3b3c6133fb39c2@reviews.freebsd.org Subject: [Differential] D8637: buf_ring.h: fix memory order issues. Message-ID: <97fc3e89e8a20806270e7ab7134d7e0e@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , Thread-Topic: D8637: buf_ring.h: fix memory order issues. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: MTU4NzczNmYxMjUyY2VhODkxYTIyZGM3NmJiIFhGvKI= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_97fc3e89e8a20806270e7ab7134d7e0e" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 13:26:59 -0000 --b1_97fc3e89e8a20806270e7ab7134d7e0e Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 b2xlZyB1cGRhdGVkIHRoaXMgcmV2aXNpb24gdG8gRGlmZiAyMjcyOC4Kb2xlZyBhZGRlZCBhIGNv bW1lbnQuCgoKICAxLiBmaXggaXNzdWVzIHJlcG9ydGVkIGJ5IHNiYWhyYV9yZXBub3Aub3JnIGhl cmU6IGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EMTk0NQogIDIuIGZpeCBzeW5jaHJvbml6 YXRpb24gY2hhaW4gKHByb2R1Y2VyIC0+IHByb2R1Y2VyIC0+IGNvbnN1bWVyKSBub3RlZCBieSBh bGMuCiAgMy4gbWFzc2l2ZSBjb21tZW50cy4KCkNIQU5HRVMgU0lOQ0UgTEFTVCBVUERBVEUKICBo dHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDg2Mzc/dnM9MjI1MDcmaWQ9MjI3MjgKClJFVklT SU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EODYzNwoKQUZGRUNURUQg RklMRVMKICBzeXMvc3lzL2J1Zl9yaW5nLmgKCkVNQUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9y ZXZpZXdzLmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzog b2xlZywga21hY3ksIGtpYiwgYWxjCkNjOiBlbWFzdGUsIGZyZWVic2QtbmV0LWxpc3QK --b1_97fc3e89e8a20806270e7ab7134d7e0e Content-Type: text/x-patch; charset=utf-8; name="D8637.22728.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D8637.22728.patch" ZGlmZiAtLWdpdCBhL3N5cy9zeXMvYnVmX3JpbmcuaCBiL3N5cy9zeXMvYnVmX3JpbmcuaAotLS0g YS9zeXMvc3lzL2J1Zl9yaW5nLmgKKysrIGIvc3lzL3N5cy9idWZfcmluZy5oCkBAIC03NSwzNSAr NzUsNjkgQEAKICNlbmRpZgkKIAljcml0aWNhbF9lbnRlcigpOwogCWRvIHsKLQkJcHJvZF9oZWFk ID0gYnItPmJyX3Byb2RfaGVhZDsKKwkJLyoKKwkJICogbG9hZF9hY3EocHJvZF9oZWFkKSBwcmVj ZWRpbmcgbG9hZChjb25zX3RhaWwpIGlzCisJCSAqIG1hbmRhdG9yeTogY29uc190YWlsIE1VU1Qg YmUgbm90ICdvbGRlcicgdGhhbiBwcm9kX2hlYWQuCisJCSAqIE90aGVyd2lzZSBmb2xsb3dpbmcg Y2FuIGhhcHBlbjoKKwkJICogYSkgaW5pdGlhbCBzdGF0ZTogY29uc190YWlsOiAxIHByb2RfaGVh ZDogMCByaW5nIGlzIGZ1bGwuCisJCSAqIGIpIGNwdTA6IHJlYWRzIGNvbnNfdGFpbDogMQorCQkg KiBjKSBjcHUxOiBydW5zIGNvbnN1bWVyIGFuZCBzZXRzIGNvbnNfdGFpbDogMgorCQkgKiBkKSBj cHUxOiBydW5zIHByb2R1Y2VyIGFuZCBzZXRzIHByb2RfaGVhZDogMQorCQkgKiAgICAgICAgICBy aW5nIGlzIGZ1bGwgYWdhaW4uCisJCSAqIGUpIGNwdTA6IHJlYWRzIHByb2RfaGVhZDogMSwgJ3Jp bmcgaXMgZnVsbCcgY2hlY2sgd2lsbCBmYWlsLgorCQkgKiBmKSBjcHUwOiBjbXBzZXQocHJvZF9o ZWFkKSB3aWxsIGJlIHN1Y2Nlc3NmdWwuCisJCSAqIGcpIHJpbmcgaXMgY29ycnVwdGVkLgorCQkg Ki8KKwkJcHJvZF9oZWFkID0gYXRvbWljX2xvYWRfYWNxXzMyKCZici0+YnJfcHJvZF9oZWFkKTsK IAkJcHJvZF9uZXh0ID0gKHByb2RfaGVhZCArIDEpICYgYnItPmJyX3Byb2RfbWFzazsKLQkJY29u c190YWlsID0gYnItPmJyX2NvbnNfdGFpbDsKLQotCQlpZiAocHJvZF9uZXh0ID09IGNvbnNfdGFp bCkgewotCQkJcm1iKCk7Ci0JCQlpZiAocHJvZF9oZWFkID09IGJyLT5icl9wcm9kX2hlYWQgJiYK LQkJCSAgICBjb25zX3RhaWwgPT0gYnItPmJyX2NvbnNfdGFpbCkgewotCQkJCWJyLT5icl9kcm9w cysrOwotCQkJCWNyaXRpY2FsX2V4aXQoKTsKLQkJCQlyZXR1cm4gKEVOT0JVRlMpOwotCQkJfQot CQkJY29udGludWU7CisJCS8qCisJCSAqIGxvYWRfYWNxKGNvbnNfdGFpbCkgaXMgcmVxdWlyZWQ6 IHRodXMgd2Ugc3luY2hyb25pemUgd2l0aAorCQkgKiBjb25zdW1lcnMuCisJCSAqLworCQljb25z X3RhaWwgPSBhdG9taWNfbG9hZF9hY3FfMzIoJmJyLT5icl9jb25zX3RhaWwpOworCisJCWlmIChw cm9kX25leHQgPT0gY29uc190YWlsKSB7CS8qIHJpbmcgaXMgZnVsbCAqLworCQkJLyoKKwkJCSAq IHByb2RfaGVhZCBjYW4gYmUgJ29sZGVyJyB0aGFuIGNvbnNfdGFpbCAoc2VlIGFib3ZlKSwKKwkJ CSAqIHNvIHRoaXMgY2FuIGJlIGZhbHNlIHBvc2l0aXZlICdyaW5nIGlzIGZ1bGwnIGVycm9yLgor CQkJICogY2hlY2sgaXQuCisJCQkgKi8KKwkJCWlmIChwcm9kX2hlYWQgIT0gYXRvbWljX2xvYWRf YWNxXzMyKCZici0+YnJfcHJvZF9oZWFkKSkKKwkJCQljb250aW51ZTsKKwkJCWJyLT5icl9kcm9w cysrOworCQkJY3JpdGljYWxfZXhpdCgpOworCQkJcmV0dXJuIChFTk9CVUZTKTsKIAkJfQotCX0g d2hpbGUgKCFhdG9taWNfY21wc2V0X2FjcV9pbnQoJmJyLT5icl9wcm9kX2hlYWQsIHByb2RfaGVh ZCwgcHJvZF9uZXh0KSk7CisJfSB3aGlsZSAoIWF0b21pY19jbXBzZXRfMzIoJmJyLT5icl9wcm9k X2hlYWQsIHByb2RfaGVhZCwgcHJvZF9uZXh0KSk7CiAjaWZkZWYgREVCVUdfQlVGUklORwogCWlm IChici0+YnJfcmluZ1twcm9kX2hlYWRdICE9IE5VTEwpCiAJCXBhbmljKCJkYW5nbGluZyB2YWx1 ZSBpbiBlbnF1ZXVlIik7CiAjZW5kaWYJCiAJYnItPmJyX3JpbmdbcHJvZF9oZWFkXSA9IGJ1ZjsK LQogCS8qCi0JICogSWYgdGhlcmUgYXJlIG90aGVyIGVucXVldWVzIGluIHByb2dyZXNzCi0JICog dGhhdCBwcmVjZWRlZCB1cywgd2UgbmVlZCB0byB3YWl0IGZvciB0aGVtCi0JICogdG8gY29tcGxl dGUgCisJICogSWYgdGhlcmUgYXJlIG90aGVyIGVucXVldWVzIGluIHByb2dyZXNzIHRoYXQgcHJl Y2VkZWQgdXMsIHdlIG5lZWQKKwkgKiB0byB3YWl0IGZvciB0aGVtIHRvIGNvbXBsZXRlLgorCSAq IGxvYWRfYWNxKHByb2RfdGFpbCkgaXMgcmVxdWlyZWQgZm9yIHByb3BlciBzeW5jaHJvbml6YXRp b24gY2hhaW4KKwkgKiBhbW9uZyBjb25zdW1lciBhbmQgbXVsdGlwbGUgcHJvZHVjZXJzLgorCSAq IENvbnNpZGVyIGZvbGxvd2luZyBzY2VuYXJpbzoKKwkgKiBhKSBpbml0aWFsIHN0YXRlOiBwcm9k X2hlYWQscHJvZF90YWlsLGNvbnNfaGVhZCxjb25zX3RhaWwgYXJlIDAuCisJICogICAgcmluZyBp cyBlbXB0eS4KKwkgKiBiKSBjcHUwOiBydW5zIHByb2R1Y2VyLCBncmFicyBwcm9kX2hlYWQ6IDAg YW5kIHNldHMgcHJvZF9oZWFkOiAxCisJICogYykgY3B1MTogcnVucyBwcm9kdWNlciwgZ3JhYnMg cHJvZF9oZWFkOiAxIGFuZCBzZXRzIHByb2RfaGVhZDogMgorCSAqIGQpIGNwdTE6IHN0b3JlcyBk YXRhIHRvIHJpbmdbMV0gYW5kIHdhaXRzIGZvciBwcm9kX3RhaWw6IDEKKwkgKiBlKSBjcHUwOiBz dG9yZXMgZGF0YSB0byByaW5nWzBdLCBzZXRzIHByb2RfdGFpbDogMQorCSAqIGYpIGNwdTE6IHNl ZXMgcHJvZF90YWlsOiAxLiBJZiBsb2FkKHByb2RfdGFpbCkgd2FzIGRvbmUgd2l0aG91dCBfYWNx CisJICogICAgYmFycmllciB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCBzdG9yZSB0byByaW5n WzBdIGlzIHZpc2libGUuCisJICogZykgY3B1MTogZXhlY3V0ZXMgc3RvcmVfcmVsKHByb2RfdGFp bDogMikKKwkgKiBoKSBjcHUyOiBydW5zIGNvbnN1bWVyLCBleGVjdXRlcyBsb2FkX2FjcShwcm9k X3RhaWwpIGFuZCBzZWVzCisJICogICAgcHJvZF90YWlsOiAyLiBhY3EvcmVsIHNlbWFudGljIGlu IGNvbnN1bWVyL3Byb2R1Y2VyIGd1YXJhbnRlZXMKKwkgKiAgICBjb25zaXN0ZW50IHJlYWQgZnJv bSByaW5nWzFdIGFuZCBfZG9lcyBub3QgZ3VhcmFudGVlXyBjb25zaXN0ZW50CisJICogICAgcmVh ZCBmcm9tIHJpbmdbMF0gKGlmIHdlIGhhZCB1bm9yZGVyZWQgbG9hZChwcm9kX3RhaWwpIGluIGYp LgorCSAqIGkpIGNwdTI6IHJlYWRzIGp1bmsgZnJvbSByaW5nWzBdCiAJICovICAgCi0Jd2hpbGUg KGJyLT5icl9wcm9kX3RhaWwgIT0gcHJvZF9oZWFkKQorCXdoaWxlIChhdG9taWNfbG9hZF9hY3Ff MzIoJmJyLT5icl9wcm9kX3RhaWwpICE9IHByb2RfaGVhZCkKIAkJY3B1X3NwaW53YWl0KCk7Ci0J YXRvbWljX3N0b3JlX3JlbF9pbnQoJmJyLT5icl9wcm9kX3RhaWwsIHByb2RfbmV4dCk7CisJYXRv bWljX3N0b3JlX3JlbF8zMigmYnItPmJyX3Byb2RfdGFpbCwgcHJvZF9uZXh0KTsKIAljcml0aWNh bF9leGl0KCk7CiAJcmV0dXJuICgwKTsKIH0KQEAgLTExNSwxOSArMTQ5LDQ1IEBACiBzdGF0aWMg X19pbmxpbmUgdm9pZCAqCiBidWZfcmluZ19kZXF1ZXVlX21jKHN0cnVjdCBidWZfcmluZyAqYnIp CiB7Ci0JdWludDMyX3QgY29uc19oZWFkLCBjb25zX25leHQ7CisJdWludDMyX3QgY29uc19oZWFk LCBjb25zX25leHQsIHByb2RfdGFpbDsKIAl2b2lkICpidWY7CiAKIAljcml0aWNhbF9lbnRlcigp OwogCWRvIHsKLQkJY29uc19oZWFkID0gYnItPmJyX2NvbnNfaGVhZDsKLQkJY29uc19uZXh0ID0g KGNvbnNfaGVhZCArIDEpICYgYnItPmJyX2NvbnNfbWFzazsKLQotCQlpZiAoY29uc19oZWFkID09 IGJyLT5icl9wcm9kX3RhaWwpIHsKKwkJLyoKKwkJICogbG9hZF9hY3EoY29uc19oZWFkKSBwcmVj ZWRpbmcgbG9hZChwcm9kX3RhaWwpIGlzCisJCSAqIG1hbmRhdG9yeTogcHJvZF90YWlsIE1VU1Qg YmUgbm90ICdvbGRlcicgdGhhbiBjb25zX2hlYWQuCisJCSAqIE90aGVyd2lzZSBmb2xsb3dpbmcg Y2FuIGhhcHBlbjoKKwkJICogYSkgaW5pdGlhbCBzdGF0ZTogcHJvZF90YWlsOiAwIGNvbnNfaGVh ZDogMCByaW5nIGlzIGVtcHR5LgorCQkgKiBiKSBjcHUwOiByZWFkcyBwcm9kX3RhaWw6IDAKKwkJ ICogYykgY3B1MTogcnVucyBwcm9kdWNlciBhbmQgc2V0cyBwcm9kX3RhaWw6IDEKKwkJICogZCkg Y3B1MTogcnVucyBjb25zdW1lciBhbmQgc2V0cyBjb25zX2hlYWQ6IDEKKwkJICogICAgICAgICAg cmluZyBpcyBlbXB0eSBhZ2Fpbi4KKwkJICogZSkgY3B1MDogcmVhZHMgY29uc19oZWFkOiAxLCAn cmluZyBpcyBlbXB0eScgY2hlY2sgd2lsbCBmYWlsLgorCQkgKiBmKSBjcHUwOiBjbXBzZXQoY29u c19oZWFkKSB3aWxsIGJlIHN1Y2Nlc3NmdWwuCisJCSAqIGcpIGNwdTA6IHJlYWRzIGp1bmsgZnJv bSBlbXB0eSByaW5nCisJCSAqLworCQljb25zX2hlYWQgPSBhdG9taWNfbG9hZF9hY3FfMzIoJmJy LT5icl9jb25zX2hlYWQpOworCQkvKgorCQkgKiBsb2FkX2FjcShwcm9kX3RhaWwpIGlzIHJlcXVp cmVkOiB0aHVzIHdlIHN5bmNocm9uaXplIHdpdGgKKwkJICogcHJvZHVjZXJzIGFuZCBsYXRlciBi ci0+YnJfcmluZ1tjb25zX2hlYWRdIGxvYWQgd2lsbCBiZQorCQkgKiBjb25zaXN0ZW50LgorCQkg Ki8KKwkJcHJvZF90YWlsID0gYXRvbWljX2xvYWRfYWNxXzMyKCZici0+YnJfcHJvZF90YWlsKTsK KworCQlpZiAoY29uc19oZWFkID09IHByb2RfdGFpbCkgewkvKiByaW5nIGlzIGVtcHR5ICovCisJ CQkvKgorCQkJICogU2luY2UgY29uc19oZWFkIGNhbiBiZSAnb2xkZXInIHRoYW4gcHJvZF90YWls IHRoaXMKKwkJCSAqIGNhbiBiZSBmYWxzZSBwb3NpdGl2ZSAncmluZyBpcyBlbXB0eScuCisJCQkg KiBXZSBjYW4gY2hlY2sgaXQgaGVyZSBvciBqdXN0IHdhaXQgZm9yIG5leHQKKwkJCSAqIGJ1Zl9y aW5nX2RlcXVldWVfbWMoKSBjYWxsLgorCQkJICovCiAJCQljcml0aWNhbF9leGl0KCk7CiAJCQly ZXR1cm4gKE5VTEwpOwogCQl9Ci0JfSB3aGlsZSAoIWF0b21pY19jbXBzZXRfYWNxX2ludCgmYnIt PmJyX2NvbnNfaGVhZCwgY29uc19oZWFkLCBjb25zX25leHQpKTsKKworCQljb25zX25leHQgPSAo Y29uc19oZWFkICsgMSkgJiBici0+YnJfY29uc19tYXNrOworCX0gd2hpbGUgKCFhdG9taWNfY21w c2V0XzMyKCZici0+YnJfY29uc19oZWFkLCBjb25zX2hlYWQsIGNvbnNfbmV4dCkpOwogCiAJYnVm ID0gYnItPmJyX3JpbmdbY29uc19oZWFkXTsKICNpZmRlZiBERUJVR19CVUZSSU5HCkBAIC0xNDAs MTAgKzIwMCw4IEBACiAJICovICAgCiAJd2hpbGUgKGJyLT5icl9jb25zX3RhaWwgIT0gY29uc19o ZWFkKQogCQljcHVfc3BpbndhaXQoKTsKLQotCWF0b21pY19zdG9yZV9yZWxfaW50KCZici0+YnJf Y29uc190YWlsLCBjb25zX25leHQpOworCWF0b21pY19zdG9yZV9yZWxfMzIoJmJyLT5icl9jb25z X3RhaWwsIGNvbnNfbmV4dCk7CiAJY3JpdGljYWxfZXhpdCgpOwotCiAJcmV0dXJuIChidWYpOwog fQogCkBAIC0xNTUsNjIgKzIxMyw0MSBAQAogc3RhdGljIF9faW5saW5lIHZvaWQgKgogYnVmX3Jp bmdfZGVxdWV1ZV9zYyhzdHJ1Y3QgYnVmX3JpbmcgKmJyKQogewotCXVpbnQzMl90IGNvbnNfaGVh ZCwgY29uc19uZXh0OworCXVpbnQzMl90IGNvbnNfaGVhZCwgY29uc19uZXh0LCBwcm9kX3RhaWw7 CiAjaWZkZWYgUFJFRkVUQ0hfREVGSU5FRAogCXVpbnQzMl90IGNvbnNfbmV4dF9uZXh0OwogI2Vu ZGlmCi0JdWludDMyX3QgcHJvZF90YWlsOwogCXZvaWQgKmJ1ZjsKIAogCS8qCi0JICogVGhpcyBp cyBhIHdvcmthcm91bmQgdG8gYWxsb3cgdXNpbmcgYnVmX3Jpbmcgb24gQVJNIGFuZCBBUk02NC4K LQkgKiBBUk02NFRPRE86IEZpeCBidWZfcmluZyBpbiBhIGdlbmVyaWMgd2F5LgotCSAqIFJFTUFS S1M6IEl0IGlzIHN1c3BlY3RlZCB0aGF0IGJyX2NvbnNfaGVhZCBkb2VzIG5vdCByZXF1aXJlCi0J ICogICBsb2FkX2FjcSBvcGVyYXRpb24sIGJ1dCB0aGlzIGNoYW5nZSB3YXMgZXh0ZW5zaXZlbHkg dGVzdGVkCi0JICogICBhbmQgY29uZmlybWVkIGl0J3Mgd29ya2luZy4gVG8gYmUgcmV2aWV3ZWQg b25jZSBhZ2FpbiBpbgotCSAqICAgRnJlZUJTRC0xMi4KLQkgKgotCSAqIFByZXZlbnRpbmcgZm9s bG93aW5nIHNpdHVhdGlvbjoKLQotCSAqIENvcmUoMCkgLSBidWZfcmluZ19lbnF1ZXVlKCkgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb3JlKDEpIC0gYnVmX3JpbmdfZGVx dWV1ZV9zYygpCi0JICogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0JICoKLQkgKiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY29uc19oZWFkID0gYnItPmJyX2NvbnNfaGVhZDsKLQkgKiBhdG9taWNfY21wc2V0X2FjcV8z MigmYnItPmJyX3Byb2RfaGVhZCwgLi4uKSk7Ci0JICogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJ1 ZiA9IGJyLT5icl9yaW5nW2NvbnNfaGVhZF07ICAgICA8c2VlIDwxPj4KLQkgKiBici0+YnJfcmlu Z1twcm9kX2hlYWRdID0gYnVmOwotCSAqIGF0b21pY19zdG9yZV9yZWxfMzIoJmJyLT5icl9wcm9k X3RhaWwsIC4uLik7Ci0JICogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2RfdGFpbCA9IGJyLT5i cl9wcm9kX3RhaWw7Ci0JICogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChjb25zX2hlYWQgPT0g cHJvZF90YWlsKSAKLQkgKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gKE5V TEwpOwotCSAqICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8Y29uZGl0aW9uIGlzIGZhbHNlIGFuZCBj b2RlIHVzZXMgaW52YWxpZChvbGQpIGJ1Zj5gCQotCSAqCi0JICogPDE+IExvYWQgKG9uIGNvcmUg MSkgZnJvbSBici0+YnJfcmluZ1tjb25zX2hlYWRdIGNhbiBiZSByZW9yZGVyZWQgKHNwZWN1bGF0 aXZlIHJlYWRlZCkgYnkgQ1BVLgotCSAqLwkKLSNpZiBkZWZpbmVkKF9fYXJtX18pIHx8IGRlZmlu ZWQoX19hYXJjaDY0X18pCi0JY29uc19oZWFkID0gYXRvbWljX2xvYWRfYWNxXzMyKCZici0+YnJf Y29uc19oZWFkKTsKLSNlbHNlCi0JY29uc19oZWFkID0gYnItPmJyX2NvbnNfaGVhZDsKLSNlbmRp ZgorCSAqIGJ1Zl9yaW5nX2RlcXVldWVfbWMoKSBmYXRhbCBzY2VuYXJpbyAoc2VlIGFib3ZlKSBp cyBub3QgcG9zc2libGUKKwkgKiBmb3Igc2luZ2xlIGNvbnN1bWVyLiBTbyB3ZSByZWFkIHByb2Rf dGFpbCBmaXJzdCBpbiBvcmRlciB0bworCSAqIGF2b2lkIGZhbHNlIHBvc2l0aXZlICdyaW5nIGlz IGVtcHR5JyBjaGVjay4KKwkgKiBsb2FkX2FjcShwcm9kX3RhaWwpIGlzIG5lY2Vzc2FyeSBmb3Ig bGF0ZXIgYnItPmJyX3JpbmdbY29uc19oZWFkXQorCSAqIGxvYWQuCisJICovCiAJcHJvZF90YWls ID0gYXRvbWljX2xvYWRfYWNxXzMyKCZici0+YnJfcHJvZF90YWlsKTsKLQkKLQljb25zX25leHQg PSAoY29uc19oZWFkICsgMSkgJiBici0+YnJfY29uc19tYXNrOwotI2lmZGVmIFBSRUZFVENIX0RF RklORUQKLQljb25zX25leHRfbmV4dCA9IChjb25zX2hlYWQgKyAyKSAmIGJyLT5icl9jb25zX21h c2s7Ci0jZW5kaWYKKwljb25zX2hlYWQgPSBici0+YnJfY29uc19oZWFkOwogCQogCWlmIChjb25z X2hlYWQgPT0gcHJvZF90YWlsKSAKIAkJcmV0dXJuIChOVUxMKTsKIAotI2lmZGVmIFBSRUZFVENI X0RFRklORUQJCisJY29uc19uZXh0ID0gKGNvbnNfaGVhZCArIDEpICYgYnItPmJyX2NvbnNfbWFz azsKKyNpZmRlZiBQUkVGRVRDSF9ERUZJTkVECiAJaWYgKGNvbnNfbmV4dCAhPSBwcm9kX3RhaWwp IHsJCQogCQlwcmVmZXRjaChici0+YnJfcmluZ1tjb25zX25leHRdKTsKKwkJY29uc19uZXh0X25l eHQgPSAoY29uc19oZWFkICsgMikgJiBici0+YnJfY29uc19tYXNrOwogCQlpZiAoY29uc19uZXh0 X25leHQgIT0gcHJvZF90YWlsKSAKIAkJCXByZWZldGNoKGJyLT5icl9yaW5nW2NvbnNfbmV4dF9u ZXh0XSk7CiAJfQogI2VuZGlmCi0JYnItPmJyX2NvbnNfaGVhZCA9IGNvbnNfbmV4dDsKKwkvKgor CSAqIFRoZSBvcmRlciBhbmQgYXRvbWljaXR5IG9mIG5leHQgdHdvIG9wZXJhdGlvbnMgYXJlIHVu aW1wb3J0YW50OgorCSAqIHN0b3JlKGNvbnNfaGVhZCkgaXMgcHJvdGVjdGVkIGJ5IGxvY2sgKHNp bmdsZSBjb25zdW1lciBjYXNlKSwKKwkgKiBsb2FkKHJpbmdbY29uc19oZWFkXSkgaXMgb3JkZXJl ZCBieSBsYXRlciBzdG9yZV9yZWwoY29uc190YWlsKS4KKwkgKi8KIAlidWYgPSBici0+YnJfcmlu Z1tjb25zX2hlYWRdOworCWJyLT5icl9jb25zX2hlYWQgPSBjb25zX25leHQ7CiAKICNpZmRlZiBE RUJVR19CVUZSSU5HCiAJYnItPmJyX3JpbmdbY29uc19oZWFkXSA9IE5VTEw7CkBAIC0yMjAsNyAr MjU3LDcgQEAKIAkJcGFuaWMoImluY29uc2lzdGVudCBsaXN0IGNvbnNfdGFpbD0lZCBjb25zX2hl YWQ9JWQiLAogCQkgICAgYnItPmJyX2NvbnNfdGFpbCwgY29uc19oZWFkKTsKICNlbmRpZgotCWJy LT5icl9jb25zX3RhaWwgPSBjb25zX25leHQ7CisJYXRvbWljX3N0b3JlX3JlbF8zMigmYnItPmJy X2NvbnNfdGFpbCwgY29uc19uZXh0KTsKIAlyZXR1cm4gKGJ1Zik7CiB9CiAKQEAgLTIzMywxOSAr MjcwLDI1IEBACiBidWZfcmluZ19hZHZhbmNlX3NjKHN0cnVjdCBidWZfcmluZyAqYnIpCiB7CiAJ dWludDMyX3QgY29uc19oZWFkLCBjb25zX25leHQ7Ci0JdWludDMyX3QgcHJvZF90YWlsOwogCQor CS8qCisJICogYXRvbWljX2xvYWRfYWNxXzMyKCZici0+YnJfcHJvZF90YWlsKSBpcyBzdXBlcmZs dW91cyBoZXJlLgorCSAqIChhY3R1YWxseSBpdCB3YXMgZG9uZSBpbiBwcmVjZWRpbmcgYnVmX3Jp bmdfcGVlaykKKwkgKi8KIAljb25zX2hlYWQgPSBici0+YnJfY29uc19oZWFkOwotCXByb2RfdGFp bCA9IGJyLT5icl9wcm9kX3RhaWw7Ci0JCi0JY29uc19uZXh0ID0gKGNvbnNfaGVhZCArIDEpICYg YnItPmJyX2NvbnNfbWFzazsKLQlpZiAoY29uc19oZWFkID09IHByb2RfdGFpbCkgCisJaWYgKGNv bnNfaGVhZCA9PSBici0+YnJfcHJvZF90YWlsKSB7CisjaWZkZWYgREVCVUdfQlVGUklORworCQlw YW5pYygiYWR2YW5jZSBvbiBlbXB0eSByaW5nLiBubyBwcmV2aW91cyBwZWVrPyIpOworI2VuZGlm CiAJCXJldHVybjsKKwl9CisKKwljb25zX25leHQgPSAoY29uc19oZWFkICsgMSkgJiBici0+YnJf Y29uc19tYXNrOwogCWJyLT5icl9jb25zX2hlYWQgPSBjb25zX25leHQ7CiAjaWZkZWYgREVCVUdf QlVGUklORwogCWJyLT5icl9yaW5nW2NvbnNfaGVhZF0gPSBOVUxMOwogI2VuZGlmCi0JYnItPmJy X2NvbnNfdGFpbCA9IGNvbnNfbmV4dDsKKwlhdG9taWNfc3RvcmVfcmVsXzMyKCZici0+YnJfY29u c190YWlsLCBjb25zX25leHQpOwogfQogCiAvKgpAQCAtMjgwLDQ4ICszMjMsNDYgQEAKIHN0YXRp YyBfX2lubGluZSB2b2lkICoKIGJ1Zl9yaW5nX3BlZWsoc3RydWN0IGJ1Zl9yaW5nICpicikKIHsK Kwl1aW50MzJfdCBjb25zX2hlYWQsIHByb2RfdGFpbDsKIAogI2lmZGVmIERFQlVHX0JVRlJJTkcK IAlpZiAoKGJyLT5icl9sb2NrICE9IE5VTEwpICYmICFtdHhfb3duZWQoYnItPmJyX2xvY2spKQog CQlwYW5pYygibG9jayBub3QgaGVsZCBvbiBzaW5nbGUgY29uc3VtZXIgZGVxdWV1ZSIpOwogI2Vu ZGlmCQotCS8qCi0JICogSSBiZWxpZXZlIGl0IGlzIHNhZmUgdG8gbm90IGhhdmUgYSBtZW1vcnkg YmFycmllcgotCSAqIGhlcmUgYmVjYXVzZSB3ZSBjb250cm9sIGNvbnMgYW5kIHRhaWwgaXMgd29y c3QgY2FzZQotCSAqIGEgbGFnZ2luZyBpbmRpY2F0b3Igc28gd2Ugd29yc3QgY2FzZSB3ZSBtaWdo dAotCSAqIHJldHVybiBOVUxMIGltbWVkaWF0ZWx5IGFmdGVyIGEgYnVmZmVyIGhhcyBiZWVuIGVu cXVldWVkCi0JICovCi0JaWYgKGJyLT5icl9jb25zX2hlYWQgPT0gYnItPmJyX3Byb2RfdGFpbCkK KwkvKiBzZWUgYnVmX3JpbmdfZGVxdWV1ZV9zYygpIGNvbW1lbnQgKi8KKwlwcm9kX3RhaWwgPSBh dG9taWNfbG9hZF9hY3FfMzIoJmJyLT5icl9wcm9kX3RhaWwpOworCWNvbnNfaGVhZCA9IGJyLT5i cl9jb25zX2hlYWQ7CisKKwlpZiAoY29uc19oZWFkID09IHByb2RfdGFpbCkKIAkJcmV0dXJuIChO VUxMKTsKIAkKLQlyZXR1cm4gKGJyLT5icl9yaW5nW2JyLT5icl9jb25zX2hlYWRdKTsKKwlyZXR1 cm4gKGJyLT5icl9yaW5nW2NvbnNfaGVhZF0pOwogfQogCiBzdGF0aWMgX19pbmxpbmUgdm9pZCAq CiBidWZfcmluZ19wZWVrX2NsZWFyX3NjKHN0cnVjdCBidWZfcmluZyAqYnIpCiB7CisJdWludDMy X3QgY29uc19oZWFkLCBwcm9kX3RhaWw7CisKICNpZmRlZiBERUJVR19CVUZSSU5HCiAJdm9pZCAq cmV0OwogCiAJaWYgKCFtdHhfb3duZWQoYnItPmJyX2xvY2spKQogCQlwYW5pYygibG9jayBub3Qg aGVsZCBvbiBzaW5nbGUgY29uc3VtZXIgZGVxdWV1ZSIpOwogI2VuZGlmCQotCS8qCi0JICogSSBi ZWxpZXZlIGl0IGlzIHNhZmUgdG8gbm90IGhhdmUgYSBtZW1vcnkgYmFycmllcgotCSAqIGhlcmUg YmVjYXVzZSB3ZSBjb250cm9sIGNvbnMgYW5kIHRhaWwgaXMgd29yc3QgY2FzZQotCSAqIGEgbGFn Z2luZyBpbmRpY2F0b3Igc28gd2Ugd29yc3QgY2FzZSB3ZSBtaWdodAotCSAqIHJldHVybiBOVUxM IGltbWVkaWF0ZWx5IGFmdGVyIGEgYnVmZmVyIGhhcyBiZWVuIGVucXVldWVkCi0JICovCi0JaWYg KGJyLT5icl9jb25zX2hlYWQgPT0gYnItPmJyX3Byb2RfdGFpbCkKLQkJcmV0dXJuIChOVUxMKTsK KwkvKiBzZWUgYnVmX3JpbmdfZGVxdWV1ZV9zYygpIGNvbW1lbnQgKi8KKwlwcm9kX3RhaWwgPSBh dG9taWNfbG9hZF9hY3FfMzIoJmJyLT5icl9wcm9kX3RhaWwpOworCWNvbnNfaGVhZCA9IGJyLT5i cl9jb25zX2hlYWQ7CiAKKwlpZiAoY29uc19oZWFkID09IHByb2RfdGFpbCkKKwkJcmV0dXJuIChO VUxMKTsKICNpZmRlZiBERUJVR19CVUZSSU5HCiAJLyoKIAkgKiBTaW5nbGUgY29uc3VtZXIsIGku ZS4gY29uc19oZWFkIHdpbGwgbm90IG1vdmUgd2hpbGUgd2UgYXJlCiAJICogcnVubmluZywgc28g YXRvbWljX3N3YXBfcHRyKCkgaXMgbm90IG5lY2Vzc2FyeSBoZXJlLgogCSAqLwotCXJldCA9IGJy LT5icl9yaW5nW2JyLT5icl9jb25zX2hlYWRdOwotCWJyLT5icl9yaW5nW2JyLT5icl9jb25zX2hl YWRdID0gTlVMTDsKKwlyZXQgPSBici0+YnJfcmluZ1tjb25zX2hlYWRdOworCWJyLT5icl9yaW5n W2NvbnNfaGVhZF0gPSBOVUxMOwogCXJldHVybiAocmV0KTsKICNlbHNlCiAJcmV0dXJuIChici0+ YnJfcmluZ1tici0+YnJfY29uc19oZWFkXSk7CkBAIC0zNTQsNiArMzk1LDQgQEAKICAgICBzdHJ1 Y3QgbXR4ICopOwogdm9pZCBidWZfcmluZ19mcmVlKHN0cnVjdCBidWZfcmluZyAqYnIsIHN0cnVj dCBtYWxsb2NfdHlwZSAqdHlwZSk7CiAKLQotCiAjZW5kaWYKCg== --b1_97fc3e89e8a20806270e7ab7134d7e0e-- From owner-freebsd-net@freebsd.org Tue Dec 6 13:38:32 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41A7DC635E7 for ; Tue, 6 Dec 2016 13:38:32 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 1FAE8DD0 for ; Tue, 6 Dec 2016 13:38:32 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 8A88410E9; Tue, 6 Dec 2016 13:38:31 +0000 (UTC) Date: Tue, 6 Dec 2016 13:38:31 +0000 To: freebsd-net@freebsd.org From: "oleg (Oleg Bulyzhin)" Reply-to: D8637+325+4a3b3c6133fb39c2@reviews.freebsd.org Subject: [Differential] D8637: buf_ring.h: fix memory order issues. Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D8637: buf_ring.h: fix memory order issues. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: MTU4NzczNmYxMjUyY2VhODkxYTIyZGM3NmJiIFhGv1c= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 13:38:32 -0000 b2xlZyBhZGRlZCBhIHJldmlld2VyOiBzYmFocmFfcmVwbm9wLm9yZy4KClJFVklTSU9OIERFVEFJ TAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EODYzNwoKRU1BSUwgUFJFRkVSRU5DRVMK ICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJl bmNlcy8KClRvOiBvbGVnLCBrbWFjeSwga2liLCBhbGMsIHNiYWhyYV9yZXBub3Aub3JnCkNjOiBl bWFzdGUsIGZyZWVic2QtbmV0LWxpc3QK From owner-freebsd-net@freebsd.org Tue Dec 6 14:34:58 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1927C69EF9; Tue, 6 Dec 2016 14:34:58 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B32511713; Tue, 6 Dec 2016 14:34:58 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-io0-x235.google.com with SMTP id c21so605732647ioj.1; Tue, 06 Dec 2016 06:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i+tl9Nxsfj9lnWvrPpCosHpKJa9fryseqJkDUdcmCBQ=; b=PsRrpgoOqFGkW4Y4rt4e9c9hVl5mU+WLR2sv5WQwSfffVhGEDfcbRcPZw33y5Ee8Wg fica3OBFU/Fwjv/jmlu5W330T7RFXHG2YCpwxV0SgrKz0nT/QUIvO69WAPMuXEMXLomO Rb+kgVZBu5pxDhSbWOGtHc2inicaeK+SBLK9DJGZoXFFfpqk8VEqgGOUA2Qen2AZPHOf Lz1g5E4TvvIPAtAumPZTAZNYAD3GNvNdKqF4rR3uJXiIClG50lUYZ9+XmA+Ft0X6fzvN 26Oo0lY3Qhh0Ru9zd27SBI8zmrsF3uHmlQsx66SF3DSNURJQWCZGzRIrcnIir/ePhd4v sLsQ== 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:from:date :message-id:subject:to:cc; bh=i+tl9Nxsfj9lnWvrPpCosHpKJa9fryseqJkDUdcmCBQ=; b=Ih6IGeW+5grkcX4lUg+37I7Pr04gL0+UMl0x6IZSFW4A51DaKXps9M8MeWC71aemn7 76kyNQl62ui1JbKlUOuzUrDxQhtIxegORZb2/fesq/muWZllbUWRJtU4URWEFULn3ZYq Sul2wVsHm6WBGNKfuzvl8ef4vTmUHxmS3Z9A6q881K1C3Su9wSfzDPLlQfzijRcY2omT B/NOdpH42eX+Ga1VCLWDrFdgD1rfNFu0bMZiGzCrLsPmyEgufBCqGAoUqfCqHc1acsMQ 2rLQBW02B3cA2vzZgG4lTXE8Nj3me/zovExQHj8Sv48/6lZWN6XnTd0JsMQqKvlU7wW3 9VEA== X-Gm-Message-State: AKaTC01vsGmei3HZlS7zc0EQXl0MgtzzKquVF73BsygcZ8zaNbSRAVYXz15c8/0iGDXfCsABMeOs+hmKzX1FCQ== X-Received: by 10.36.245.9 with SMTP id k9mr1720013ith.65.1481034896021; Tue, 06 Dec 2016 06:34:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.144.84 with HTTP; Tue, 6 Dec 2016 06:34:55 -0800 (PST) In-Reply-To: <8C636365-DD9D-4375-9418-D540D8D13C56@distal.com> References: <619F01C2-5A20-4E25-AB0B-4064B598239D@distal.com> <8C636365-DD9D-4375-9418-D540D8D13C56@distal.com> From: Ryan Stone Date: Tue, 6 Dec 2016 09:34:55 -0500 Message-ID: Subject: Re: Problems with FreeBSD (amd64 stable/11) router To: Chris Ross Cc: freebsd-net , freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 14:34:59 -0000 Let me confirm I understand what's happening: 1) You want to use your router to vlan-tag traffic from your network, and then send it out of a lagg over bce interfaces. The bxe interfaces have their MTU set to 1500 and the vlan interface to 1496 2) The TiVo is sending packets with a payload size of 1500 and the DF bit set. If this is the case, then the problem is simply that when the packets are passed through the vlan interface, the payload of the packets exceeds the MTU, but as the DF bit is set, the packets cannot be fragmented. Your choices are either to use a 1500 byte MTU on the vlan interface (assuming that the network that you are routing to can accept 1518 byte packets), or only advertise a 1496 byte MTU in your internal network. On Mon, Dec 5, 2016 at 2:10 PM, Chris Ross wrote= : > > > On Dec 5, 2016, at 11:59, Ryan Stone wrote: > > > > What's the MTU on the bce and vlan interfaces? Does the bce interface > show VLAN_MTU option set (in ifconfig)? > > I had manually set these to try to work out the problem earlier in my > experimentation, but am now back (unless I missed something) to the natur= al > MTUs on all interfaces. The vlan=E2=80=99s all show 1496, and the bee=E2= =80=99s (and > lagg0) show 1500. The options on each of the bce=E2=80=99s show VLAN_MTU= , and a > few other VLAN_ options. > > - Chris > > > > On Mon, Dec 5, 2016 at 10:00 AM, Chris Ross > wrote: > > > > Hello all. I recently replaced my router with a FreeBSD/11 box > (stable/11 r308579). I am running a lagg device across two bce=E2=80=99s= , and > 802.1q vlan interfaces atop lagg0. I=E2=80=99m using pf to NAT/filter ou= t through > a single outside IP address. > > > > I=E2=80=99m having the following problem. Some devices appear to be h= aving > trouble passing traffic. Of course, I first assumed I was doing somethin= g > wrong with my pf filters, but I believe now that=E2=80=99s not the proble= m. One > client machine (a TiVo Roamio) that produces a failure reliably, so I=E2= =80=99ve > been using it for testing, is showing that during a TCP session, which > starts up fine, in the middle of a POST operation to an outside server, > there are 1500 byte packets. These packets have the DF bit in the IP > header, and then never show up on the external interface (vlan0). Smalle= r > packets in the same TCP stream do. But, I=E2=80=99m also not seeing the = ICMP from > the router back to the client telling it that it cannot send the packet. > > > > I have tried all sorts of changes to my pf rules, including now > allowing all ICMP unconditionally on all interfaces (pass out log quick > inet proto icmp all). I have packet traces during the failed communicati= on > across pflog0, vlan0 (external network) and vlan7 (internal network). I= =E2=80=99d > be happy to answer any questions, or provide the traces off-list. > > > > Does anyone have any idea what I=E2=80=99ve missed? Thank you very mu= ch for > your help. > > > > - Chris > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://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 Dec 6 16:37:44 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AE3DC6A2F9; Tue, 6 Dec 2016 16:37:44 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:11::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD5C1166F; Tue, 6 Dec 2016 16:37:43 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPSA id uB6GbYpT010892 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Dec 2016 11:37:42 -0500 (EST) (envelope-from cross+freebsd@distal.com) Received: from [IPv6:2001:420:2710:1330:5c30:fff7:412f:bf14] ([IPv6:2001:420:2710:1330:5c30:fff7:412f:bf14]) (authenticated bits=0) by mail.distal.com (8.15.2/8.15.2) with ESMTPSA id uB6GbWYX053157 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Dec 2016 11:37:33 -0500 (EST) (envelope-from cross+freebsd@distal.com) Content-Type: multipart/signed; boundary="Apple-Mail=_EEED0B37-58D1-4216-8357-49C3F65A1E65"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Problems with FreeBSD (amd64 stable/11) router From: Chris Ross In-Reply-To: Date: Tue, 6 Dec 2016 11:37:20 -0500 Cc: freebsd-net , freebsd-pf@freebsd.org Message-Id: References: <619F01C2-5A20-4E25-AB0B-4064B598239D@distal.com> <8C636365-DD9D-4375-9418-D540D8D13C56@distal.com> To: Ryan Stone X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 16:37:44 -0000 --Apple-Mail=_EEED0B37-58D1-4216-8357-49C3F65A1E65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 6, 2016, at 09:34, Ryan Stone wrote: >=20 > Let me confirm I understand what's happening: >=20 > 1) You want to use your router to vlan-tag traffic from your network, = and then send it out of a lagg over bce interfaces. The bxe interfaces = have their MTU set to 1500 and the vlan interface to 1496 I believe this is correct. All traffic is using vlan interfaces, = including the external network connection. But they are all over a lagg = on two bce=E2=80=99s. > 2) The TiVo is sending packets with a payload size of 1500 and the DF = bit set. >=20 > If this is the case, then the problem is simply that when the packets = are passed through the vlan interface, the payload of the packets = exceeds the MTU, but as the DF bit is set, the packets cannot be = fragmented. Your choices are either to use a 1500 byte MTU on the vlan = interface (assuming that the network that you are routing to can accept = 1518 byte packets), or only advertise a 1496 byte MTU in your internal = network. Perhaps I misunderstood, but I thought that the router should send an = ICMP in this case (that it cannot fragment the packets due to the DF = bit), which would then cause the TiVo to send smaller packets. But = passing that detail for now; You mention =E2=80=9Conly advertise a 1496 byte MTU in [my] internal = network.=E2=80=9D I tried doing this by setting an =E2=80=9Cinterface-mtu= =E2=80=9D option in the DHCP response to the device, but it didn=E2=80=99t= obey that option. Do you know of another way to =E2=80=9Cadvertise=E2=80= =9D MTU=E2=80=99s on the internal network? You also mention using a higher MTU on the network. I hadn=E2=80=99t = thought of this, but presume it would work. I would only need support = for that MTU on the bce=E2=80=99s, and in the ethernet switches, = correct? The ethernet switches I have are Dell PowerConnect 2724 and = 2824 switches, which claim to support jumbo frames. I=E2=80=99ll have = to find out if I have to _do_ anything to support that, but it should = work. Thanks for the suggestion, I=E2=80=99ll look into that=E2=80=A6 - Chris --Apple-Mail=_EEED0B37-58D1-4216-8357-49C3F65A1E65 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYRulHAAoJEPFBDnXvoNg0MMwP/jKDI2ObON879i5RkFXA9GmW rCipiwXItvgmWbXgVBhq7PuokSnsfIp//7yLke5ks6058/imCw9ib/hJTfyIy4uZ xFU73UROYb3iexuQa5FoCHnbSArhzPQyleEUxFBJ9GJ0fVwWD2O0gLTuEuC3ArvP 3t/pNoPuTjYfF54zrK94xuIls77q/Ot47PX7tTmX11xpkyigLeqU0ImlBdJQM+3C sHLoZ2rTSr2bhidWWglLG9TxfdztKCXpZ/DGQnS889t8zGe2lfVidLz4tv/hgb6r 7hBC4nAbT18Df6zQEdli6MmItYVnkbPquvpYcRW3uTs1hd1w32nEUMugHqDmObkA 1vfd/BlSSlp32umJShE2QuEycoK5yLpbBg9wirUrYvOe4K+8LszKrLX0AbszeP6y L8GRN9jYEG+xTjImAWhJcSnl1WQhUoNQReG4uprMjuFb1CMay3EiJO1q8RRJhCvy Duw79rLzFvN/YprQ7U89VHrvEy+TCD1UXKr2foXMPdb/27H97Jj8I3EyHg55Xre2 vabLZ3gPR7dbFnwQmUH0tZxTYvS/r6dRDB76svFtkew+m4B/X/CEBhzSoce6HKzm j4yaj4lPUqhSplrH1nbfW/jdELoGnm0klxGwC+BGRzKDm2gwMAkatZKEW7tdBClT 2iJ7khZ1RkMdiKlf6gaV =J15r -----END PGP SIGNATURE----- --Apple-Mail=_EEED0B37-58D1-4216-8357-49C3F65A1E65-- From owner-freebsd-net@freebsd.org Wed Dec 7 01:36:17 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F1C4C6A4D8 for ; Wed, 7 Dec 2016 01:36:17 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 4A17EF0F for ; Wed, 7 Dec 2016 01:36:17 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-io0-x231.google.com with SMTP id l140so71763946iol.3 for ; Tue, 06 Dec 2016 17:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=XvHsgyLRrw/OwOd5gtET2Y3E3wped2lK8SwPl3W8WEM=; b=BwcrEcIwCZmIYtYVDnQN82uA4ZuAoE6nTNyau/l/00QdwTfffNkHpfZfmLk6fwL5JA rz/GdWzjPiHOfnsxQMoIcIMODLdFN9HvUZaPyK01wsbXn4sYzfZVJ7/VgpKPdw3T03v7 3IFbKTSrdrAB9oL87DqIzp/4FJ/Vy5ypn/oHm0f8jHc7F1cZXihm8DYoDIUssGuWSgP4 WYlUjvCynE5z6yCTvkb4rgSvTfHKzE5aTTuJhsDPzghh/1WxeiAy2vN7Kn3xqBCNxOXB zdu+Bn+PRphQch/dpnYdeh2zWjms2bUzbLyurSHrBU0ESVZl/ckGJPnT3PQif30qSfsf UN2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=XvHsgyLRrw/OwOd5gtET2Y3E3wped2lK8SwPl3W8WEM=; b=FBZHZctTJ8dB0lJrl5qIcLMjqCtZzTbjbkwLy6T9P3wexrGrUL1sH+IIW8GIBaLb90 3oUTSM39mQlOO0evJ3XqiZbGB2tRf8KSTAOnmoPyPndHp5fJZ2aPVqZZW6YtV6PpyvBh U9uxuBXku1chKfz7slcEdCafSUiN/pqwVvVRWN4rUmiiUdt8yzvRB9U60ERS+8IdIHLF RIos7WeMwFiaTJ79uKlIEkKzw1p+VILNHp7MHjwOVX76q3qYQJZ2Oo3lumkOaYK4sWMe NthY/ahpQj0PFmHe6fiWO/oBMMl5rbMnjQWRW9Hqp5KrApb7snhJ3kxB8dJExhLSFNOB yDbQ== X-Gm-Message-State: AKaTC01mQnkoabGira47bKY4Vag4izjErwYjTp36Qxp2fxhu5UPsEvZL8T6ItUQMX54i8V2PLGLzmOX3mwthZQ== X-Received: by 10.36.19.9 with SMTP id 9mr269135itz.32.1481074576525; Tue, 06 Dec 2016 17:36:16 -0800 (PST) MIME-Version: 1.0 Sender: sunxiaoye07@gmail.com Received: by 10.64.213.98 with HTTP; Tue, 6 Dec 2016 17:36:16 -0800 (PST) From: Xiaoye Sun Date: Tue, 6 Dec 2016 19:36:16 -0600 X-Google-Sender-Auth: ahI34y3frGQtiA59QNBzvj6udUY Message-ID: Subject: Can netmap be more efficient when it just does bridging between NIC and Linux kernal? To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 01:36:17 -0000 Hi, I am wondering if there a way to reduce the CPU usage of a netmap program similar to the bridge.c example. In my use case, I have a distributed application/framework (e.g. Spark or Hadoop) running on a cluster of machines (each of the machines runs Linux and has an Intel 10Gbps NIC). The application is both computation and network intensive. So there is a lot of data transfers between machines. I divide different data into two types (type 1 and type 2). Packets of type 1 data are sent through netmap (these packets don't go through Linux network stack). Packets of type 2 data are sent through Linux network stack. Both type 1 and type 2 data could be small or large. My netmap program runs on all the machines in the cluster and processes the packets of type 1 data (create, send, receive the packets) and forward packets of type 2 data between the NIC and the kernel by swapping the pointer to the NIC slot and the pointer to the kernel stack slot (similar to the bridge.c example in netmap repository). With my netmap program running on the machines, for an application having no type 1 data (netmap program behaves like a bridge which only does slot pointer swapping), the total running time of the application is longer than the case where no netmap program runs on the machines. It seems to me that the netmap program either slows down the network transfer for type 2 data, or it eats up too many CPU cycles and competes with the application process. However, with my netmap program running, iperf can reach 10Gbps bandwidth with 40-50% CPU usage on the netmap program (the netmap program is doing pointer swaping for iperf packets). I also found that after each poll returns, most of the time, the program might just swap one pointer, so there is a lot of system call overhead. Can anybody help me diagnose the source of the problem or is there a better way to write such program? I am wondering if there is a way to tuning the configuration so that the netmap program won't take up too much extra CPU when it runs like the bridge.c program. Best, Xiaoye From owner-freebsd-net@freebsd.org Wed Dec 7 07:42:15 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D971C6BFDD; Wed, 7 Dec 2016 07:42:15 +0000 (UTC) (envelope-from ratri@cisco.com) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52FB8B88; Wed, 7 Dec 2016 07:42:11 +0000 (UTC) (envelope-from ratri@cisco.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21846; q=dns/txt; s=iport; t=1481096535; x=1482306135; h=from:to:subject:date:message-id:mime-version; bh=uW/TrNt0/HReIAqGY928J11yd3UuuehdEv987bhv/yE=; b=Je8LqqYD0/+g2RhQbXqJWoWXhu/zWSum40vGCrJx0pWRTp54rxyX3ypv 5qGfpsDDEWEAm4EUQdZUTjCq1WOmvjBuEaHq5vmMoypFNGxM7vP0F4Omq hvm7ZnCKP1iFOonX5oQj5Dv/+niLBea7P3HzZc94e0PBgLCnfWGyxLZky Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/BQAqvEdY/4ENJK1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBgnNGAQEBAQEfgWcBuU2CB4Y+ghBAEwECAQEBAQEBAWIohG8jaAFKAgQwJwQ?= =?us-ascii?q?BiQGpGoIpiz0BAQEBAQEBAwEBAQEBAQEBH4Y+gX2KKi2CMAWIWg+HWIolAYVjh?= =?us-ascii?q?wqEKoFzF4FAjHWHYYovASEDMoEZMQEBhSKJKwGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208,217";a="357683300" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2016 07:42:04 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uB77g4wq013406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 07:42:04 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 01:42:04 -0600 Received: from xch-rcd-011.cisco.com ([173.37.102.21]) by xch-rcd-011.cisco.com ([173.37.102.21]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 01:42:03 -0600 From: "Rohit Atri (ratri)" To: "freebsd-net@freebsd.org" , "freebsd-cloud@freebsd.org" Subject: ARP not working on secondary interface Thread-Topic: ARP not working on secondary interface Thread-Index: AQHSUF1mCsAMuHKHXUyaxy6GJN82Rg== Date: Wed, 7 Dec 2016 07:42:03 +0000 Message-ID: <2695979A-5BD2-4D26-BF86-FBF696DBEECA@cisco.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.39.64.112] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 07:42:15 -0000 SGVsbG8sDQoNCkkgaGF2ZSBFQzIgaW5zdGFuY2Ugd2l0aCBhIGN1c3RvbSBGcmVlQlNEIGtlcm5l bCAoOS4yLVJFTEVBU0UpIHdpdGggdHdvIGludGVyZmFjZXMg4oCTIG5pYzAgJiBuaWMxLiBCb3Ro IGhhdmUgZWxhc3RpYyBJUHMgYXNzb2NpYXRlZCAgLSBFMCAmIEUxLg0KDQpJIG5vdGljZWQgdGhh dCB3aGVuIEkgcGluZyBFMSwgdGhlIElDTVAgcmVzcG9uc2UgcGFja2V0cyBnbyBvdXQgb2Ygbmlj MSBpbnN0ZWFkIG9mIG5pYzAgJiB0aHVzLCBmcm9tIHRoZSBwaW5nIHNvdXJjZSBwZXJzcGVjdGl2 ZSwgaG9zdCBpcyBkb3duLiBUbyB3b3JrYXJvdW5kIHRoZSBhc3ltbWV0cmljIHJvdXRpbmcsIEkg YWRkZWQgYSBkZWZhdWx0IHJvdXRlIHZpYSBuaWMxIHRvIEZJQiAxICYgYWRkZWQgYW4gSVBGVyBy dWxlIHRvIGVuc3VyZSBGSUIgMSBpcyB1c2VkIGZvciBhbGwgcGFja2V0cyByZWNlaXZlZCB2aWEg bmljMS4NCg0KTm93LCB3aGVuIG5pYzEgdHJpZXMgdG8gcmVzcG9uZCB0byBhbiBJQ01QIHJlcXVl c3QsIHRoZSBmaXJzdCB0aGluZyBpdCBkb2VzIGlzIHRvIEFSUCBmb3IgdGhlIHJvdXRlcuKAmXMg SVAuIFRoZSByb3V0ZXIgcmVzcG9uZHMgd2l0aCBpdHMgTUFDIGFkZHJlc3MgYnV0IG5pYzEgZG9l c27igJl0IHNlZW0gdG8gYmUgcHJvY2Vzc2luZyBpdC4gVGhlIGVudHJ5IGZvciBkZWZhdWx0IHJv dXRlcuKAmXMgSVAgaW4gdGhlIEFSUCB0YWJsZSByZW1haW5zIG1hcmtlZCDigJhpbmNvbXBsZXRl 4oCZIGFuZCBuZXZlciBnZXRzIHVwZGF0ZWQgLQ0KDQoqKioqKioqKioqKioqKioqKioqKioNCg0K IyB0Y3BkdW1wIC1uaSBuaWMxIC1wIGFycA0KDQowNzoyOTowNC45MjIyMDkgQVJQLCBSZXF1ZXN0 IHdoby1oYXMgMTcyLjMxLjE2LjEgdGVsbCAxNzIuMzEuMzAuMTMzLCBsZW5ndGggMjgNCg0KMDc6 Mjk6MDQuOTIyMzE2IEFSUCwgUmVwbHkgMTcyLjMxLjE2LjEgaXMtYXQgMDI6MTg6Yzk6NTM6ZDA6 MmYsIGxlbmd0aCA0Mg0KDQoNCiMgYXJwIC1hDQoNCmlwLTE3Mi0zMS0xNi0xLnVzLXdlc3QtMi5j b21wdXRlLmludGVybmFsICgxNzIuMzEuMTYuMSkgYXQgKGluY29tcGxldGUpIG9uIG5pYzEgZXhw aXJlZCBbZXRoZXJuZXRdDQoNCmlwLTE3Mi0zMS0zMC0xMzMudXMtd2VzdC0yLmNvbXB1dGUuaW50 ZXJuYWwgKDE3Mi4zMS4zMC4xMzMpIGF0IDAyOjZlOjMyOjkwOjBlOmFkIG9uIG5pYzEgcGVybWFu ZW50IFtldGhlcm5ldF0NCg0KaXAtMTcyLTMxLTE2LTEudXMtd2VzdC0yLmNvbXB1dGUuaW50ZXJu YWwgKDE3Mi4zMS4xNi4xKSBhdCAwMjoxODpjOTo1MzpkMDoyZiBvbiBuaWMwIGV4cGlyZXMgaW4g MTE5OSBzZWNvbmRzIFtldGhlcm5ldF0NCg0KaXAtMTcyLTMxLTIyLTExMy51cy13ZXN0LTIuY29t cHV0ZS5pbnRlcm5hbCAoMTcyLjMxLjIyLjExMykgYXQgMDI6ZWE6Mzk6Y2U6NWE6NDkgb24gbmlj MCBwZXJtYW5lbnQgW2V0aGVybmV0XQ0KDQoqKioqKioqKioqKioqKioqKioqKioNCkJ1dOKApiBp ZiBJIGRlbGV0ZSB0aGUgYXJwIGVudHJ5IChhcnAg4oCTZCAxNzIuMzEuMTYuMSksIEFSUCBlbnRy eSBmb3IgdGhlIGRlZmF1bHQgcm91dGVyIElQIGdldHMgdXBkYXRlZCBwcm9wZXJseSAtDQoNCg0K KioqKioqKioqKioqKioqKioqKioqDQoNCiMgYXJwIC1hDQoNCmlwLTE3Mi0zMS0xNi0xLnVzLXdl c3QtMi5jb21wdXRlLmludGVybmFsICgxNzIuMzEuMTYuMSkgYXQgMDI6MTg6Yzk6NTM6ZDA6MmYg b24gbmljMSBleHBpcmVzIGluIDExOTUgc2Vjb25kcyBbZXRoZXJuZXRdDQoNCuKApg0KDQoqKioq KioqKioqKioqKioqKioqKioNCg0KQnV0IGJ1dOKApiB0aGlzIG9ubHkgbGFzdHMgdW50aWwgdGhl IGVudHJ5IGV4cGlyZXMuIEFmdGVyIHRoYXQsIHRoZSBlbnRyeSBnZXRzIG1hcmtlZCDigJhpbmNv bXBsZXRl4oCZIGFnYWluLg0KDQoNCkkgYWxzbyBub3RpY2UgdGhlc2UgQVJQIHJlcXVlc3RzIHN0 YXJ0IGJlaW5nIHJlY2VpdmVkIGZyb20gdGhlIHJvdXRlciBhcm91bmQgdGhlIHNhbWUgdGltZSBJ IGRlbGV0ZSB0aGUgZW50cnkgKG1heSB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlc2UgcGFja2V0 cyBhcmUgYmVpbmcgdXNlZCB0byB1cGRhdGUgdGhlIEFSUCBlbnRyeT8pIC0NCg0KKioqKioqKioq KioqKioqKioqKioqDQoNCjA3OjMyOjQxLjQxMTIyOSBBUlAsIFJlcXVlc3Qgd2hvLWhhcyAxNzIu MzEuMTYuMSB0ZWxsIDE3Mi4zMS4zMC4xMzMsIGxlbmd0aCAyOA0KDQowNzozMjo0MS40MTEyOTcg QVJQLCBSZXBseSAxNzIuMzEuMTYuMSBpcy1hdCAwMjoxODpjOTo1MzpkMDoyZiwgbGVuZ3RoIDQy DQoNCjA3OjMzOjA0LjQ4MjcxOSBBUlAsIFJlcXVlc3Qgd2hvLWhhcyAxNzIuMzEuMzAuMTMzIHRl bGwgMTcyLjMxLjE2LjEsIGxlbmd0aCA0MiA8PDw8PDwNCg0KMDc6MzM6MDQuNDgyNzM0IEFSUCwg UmVwbHkgMTcyLjMxLjMwLjEzMyBpcy1hdCAwMjo2ZTozMjo5MDowZTphZCwgbGVuZ3RoIDI4DQoN CioqKioqKioqKioqKioqKioqKioqKg0KDQoNCkFueSBpZGVhIHdoeSB0aGUgQVJQIHJlcGxpZXMg YXJlIG5vdCBiZWluZyBwcm9jZXNzZWQgYnkgbmljMT8gQW55IGtub3duIHdvcmthcm91bmRzPw0K DQoNClRoYW5rcywNCg0KUm9oaXQNCg0KDQoNClBTIOKAkw0KDQpGSUIgMToNCg0KSW50ZXJuZXQ6 DQoNCkRlc3RpbmF0aW9uICAgICAgICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAg ICAgIFVzZSAgTmV0aWYgRXhwaXJlDQoNCmRlZmF1bHQgICAgICAgICAgICAxNzIuMzEuMTYuMSAg ICAgICAgVUdTICAgICAgICAgMCAgICAgMTk4NSAgIG5pYzENCg0KMTI3LjAuMC4xICAgICAgICAg IGxpbmsjMiAgICAgICAgICAgICBVSCAgICAgICAgICAwICAgICAgICAwICAgIGxvMA0KDQoxNzIu MzEuMTYuMC8yMCAgICAgbGluayM0ICAgICAgICAgICAgIFUgICAgICAgICAgIDAgICAgICAgIDAg ICBuaWMxDQoNCg0KSUZQVyAtDQoNCjAwMDAyIHNldGZpYiAxIGlwIGZyb20gYW55IHRvIGFueSB2 aWEgbmljMQ0KDQo2NTUzNSBhbGxvdyBpcCBmcm9tIGFueSB0byBhbnkNCg== From owner-freebsd-net@freebsd.org Wed Dec 7 08:48:44 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CB47C6815C; Wed, 7 Dec 2016 08:48:44 +0000 (UTC) (envelope-from ratri@cisco.com) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C930DB4E; Wed, 7 Dec 2016 08:48:43 +0000 (UTC) (envelope-from ratri@cisco.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5014; q=dns/txt; s=iport; t=1481100523; x=1482310123; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5P7WkofpXagwWPixTajCx5h+SisCQQczixq9d3Pkc6k=; b=NFFOtaeP5D3xh96aFUOSJbiNWdE+OcA2DJd49Ncr8EgD0Jhy05AZZEOj 3UZI231qX2yhy+5jMHB1JL6WB+rv/4hWKBUpU3jTXCuRkqi9+GjDIHehN iJI/Uh4HYMLVQsZQFy2kC1NazQ3bh1gbVEoSwqvFPpVO5cpuC5KmeZu+H Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAwAZzEdY/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR9agQYHAblNggceC4UvSgIagg5BEgECAQEBAQEBAWI?= =?us-ascii?q?ohGkCBAEBIREaIBsCAQgaAiYCAgIlAQkBFRACBAEHBwQBHASITg6pH4Ipiz0BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEXBYELhTOBfYJehCsBARsXgm0tgjAFiFqHZ4o?= =?us-ascii?q?lAYZLhW01hCqBcxeONYdhii8BJgslgRkjDgEBhSJyB4cRgSEBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="178559798" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2016 08:48:42 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uB78mfJH016950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 08:48:41 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 02:48:41 -0600 Received: from xch-rcd-011.cisco.com ([173.37.102.21]) by xch-rcd-011.cisco.com ([173.37.102.21]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 02:48:41 -0600 From: "Rohit Atri (ratri)" To: "freebsd-net@freebsd.org" , "freebsd-cloud@freebsd.org" Subject: Re: ARP not working on secondary interface Thread-Topic: ARP not working on secondary interface Thread-Index: AQHSUF1mCsAMuHKHXUyaxy6GJN82RqD87XUA Date: Wed, 7 Dec 2016 08:48:41 +0000 Message-ID: <64FFAB39-FFF6-4ED2-80C1-C7B25E7D9AAD@cisco.com> References: <2695979A-5BD2-4D26-BF86-FBF696DBEECA@cisco.com> In-Reply-To: <2695979A-5BD2-4D26-BF86-FBF696DBEECA@cisco.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.39.64.112] Content-Type: text/plain; charset="utf-8" Content-ID: <300ADEFCE962794681D28663973358ED@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 08:48:44 -0000 VGhpcyBxdWVyeSBoZXJlIHRhbGtzIGFib3V0IGEgc2ltaWxhciBzY2VuYXJpbyAtIGh0dHBzOi8v Zm9ydW1zLmZyZWVic2Qub3JnL3RocmVhZHMvMjYwNTAvDQpPbmx5IGRpZmZlcmVuY2UgYmVpbmcg dGhhdCBpbiBteSBjYXNlLCBBUlAgcmVwbGllcyBhcmUgYWN0dWFsbHkgcmVjZWl2ZWQuDQoNClRo YW5rcywNClJvaGl0DQoNCg0KDQpPbiAwNy8xMi8xNiwgMToxMiBQTSwgIm93bmVyLWZyZWVic2Qt bmV0QGZyZWVic2Qub3JnIG9uIGJlaGFsZiBvZiBSb2hpdCBBdHJpIChyYXRyaSkiIDxvd25lci1m cmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBvbiBiZWhhbGYgb2YgcmF0cmlAY2lzY28uY29tPiB3cm90 ZToNCg0KPkhlbGxvLA0KPg0KPkkgaGF2ZSBFQzIgaW5zdGFuY2Ugd2l0aCBhIGN1c3RvbSBGcmVl QlNEIGtlcm5lbCAoOS4yLVJFTEVBU0UpIHdpdGggdHdvIGludGVyZmFjZXMg4oCTIG5pYzAgJiBu aWMxLiBCb3RoIGhhdmUgZWxhc3RpYyBJUHMgYXNzb2NpYXRlZCAgLSBFMCAmIEUxLg0KPg0KPkkg bm90aWNlZCB0aGF0IHdoZW4gSSBwaW5nIEUxLCB0aGUgSUNNUCByZXNwb25zZSBwYWNrZXRzIGdv IG91dCBvZiBuaWMxIGluc3RlYWQgb2YgbmljMCAmIHRodXMsIGZyb20gdGhlIHBpbmcgc291cmNl IHBlcnNwZWN0aXZlLCBob3N0IGlzIGRvd24uIFRvIHdvcmthcm91bmQgdGhlIGFzeW1tZXRyaWMg cm91dGluZywgSSBhZGRlZCBhIGRlZmF1bHQgcm91dGUgdmlhIG5pYzEgdG8gRklCIDEgJiBhZGRl ZCBhbiBJUEZXIHJ1bGUgdG8gZW5zdXJlIEZJQiAxIGlzIHVzZWQgZm9yIGFsbCBwYWNrZXRzIHJl Y2VpdmVkIHZpYSBuaWMxLg0KPg0KPk5vdywgd2hlbiBuaWMxIHRyaWVzIHRvIHJlc3BvbmQgdG8g YW4gSUNNUCByZXF1ZXN0LCB0aGUgZmlyc3QgdGhpbmcgaXQgZG9lcyBpcyB0byBBUlAgZm9yIHRo ZSByb3V0ZXLigJlzIElQLiBUaGUgcm91dGVyIHJlc3BvbmRzIHdpdGggaXRzIE1BQyBhZGRyZXNz IGJ1dCBuaWMxIGRvZXNu4oCZdCBzZWVtIHRvIGJlIHByb2Nlc3NpbmcgaXQuIFRoZSBlbnRyeSBm b3IgZGVmYXVsdCByb3V0ZXLigJlzIElQIGluIHRoZSBBUlAgdGFibGUgcmVtYWlucyBtYXJrZWQg 4oCYaW5jb21wbGV0ZeKAmSBhbmQgbmV2ZXIgZ2V0cyB1cGRhdGVkIC0NCj4NCj4qKioqKioqKioq KioqKioqKioqKioNCj4NCj4jIHRjcGR1bXAgLW5pIG5pYzEgLXAgYXJwDQo+DQo+MDc6Mjk6MDQu OTIyMjA5IEFSUCwgUmVxdWVzdCB3aG8taGFzIDE3Mi4zMS4xNi4xIHRlbGwgMTcyLjMxLjMwLjEz MywgbGVuZ3RoIDI4DQo+DQo+MDc6Mjk6MDQuOTIyMzE2IEFSUCwgUmVwbHkgMTcyLjMxLjE2LjEg aXMtYXQgMDI6MTg6Yzk6NTM6ZDA6MmYsIGxlbmd0aCA0Mg0KPg0KPg0KPiMgYXJwIC1hDQo+DQo+ aXAtMTcyLTMxLTE2LTEudXMtd2VzdC0yLmNvbXB1dGUuaW50ZXJuYWwgKDE3Mi4zMS4xNi4xKSBh dCAoaW5jb21wbGV0ZSkgb24gbmljMSBleHBpcmVkIFtldGhlcm5ldF0NCj4NCj5pcC0xNzItMzEt MzAtMTMzLnVzLXdlc3QtMi5jb21wdXRlLmludGVybmFsICgxNzIuMzEuMzAuMTMzKSBhdCAwMjo2 ZTozMjo5MDowZTphZCBvbiBuaWMxIHBlcm1hbmVudCBbZXRoZXJuZXRdDQo+DQo+aXAtMTcyLTMx LTE2LTEudXMtd2VzdC0yLmNvbXB1dGUuaW50ZXJuYWwgKDE3Mi4zMS4xNi4xKSBhdCAwMjoxODpj OTo1MzpkMDoyZiBvbiBuaWMwIGV4cGlyZXMgaW4gMTE5OSBzZWNvbmRzIFtldGhlcm5ldF0NCj4N Cj5pcC0xNzItMzEtMjItMTEzLnVzLXdlc3QtMi5jb21wdXRlLmludGVybmFsICgxNzIuMzEuMjIu MTEzKSBhdCAwMjplYTozOTpjZTo1YTo0OSBvbiBuaWMwIHBlcm1hbmVudCBbZXRoZXJuZXRdDQo+ DQo+KioqKioqKioqKioqKioqKioqKioqDQo+QnV04oCmIGlmIEkgZGVsZXRlIHRoZSBhcnAgZW50 cnkgKGFycCDigJNkIDE3Mi4zMS4xNi4xKSwgQVJQIGVudHJ5IGZvciB0aGUgZGVmYXVsdCByb3V0 ZXIgSVAgZ2V0cyB1cGRhdGVkIHByb3Blcmx5IC0NCj4NCj4NCj4qKioqKioqKioqKioqKioqKioq KioNCj4NCj4jIGFycCAtYQ0KPg0KPmlwLTE3Mi0zMS0xNi0xLnVzLXdlc3QtMi5jb21wdXRlLmlu dGVybmFsICgxNzIuMzEuMTYuMSkgYXQgMDI6MTg6Yzk6NTM6ZDA6MmYgb24gbmljMSBleHBpcmVz IGluIDExOTUgc2Vjb25kcyBbZXRoZXJuZXRdDQo+DQo+4oCmDQo+DQo+KioqKioqKioqKioqKioq KioqKioqDQo+DQo+QnV0IGJ1dOKApiB0aGlzIG9ubHkgbGFzdHMgdW50aWwgdGhlIGVudHJ5IGV4 cGlyZXMuIEFmdGVyIHRoYXQsIHRoZSBlbnRyeSBnZXRzIG1hcmtlZCDigJhpbmNvbXBsZXRl4oCZ IGFnYWluLg0KPg0KPg0KPkkgYWxzbyBub3RpY2UgdGhlc2UgQVJQIHJlcXVlc3RzIHN0YXJ0IGJl aW5nIHJlY2VpdmVkIGZyb20gdGhlIHJvdXRlciBhcm91bmQgdGhlIHNhbWUgdGltZSBJIGRlbGV0 ZSB0aGUgZW50cnkgKG1heSB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlc2UgcGFja2V0cyBhcmUg YmVpbmcgdXNlZCB0byB1cGRhdGUgdGhlIEFSUCBlbnRyeT8pIC0NCj4NCj4qKioqKioqKioqKioq KioqKioqKioNCj4NCj4wNzozMjo0MS40MTEyMjkgQVJQLCBSZXF1ZXN0IHdoby1oYXMgMTcyLjMx LjE2LjEgdGVsbCAxNzIuMzEuMzAuMTMzLCBsZW5ndGggMjgNCj4NCj4wNzozMjo0MS40MTEyOTcg QVJQLCBSZXBseSAxNzIuMzEuMTYuMSBpcy1hdCAwMjoxODpjOTo1MzpkMDoyZiwgbGVuZ3RoIDQy DQo+DQo+MDc6MzM6MDQuNDgyNzE5IEFSUCwgUmVxdWVzdCB3aG8taGFzIDE3Mi4zMS4zMC4xMzMg dGVsbCAxNzIuMzEuMTYuMSwgbGVuZ3RoIDQyIDw8PDw8PA0KPg0KPjA3OjMzOjA0LjQ4MjczNCBB UlAsIFJlcGx5IDE3Mi4zMS4zMC4xMzMgaXMtYXQgMDI6NmU6MzI6OTA6MGU6YWQsIGxlbmd0aCAy OA0KPg0KPioqKioqKioqKioqKioqKioqKioqKg0KPg0KPg0KPkFueSBpZGVhIHdoeSB0aGUgQVJQ IHJlcGxpZXMgYXJlIG5vdCBiZWluZyBwcm9jZXNzZWQgYnkgbmljMT8gQW55IGtub3duIHdvcmth cm91bmRzPw0KPg0KPg0KPlRoYW5rcywNCj4NCj5Sb2hpdA0KPg0KPg0KPg0KPlBTIOKAkw0KPg0K PkZJQiAxOg0KPg0KPkludGVybmV0Og0KPg0KPkRlc3RpbmF0aW9uICAgICAgICBHYXRld2F5ICAg ICAgICAgICAgRmxhZ3MgICAgUmVmcyAgICAgIFVzZSAgTmV0aWYgRXhwaXJlDQo+DQo+ZGVmYXVs dCAgICAgICAgICAgIDE3Mi4zMS4xNi4xICAgICAgICBVR1MgICAgICAgICAwICAgICAxOTg1ICAg bmljMQ0KPg0KPjEyNy4wLjAuMSAgICAgICAgICBsaW5rIzIgICAgICAgICAgICAgVUggICAgICAg ICAgMCAgICAgICAgMCAgICBsbzANCj4NCj4xNzIuMzEuMTYuMC8yMCAgICAgbGluayM0ICAgICAg ICAgICAgIFUgICAgICAgICAgIDAgICAgICAgIDAgICBuaWMxDQo+DQo+DQo+SUZQVyAtDQo+DQo+ MDAwMDIgc2V0ZmliIDEgaXAgZnJvbSBhbnkgdG8gYW55IHZpYSBuaWMxDQo+DQo+NjU1MzUgYWxs b3cgaXAgZnJvbSBhbnkgdG8gYW55DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5mcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj5o dHRwczovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1uZXQNCj5U byB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVA ZnJlZWJzZC5vcmciDQo= From owner-freebsd-net@freebsd.org Wed Dec 7 09:41:52 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E15D3C6987A for ; Wed, 7 Dec 2016 09:41:52 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 9BA17A54 for ; Wed, 7 Dec 2016 09:41:52 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-ua0-x236.google.com with SMTP id 51so409491302uai.1 for ; Wed, 07 Dec 2016 01:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VWrB+AwhVNJMzsvD9iIBGGcGIeYqhS9sPW2sIu6Ojfc=; b=ZNyMVH8Qs57pyN7gygmC6OtK9nI8rPvh+z+QY8JADpnxN2BhEe6frzsUtXGy/DNkPd t60CS51JQ/GNmxoTl4CNptnOJLAGOsk20wJdfPXPkgXDnLhDYo20aONEbIYoi/bFsp9Z UOCvCbxQ5ADQDAaDkNqKtr5r5cLqBr0tAe/YJ1OM4ZW9zeh4n0CXg33Ds8X0fZTLN72z 4zCduTxmdRBzTtc3Fa6Zpwxo7vbKr/S27SLqGlzWfZAg+gIgdUgTkfhYLomroAfZ94N7 0hMnuTPcLXYC9gVsE0ixZv4Zt7RIaKPtmqLwtipzTiKdSYIJ7JyB8ODawHpx9ptn9APK WUoA== 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:from:date :message-id:subject:to:cc; bh=VWrB+AwhVNJMzsvD9iIBGGcGIeYqhS9sPW2sIu6Ojfc=; b=Ba0hN4QWDU28LmImDQ8MHIjOleft7XPQsPBa/2QFkq9btLrvKpJ7n1NjDgKin0Kf9K jx3OK3o93lcntxLguQ5EeoREsKkIwlrgICD3zIQnuWkSS01joRoIRERHsg7RIONBmg+x EmO8rpCRW1QZgBd5xxLRGZwNrV0h/eFe3GPBC7NnaAF6gozrni6n/ef7Z7BxqdZKvYBs inLAEujJiO0rDk1Qrv3UuaTK9atW6QiJRc/0D4HZAjal6Dp3IvP/jqch+ayk0UgQv8vN sfLqI5OSsR/eS0vlmFsImnt8PBWk/XcJDACIRzL+wi1NpvsCPIcM8YB2H58C91AKwDHc xr8w== X-Gm-Message-State: AKaTC00V17HSEOis9eqy4eOsKzBmWimVX0onAj10w26S1iRViJJdBWFU0cWvRpKVVSxVRXnsWPXI/3XA74L9Cw== X-Received: by 10.176.83.151 with SMTP id k23mr52949534uaa.90.1481103711818; Wed, 07 Dec 2016 01:41:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.198 with HTTP; Wed, 7 Dec 2016 01:41:51 -0800 (PST) In-Reply-To: <201612030736.uB37aArG057471@elf.torek.net> References: <201612030736.uB37aArG057471@elf.torek.net> From: Sepherosa Ziehau Date: Wed, 7 Dec 2016 17:41:51 +0800 Message-ID: Subject: Re: mutex usage in if_bridge vs other drivers To: Chris Torek Cc: rysto32@gmail.com, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 09:41:53 -0000 On Sat, Dec 3, 2016 at 3:36 PM, Chris Torek wrote: >>... Dropping the lock is entirely the wrong thing to do -- as >>you note, if we do, then the bridge members can change out from >>under us. The only path forward is to use an sx lock, but ... > [snip] >>In code paths that modify the list of bridge members, hold both the >>BRIDGE_LOCK and the new sx lock. In the transmit and receive paths, >>nothing should change. > > That should work, but I hate the cost of obtaining two locks -- > not so much the lock acquire/release cost, but the "mental cost" > of keeping the lock ordering straight. > > The other option I thought of was gathering the list of members > that need an ioctl done on them in one pass, then doing all the > ioctls after dropping the lock. But that runs the risk of doing > ioctls on interfaces that are no longer members of the bridge. > > I guess the "mental cost" is not that high, since the lock order > requirement is guaranteed to be "sx lock first, then mtx lock" > (because the other way around causes sleeping while holding a > regular mutex!). This is what did for Hyper-V network drivers: while (sx_try_xlock(drv_conf_sx) == 0) DELAY(1000); since that mainlock, i.e. configuration lock, is not on hot path for drivers. In this way, driver can sleep freely on IF_UP/DOWN/detach path, which is convenient, though other paths e.g. promisc, add/delmulti still requires busy-wait instead of sleeping. Thanks, sephe -- Tomorrow Will Never Die From owner-freebsd-net@freebsd.org Wed Dec 7 10:09:49 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8763CC6A56F for ; Wed, 7 Dec 2016 10:09:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02C371BA3 for ; Wed, 7 Dec 2016 10:09:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uB7A9g8r016222 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Dec 2016 12:09:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uB7A9g8r016222 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uB7A9gDc016221; Wed, 7 Dec 2016 12:09:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Dec 2016 12:09:42 +0200 From: Konstantin Belousov To: Sepherosa Ziehau Cc: Chris Torek , "freebsd-net@freebsd.org" , rysto32@gmail.com Subject: Re: mutex usage in if_bridge vs other drivers Message-ID: <20161207100942.GU54029@kib.kiev.ua> References: <201612030736.uB37aArG057471@elf.torek.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 10:09:49 -0000 On Wed, Dec 07, 2016 at 05:41:51PM +0800, Sepherosa Ziehau wrote: > On Sat, Dec 3, 2016 at 3:36 PM, Chris Torek wrote: > >>... Dropping the lock is entirely the wrong thing to do -- as > >>you note, if we do, then the bridge members can change out from > >>under us. The only path forward is to use an sx lock, but ... > > [snip] > >>In code paths that modify the list of bridge members, hold both the > >>BRIDGE_LOCK and the new sx lock. In the transmit and receive paths, > >>nothing should change. > > > > That should work, but I hate the cost of obtaining two locks -- > > not so much the lock acquire/release cost, but the "mental cost" > > of keeping the lock ordering straight. > > > > The other option I thought of was gathering the list of members > > that need an ioctl done on them in one pass, then doing all the > > ioctls after dropping the lock. But that runs the risk of doing > > ioctls on interfaces that are no longer members of the bridge. > > > > I guess the "mental cost" is not that high, since the lock order > > requirement is guaranteed to be "sx lock first, then mtx lock" > > (because the other way around causes sleeping while holding a > > regular mutex!). > > This is what did for Hyper-V network drivers: > > while (sx_try_xlock(drv_conf_sx) == 0) > DELAY(1000); > > since that mainlock, i.e. configuration lock, is not on hot path for drivers. > > In this way, driver can sleep freely on IF_UP/DOWN/detach path, which > is convenient, though other paths e.g. promisc, add/delmulti still > requires busy-wait instead of sleeping. Consider what happens if some other thread already owns the conf sx lock and tries to acquire the mutex. If the thread blocks execution by whatever mean, be it lock primitive putting the thread off cpu, or thread executing spin loop (as in your case), reversing the order still causes the deadlock. From owner-freebsd-net@freebsd.org Wed Dec 7 16:37:44 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59A4EC6C785 for ; Wed, 7 Dec 2016 16:37:44 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 38BED1FC1 for ; Wed, 7 Dec 2016 16:37:44 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 35472C6C784; Wed, 7 Dec 2016 16:37:44 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 332EEC6C783 for ; Wed, 7 Dec 2016 16:37:44 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 E2B0D1FC0 for ; Wed, 7 Dec 2016 16:37:43 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id n204so48948125qke.2 for ; Wed, 07 Dec 2016 08:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=aIZdvM5G5r+IkekDudq+CbuYV8DKhAN0jiwenbYd51U=; b=h1mOXe7+wS8OXkhQ2k8dgbCUQbtBO09lzdO6Pq3FAEB+C9QVqv5ZsMC1QUiESTvx8B xkE/DWDtxkDFQv9A0Ct45zfPrEdNotgH2p6yErh3IRPvEpzoRanqwbHc796Z9VkJ4+AR YzsXo9KUYO8e9I1Fs0TFYo4K0yNZBjLBdeoSAm8PVVMenX2e/sdgMEsV7/xBloDF2R+5 Q3IrW78wx+eDJKiRNpk8lw8n1MZCuUwZ70C7nbnSsfaDil0LBbzPZG61tzLuTVfqbbCT Yb+Fp1YztIGEfTXHANgDv+OOuULOTUxyapTfbJJA5dVgmCHBI8GvHMIJn2Y4gQ0dNWzQ KtsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-transfer-encoding :mime-version:subject:message-id:date:to; bh=aIZdvM5G5r+IkekDudq+CbuYV8DKhAN0jiwenbYd51U=; b=EGar6HdIdfc6jZDWKQwm9sJRKboYQEoFAIbGQ2RM1uFzqGctL7eRX6FJEQmbVz0TOP ZNegLr3o4lpAuf1xFN2nhpTr5WEApC/lSebZAj6WOopovfw1mB6Qrzkh9yv6wba7s3MH dVf0vxsZ/8Z9O+ed/Xzr5xgpMobtNVAUuQPU97KEb2SWMHCXirXmRI+5g2giNlzTqymN QIQmSlD2Y6nZ09N3VtYUPHKSsl+2FxJbgA9/Mr+7EIkkX86zPvYScC+PlE3rrSVVeKYq OSi9nhe2M0m31ni0Rjzqex3boULyzKCDUF4+85TBsxJorRdlCQqcitjrg5tnn4+mt+oO yLpw== X-Gm-Message-State: AKaTC03CF9RIMfu6TjEyo2AVwGOxTNdLKAh9l6/wy2GgCU2ObvQjDnCIxET0oCDwyZx+NQ== X-Received: by 10.55.197.6 with SMTP id p6mr67015956qki.239.1481128662837; Wed, 07 Dec 2016 08:37:42 -0800 (PST) Received: from mbp-eth.home (179-125-201-151.desktop.com.br. [179.125.201.151]) by smtp.gmail.com with ESMTPSA id f2sm12374201qtg.22.2016.12.07.08.37.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2016 08:37:42 -0800 (PST) Sender: Renato Botelho From: Renato Botelho Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Try to change default route to an IP out of the range lock the system Message-Id: Date: Wed, 7 Dec 2016 14:37:37 -0200 To: net@FreeBSD.org X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:37:44 -0000 It was reported to pfSense [1] and I already opened a bugzilla ticket = [2]. It=E2=80=99s reproducible on all versions >=3D 11.0. I was not sure about who could be assigned on ticket then I decided to = send it here on the list. Looks like a regression that would be nice to = see fixed. [1] https://redmine.pfsense.org/issues/6850 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215122 -- Renato Botelho From owner-freebsd-net@freebsd.org Thu Dec 8 10:39:33 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB6ABC6ADF8 for ; Thu, 8 Dec 2016 10:39:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 DB1EB1A45 for ; Thu, 8 Dec 2016 10:39:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB8AdX0a070450 for ; Thu, 8 Dec 2016 10:39:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213606] LACP not working with qlogic BCM57800 Date: Thu, 08 Dec 2016 10:39:33 +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-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: simon.lindgren@loopia.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 10:39:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213606 Simon Lindgren changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simon.lindgren@loopia.se --- Comment #13 from Simon Lindgren --- Hi! I'm having the same issues in recent versions of freebsd, it worked before upgrade, also using bxe driver. When putting the interfaces in promiscious mode, they start working again f= or some unknown reason, but when taking them out of promisc they stop working after about a minute. If i start a tcpdump (and therefor putting the interf= ace in promisc), i get around 10 LACPv1 packets and then i start seeing other traffic coming in/out as it should, and the interface flags becomes ACTIVE,COLLECTING,DISTRIBUTING. Using laggproto loadbalance or failover works fine. NIC: QLogic NetXtreme II BCM57810 10GbE (B0) BXE v:1.78.81 LACP works on: 10.3-RELEASE-p7 (and at the very least, some earlier versions as well) LACP does NOT work on: FreeBSD 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p2 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Dec 8 11:39:42 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61279C6C1C7 for ; Thu, 8 Dec 2016 11:39:42 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 2277C1B4C for ; Thu, 8 Dec 2016 11:39:42 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x22a.google.com with SMTP id y198so450417572oia.1 for ; Thu, 08 Dec 2016 03:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EzpzNDlIUd9GVv0nMX19gQsledWEiKfdFTn2oUPS1rE=; b=gf7S+exuRA3uXtaw7A5TgD5Wd5I/A04/MSwsaga7iFqXstaeHxrzmd+0My8xRkYUks /SK18ZP8WVfc9183F6FLT1hdw++LpuLaMy+bxugFcpmC+//dhEpldX/uRBHbSIkAi4E0 XrGQ8iCYHSBhVkQmaxKaZ/cKxavDu1vznN2OrqmF30Gx+ctM+Xa8tuhjgVxJwjRsMSly f4QNXbwJReg3z0ol7AmHNHWNSzZa93CuizucwBlkXGb0ml8Ew8laa6Mr5S6wv25D9PtH dTcPAzQ78a7Wx2xFUTBablbJgQFC+Ri+Oe6JqeWP+xGvihXd3CaLdJq1XOy4vP/UCAvy uy1g== 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:from:date :message-id:subject:to:cc; bh=EzpzNDlIUd9GVv0nMX19gQsledWEiKfdFTn2oUPS1rE=; b=RchvUU9/nkuTi3Vbwdo2zKZhCm/KEFV/XzLJx4N61qf+KFXUNG7OnyKYmaFSsRUiqH usvsNsDYI/Q8SR5M31AKtfSS+HFg4zsgIDCuCGtAMV3fkQHz5QEY3LZpHT4/36+Bq+MR NjzAqMS3Hb2RWSTw2inVtTTHiZimcLk26Lj47ch4ogkj1K1vPPLXFtvfYrYxHMmxQJIU Lrp3yBhjD3LYj8CIFwX71UcZDa400P3Pcjnah87ZmRTSY+pRgsY+3CtqfU9zF4WgnSta rhgbHkUvHD6H2ZjA9hYgAvPPDtbKU6KKOEOfqD/l2FXAdaK8kXZiUPpZNmU7WG7H+KnG fM2A== X-Gm-Message-State: AKaTC01g7dCvUkGtbX5J5fDqmN4WA+DvU2IRg1+bvymtdbjCses6XTRs+/9UxkGDMEGqglRL0kQtMZtl9RPiYA== X-Received: by 10.202.67.7 with SMTP id q7mr34989099oia.103.1481197180942; Thu, 08 Dec 2016 03:39:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.200 with HTTP; Thu, 8 Dec 2016 03:39:40 -0800 (PST) In-Reply-To: References: From: Vincenzo Maffione Date: Thu, 8 Dec 2016 12:39:40 +0100 Message-ID: Subject: Fwd: Can netmap be more efficient when it just does bridging between NIC and Linux kernal? To: Xiaoye Sun Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 11:39:42 -0000 Hi, 2016-12-07 2:36 GMT+01:00 Xiaoye Sun : > Hi, > > I am wondering if there a way to reduce the CPU usage of a netmap program > similar to the bridge.c example. > > In my use case, I have a distributed application/framework (e.g. Spark or > Hadoop) running on a cluster of machines (each of the machines runs Linux > and has an Intel 10Gbps NIC). The application is both computation and > network intensive. So there is a lot of data transfers between machines. I > divide different data into two types (type 1 and type 2). Packets of type 1 > data are sent through netmap (these packets don't go through Linux network > stack). Packets of type 2 data are sent through Linux network stack. Both > type 1 and type 2 data could be small or large. > > My netmap program runs on all the machines in the cluster and processes the > packets of type 1 data (create, send, receive the packets) and forward > packets of type 2 data between the NIC and the kernel by swapping the > pointer to the NIC slot and the pointer to the kernel stack slot (similar > to the bridge.c example in netmap repository). > > With my netmap program running on the machines, for an application having > no type 1 data (netmap program behaves like a bridge which only does slot > pointer swapping), the total running time of the application is longer than > the case where no netmap program runs on the machines. > Yes, but this is not surprising. If the only thing your netmap application is doing is forwardinig all the traffic between the nework stack and the NIC, then your netmap application is a process that is doing an useless job: netmap is intercepting packets from the network stack and reinjecting them back in the network stack (where their goes on as they were not intercepted). It's just wasting resources. Netmap is designed to let netmap applications use efficiently the NICs and/or talk efficently to each other (e.g. using the VALE switch or the virtualization extensions). The "host rings" are instead useful in some use-cases, for example (1) you want to implement an high performance input packet filter for your network stack, that is able to manage Ddos attacks: your netmap application would receive somthing like 10 Mpps from the NIC, drop 99% of it (since it realize it is not legitimate traffic) and forward the remaining packets to the network stack; (2) you want to manage (forward, drop, modify, etc.) most of the traffic in your netmap application, but there are some low badwidth protocols that you want to manage using standard socket applications (e.g. SSH). > > It seems to me that the netmap program either slows down the network > transfer for type 2 data, or it eats up too many CPU cycles and competes > with the application process. However, with my netmap program running, > iperf can reach 10Gbps bandwidth with 40-50% CPU usage on the netmap > program (the netmap program is doing pointer swaping for iperf packets). I > also found that after each poll returns, most of the time, the program > might just swap one pointer, so there is a lot of system call overhead. > > This is also not surprising, since you are probably iperf is generating large packets (1500 bytes or more). As a consequence, the packet rate is something like 800Kpps, which is not extremely high (netmap applications can work with workloads of 5, 10, 20 or more Mpps; since the packet rate is not high, it means that the interval between two packets arriving is greater than the time needed to do a poll()/ioctl() syscall and process the packet, and so the batches don't get formed. > Can anybody help me diagnose the source of the problem or is there a better > way to write such program? > I am wondering if there is a way to tuning the configuration so that the > netmap program won't take up too much extra CPU when it runs like the > bridge.c program. > The point is that when you have only type 2 data you shouldn't use netmap, as it does not make sense. Unfortunately, the fact that packet batches (with more than 1 packet) get formed or not depends on the external traffic input patterns: it's basically a producer/consumer problem, and there are no tunable for this. One thing you may do is to rate-limit the calls to poll()/ioctl() in order to artificially create the batches; in this way you would trade off a bit of latency for the sake of energy efficiency. Another approach that you may be interested in is using NIC hardware features like "flow-director" or "receive-flow-steering" to classify input packets and steer different classes into specific NIC queues. In this way you could open with netmap just a subset of the NIC queues (the type 1 data1traffic), and let the network stack directly process the traffic on the other queues (type 2 data). There are some blog posts about this kind of setup, here is one https://blog.cloudflare.com/ single-rx-queue-kernel-bypass-with-netmap/ Cheers, Vincenzo > > > Best, > Xiaoye > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Vincenzo Maffione -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri Dec 9 09:02:45 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7B70C6DE99 for ; Fri, 9 Dec 2016 09:02:45 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 6E9711ED5 for ; Fri, 9 Dec 2016 09:02:45 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-io0-x243.google.com with SMTP id p13so5488806ioi.0 for ; Fri, 09 Dec 2016 01:02:45 -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:from:date:message-id :subject:to:cc; bh=+KZPuYGpFNX0JgPSXgSDuTWoxStZS6unRhoQjUW9Sow=; b=IE1OqeiYIitvfrGWtXDOClnrF7rkXn6sHlw2xUv7F4ts6OuSOof5wXXSjI/eNUFH2r pp8DPQnGlzQUEhxrVJ0nNv4EB8R+ShgQUDfFRkqFoJj/oVsdavD65ZBARldnTSAbQyyv NkcHYzwO3vJMunuOgKV+2R0PxcriIz3E3pXhMSEnlweuwQ8D6gBfjklf/prq47sAAljE LW3MF6WUoiz3HdOCoZbJunNZySE2Dyfi9uDXvAnzVd8Gpnciqi3Oal4ZaJgBkoagewGl rTVsjV2pk5l7Z/1b8swM6IDjRn35Qfc9gJ2sIEctK4mi5soVApg33WVezynwmdT2ejLq ftuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+KZPuYGpFNX0JgPSXgSDuTWoxStZS6unRhoQjUW9Sow=; b=OR8bqQHHunV0pXc+Scqv4YUZgHnn2JIdEbC5j2AtmrV8FtHeqZ6uSvGc3miD0MMA0Z vMPTnGHk5sJ3XdkPWA8wk35JjdHBjdsWMhr4EcKODC6NbZD1Wz8lII63NGxyrmqnjV0O MXv7vZzIIejqEhVh8TIvGwwSvO9NGZ+HJfyNlAgzsJqy6fPqqCHxkK1zVOr6lR0lst4l noW7dDz0Q7+ANi3khJoT2KnKgiM97t4LoqoPHhlp+CfNyKA20eCogVK3IruV7xlt7rMN wpLU5yzh33eY1XmUSDALf0PJ5NNsVX+Li5iz7tNp5LUudkbw1545xVekPfuK+jUhHEiT sAAA== X-Gm-Message-State: AKaTC014iaJnOrQDW94WH2ilz/aVCBYqaT1N1/Ug2+gFpAEjo4iL2wHLsiIPUUbZg56F5szOCbpNF0ZPOaU6Rg== X-Received: by 10.36.211.137 with SMTP id n131mr5819836itg.28.1481274164653; Fri, 09 Dec 2016 01:02:44 -0800 (PST) MIME-Version: 1.0 Sender: sunxiaoye07@gmail.com Received: by 10.64.213.98 with HTTP; Fri, 9 Dec 2016 01:02:44 -0800 (PST) In-Reply-To: References: From: Xiaoye Sun Date: Fri, 9 Dec 2016 03:02:44 -0600 X-Google-Sender-Auth: RMyg2qmPGRzFSvhBsc__8Vx6tqU Message-ID: Subject: Re: Can netmap be more efficient when it just does bridging between NIC and Linux kernal? To: Vincenzo Maffione Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 09:02:45 -0000 Hi Vincenzo, Thank you for your suggestion. I think attaching only subset of NIC queues to netmap is a brilliant idea!!! I am going through the instructions on the blog you send to me. https://blog.cloudflare.com/single-rx-queue-kernel-bypass-with-netmap/ Now, I can use "ethtool -N eth3" (Configure Rx network flow classification) command to set up filters so that type 1 data goes to the netmap nic queues and the type 2 data goes to other queues at the receiver side. However, it seems that my NIC (Intel 10G IXGBE) does not support indirection table, since when I use the command "ethtool -X eth3 weight 0 1 1 1", I got error message like Cannot get RX flow hash indirection table size: Operation not supported This makes the kernel not isolate the queues given to netmap. In such case, outgoing packets from the kernel stack are stuck and never sent out, since these packets may want to go to the TX nic queues that have been given to netmap (I guess). I am wondering is there a way to work around this issue. Best, Xiaoye On Thu, Dec 8, 2016 at 5:39 AM, Vincenzo Maffione wrote: > Hi, > > 2016-12-07 2:36 GMT+01:00 Xiaoye Sun : > >> Hi, >> >> I am wondering if there a way to reduce the CPU usage of a netmap program >> similar to the bridge.c example. >> >> In my use case, I have a distributed application/framework (e.g. Spark or >> Hadoop) running on a cluster of machines (each of the machines runs Linux >> and has an Intel 10Gbps NIC). The application is both computation and >> network intensive. So there is a lot of data transfers between machines. I >> divide different data into two types (type 1 and type 2). Packets of type >> 1 >> data are sent through netmap (these packets don't go through Linux network >> stack). Packets of type 2 data are sent through Linux network stack. Both >> type 1 and type 2 data could be small or large. >> >> My netmap program runs on all the machines in the cluster and processes >> the >> packets of type 1 data (create, send, receive the packets) and forward >> packets of type 2 data between the NIC and the kernel by swapping the >> pointer to the NIC slot and the pointer to the kernel stack slot (similar >> to the bridge.c example in netmap repository). >> >> With my netmap program running on the machines, for an application having >> no type 1 data (netmap program behaves like a bridge which only does slot >> pointer swapping), the total running time of the application is longer >> than >> the case where no netmap program runs on the machines. >> > > Yes, but this is not surprising. If the only thing your netmap application > is doing is forwardinig all the traffic between the nework stack and the > NIC, then your netmap application is a process that is doing an useless > job: netmap is intercepting packets from the network stack and reinjecting > them back in the network stack (where their goes on as they were not > intercepted). It's just wasting resources. Netmap is designed to let netmap > applications use efficiently the NICs and/or talk efficently to each other > (e.g. using the VALE switch or the virtualization extensions). > The "host rings" are instead useful in some use-cases, for example (1) you > want to implement an high performance input packet filter for your network > stack, that is able to manage Ddos attacks: your netmap application would > receive somthing like 10 Mpps from the NIC, drop 99% of it (since it > realize it is not legitimate traffic) and forward the remaining packets to > the network stack; (2) you want to manage (forward, drop, modify, etc.) > most of the traffic in your netmap application, but there are some low > badwidth protocols that you want to manage using standard socket > applications (e.g. SSH). > > >> >> It seems to me that the netmap program either slows down the network >> transfer for type 2 data, or it eats up too many CPU cycles and competes >> with the application process. However, with my netmap program running, >> iperf can reach 10Gbps bandwidth with 40-50% CPU usage on the netmap >> program (the netmap program is doing pointer swaping for iperf packets). I >> also found that after each poll returns, most of the time, the program >> might just swap one pointer, so there is a lot of system call overhead. >> >> This is also not surprising, since you are probably iperf is generating > large packets (1500 bytes or more). As a consequence, the packet rate is > something like 800Kpps, which is not extremely high (netmap applications > can work with workloads of 5, 10, 20 or more Mpps; since the packet rate is > not high, it means that the interval between two packets arriving is > greater than the time needed to do a poll()/ioctl() syscall and process the > packet, and so the batches don't get formed. > > >> Can anybody help me diagnose the source of the problem or is there a >> better >> way to write such program? > > > >> I am wondering if there is a way to tuning the configuration so that the >> netmap program won't take up too much extra CPU when it runs like the >> bridge.c program. >> > > The point is that when you have only type 2 data you shouldn't use netmap, > as it does not make sense. Unfortunately, the fact that packet batches > (with more than 1 packet) get formed or not depends on the external traffic > input patterns: it's basically a producer/consumer problem, and there are > no tunable for this. One thing you may do is to rate-limit the calls to > poll()/ioctl() in order to artificially create the batches; in this way you > would trade off a bit of latency for the sake of energy efficiency. > > Another approach that you may be interested in is using NIC hardware > features like "flow-director" or "receive-flow-steering" to classify input > packets and steer different classes into specific NIC queues. In this way > you could open with netmap just a subset of the NIC queues (the type 1 > data1traffic), and let the network stack directly process the traffic on > the other queues (type 2 data). There are some blog posts about this kind > of setup, here is one https://blog.cloudflare.com/si > ngle-rx-queue-kernel-bypass-with-netmap/ > > Cheers, > Vincenzo > >> >> >> Best, >> Xiaoye >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > Vincenzo Maffione > > > > -- > Vincenzo Maffione > From owner-freebsd-net@freebsd.org Fri Dec 9 10:50:09 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20833C6EC18 for ; Fri, 9 Dec 2016 10:50:09 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 D74481336 for ; Fri, 9 Dec 2016 10:50:08 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x22d.google.com with SMTP id v84so14670430oie.3 for ; Fri, 09 Dec 2016 02:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IKGVIkG45zugR4c7oJQK/7RS62FD2WJwKjriSL+k1mA=; b=fATIPpDehCrXyFhpyj9W0SnGpwxZvPBqJ97jNXyCJwM6UfRGzGCv5ODvV6VqqtvL4p DWKHA/BXEnh4VYtHtmDf/p8SXcnM8y2mI/56vp/9bD91lspiMfcbpO+3tWK9C2cA+nRa DOGoPUNsnvrowf8egTS+FatemtHCBJcFfYrk0NOEvpIT4pWpSChYz87u0/9Z6cZCOVYS ydD6b56bRuxcU5JrT5GYk9CrbJjxBxLIs5mjIktlrC9sdfUF3dl3B3oIZ9rRR6FqPNEz l6Cm8p6k330Q0f6XORHUtvfpkSV+E3iea9j8eS2URf1xwynWDtNn3OsKuMhD0CKsQb7n Ygrw== 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:from:date :message-id:subject:to:cc; bh=IKGVIkG45zugR4c7oJQK/7RS62FD2WJwKjriSL+k1mA=; b=llSdWfwNL4BoKFacPxbN2UAkmAKTu9qLj8CrOrn+hafH8H0DoVZJ6oiRHoQef6wSrG GS9BU3Qg/1IUa63M0OeGxqtHGHnG850hJJz40es7/7hF44gT8e7kSz53w+L5LjwsbiGX xs9CnQMkT9pi6cxufQCgrupNPlYP49TjcqjwTBvv4d0bq4Ksnb7I9SSfmaurBmIbQi4x XHZjTof6LLvqnbf6s2Y1+zodfKl93CNYMKuB8WgC7Hd754aUvtgjQrOb+yoRU2Q57zYk hSO/br9awElfYB/ICYFEFdClrgW4VQSbJrA+8SODvHgvlS6DIv7WYsVAPZaigMrKS19O /nhQ== X-Gm-Message-State: AKaTC03u5u19GnuIPKm2ZSoIp85j5c6FWtp7BKhOHFCUrACIxvqX3reo6VDaAPkRijdutRjvxAfWt2lle5+fmw== X-Received: by 10.202.185.198 with SMTP id j189mr37684660oif.32.1481280608062; Fri, 09 Dec 2016 02:50:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.200 with HTTP; Fri, 9 Dec 2016 02:50:07 -0800 (PST) In-Reply-To: References: From: Vincenzo Maffione Date: Fri, 9 Dec 2016 11:50:07 +0100 Message-ID: Subject: Re: Can netmap be more efficient when it just does bridging between NIC and Linux kernal? To: Xiaoye Sun Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 10:50:09 -0000 Hi, 2016-12-09 10:02 GMT+01:00 Xiaoye Sun : > Hi Vincenzo, > > Thank you for your suggestion. I think attaching only subset of NIC queues > to netmap is a brilliant idea!!! > > I am going through the instructions on the blog you send to me. > https://blog.cloudflare.com/single-rx-queue-kernel-bypass-with-netmap/ > > Now, I can use "ethtool -N eth3" (Configure Rx network flow classification) > command to set up filters so that type 1 data goes to the netmap nic queues > and the type 2 data goes to other queues at the receiver side. > > However, it seems that my NIC (Intel 10G IXGBE) does not support > indirection table, since when I use the command "ethtool -X eth3 weight 0 > 1 1 1", I got error message like > Cannot get RX flow hash indirection table size: Operation not supported > This makes the kernel not isolate the queues given to netmap. > I see, but actually I have never personally tried these hw flow steering configurations, so I cannot help here. Maybe you can try asking the Cloudflare guys that did the setup, they could have had similar problems. In the end these are hardware specific features, not related to netmap. > > In such case, outgoing packets from the kernel stack are stuck and never > sent out, since these packets may want to go to the TX nic queues that have > been given to netmap (I guess). > Netmap intercepts all the packets that the kernel wants to transmit on a NIC opened in netmap mode (to be precise, in general just a subset of the TX/RX NIC queues are opened in netmap mode). However, at the point the TX packet gets intercepted, the kernel has already decided what is the designated TX (hardware) NIC queue for the packet: if the designated queue is opened in netmap mode, then the packet will be put in the host RX ring (and will wait there until a netmap application consumes it); on the other hand, if the designed queue is not open in netmap mode, netmap will just let it go transparently, as if the packet was never intercepted. Pay attention to play well with nm_open() modifiers: the T and R modifiers can be used to open in netmap mode only TX or RX queues. So for instance: "netmap:ethX" --> opens all TX and RX queues in netmap mode; all packets that network stack tries to transmit will end up into the host RX ring "netmap:ethX/T" --> opens only TX queues in netmap mode; all packets that network stack tries to transmit will end up into the host RX ring "netmap:ethX/R" --> opens only RX queues in netmap mode; this means that network stack can actually transmit on ethX, and packet won't end up into the host RX ring Of course you can play with the ring ids, to open just specific queues: e.g. "netmap:ethX-3/T" "netmap:ethX-0/R", etc. Cheers, Vincenzo > I am wondering is there a way to work around this issue. > > Best, > Xiaoye > > On Thu, Dec 8, 2016 at 5:39 AM, Vincenzo Maffione > wrote: > >> Hi, >> >> 2016-12-07 2:36 GMT+01:00 Xiaoye Sun : >> >>> Hi, >>> >>> I am wondering if there a way to reduce the CPU usage of a netmap program >>> similar to the bridge.c example. >>> >>> In my use case, I have a distributed application/framework (e.g. Spark or >>> Hadoop) running on a cluster of machines (each of the machines runs Linux >>> and has an Intel 10Gbps NIC). The application is both computation and >>> network intensive. So there is a lot of data transfers between machines. >>> I >>> divide different data into two types (type 1 and type 2). Packets of >>> type 1 >>> data are sent through netmap (these packets don't go through Linux >>> network >>> stack). Packets of type 2 data are sent through Linux network stack. Both >>> type 1 and type 2 data could be small or large. >>> >>> My netmap program runs on all the machines in the cluster and processes >>> the >>> packets of type 1 data (create, send, receive the packets) and forward >>> packets of type 2 data between the NIC and the kernel by swapping the >>> pointer to the NIC slot and the pointer to the kernel stack slot (similar >>> to the bridge.c example in netmap repository). >>> >>> With my netmap program running on the machines, for an application having >>> no type 1 data (netmap program behaves like a bridge which only does slot >>> pointer swapping), the total running time of the application is longer >>> than >>> the case where no netmap program runs on the machines. >>> >> >> Yes, but this is not surprising. If the only thing your netmap >> application is doing is forwardinig all the traffic between the nework >> stack and the NIC, then your netmap application is a process that is doing >> an useless job: netmap is intercepting packets from the network stack and >> reinjecting them back in the network stack (where their goes on as they >> were not intercepted). It's just wasting resources. Netmap is designed to >> let netmap applications use efficiently the NICs and/or talk efficently to >> each other (e.g. using the VALE switch or the virtualization extensions). >> The "host rings" are instead useful in some use-cases, for example (1) >> you want to implement an high performance input packet filter for your >> network stack, that is able to manage Ddos attacks: your netmap application >> would receive somthing like 10 Mpps from the NIC, drop 99% of it (since it >> realize it is not legitimate traffic) and forward the remaining packets to >> the network stack; (2) you want to manage (forward, drop, modify, etc.) >> most of the traffic in your netmap application, but there are some low >> badwidth protocols that you want to manage using standard socket >> applications (e.g. SSH). >> >> >>> >>> It seems to me that the netmap program either slows down the network >>> transfer for type 2 data, or it eats up too many CPU cycles and competes >>> with the application process. However, with my netmap program running, >>> iperf can reach 10Gbps bandwidth with 40-50% CPU usage on the netmap >>> program (the netmap program is doing pointer swaping for iperf packets). >>> I >>> also found that after each poll returns, most of the time, the program >>> might just swap one pointer, so there is a lot of system call overhead. >>> >>> This is also not surprising, since you are probably iperf is generating >> large packets (1500 bytes or more). As a consequence, the packet rate is >> something like 800Kpps, which is not extremely high (netmap applications >> can work with workloads of 5, 10, 20 or more Mpps; since the packet rate is >> not high, it means that the interval between two packets arriving is >> greater than the time needed to do a poll()/ioctl() syscall and process the >> packet, and so the batches don't get formed. >> >> >>> Can anybody help me diagnose the source of the problem or is there a >>> better >>> way to write such program? >> >> >> >>> I am wondering if there is a way to tuning the configuration so that the >>> netmap program won't take up too much extra CPU when it runs like the >>> bridge.c program. >>> >> >> The point is that when you have only type 2 data you shouldn't use >> netmap, as it does not make sense. Unfortunately, the fact that packet >> batches (with more than 1 packet) get formed or not depends on the external >> traffic input patterns: it's basically a producer/consumer problem, and >> there are no tunable for this. One thing you may do is to rate-limit the >> calls to poll()/ioctl() in order to artificially create the batches; in >> this way you would trade off a bit of latency for the sake of energy >> efficiency. >> >> Another approach that you may be interested in is using NIC hardware >> features like "flow-director" or "receive-flow-steering" to classify input >> packets and steer different classes into specific NIC queues. In this way >> you could open with netmap just a subset of the NIC queues (the type 1 >> data1traffic), and let the network stack directly process the traffic on >> the other queues (type 2 data). There are some blog posts about this kind >> of setup, here is one https://blog.cloudflare.com/si >> ngle-rx-queue-kernel-bypass-with-netmap/ >> >> Cheers, >> Vincenzo >> >>> >>> >>> Best, >>> Xiaoye >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >> >> -- >> Vincenzo Maffione >> >> >> >> -- >> Vincenzo Maffione >> > > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Sat Dec 10 03:01:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C76EC6F0E2 for ; Sat, 10 Dec 2016 03:01:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 1BFB21C4A for ; Sat, 10 Dec 2016 03:01:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA31jUx087474 for ; Sat, 10 Dec 2016 03:01:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215122] Try to change route default to IP out of range lock the system Date: Sat, 10 Dec 2016 03:01:45 +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-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:01:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215122 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org CC| |garga@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Dec 10 03:09:55 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAC88C6F6EB for ; Sat, 10 Dec 2016 03:09:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 9A10486F for ; Sat, 10 Dec 2016 03:09:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA39tYx063539 for ; Sat, 10 Dec 2016 03:09:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 215101] [ixgbe] Intel X552 SFP+ fails to initialize when no SFP module is plugged in Date: Sat, 10 Dec 2016 03:09:55 +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: CURRENT X-Bugzilla-Keywords: IntelNetworking, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:09:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215101 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |IntelNetworking, patch CC|freebsd-amd64@FreeBSD.org | Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Dec 10 03:30:02 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F77BC6FB77 for ; Sat, 10 Dec 2016 03:30:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 F3861324 for ; Sat, 10 Dec 2016 03:30:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3U1U4046263 for ; Sat, 10 Dec 2016 03:30:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 214955] rpc.lockd sends spurious NLM_UNLOCKs Date: Sat, 10 Dec 2016 03:30:01 +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: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org 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: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:30:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214955 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Dec 10 04:24:33 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13C7AC6F497 for ; Sat, 10 Dec 2016 04:24:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 03846A26 for ; Sat, 10 Dec 2016 04:24:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA4OWlB030904 for ; Sat, 10 Dec 2016 04:24:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 214558] Improve descriptions for sysctl net.inet.tcp.keepinit Date: Sat, 10 Dec 2016 04:24:33 +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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org 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: quoted-printable 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.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 04:24:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214558 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #1 from Hiren Panchasara --- IMO, it is named "time to establish connection" because if we don't hear ba= ck within that time period when in state < TCPS_ESTABLISHED, we drop the connection. JFYI and you may already know that. Regarding the proposed patch, I have no opinion. Thanks for your submission. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Dec 10 23:08:01 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22CF2C715FC; Sat, 10 Dec 2016 23:08:01 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by mx1.freebsd.org (Postfix) with ESMTP id EF7121AC8; Sat, 10 Dec 2016 23:07:59 +0000 (UTC) (envelope-from ae@FreeBSD.org) To: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org From: "Andrey V. Elsukov" Subject: [RFC/RFT] projects/ipsec Message-ID: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> Date: Sun, 11 Dec 2016 02:07:30 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xPIWdG2PqMS3owTuVatnqNcKkmtHJUivX" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 23:08:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xPIWdG2PqMS3owTuVatnqNcKkmtHJUivX Content-Type: multipart/mixed; boundary="fjA6JBVMN49EwIArQdlwEixmfTFo2QW6S"; protected-headers="v1" From: "Andrey V. Elsukov" To: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Message-ID: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> Subject: [RFC/RFT] projects/ipsec --fjA6JBVMN49EwIArQdlwEixmfTFo2QW6S Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All, I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/SPDB faster; * revise PFKEY implementation, remove stale code, make it closer to RFC; * implement IPsec VTI (virtual tunneling interface); * make IPsec code loadable as kernel module. Currently all, except the last one is mostly done. So, I decided ask for a help to test the what already done, while I will work on the last task.= How to try? There are no patches, you need to checkout the full projects/ipsec source tree, and build the kernel and the base system. There are very few changes in the base system, mostly the kernel changes. Thus for testing that old configuration is still work, it is enough to build only the kernel. The approximate list of changes that may be visible to users: * SA bundles now can have only 4 items in the chain. I think it is enough, I can't imagine configurations when needed more. Also now SA bundles supported for IPv6 too. * due to changes in SPDB/SADB, systems where large number of SPs and SAs are in use should get significant performance benefits. * the memory consumption should slightly increase. There are several hash tables and SP cache appeared. * INPCB SP cache should noticeable increase network performance of application when security policies are presence. https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html * use transport mode IPsec for forwarded IPv4 packets now unsupported. This matches the IPv6 behavior, and since we can handle the replies, I think it is useless. * Added net.inet.ipsec.check_policy_history sysctl variable. When it is set, each inbound packet that was handled by IPsec will be checked according to matching security policy. If not all IPsec transforms were applied, the check will fail, and packet will be dropped. * Many PF_KEY messages handlers was updated, probably some IKEd now may fail due to stricter checks. * SPI now unique for each SA. This also can break something. * Added if_ipsec interface. For more info look at https://svnweb.freebsd.org/base?view=3Drevision&revision=3D309115 https://reviews.freebsd.org/P112 * TCP_SIGNATURE code was reworked and now it behaves closer to RFC https://svnweb.freebsd.org/base?view=3Drevision&revision=3D309610 * NAT-T support was reworked. https://svnweb.freebsd.org/base?view=3Drevision&revision=3D309808 Also I made the patch to racoon that adds better support of NAT-T, you can use this port to build patched racoon: https://people.freebsd.org/~ae/ipsec-tools.tgz What results is interesting to me? If you have some nontrivial configuration, please test. If you have some configuration, that did't work, please test this branch.= If you have performance problems, please test. But don't forget that this is head/ branch, you need to disable all debugging first. If you just want to test, pay attention to the output of `vmstat -m | egrep "sec|sah|pol|crypt"`. If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this support was significantly changed. PS. I just updated the branch to last head/, and it was not tested, sorry= :) --=20 WBR, Andrey V. Elsukov --fjA6JBVMN49EwIArQdlwEixmfTFo2QW6S-- --xPIWdG2PqMS3owTuVatnqNcKkmtHJUivX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEsBAEBCAAWBQJYTIqyDxxhZUBmcmVlYnNkLm9yZwAKCRABxeoEEMihepkPB/94 m2uBSfnT/Yypv+PDnkquTTABifE9MUMXBpquYuHZJtaF3IquIFx51Sr5aqH09y+w ofMosuIDUFJ6907rQJF9Hn3cXniLknCO8cmnFHdv4AuyRaZfZhPr+UocwlfU4oaI 3m22jMba3rT44xx5y0a8KxW7GcUGwr3uhOfBeg1ylYEpyWib5wP5mV0DV2Gw6KmS NfGdE/bvYxFBkoDfgaJRHz9jM6V06kK9SdOIUISYR8LXXuyPjnQ6iietdmN83x1L 6DyyOTz4Yl+433l0MbUcE9KSIfnYHpIpIYufeV1XcphTuB+qyhSP1M6ZfPS2BTuz GoAQRxmB5GhRCSwRWQCO =1NJs -----END PGP SIGNATURE----- --xPIWdG2PqMS3owTuVatnqNcKkmtHJUivX--