From owner-freebsd-net@freebsd.org Sun Mar 25 05:05:35 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 654F7F6E814 for ; Sun, 25 Mar 2018 05:05:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F21DC74236 for ; Sun, 25 Mar 2018 05:05:34 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 368C14671 for ; Sun, 25 Mar 2018 05:05:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2P55YMb069273 for ; Sun, 25 Mar 2018 05:05:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2P55YeJ069272 for freebsd-net@FreeBSD.org; Sun, 25 Mar 2018 05:05:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 223835] BGP session not established with md5 password via FRRouting Date: Sun, 25 Mar 2018 05:05:33 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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.25 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, 25 Mar 2018 05:05:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835 --- Comment #35 from Andrey V. Elsukov --- Created attachment 191795 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D191795&action= =3Dedit patch to net/openbgpd port I looked at the openbgpd code from ports. Port has wrong patch, because of which openbgbd doesn't enable TCP_MD5SIG option for used sockets and thus M= D5 signatures don't work. Can you replace files/patch-bgpd_session.c with attached file and rebuild openbgpd, then test again? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 25 10:38:39 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9817F607A1 for ; Sun, 25 Mar 2018 10:38:38 +0000 (UTC) (envelope-from supportsobaka@mail.ru) Received: from fallback.mail.ru (fallback5.mail.ru [94.100.181.253]) (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 50B517EF7A for ; Sun, 25 Mar 2018 10:38:37 +0000 (UTC) (envelope-from supportsobaka@mail.ru) Received: from [10.161.60.74] (port=54412 helo=f345.i.mail.ru) by fallback5.mail.ru with esmtp (envelope-from ) id 1f032i-0008A7-LP for freebsd-net@freebsd.org; Sun, 25 Mar 2018 13:38:28 +0300 Received: by f345.i.mail.ru with local (envelope-from ) id 1f032a-0006B3-99; Sun, 25 Mar 2018 13:38:20 +0300 Received: by e.mail.ru with HTTP; Sun, 25 Mar 2018 13:38:20 +0300 From: supportsobaka@mail.ru To: freebsd-net@freebsd.org, freebsdnic@mailbox.intel.com Subject: =?UTF-8?B?RnJlZUJTRCAxMS4xIHdpdGggSW50ZWwoUikgUFJPLzEwMDAgdW5yZXNwb25z?= =?UTF-8?B?aXZlIHRvIGFsbCBuZXR3b3JrIGludGVyZmFjZXMgZnJvbSBvdXRzaWRlIChz?= =?UTF-8?B?ZWVtcywgZHVyaW5nIGlkbGUpLCBidXQgaW1tZWRpYXRlbHkgdXAgd2hlbiBw?= =?UTF-8?B?aW5nIGFueXRoaW5nIGZyb20gaW5zaWRlIHRoZSBzZXJ2ZXI=?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 Date: Sun, 25 Mar 2018 13:38:20 +0300 Reply-To: supportsobaka@mail.ru X-Priority: 3 (Normal) Message-ID: <1521974300.464728846@f345.i.mail.ru> X-7FA49CB5: 70AAF3C13DB7016878DA827A17800CE724BC488DC9095E0BC4224003CC836476D1DB134E79BD61627866D6147AF826D80DC11A23C0FF2809AAE31F531AEFB06D089D37D7C0E48F6C8AA50765F790063746E2B5509BC2063E70DB341224E31499089D37D7C0E48F6C5571747095F342E857739F23D657EF2B6825BDBE14D8E7024847893F9AA87235E5BFE6E7EFDEDCD789D4C264860C145E X-Mailru-Sender: C1D09E46DAAD3409338448D8342DA04354D61D884900D82249B2D9B8767189D75E6F2943F928959E12824C74316D419A9E6BD6917B53005D7268C455A0344CD32AA3CDD27765A5666233C95170C4828D08E29FF3D9B2F13D0DA7A0AF5A3A8387 X-Mras: OK X-Spam: undefined X-Mailru-MI: 800 X-Mras: OK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 10:38:39 -0000 CgpIZWxsbyBndXlzLApOZWVkIGhlbHAgd2l0aCBpc3N1ZXMgSSBuZXZlciBtZXQgYmVmb3JlIGZv ciBteSBsb25nIGV4cGVyaWVuY2Ugd2l0aCBGcmVlQlNELgoKQSBuZXcgc2VydmVyIGluIHJlbW90 ZSBEQyBiYXNlZCBvZiBJbnRlbCBTMTIwMFJQIHdpdGjCoEZyZWVCU0QgMTEuMSB1c2VzIGlnYiBk cml2ZXIgZm9yIEludGVsKFIpIFBSTy8xMDAwLiBUaGVyZSBpcyBubyBhbnkgbG9hZCBvciB0cmFm ZmljIHlldCwgSSdtIGp1c3QgY29uZmlndXJpbmcgaXQsIHNvIEkgYmVsaWV2ZSB0aGF0IG15IEtp dHR5IChQdXR0eSkgc2Vzc2lvbiBpcyB0aGUgb25seSBvbmUgdGhhdCBtYWtlcyB0cmFmZmljLiBJ IGxvc3QgY29ubmVjdGlvbiB0byB0aGUgc2VydmVyIGRvemVucyB0aW1lcyBkdXJpbmcgbGFzdCB3 ZWVrLgoKSSBuZXZlciBsb3N0IGNvbm5lY3Rpb24gd2hlbiBJIHdhcyBkb2luZyBzb21ldGhpbmcg b24gdGhlIHNlcnZlciB2aWEgcmVtb3RlIEtpdHR5IHRlcm1pbmFsLCBidXQgaXQgd2FzIGFsd2F5 cyB3aGVuIEkgcmV0dXJuIGJhY2sgdG8gS2l0dHnCoGFmdGVyIHNvbWUgaWRsZS4gVGhlbiwgSSBr aWNrZWQgb3V0IG9mIHRlcm1pbmFsIGFuZCBzZXJ2ZXIgZG9lc24ndCByZXNwb25zZSB0byBwaW5n cyBvciAndGVsbmV0IHBvcnQnIGZyb20gYW55d2hlcmUuCgpUaGUgc2VydmVyIGhhcyBJUE1JIChh bmQgc28gS1ZNKSBhbmQgSSBub3cgY2FuIHNlZSB0aGF0IHRoZSBzZXJ2ZXIgaXMgbGl2ZSBhbmQg bmV0d29yayBpbnRlcmZhY2UgaXMgdXAuIE5vIG1lc3NhZ2VzIGluIGRtZXNnIHdoZW4gdGhpcyBo YXBwZW5zLiBUaGUgbmV0d29yayBnb2VzIHVwIChpLmUuIHBpbmdzIGdvIHRyb3VnaCBmcm9tIG91 dHNpZGUpIGltbWVkaWF0ZWx5IGFmdGVyIEkgcGluZyBzb21ldGhpbmcgZnJvbSBpbnNpZGUgdGhl IHNlcnZlciAodmlhIElQTUkncyBLVk0gYWNjZXNzKSBvciBpbW1lZGlhdGVseSBhZnRlciBJIGV4 ZWN1dGUgbmV0c3RhdCAtci4KCkkgbm93IHJ1biBHRU5FUklDIHRvIGV4Y2x1ZGUgYW55IGlzc3Vl IHdpdGggbXkgb3duIGtlcm5lbC4KClRoZSBwcm9ibGVtIGlzIDEwMCUgcmVwZWF0YWJsZSByaWdo dCBub3cgd2hpbGUgSSdtIHdyaXRpbmcgdGhpczogCgoxKSBsZWF2ZSBLaXR0eSB0ZXJtaW5hbCBm b3IgYSBwZXJpb2Qgb2YgdGltZSAoYWJvdXQgMTAgbWludXRlcyBlbm91Z2gpCjIpIGNvbWUgYmFj ayB0byB0ZXJtaW5hbCwgc3RhcnQgdHlwaW5nLCBnb3Qga2lja2VkIG9mZiwgcGluZyAtIG5vIHJl c3BvbnNlCjMpIGxvZ2luIHRvIHNlcnZlciB2aWEgS1ZNIChJJ20gYWxyZWFkeSBsb2dnZWQgaW4p IGFuZCBwaW5nIGFueSBVUkwgZnJvbSB0aGVyZQo0KSBzZXJ2ZXIgaXMgcmVzcG9uc2l2ZSBhZ2Fp bgoKSSBydW4gY29udGludW91cyBwaW5nIHRvIHRoaXMgc2VydmVyIGxhc3QgbmlnaCBhbmQgaXQg bmV2ZXIgZHJvcHBlZC4gSXQgbG9va3MgdG8gbWUgbGlrZSBJbnRlbCBjYXJkIGdvZXMgdG8gc29t ZSBzbGVlcCBtb2RlIGR1cmluZyBpZGxlICh3aGVuIG5vIHRyYWZmaWMgY29tZXMgdG8gdGhlIHNl cnZlciBhdCBhbGwsIGV4Y2VwdCBLaXR0eSdzIGtlZXAtYWxpdmUgcGVyaGFwcykuCgpUaGlzIGlz IG15IGZpcnN0IGV4cGVyaWVuY2Ugd2l0aCBGcmVlQlNEwqAxMS4xIGFuZCBaRlMgKGluY2x1ZGUg cm9vdCBmcm9tIFpGUykuIEFsbCBteSBwcmV2aW91cyBzZXJ2ZXJzIGFyZSBvbiBGcmVlQlNEIDkg YW5kIFVGUywgYnV0IG5vdCB0aGUgZmlyc3Qgd2l0aCBJbnRlbCBjYXJkcy4gTm90IHN1cmUgaWYg ZmlsZXN5c3RlbSBtYXR0ZXIgaW4gdGhpcyBpc3N1ZS4KCkkgdHJpZWQgc29tZSB0aGluZ3MgZGVz Y3JpYmVkIGhlcmXCoCBodHRwczovL2ZvcnVtcy5mcmVlYnNkLm9yZy90aHJlYWRzL3dvcmthcm91 bmQtZnJlZWJzZC0xMC0xLXN1ZGRlbi1uZXR3b3JrLWRvd24uNDkyNjQvIMKgIC0gaXQgZG9lc24n dCBoZWxwLgoKV2hhdCBlbHNlIGluZm9ybWF0aW9uIGRvIHlvdSBuZWVkIHRvIGRlYnVnIHRoaXM/ From owner-freebsd-net@freebsd.org Sun Mar 25 15:14:10 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B36FF4F06B for ; Sun, 25 Mar 2018 15:14:10 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EADC469414 for ; Sun, 25 Mar 2018 15:14:09 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2PFDtmq028588 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 25 Mar 2018 17:13:55 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: supportsobaka@mail.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w2PFDj72039400 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 25 Mar 2018 22:13:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: FreeBSD 11.1 with Intel(R) PRO/1000 unresponsive to all network interfaces from outside (seems, during idle), but immediately up when ping anything from inside the server To: supportsobaka@mail.ru, freebsd-net@freebsd.org, freebsdnic@mailbox.intel.com References: <1521974300.464728846@f345.i.mail.ru> From: Eugene Grosbein Message-ID: <5AB7BCA5.2020201@grosbein.net> Date: Sun, 25 Mar 2018 22:13:41 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1521974300.464728846@f345.i.mail.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 15:14:10 -0000 25.03.2018 17:38, supportsobaka--- via freebsd-net wrote: > Hello guys, > Need help with issues I never met before for my long experience with FreeBSD. > > A new server in remote DC based of Intel S1200RP with FreeBSD 11.1 uses igb driver for Intel(R) PRO/1000. There is no any load or traffic yet, I'm just configuring it, so I believe that my Kitty (Putty) session is the only one that makes traffic. I lost connection to the server dozens times during last week. > > I never lost connection when I was doing something on the server via remote Kitty terminal, but it was always when I return back to Kitty after some idle. Then, I kicked out of terminal and server doesn't response to pings or 'telnet port' from anywhere. > > The server has IPMI (and so KVM) and I now can see that the server is live and network interface is up. No messages in dmesg when this happens. The network goes up (i.e. pings go trough from outside) immediately after I ping something from inside the server (via IPMI's KVM access) or immediately after I execute netstat -r. > > I now run GENERIC to exclude any issue with my own kernel. > > The problem is 100% repeatable right now while I'm writing this: > > 1) leave Kitty terminal for a period of time (about 10 minutes enough) > 2) come back to terminal, start typing, got kicked off, ping - no response > 3) login to server via KVM (I'm already logged in) and ping any URL from there > 4) server is responsive again > > I run continuous ping to this server last nigh and it never dropped. It looks to me like Intel card goes to some sleep mode during idle (when no traffic comes to the server at all, except Kitty's keep-alive perhaps). > > This is my first experience with FreeBSD 11.1 and ZFS (include root from ZFS). All my previous servers are on FreeBSD 9 and UFS, but not the first with Intel cards. Not sure if filesystem matter in this issue. > > I tried some things described here https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ - it doesn't help. > > What else information do you need to debug this? It might be that network of your DC provider has famous bug: sometimes its MAC/ARP cache expires MAC address of your machine and does not re-ask it using ARP protocol nor delivers a packet to the server. When you run ping or netstat -r you make some outgoing traffic (ICMP for ping and DNS for netstat) so you forcibly re-fill MAC/ARP caches of DC provider and now things come to normal for some time. There is an easy way to check if this is the case. You can change sysctl net.link.ether.inet.max_age parameter to some low value like 60 (seconds), so your own ARP cache for gateway's MAC address would expire often producing outgoing ARP request that re-fills caches of DC provider too, before it expires. If this helps - use it as workaround and bug DC provider. From owner-freebsd-net@freebsd.org Sun Mar 25 18:40:39 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C0EDF622F4; Sun, 25 Mar 2018 18:40:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 061A473286; Sun, 25 Mar 2018 18:40:38 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B4B0F5A9F16; Sun, 25 Mar 2018 18:40:32 +0000 (UTC) Date: Sun, 25 Mar 2018 18:40:32 +0000 From: Brooks Davis To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Calling nxge(4) users Message-ID: <20180325184032.GA42437@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 18:40:39 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE adapters has obvious bugs (by inspection) and it doesn't appear the company exists any more. We'd like to see if there are any significant users of this device and plan to remove it from FreeBSD-12 if not. -- Brooks --UugvWAfsgieZRqgk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJat+0fAAoJEKzQXbSebgfAwloIAKTzwact5dMn4JkLwJLKjdSk 18t75i4Exf5xjIulqxnSTo7sB02LJ/VT2XC043UeiyZDJRSMZz+kk0mDukMFhSAp 7VDOiDrNpClA6s62tUxxmHJXRY2rxhKgGTXsKIE+HZiYtxqIKGgbx+S9eiJWO31K Ty0Rva22BwBKQMpnxjWdaWrVssaNIertj1E8WGPBg8OREy4Q5XwRoMTBq8jF3g+d iAb2tMeQqJTttOt8dsgyxSlG1MAmZguo8rhLL069AqKXhtWME1ufac9AgcTSJILm e0k+LmrluaUuvIlox1wqs2DdNRbx3J6p/KeJjUZYLBJvu6FMg1F0Me0dti1URfg= =mbr2 -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-net@freebsd.org Sun Mar 25 19:29:43 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18CFCF6666B; Sun, 25 Mar 2018 19:29:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 9DCC4751D3; Sun, 25 Mar 2018 19:29:42 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id x5so10014540vkd.7; Sun, 25 Mar 2018 12:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Wa9EnUkXPtExYq8S4Iauhf8G5DUxbsrtd5JNTE091Uk=; b=CHJy5Y79hdnxhqKjsC0UjMtPih5NgY0hsl096cbPXBXefcQFLyTm7gzyzgGLlk9odS lwNhD6kHqs+rcbsWfx5SCqZbNjNe0MqcmR24y+QjYqzxZgoEQw7TzUIdNY2kRGHnftyo YvptbqysG0Ed6IaEW/ppbLI/sVWPcGBLyWROtGk/AmgofzcaMd+aFPRCXUcNgueVd1K+ FtDOwubwKcbs+f7ULMMR+/i9afCE78RJljL8iRpIKOtbqoDegmNWYFTsrvPK+O/WVwbw Arj1ClSTkeEwgr4jf+e0L4SBWzDjkNxjKjMt1Db0A78YBxZgjyX0kqiWyoMDSd5Xrw2w s1bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Wa9EnUkXPtExYq8S4Iauhf8G5DUxbsrtd5JNTE091Uk=; b=gi5lPeHclq4j/SEhqzaTK5w/wBieI0wv0uW2VuYxtPIeyrctfxkKb/kxpJzyOHu0Fc nCrWZhzLurjQR1ZXmEiRCpJcKOvpqxZj4A8VIsmNZkHMZq+r3sI9K4H21uvrEZ5amKGB SLlRX8S5PWSft3zrdYhFLx3APtibLZ5p/NhM0B8Ji0y5WSpFn8XeP1Fz7xD/L8YvIs2V xsbmosFL5aifZKTlNKxnaQTd+tWYfLf6NB7ZksUd3Nj6Ij9SMKCMJHg2qjBCSYrUW4bY MVVd/QP3TZyuPDSKOI8tRE+WWUwTr0xTlFJHDiAu9pLk6UA8utAx5ubzLJbnyIkXFAqI mIzg== X-Gm-Message-State: AElRT7HyljrX1kF9HMIBH1kSp05Xi5SP3pjkoVomRBtlzbw8nRT6yeNW shnwAj8mZw99APnubp7tv+5/SNfX0q5zrv5vi+n2cXlA X-Google-Smtp-Source: AG47ELscoeN6uNZwthvZgzf26PSQ+IspF5/0+11qMJqSt81jhVr/zzkt3D6ag9WOzkRyOG3MshjhWtB3LqMjOR5nsas= X-Received: by 10.31.252.68 with SMTP id a65mr21416873vki.78.1522006181734; Sun, 25 Mar 2018 12:29:41 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.91.5 with HTTP; Sun, 25 Mar 2018 12:29:41 -0700 (PDT) In-Reply-To: <20180325184032.GA42437@spindle.one-eyed-alien.net> References: <20180325184032.GA42437@spindle.one-eyed-alien.net> From: Kevin Oberman Date: Sun, 25 Mar 2018 12:29:41 -0700 X-Google-Sender-Auth: -D3f7Cby-sDa1Q_Pu1_RBJ_2imw Message-ID: Subject: Re: Calling nxge(4) users To: Brooks Davis Cc: FreeBSD-STABLE Mailing List , freebsd-net Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 19:29:43 -0000 On Sun, Mar 25, 2018 at 11:40 AM, Brooks Davis wrote: > The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE > adapters has obvious bugs (by inspection) and it doesn't appear the > company exists any more. We'd like to see if there are any significant > users of this device and plan to remove it from FreeBSD-12 if not. > > -- Brooks > Just for the record, Neterion was acquired by Exar, an old-line hybrid IC company in 2010 and Exar was acquired last year by MaxLinear. Looks like Exar bought them for some of their tech and killed off the Ethernet products. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-net@freebsd.org Sun Mar 25 20:09:31 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A91CF6927F; Sun, 25 Mar 2018 20:09:31 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E97576545; Sun, 25 Mar 2018 20:09:30 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2PK9RgI043534; Sun, 25 Mar 2018 13:09:27 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2PK9Rjk043533; Sun, 25 Mar 2018 13:09:27 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803252009.w2PK9Rjk043533@pdx.rh.CN85.dnsmgr.net> Subject: Re: Calling nxge(4) users In-Reply-To: <20180325184032.GA42437@spindle.one-eyed-alien.net> To: Brooks Davis Date: Sun, 25 Mar 2018 13:09:27 -0700 (PDT) CC: freebsd-stable@freebsd.org, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 20:09:31 -0000 > The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE > adapters has obvious bugs (by inspection) and it doesn't appear the > company exists any more. We'd like to see if there are any significant > users of this device and plan to remove it from FreeBSD-12 if not. > > -- Brooks Neterion has been acquired by exar. https://www.eetimes.com/document.asp?doc_id=1173009 They have the datasheet for the Xframe-I here: https://www.exar.com/ds/xframedatasheet.pdf The cards appear to be readily avaliable on ebay. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Sun Mar 25 21:01:30 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF7A7F6CE58 for ; Sun, 25 Mar 2018 21:01:29 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5778E78416 for ; Sun, 25 Mar 2018 21:01:28 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 6E90114C17 for ; Sun, 25 Mar 2018 21:01:27 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2PL1RmO003163 for ; Sun, 25 Mar 2018 21:01:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2PL1R2a003156 for freebsd-net@FreeBSD.org; Sun, 25 Mar 2018 21:01:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201803252101.w2PL1R2a003156@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 25 Mar 2018 21:01:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 21:01:30 -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 | 206581 | bxe_ioctl_nvram handler is faulty In Progress | 221146 | [ixgbe] Problem with second laggport 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 | 209682 | [panic] [netinet] arptimer race New | 213410 | [carp] service netif restart causes hang only whe New | 217748 | sys/dev/ixgbe/if_ix.c: PVS-Studio: Assignment to 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 | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ Open | 213814 | AWS/EC2: no egress traffic stats on ixv(4) Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo 17 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Mar 25 22:00:24 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7C48F436F3 for ; Sun, 25 Mar 2018 22:00:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D3CB7BD05 for ; Sun, 25 Mar 2018 22:00:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2PM0FQX031228 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Mar 2018 00:00:16 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: supportsobaka@mail.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w2PM07go042343 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Mar 2018 05:00:07 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: FreeBSD 11.1 with Intel(R) PRO/1000 unresponsive to all network interfaces from outside (seems, during idle), but immediately up when ping anything from inside the server To: supportsobaka@mail.ru References: <1521974300.464728846@f345.i.mail.ru> <5AB7BCA5.2020201@grosbein.net> <1522013857.196729581@f405.i.mail.ru> Cc: "freebsd-net@freebsd.org" From: Eugene Grosbein Message-ID: <5AB81BE2.5030800@grosbein.net> Date: Mon, 26 Mar 2018 05:00:02 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1522013857.196729581@f405.i.mail.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 22:00:24 -0000 26.03.2018 4:37, supportsobaka@mail.ru wrote: > It doesn't help, unfortunately. The DC provides rescue system, both Linux and FreeBSD 11.1. I booted to both today > and keep it idle for several hours and never get lost connection to the server (never kicked out from terminal). > They also run GENERIC on FreeBSD 11.1. That's just fine. > They have sysctl net.link.ether.inet.max_age = 1200, so even higher than default 600. No, default is 1200. > So the confuse now is what's the difference between their and mine FreeBSD 11.1 that I didn't tune much yet. Firewalls disabled. > > Any idea? That's obviously your tuning then :-) Post it. From owner-freebsd-net@freebsd.org Sun Mar 25 22:51:45 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC4E3F4F091 for ; Sun, 25 Mar 2018 22:51:44 +0000 (UTC) (envelope-from supportsobaka@mail.ru) Received: from fallback.mail.ru (fallback11.m.smailru.net [94.100.179.26]) (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 5A3587DDC5 for ; Sun, 25 Mar 2018 22:51:43 +0000 (UTC) (envelope-from supportsobaka@mail.ru) Received: from [10.161.63.10] (port=37622 helo=f387.i.mail.ru) by fallback11.m.smailru.net with esmtp (envelope-from ) id 1f0Dql-0008VO-Gb for freebsd-net@freebsd.org; Mon, 26 Mar 2018 01:10:51 +0300 Received: by f387.i.mail.ru with local (envelope-from ) id 1f0Dq4-0000yj-3z; Mon, 26 Mar 2018 01:10:08 +0300 Received: by e.mail.ru with HTTP; Mon, 26 Mar 2018 01:10:08 +0300 From: supportsobaka@mail.ru To: =?UTF-8?B?RXVnZW5lIEdyb3NiZWlu?= Cc: =?UTF-8?B?ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc=?= Subject: =?UTF-8?B?UmVbMl06IEZyZWVCU0QgMTEuMSB3aXRoIEludGVsKFIpIFBSTy8xMDAwIHVu?= =?UTF-8?B?cmVzcG9uc2l2ZSB0byBhbGwgbmV0d29yayBpbnRlcmZhY2VzIGZyb20gb3V0?= =?UTF-8?B?c2lkZSAoc2VlbXMsIGR1cmluZyBpZGxlKSwgYnV0IGltbWVkaWF0ZWx5IHVw?= =?UTF-8?B?IHdoZW4gcGluZyBhbnl0aGluZyBmcm9tIGluc2lkZSB0aGUgc2VydmVy?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 Date: Mon, 26 Mar 2018 01:10:08 +0300 Reply-To: supportsobaka@mail.ru X-Priority: 3 (Normal) Message-ID: <1522015808.829415859@f387.i.mail.ru> X-7FA49CB5: 70AAF3C13DB7016878DA827A17800CE72F77D32A8A6015ECC4224003CC836476D1DB134E79BD61627866D6147AF826D8AA873B5EDB01EDDB0328DAFCD22BA938089D37D7C0E48F6C8AA50765F7900637AB618AFAE38917A3F7DD8EA147386B3775ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC8519DC0BE04022C72727F269C8F02392CD5571747095F342E88FB05168BE4CE3AF X-Mailru-Sender: C1D09E46DAAD3409338448D8342DA043B303DC7B5BD4420E59D9E9708FE572423E6AE937B715D86E12824C74316D419A9E6BD6917B53005D7268C455A0344CD32AA3CDD27765A5666233C95170C4828D08E29FF3D9B2F13D0DA7A0AF5A3A8387 X-Mras: OK X-Spam: undefined In-Reply-To: <5AB81BE2.5030800@grosbein.net> References: <1521974300.464728846@f345.i.mail.ru> <1522013857.196729581@f405.i.mail.ru> <5AB81BE2.5030800@grosbein.net> X-7FA49CB5: 0D63561A33F958A5CABDEFB0F05F4E6289264672688C6E94DCBA405CD88C1A43462275124DF8B9C99B0B8D173C204012BD9CCCA9EDD067B1EDA766A37F9254B7 X-Mailru-MI: 800 X-Mras: OK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Mar 2018 22:51:45 -0000 SSB0aGluayBzby4gSSB1c2UgYSBzZXQgb2Ygc3lzY3RsIGZyb20gbXkgcHJldmlvdXMgc2VydmVy cyB0aGF0IHdvcmsgNSsgeWVhcnMgZmxhd2xlc3NseSwgSSB3aWxsIHNldCBhbGwgdG8gZGVmYXVs dHMgdG8gc2VlIGlmIGl0IGhlbHBzIGFuZCB3aWxsIGJlIGluY2x1ZGluZyBvbmUgYnkgb25lIHRv IHNlZSB3aGVyZSBpdCBmYWlscy4KCgo+VGhhdCdzIG9idmlvdXNseSB5b3VyIHR1bmluZyB0aGVu IDotKSBQb3N0IGl0Lgo+Cj4KCgoK From owner-freebsd-net@freebsd.org Mon Mar 26 00:40:07 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07178F57707 for ; Mon, 26 Mar 2018 00:40:07 +0000 (UTC) (envelope-from ddobrev85@gmail.com) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 789E681ACA for ; Mon, 26 Mar 2018 00:40:06 +0000 (UTC) (envelope-from ddobrev85@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id 80so16075954wrb.2 for ; Sun, 25 Mar 2018 17:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance; bh=0wLnKgZp655EdtvbtnG2VvWh/F9HDDdpPWZ9wlPoiNc=; b=ANKUUNN6gaIP+cShlExfnB0FCsCiDonaUODIVGab9LXpTSbHcH05S/9SWvyPoIh/UX MozN1/n3gfFMYtoqoP//So2RdMygrSuWplVtQ1FNh0wYwWFmvIMMWaxd7YyA7pM5TMQq qSmgJrhenrCaluJ9fPyTkZY9xQTbSkGEqs04n06hETJwKXMSig574GWt3ff0wCh6GJdZ 8kbO9YfaNF0O77y77491DLY5aQk81lZxB9JXtYj9WI+j7XwiNclcuF47iGC7xYHYB+WV VLbXhHcSxVWLs6aKYuV9butkfrXIiufs4CXPLcKeyN+ZVOiyP4eCFIQykJ2ByCZ3fsny B3ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=0wLnKgZp655EdtvbtnG2VvWh/F9HDDdpPWZ9wlPoiNc=; b=K3kzFqFaKt5t124YkeihrNu2WFScgokOho/ed3rBvoNRwX2CdrX75ofIjVWDlpgw8W rqoXt2S1QlMN8uMFcQk40LD8Q4Y3m2g0/IE7RNlEIV8Pp5v1H4ZEgKOawD1xiZFPvZlc Vn6akmm+fyxya0zQYn2yizy8t7nxyQGHj/aOi7Z67mMLPPUyOO8KSKN1z99E5YK4FgOQ lQBGAeZynMQcYbGiHgPweGYiNgOvEyDT9jWxbt3LdE0CKesi8rfoUjNkaqEdlXckV00X o8R9ESQ9f0PgvwyCtNpkfEL8DjNyzLnJyzcKp+arTLMl1akOjdZk2TUQ9HQHk7/V7k2V LTUg== X-Gm-Message-State: AElRT7FYb7WrZZLXMPEQt+ILO5H8rNez75lbe/LiOhbI2HDFvGGm/Ih7 z2dhCwYloGNhgq7LvI/WGFz2vL2A X-Google-Smtp-Source: AG47ELt1H47r0yfsH+y9boBa5o7yaEoMG9jj9CvAEbSd+gdq3VOONWsCDjL0nKe8ra8GaN0bYRB6qA== X-Received: by 10.223.224.200 with SMTP id e8mr28621257wri.149.1522024804525; Sun, 25 Mar 2018 17:40:04 -0700 (PDT) Received: from ?IPv6:::ffff:192.168.254.130? ([87.227.223.203]) by smtp.gmail.com with ESMTPSA id k17sm12657026wrh.18.2018.03.25.17.40.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Mar 2018 17:40:03 -0700 (PDT) Message-ID: <5ab84163.91c8df0a.8c2a1.815a@mx.google.com> MIME-Version: 1.0 To: "freebsd-net@freebsd.org" From: Dobri Dobrev Subject: accf_http question Date: Mon, 26 Mar 2018 03:40:01 +0300 Importance: normal X-Priority: 3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Mar 2018 00:40:07 -0000 In my application I set SO_RECVTIMEO to 1.5 seconds, then enable SO_ACCEPTF= ILTER (httpready). accf_http module is loaded in the kernel. The problem is that if I connect to the socket but don=E2=80=99t send any d= ata, the connection remains open indefinitely. The application of course wo= n=E2=80=99t see a connection since the accept filter don=E2=80=99t see a co= mplete http request. Why is this the case? Why doesn=E2=80=99t SO_RECVTIMEO affect the socket? H= ow to close such connections early? Also, the documentation says: =E2=80=9CThe optional argument af_arg can be passed to the accept filter specified by af_name to provide additional configuration options at attach time.=E2=80=9D I checked the code of accf_http.c, but from what I see =E2=80=93 the =E2=80= =9Carg=E2=80=9D value is not used anywhere, nor is there any indication as = to what that value might be. Does anyone have any ideas? From owner-freebsd-net@freebsd.org Mon Mar 26 11:59:30 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D36CF652CA for ; Mon, 26 Mar 2018 11:59:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 096E77A0BD for ; Mon, 26 Mar 2018 11:59:30 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 489C31C99D for ; Mon, 26 Mar 2018 11:59:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2QBxTCO061514 for ; Mon, 26 Mar 2018 11:59:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2QBxTis061512 for freebsd-net@FreeBSD.org; Mon, 26 Mar 2018 11:59:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 223835] BGP session not established with md5 password via FRRouting Date: Mon, 26 Mar 2018 11:59:26 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: felipe@felipeoliva.eti.br X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@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.25 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, 26 Mar 2018 11:59:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835 --- Comment #36 from Felipe N. Oliva --- (In reply to Andrey V. Elsukov from comment #35) Of course and thank you. Do I need to use the SA from IPSec too or with your patch I can use on open= bgpd configuration? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 26 20:54:54 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC944F6B09F for ; Mon, 26 Mar 2018 20:54:53 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5241D73B85 for ; Mon, 26 Mar 2018 20:54:53 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id x4so5567063wmh.5 for ; Mon, 26 Mar 2018 13:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4j8zTMFpJjfw3dZzl+yuiSyWV+hnhq54ZddF/E92bEw=; b=Ge6vI7xi4SAO3SsrR9kWjW26ubrsL9gwNclZc70JwxIt3dRSBEdVR323k3/MPPZ9BD n93oSbCN7CBCs799UzE+VBPwd4fsQ1Ig/NcVdXmjd/KyWBkYchttPNXOGhIYzgeHZ0z2 5IKFKcBpjmJ18ARuDgii8W0Lgc0FNtq9FSwRkwgjO8kLE9D37LwRt3FUw/fvuf76PKOn SHnt9iaIXob0E+BY2ONXzP5fOylMCdUuw4xeGtW4MGVhuVYXtX0Fb8+SpAjQ/OKYrnD6 QjQNJwHYqley8S0fMlLh8HjFzLsDhrN+ymSQtywzTOCoCRUf+QSlUSQNu0WQEtmBxEDG Zv+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4j8zTMFpJjfw3dZzl+yuiSyWV+hnhq54ZddF/E92bEw=; b=r+DqG+v5VWH94ApmAX/zLsfnbASVtXnybcglG1PAPTDtCpcM4hGXQ6zuaNtAQuxk4S /MvMFVpxanOyCCm2rvD9ywepWqVnLS28UsX1r3ZeLTn1NzMax9jfAvDJ8S2M366MpKOQ /bEZgTcFexvY9HIWuhAUu3t4uivwlYm/WmZuoxMlFRJTiuO1FPvTUTSfR3eSgd2iJFLe zRxn6WobIKMVnE8nWDVmJ7wqp+5iIt8YbSPtvi+pVK1BMv2BWsldLlUp//9TKqF4erCq H5KqN0JKwi3udRWZXrRn1Zk5+G9Hd8ny2C6k0sg7kdoGKkJBgO7C+Y+HMO2vLcCTArxf Z42g== X-Gm-Message-State: AElRT7EgvyfF+1fuXXybv6bnm4GoPuZFnazv1K9Gb+foJxqF7WM7MA5u yLgqyyqOD+3xM/tOc5QV9X16AUYc X-Google-Smtp-Source: AG47ELv3/Z+4/VoHmLWFVj4RRSV/64CcfDFrcXwcr0YGf4ldn4BioZThbrHvNGKcBTyowI+Nu4ZnTg== X-Received: by 10.80.149.237 with SMTP id x42mr40495555eda.99.1522097692097; Mon, 26 Mar 2018 13:54:52 -0700 (PDT) Received: from juntos.woohoo.ch ([2a02:168:681c:460:3cad:c4fc:4f61:171]) by smtp.gmail.com with ESMTPSA id b47sm10995970ede.13.2018.03.26.13.54.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 13:54:51 -0700 (PDT) Subject: Re: Same host or different? How can you tell "over the wire"? To: freebsd-net@freebsd.org References: <4903.1521667183@segfault.tristatelogic.com> From: Andreas Scherrer Message-ID: <4ec7815d-f085-acd2-56ce-c3deefe3e307@gmail.com> Date: Mon, 26 Mar 2018 22:54:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <4903.1521667183@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Mar 2018 20:54:54 -0000 Hi rfg On 21.03.18 22:19, Ronald F. Guilmette wrote: ... > Is there any method which can be applied to A and A' over the > Internet and which could reliably differentiate these two possible > cases from one another (i.e. a single common host versus two separate > hosts)? That is an interesting question (or thought experiment). I would say the answer is unfortunately a boring "no". Assuming that there IS such a method, it would have to make the decision based on (a set of) "features" in the network traffic it sees. Now there MUST be something that can be changed/mangled/tuned in the traffic that is generated by a single machine to trick the scanner into thinking that it is looking at two different machines. Whatever the "features" are, changing at least one of them must be possible. Or am I missing something? Cheers andreas From owner-freebsd-net@freebsd.org Mon Mar 26 22:29:49 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46C09F717B1; Mon, 26 Mar 2018 22:29:49 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 E94CD78714; Mon, 26 Mar 2018 22:29:48 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 511865A9F16; Mon, 26 Mar 2018 22:29:42 +0000 (UTC) Date: Mon, 26 Mar 2018 22:29:42 +0000 From: Brooks Davis To: "Rodney W. Grimes" Cc: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: Calling nxge(4) users Message-ID: <20180326222942.GB42437@spindle.one-eyed-alien.net> References: <20180325184032.GA42437@spindle.one-eyed-alien.net> <201803252009.w2PK9Rjk043533@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline In-Reply-To: <201803252009.w2PK9Rjk043533@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Mar 2018 22:29:49 -0000 --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 25, 2018 at 01:09:27PM -0700, Rodney W. Grimes wrote: > > The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE > > adapters has obvious bugs (by inspection) and it doesn't appear the > > company exists any more. We'd like to see if there are any significant > > users of this device and plan to remove it from FreeBSD-12 if not. > >=20 > > -- Brooks >=20 > Neterion has been acquired by exar.=20 > https://www.eetimes.com/document.asp?doc_id=3D1173009 >=20 > They have the datasheet for the Xframe-I here: > https://www.exar.com/ds/xframedatasheet.pdf >=20 > The cards appear to be readily avaliable on ebay. Given that most of these cards appear to have been PCI-X and the product failed in the market, I'm not finding that compelling. One could buy a Chelsio or Intel card for a similar price and have a supported driver. Unless someone has a significant deployment of these cards that will run past the EOL of FreeBSD 11 (2021) this driver is a net negative. -- Brooks --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJauXRVAAoJEKzQXbSebgfAza8H/iJ6bdHMZ/Vbl2q1F2ytd1cl MxUszVU0g77ld7cjan6zu0AgcIh7yhfCDXJBkuNvmE6RyuAdz0dJGnWElrq4DQo2 wrIkhbNAmsZojGqUwatiEcmNtz8zTfm4gOwGA4qjAqOXfdFFMhCBnktrZ4EZ1oUk 4ANq9EHqhOphEL4AgNGAJnqIN+9ywoIrZhI5VzjOe9CRusQ73Ym/H9BmoSa1d2Pg WZWKNJBpC5/bbv0UVFEAPhI6lJwLsXa8jsNTr0Zvds13RuZXBJMpX/XEFk2SjVgb MmD0WAbT5CoG4zruSRmB6KI5F8xNDhVWb4GUZApKCKIFnR8oZCHgjfj7oohgukY= =TB/r -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-net@freebsd.org Mon Mar 26 23:13:16 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DA3BF508C4 for ; Mon, 26 Mar 2018 23:13:16 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3371E7BC37 for ; Mon, 26 Mar 2018 23:13:16 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-io0-x22f.google.com with SMTP id l3so25290801iog.0 for ; Mon, 26 Mar 2018 16:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PchUdhr2BgHgQq220sY6PoGdBH7SH5COQ3Ogi+xthc4=; b=tNm3q4w0rHzNjzM5pZIBMEP8+UQYGK7/nD733AVVOZjeOD9EzbfE0UarPSkFT6blOG XaAa1QWMePiDyGGBfWKTmOkd0kyb7TtpMQ0+2LraDtiXzvtCOhPjdiL2eXJyJb5wKT7h CNij1HHX3HSSU+Mk3PssL8Q0stK5HF+NY2pdw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PchUdhr2BgHgQq220sY6PoGdBH7SH5COQ3Ogi+xthc4=; b=NwCGoU2hiBkTF8S9FjtOcnTFl+ftwpNQXYQDYzFBd1FId+/Dwnx7kaTkn4Qu0NcR/j r0wqaAhhBjsg0EINVd52UtM34wMZ2pGKmEbBTi9H3cHxiS7+3+v7ZzSGalOBJCb59U79 eC3r5bBBYeBoJ/ROJAV/s0eBmz1aNyvHUKUffkHjuLRubSyVgyuD88c1ot0SZmNYRETz 5abIqu9nxCJU84t+53PsGWWp0M0ZEKh+co2Pex2Zt8I4iK5bApCs5t1wHwjF2ZUqmHCg iP0bypTJsKAQdoj2gLIc+sydglhXU0qS9WE2GNuky2Anvs4tlgXCItS50laFGe+zciAS Iglg== X-Gm-Message-State: AElRT7FFNn+v9ifyHLQJ7PtWcJj4sOWujnDldFTQAufKKK9gSR2IGy5/ NEcoHHQ7N2OnbTDlw7rqDmOavdFdT7EOLuw8FqZ0Sw== X-Google-Smtp-Source: AG47ELu6mZOG5/0uqMFJ7hy/CTEQljY9zMcDTX5p1RpnRv2EVtTrn7uRMj4j2JK38jQ52ZurAfl3HRMwP1q2A6NbVx0= X-Received: by 10.107.139.70 with SMTP id n67mr41538613iod.109.1522105995580; Mon, 26 Mar 2018 16:13:15 -0700 (PDT) MIME-Version: 1.0 References: <20180325184032.GA42437@spindle.one-eyed-alien.net> <201803252009.w2PK9Rjk043533@pdx.rh.CN85.dnsmgr.net> <20180326222942.GB42437@spindle.one-eyed-alien.net> In-Reply-To: <20180326222942.GB42437@spindle.one-eyed-alien.net> From: Kevin Bowling Date: Mon, 26 Mar 2018 23:13:04 +0000 Message-ID: Subject: Re: Calling nxge(4) users To: Brooks Davis Cc: "Rodney W. Grimes" , freebsd-net@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Mar 2018 23:13:16 -0000 Agreed. Please cull the =E2=80=98ixgb=E2=80=99 driver for similar reasons On Mon, Mar 26, 2018 at 4:05 PM Brooks Davis wrote: > On Sun, Mar 25, 2018 at 01:09:27PM -0700, Rodney W. Grimes wrote: > > > The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE > > > adapters has obvious bugs (by inspection) and it doesn't appear the > > > company exists any more. We'd like to see if there are any significa= nt > > > users of this device and plan to remove it from FreeBSD-12 if not. > > > > > > -- Brooks > > > > Neterion has been acquired by exar. > > https://www.eetimes.com/document.asp?doc_id=3D1173009 > > > > They have the datasheet for the Xframe-I here: > > https://www.exar.com/ds/xframedatasheet.pdf > > > > The cards appear to be readily avaliable on ebay. > > Given that most of these cards appear to have been PCI-X and the product > failed in the market, I'm not finding that compelling. One could buy > a Chelsio or Intel card for a similar price and have a supported driver. > > Unless someone has a significant deployment of these cards that will run > past the EOL of FreeBSD 11 (2021) this driver is a net negative. > > -- Brooks > From owner-freebsd-net@freebsd.org Tue Mar 27 00:23:00 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6489F56717 for ; Tue, 27 Mar 2018 00:23:00 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 263137F03C for ; Tue, 27 Mar 2018 00:22:59 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w2R0MoF3006124 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Mar 2018 17:22:50 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w2R0MnKM006123; Mon, 26 Mar 2018 17:22:49 -0700 (PDT) (envelope-from jmg) Date: Mon, 26 Mar 2018 17:22:48 -0700 From: John-Mark Gurney To: "Joseph H. Buehler" Cc: "freebsd-net@freebsd.org" Subject: Re: netmap ixgbevf max frame size Message-ID: <20180327002248.GQ75576@funkthat.com> Mail-Followup-To: "Joseph H. Buehler" , "freebsd-net@freebsd.org" References: <5AAC49BE.3030508@cox.net> <5AAC4A96.1040107@cox.net> <5AB01439.3090003@cox.net> <5AB25533.3020003@cox.net> <5AB25EF9.4080100@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5AB25EF9.4080100@cox.net> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 26 Mar 2018 17:22:50 -0700 (PDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 00:23:00 -0000 Joseph H. Buehler wrote this message on Wed, Mar 21, 2018 at 09:32 -0400: > This turned out to be a limitation of the box we are using, there is apparently hardware between the ixgbevf chip and the fiber. I've written a program that will probe the sizes that work successfully, set the route's MTU properly. This is designed for FreeBSD, but should be adaptable to Linux, assuming it has similar features: https://github.com/jmgurney/automtud > > I am unable to send frames larger than 9216 bytes (destination MAC through trailing CRC inclusive) using ixgbevf hardware with latest netmap code (LINUX). > > > > What is the source of this limitation? From the chip datasheet it appears that much larger frames are supported. > > > > There is mention of 9216 in some of the driver source files but as an MTU, the max frame size is larger. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@freebsd.org Tue Mar 27 08:22:02 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C778CF5DCE7 for ; Tue, 27 Mar 2018 08:22:02 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 5CB75756E5 for ; Tue, 27 Mar 2018 08:22:02 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id c23so4177674qtj.5 for ; Tue, 27 Mar 2018 01:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7r7B7lya6nh1l2debO+dF3pXJfATDdAoma9wyTK0UgI=; b=oxGbl+TBWkzABD0Sg0dLfypMPp7pJ2MSokN9jVucMKUSExLnBhE4Atbe1mJVxgJy9G J8UaXfhQqKCPCwVCUTV2H56IGbQSxUKzFna69Wr0w73ZcMg+pHdiVLkOW9SnyBPo8b4n wQkVMPpX7t3Y+bTGHBUWMm0SsX4CWBLFrzc5xFMB74Yu+NappZ/aFTE/+HoP125DsTet zP+N+jZwyOQ4ADSRxAkOugk5vSur29+6dpXF9RpYF7+ufkxJioyiqIt7uOXskd9dwFQy cU+fl6j+yxOOTinKxyvlH/UX5hFNb4Dm3HoNwhaUz3DkPiyKH5IzGJlzduSkw9OmNi47 eGKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7r7B7lya6nh1l2debO+dF3pXJfATDdAoma9wyTK0UgI=; b=okRSyBfB4VuqULRZZZr3zTLaC1VRBd+9e77cHva2uy7jLjSRoZRhfRPvl2H4vQkbR2 p0RKzHiMKuaQ8G2Il5oClKkNb1Mu6O/8iaCsoB3zdB0GNEZuzaFGFRC4aVwEuG+5p5FC 2d5RkZAExGUw91Yig2nT+wCuGwrWWjy9NOO6Z3wADYfWi9YPfzFdNirXgsp/wPSAyrvN BD2WeTEoMGztNimdWQK64CDvuW1PcZ2levybYFhw4oK1Dri6Dv34f/TKQb3Wd/D+HoPt xJ7D/H8IruqGQLX/gQ+UQDX4w380fPrChew8Fqdguk1oPyhqiGSoOZIJguqVxuSZvZAG pa1w== X-Gm-Message-State: AElRT7FlYPJ2q1HOyD6lY/lXnUvvKbryy3ZZccadwu6MLpvUR9BQUnfR ApN3WiRN0n+vdf2L7Etu0+PINMfobyVNYTiVKSU= X-Google-Smtp-Source: AIpwx4/MrrxBRAzvlgxj3rZhaTMb034Ts95R7QUVuo4ZTBxJaV6RitmwHvlPqqLoX5r0h03UjABVDKzA09qZ1CN8fm0= X-Received: by 10.200.68.85 with SMTP id m21mr11739645qtn.49.1522138921767; Tue, 27 Mar 2018 01:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.195.204 with HTTP; Tue, 27 Mar 2018 01:22:01 -0700 (PDT) In-Reply-To: References: <5AAC49BE.3030508@cox.net> <5AAC4A96.1040107@cox.net> <5AB01439.3090003@cox.net> <5AB166DC.8060708@cox.net> From: Vincenzo Maffione Date: Tue, 27 Mar 2018 10:22:01 +0200 Message-ID: Subject: Re: netmap ixgbevf mtu To: Joe Buehler Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 08:22:03 -0000 Hi, This commit (fe13476b106ed1f4b517b1590e1dfb3f268b6e78) in the upstream netmap should have fixed the NS_MOREFRAG issue for ixgbe. If you happen give a try let us know. Cheers, Vincenzo 2018-03-21 21:40 GMT+01:00 Vincenzo Maffione : > I see. Unfortunately this breaks the API, so I don't think we can accept > it. > We should probably sum up the fragment lengths, remember which one was the > first descriptor and write the olinfo field when we process the last > descriptor ... > I hope this does not slow down the simpler case where NS_MOREFRAG is not > used. > > In any, case we should move this discussion to the github, if possible (so > that the issue gets tracked). > > Cheers, > Vincenzo > > 2018-03-20 20:54 GMT+01:00 Joe Buehler : > >> Attached is a patch that allows fragmented TX with the ixgbevf driver. >> >> For the first TX buffer set the slot length to the full length of the >> frame and make sure that the slot buffer is fully filled. For succeeding >> slots just set the length to the amount of the buffer filled. >> >> Not intended as the perfect solution but it works fine for my situation. >> >> Joe Buehler >> >> > > > -- > Vincenzo Maffione > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Tue Mar 27 14:40:42 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70D19F5B331 for ; Tue, 27 Mar 2018 14:40:42 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB00B68F12 for ; Tue, 27 Mar 2018 14:40:41 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from [192.168.228.1] (ptr-8ripyyegu1indwts572.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:491:5406:a491:564e]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 8E6A55551F; Tue, 27 Mar 2018 16:40:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1522161639; bh=rX+SeaaHwO+O1/z8ucJvnMEOyWaJYPVL4Kq72OACREE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=wWUZHQYEPRyr/3rV2AuR6GWTwMMyw2J74QBqF8PGr6cewq9Z7wouyNhidvLm+BTaA Rl4hCfNFrnRgC1OEK+1NxFyuwoyEfrpmVvRM4gxGJWnG+GfEYqBo4VKTPpBRQvGwXt jKnqri/avfDnYm1d1Iai5oouKhOvQgoLfUJnFyzk= From: "Kristof Provost" To: "Reshad Patuck" Cc: "FreeBSD Net" Subject: Re: [vnet] [epair] epair interface stops working after some time Date: Tue, 27 Mar 2018 16:40:37 +0200 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> In-Reply-To: <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 14:40:42 -0000 (Re-cc freebsd-net, because this is useful information) On 27 Mar 2018, at 13:07, Reshad Patuck wrote: > The epair crash occurred again today running the epair module code > with the added dtrace sdt providers. > ​ > Running the same command as last time, 'dtrace -n ::epair\*:' returns > the following: > ``` > CPU ID FUNCTION:NAME … > 0 66499 epair_transmit_locked:enqueued > ``` > Looks like its filled up a queue somewhere and is dropping connections > post that. > ​ > The value of the 'error' is 55 I can see both the ifp and m structs > but don't know what to look for in them. > That’s useful. Error 55 is ENOBUFS, which in IFQ_ENQUEUE() means we’re hitting _IF_QFULL(). There don’t seem to be counters for that drop though, so that makes it hard to diagnose without these extra probe points. It also explains why you don’t really see any drop counters incrementing. The fact that this queue is full presumably means that the other side is not reading packets off it any more. That’s supposed to happen in epair_start_locked() (Look for the IFQ_DEQUEUE() calls). It’s not at all clear to my how, but it looks like the receive side is not doing its work. It looks like the IFQ code is already a fallback for when the netisr queue is full. That code might be broken, or there might be a different issue that will just mean you’ll always end up in the same situation, regardless of queue size. It’s probably worth trying to play with â€net.route.netisr_maxqlen’. I’d recommend *lowering* it, to see if the problem happens more frequently that way. If it does it’ll be helpful in reproducing and trying to fix this. If it doesn’t the full queues is probably a consequence rather than a cause/trigger. (Of course, once you’ve confirmed that lowering the netisr_maxqlen makes the problem more frequent go ahead and increase it.) Regards, Kristof From owner-freebsd-net@freebsd.org Tue Mar 27 14:47:13 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 812EFF5BF1F for ; Tue, 27 Mar 2018 14:47:13 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C6F46977F for ; Tue, 27 Mar 2018 14:47:12 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from [192.168.228.1] (ptr-8ripyyegu1indwts572.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:491:5406:a491:564e]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 5C44955527; Tue, 27 Mar 2018 16:47:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1522162031; bh=Z/PtKz+btIKTfei3Gew/NFLFRTXQMAa1SWoxUBMik+8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jVatzWLb3eHZTtwwOjEOZSd5ZOTHMmr++SqBaEGcgWAv6po0Vemat23yUYmtTobhc DamL0uYydIywWiwEd99grxT5tAN07jHP/Fij30o8TZr3Ts2wuehj5z7PKEiHnMo5VN wbW2onY0q86vw1i0N/eRmBSNlWjklJCMcTxoFu/I= From: "Kristof Provost" To: "Reshad Patuck" Cc: "FreeBSD Net" Subject: Re: [vnet] [epair] epair interface stops working after some time Date: Tue, 27 Mar 2018 16:47:10 +0200 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <1DA1D7BE-015D-4B42-A7A8-13FE837BA6DE@sigsegv.be> In-Reply-To: <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 14:47:13 -0000 On 27 Mar 2018, at 16:40, Kristof Provost wrote: > It’s probably worth trying to play with â€net.route.netisr_maxqlen’. I probably mean â€net.link.epair.netisr_maxqlen’ here. Regards, Kristof From owner-freebsd-net@freebsd.org Tue Mar 27 14:48:37 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44081F5C191 for ; Tue, 27 Mar 2018 14:48:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CBB06698AC for ; Tue, 27 Mar 2018 14:48:36 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B8E3425D3A6E; Tue, 27 Mar 2018 14:48:34 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F2299D1F904; Tue, 27 Mar 2018 14:48:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id tMLHDd0FivuW; Tue, 27 Mar 2018 14:48:32 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 8B805D1F902; Tue, 27 Mar 2018 14:48:31 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kristof Provost" Cc: "Reshad Patuck" , "FreeBSD Net" Subject: Re: [vnet] [epair] epair interface stops working after some time Date: Tue, 27 Mar 2018 14:48:29 +0000 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> In-Reply-To: <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> 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.25 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, 27 Mar 2018 14:48:37 -0000 On 27 Mar 2018, at 14:40, Kristof Provost wrote: > (Re-cc freebsd-net, because this is useful information) > > On 27 Mar 2018, at 13:07, Reshad Patuck wrote: >> The epair crash occurred again today running the epair module code >> with the added dtrace sdt providers. >> ​ >> Running the same command as last time, 'dtrace -n ::epair\*:' returns >> the following: >> ``` >> CPU ID FUNCTION:NAME > … >> 0 66499 epair_transmit_locked:enqueued >> ``` > >> Looks like its filled up a queue somewhere and is dropping >> connections post that. >> ​ >> The value of the 'error' is 55 I can see both the ifp and m structs >> but don't know what to look for in them. >> > That’s useful. Error 55 is ENOBUFS, which in IFQ_ENQUEUE() means > we’re hitting _IF_QFULL(). > There don’t seem to be counters for that drop though, so that makes > it hard to diagnose without these extra probe points. > It also explains why you don’t really see any drop counters > incrementing. > > The fact that this queue is full presumably means that the other side > is not reading packets off it any more. > That’s supposed to happen in epair_start_locked() (Look for the > IFQ_DEQUEUE() calls). > > It’s not at all clear to my how, but it looks like the receive side > is not doing its work. > > It looks like the IFQ code is already a fallback for when the netisr > queue is full. > That code might be broken, or there might be a different issue that > will just mean you’ll always end up in the same situation, > regardless of queue size. > > It’s probably worth trying to play with > â€net.route.netisr_maxqlen’. I’d recommend *lowering* it, to see > if the problem happens more frequently that way. If it does it’ll be > helpful in reproducing and trying to fix this. If it doesn’t the > full queues is probably a consequence rather than a cause/trigger. > (Of course, once you’ve confirmed that lowering the netisr_maxqlen > makes the problem more frequent go ahead and increase it.) netstat -Q will be useful From owner-freebsd-net@freebsd.org Tue Mar 27 16:57:38 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76BEFF6A91A for ; Tue, 27 Mar 2018 16:57:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E66371D84 for ; Tue, 27 Mar 2018 16:57:38 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 59C3542B7 for ; Tue, 27 Mar 2018 16:57:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2RGvbiS039661 for ; Tue, 27 Mar 2018 16:57:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2RGvbjr039660 for freebsd-net@FreeBSD.org; Tue, 27 Mar 2018 16:57:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191700] [carp] [bridge] CARP does not work on interface which belongs to a bridge Date: Tue, 27 Mar 2018 16:57:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hf@spg.tu-darmstadt.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal 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.25 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, 27 Mar 2018 16:57:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191700 Hauke Fath changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hf@spg.tu-darmstadt.de --- Comment #3 from Hauke Fath --- (In reply to Palle Girgensohn from comment #2) I see the same problem on 11.1, so - yes. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 27 18:20:26 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8EC4F72658 for ; Tue, 27 Mar 2018 18:20:25 +0000 (UTC) (envelope-from aspam@cox.net) Received: from fed1rmfepo202.cox.net (fed1rmfepo202.cox.net [68.230.241.147]) by mx1.freebsd.org (Postfix) with ESMTP id 59CF4779F2 for ; Tue, 27 Mar 2018 18:20:25 +0000 (UTC) (envelope-from aspam@cox.net) Received: from eastrmimpo209.cox.net ([68.230.241.224]) by eastrmfepo202.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180327181935.SFC7322.eastrmfepo202.cox.net@eastrmimpo209.cox.net> for ; Tue, 27 Mar 2018 14:19:35 -0400 Received: from thunder.sweets ([68.100.138.62]) by eastrmimpo209.cox.net with cox id T6Ka1x00l1LxgH8016Kap7; Tue, 27 Mar 2018 14:19:34 -0400 X-Authority-Analysis: v=2.2 cv=K+pSJ2eI c=1 sm=1 tr=0 a=3mkzfl4ircflX6G+lDqBYw==:117 a=3mkzfl4ircflX6G+lDqBYw==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=v2DPQv5-lfwA:10 a=e9ASbk4n0QUA:10 a=pGLkceISAAAA:8 a=kviXuzpPAAAA:8 a=L01Y0KvKqF-WzihgYD4A:9 a=-Rr1gJl0YjS6l9S_:21 a=sCfkV1Ty7I_x_TyR:21 a=QEXdDO2ut3YA:10 a=qrIFiuKZe2vaD64auk6j:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=jbuehler@cox.net Received: from [10.10.10.15] (thunder.sweets [10.10.10.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thunder.sweets (Postfix) with ESMTP id F13B4FED4; Tue, 27 Mar 2018 14:19:33 -0400 (EDT) Message-ID: <5ABA8B31.9010908@cox.net> Date: Tue, 27 Mar 2018 14:19:29 -0400 From: Joe Buehler User-Agent: Thunderbird 1.5.0.12 (X11/20120201) MIME-Version: 1.0 To: Vincenzo Maffione CC: "freebsd-net@freebsd.org" Subject: Re: netmap ixgbevf mtu References: <5AAC49BE.3030508@cox.net> <5AAC4A96.1040107@cox.net> <5AB01439.3090003@cox.net> <5AB166DC.8060708@cox.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 18:20:26 -0000 Grazie mille. I will test it as time allows -- swamped. Joe Buehler Vincenzo Maffione wrote: > Hi, > This commit (fe13476b106ed1f4b517b1590e1dfb3f268b6e78) in the upstream > netmap should have fixed the NS_MOREFRAG issue for ixgbe. > If you happen give a try let us know. > > Cheers, > Vincenzo > > 2018-03-21 21:40 GMT+01:00 Vincenzo Maffione >: > > I see. Unfortunately this breaks the API, so I don't think we can > accept it. > We should probably sum up the fragment lengths, remember which one > was the first descriptor and write the olinfo field when we process > the last descriptor ... > I hope this does not slow down the simpler case where NS_MOREFRAG is > not used. > > In any, case we should move this discussion to the github, if > possible (so that the issue gets tracked). > > Cheers, > Vincenzo > > 2018-03-20 20:54 GMT+01:00 Joe Buehler >: > > Attached is a patch that allows fragmented TX with the ixgbevf > driver. > > For the first TX buffer set the slot length to the full length > of the frame and make sure that the slot buffer is fully > filled. For succeeding slots just set the length to the amount > of the buffer filled. > > Not intended as the perfect solution but it works fine for my > situation. > > Joe Buehler > > > > > -- > Vincenzo Maffione > > > > > -- > Vincenzo Maffione From owner-freebsd-net@freebsd.org Tue Mar 27 18:34:18 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E964BF73849 for ; Tue, 27 Mar 2018 18:34:17 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7617278977 for ; Tue, 27 Mar 2018 18:34:17 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from [10.0.2.164] (ptr-8ripyyhxwudjls5kxi0.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:e909:7f67:c669:b98]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id AAB3A559BE; Tue, 27 Mar 2018 20:34:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1522175656; bh=ZdsavW0b2Gc4pZMkl7gwjjqYMMTz0ocjoJuj2Z672Cw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=uPQOVWRalSNZ7ybgzMqDoMHf++Cujit4eT9/ZASe4aa40rggY2pOcP7KTkvX0UtZ+ bMYA+ZIqg2EBJrKznaWJc10hAhE7QE4DIGEhU6kabiPx2H57sv8A/INTji5Yax7tEO 2risApvaLICU1gV15MM8GiKiqJZw7RIv2CjDK1nE= From: "Kristof Provost" To: "Bjoern A. Zeeb" Cc: "Reshad Patuck" , "FreeBSD Net" Subject: Re: [vnet] [epair] epair interface stops working after some time Date: Tue, 27 Mar 2018 20:34:14 +0200 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <87E6B8EC-F92B-49F4-A540-04E084FA0A33@sigsegv.be> In-Reply-To: <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> 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.25 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, 27 Mar 2018 18:34:18 -0000 On 27 Mar 2018, at 16:48, Bjoern A. Zeeb wrote: > On 27 Mar 2018, at 14:40, Kristof Provost wrote: > >> (Re-cc freebsd-net, because this is useful information) >> >> On 27 Mar 2018, at 13:07, Reshad Patuck wrote: >>> The epair crash occurred again today running the epair module code >>> with the added dtrace sdt providers. >>> ​ >>> Running the same command as last time, 'dtrace -n ::epair\*:' >>> returns the following: >>> ``` >>> CPU ID FUNCTION:NAME >> … >>> 0 66499 epair_transmit_locked:enqueued >>> ``` >> >>> Looks like its filled up a queue somewhere and is dropping >>> connections post that. >>> ​ >>> The value of the 'error' is 55 I can see both the ifp and m structs >>> but don't know what to look for in them. >>> >> That’s useful. Error 55 is ENOBUFS, which in IFQ_ENQUEUE() means >> we’re hitting _IF_QFULL(). >> There don’t seem to be counters for that drop though, so that makes >> it hard to diagnose without these extra probe points. >> It also explains why you don’t really see any drop counters >> incrementing. >> >> The fact that this queue is full presumably means that the other side >> is not reading packets off it any more. >> That’s supposed to happen in epair_start_locked() (Look for the >> IFQ_DEQUEUE() calls). >> >> It’s not at all clear to my how, but it looks like the receive side >> is not doing its work. >> >> It looks like the IFQ code is already a fallback for when the netisr >> queue is full. >> That code might be broken, or there might be a different issue that >> will just mean you’ll always end up in the same situation, >> regardless of queue size. >> >> It’s probably worth trying to play with >> â€net.route.netisr_maxqlen’. I’d recommend *lowering* it, to see >> if the problem happens more frequently that way. If it does it’ll >> be helpful in reproducing and trying to fix this. If it doesn’t the >> full queues is probably a consequence rather than a cause/trigger. >> (Of course, once you’ve confirmed that lowering the netisr_maxqlen >> makes the problem more frequent go ahead and increase it.) > > netstat -Q will be useful Reshad included that in his e-mail to me: > On the system with the bug 'netstat -Q' seems to have queue drops for > epair. > ``` > # netstat -Q > Configuration: > Setting Current Limit > Thread count 1 1 > Default queue limit 256 10240 > Dispatch policy direct n/a > Threads bound to CPUs disabled n/a > ​ > Protocols: > Name Proto QLimit Policy Dispatch Flags > ip 1 256 flow default --- > igmp 2 256 source default --- > rtsock 3 256 source default --- > arp 4 256 source default --- > ether 5 256 source direct --- > ip6 6 256 flow default --- > epair 8 2100 cpu default CD- > ​ > Workstreams: > WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled > 0 0 ip 0 30 11150458 0 0 13092275 24242558 > 0 0 igmp 0 0 0 0 0 0 0 > 0 0 rtsock 0 1 0 0 0 42 42 > 0 0 arp 0 0 56380919 0 0 0 56380919 > 0 0 ether 0 0 108761357 0 0 0 108761357 > 0 0 ip6 0 10 34999359 0 0 4091259 39090613 > 0 0 epair 0 2100 0 0 210972 303785724 303785724 > ``` > ​ > I also noticed that the values for 'epair' in the 'Workstreams' > section including drops do not change, while all others increase after > some time. I think I’ve triggered this problem by setting net.link.epair.netisr_maxqlen to an absurdly low value (2 in my case). It looks like there’s an issue with the handling over an overflow of the “hardware” queue, but I don’t really understand that code. Regards, Kristof From owner-freebsd-net@freebsd.org Tue Mar 27 19:00:04 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24B93F4F065 for ; Tue, 27 Mar 2018 19:00:04 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 958A07A739 for ; Tue, 27 Mar 2018 19:00:03 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: by mail-pg0-x242.google.com with SMTP id f10so8748950pgs.9 for ; Tue, 27 Mar 2018 12:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=BqSzvKygyRum4uUiLBP3on1FVOEjB8A/YRxnsC8vOxw=; b=InAzPH+i0jqOCuShxTP9yOE9qi9UkQKynFAf346QMzs5+0aGOUY/mLEDTL/2fmAMXy 8vnPbcd6HbOI3OMalo+Vtz3eCvmqrRroder45tl5xnj/oo82NQRuYeIpkDgCk27aKytN 48nakWYFMzVRvr0RR+ziM748bvZ/GY5h9eK2jsw0Yk8NCmy+CkheffzHg7zm8iPEWAuv YQ89y2KE9SMsZAOlS7bLZJyxGrKoOQGxHW4Lld2LOhJKChtej4ZJWlJnO2GVxKBiVNhY dFza53CACMm/a70YxehAreP/Dfaw0cYczuS/xH7ffQJ5HhaIakqzl2Ao0MfG4T9iNN+z HhAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=BqSzvKygyRum4uUiLBP3on1FVOEjB8A/YRxnsC8vOxw=; b=hmzRcWrHOsErCfShyyDTa4Xobq6wUUEVk/+ISH/avODxuU/yC3GwS97CvRT20+JzB3 nA4m6tzq58U8YDEY8KumZ3ZTyotPIN9gW/bGrOhfhsAnU2mGBwe8zdnVSRXBlinkN/9J sD5welzeC3PkbB5YxkzV+LIYy2AQZZy/96NfJ/StKDuV14BJKEEetwKgHsundozofSDI qG7FDS06NhY6u6jYBedR3UIbOKS/6Ii6nZOJtXZD7wLQ0CbPgj04eVJ/lT0lovdLNINx 4smGuioh/iv+OPKm6GMjJYJ02GpnXiXUaOPn/3TocUDL7CXVlIdI1GzrUFh5t3tge10C 6mCQ== X-Gm-Message-State: AElRT7HRxx7ZbsaXxtYwEom9hmyeUSFLa43FXbkRSKsfIx6RukYHYqdh 9wGElKMGPqVKz06aiZ36g3VoydMj X-Google-Smtp-Source: AIpwx4/Sq0x+YiTrjLKO4r5hG1/tmvriwExMqxqMJU4GYrZ4KnG4fbIN+SjB3i196OpKoqMObUgEsg== X-Received: by 10.167.128.204 with SMTP id a12mr389030pfn.177.1522177202333; Tue, 27 Mar 2018 12:00:02 -0700 (PDT) Received: from [192.168.1.103] ([60.243.103.35]) by smtp.gmail.com with ESMTPSA id t66sm4431535pgc.0.2018.03.27.11.59.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 12:00:01 -0700 (PDT) Date: Wed, 28 Mar 2018 00:29:51 +0530 User-Agent: K-9 Mail for Android In-Reply-To: <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> MIME-Version: 1.0 Subject: Re: [vnet] [epair] epair interface stops working after some time To: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Kristof Provost CC: FreeBSD Net ,Reshad Patuck From: Reshad Patuck Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 19:00:04 -0000 Hi, =E2=80=8B @Kristof: The current value of 'net=2Elink=2Eepair=2Enetisr_maxqlen' is 2100, I will= make it 210=2E Will this require a reboot? or can I just change the sysctl and reload the= epair module? =E2=80=8B @Bjoern: here is the output to 'netstat -Q' ``` # netstat -Q Configuration: Setting Current Limit Thread count 1 1 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a =E2=80=8B Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 256 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 4 256 source default --- ether 5 256 source direct --- ip6 6 256 flow default --- epair 8 2100 cpu default CD- =E2=80=8B Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 30 11409267 0 0 13574317 24983409 0 0 igmp 0 0 0 0 0 0 0 0 0 rtsock 0 1 0 0 0 42 42 0 0 arp 0 0 61109751 0 0 0 61109751 0 0 ether 0 0 115098020 0 0 0 1150980= 20 0 0 ip6 0 10 36157577 0 0 4273274 40430846 0 0 epair 0 2100 0 0 210972 303785724 3037857= 24 ``` =E2=80=8B I still have access to a machine in this state, but will need to reset it = to a working state soon=2E =E2=80=8B Please let me know if there is any information you would like me to get fr= om this machine before I reset it=2E =E2=80=8B Best, =E2=80=8B Reshad On 27 March 2018 8:18:29 PM IST, "Bjoern A=2E Zeeb" wrote: >On 27 Mar 2018, at 14:40, Kristof Provost wrote: > >> (Re-cc freebsd-net, because this is useful information) >> >> On 27 Mar 2018, at 13:07, Reshad Patuck wrote: >>> The epair crash occurred again today running the epair module code=20 >>> with the added dtrace sdt providers=2E >>> =E2=80=8B >>> Running the same command as last time, 'dtrace -n ::epair\*:' >returns=20 >>> the following: >>> ``` >>> CPU ID FUNCTION:NAME >> =E2=80=A6 >>> 0 66499 epair_transmit_locked:enqueued >>> ``` >> >>> Looks like its filled up a queue somewhere and is dropping=20 >>> connections post that=2E >>> =E2=80=8B >>> The value of the 'error' is 55 I can see both the ifp and m structs=20 >>> but don't know what to look for in them=2E >>> >> That=E2=80=99s useful=2E Error 55 is ENOBUFS, which in IFQ_ENQUEUE() me= ans=20 >> we=E2=80=99re hitting _IF_QFULL()=2E >> There don=E2=80=99t seem to be counters for that drop though, so that m= akes=20 >> it hard to diagnose without these extra probe points=2E >> It also explains why you don=E2=80=99t really see any drop counters=20 >> incrementing=2E >> >> The fact that this queue is full presumably means that the other side > >> is not reading packets off it any more=2E >> That=E2=80=99s supposed to happen in epair_start_locked() (Look for the= =20 >> IFQ_DEQUEUE() calls)=2E >> >> It=E2=80=99s not at all clear to my how, but it looks like the receive = side=20 >> is not doing its work=2E >> >> It looks like the IFQ code is already a fallback for when the netisr=20 >> queue is full=2E >> That code might be broken, or there might be a different issue that=20 >> will just mean you=E2=80=99ll always end up in the same situation,=20 >> regardless of queue size=2E >> >> It=E2=80=99s probably worth trying to play with=20 >> =E2=80=98net=2Eroute=2Enetisr_maxqlen=E2=80=99=2E I=E2=80=99d recommend= *lowering* it, to see=20 >> if the problem happens more frequently that way=2E If it does it=E2=80= =99ll be=20 >> helpful in reproducing and trying to fix this=2E If it doesn=E2=80=99t = the=20 >> full queues is probably a consequence rather than a cause/trigger=2E >> (Of course, once you=E2=80=99ve confirmed that lowering the netisr_maxq= len=20 >> makes the problem more frequent go ahead and increase it=2E) > >netstat -Q will be useful >_______________________________________________ >freebsd-net@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd=2Eorg" From owner-freebsd-net@freebsd.org Tue Mar 27 19:02:48 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 010C6F4F527 for ; Tue, 27 Mar 2018 19:02:48 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EC137AB1B for ; Tue, 27 Mar 2018 19:02:47 +0000 (UTC) (envelope-from srs0=711/=gr=sigsegv.be=kristof@codepro.be) Received: from [10.0.2.164] (ptr-8ripyyhxwudjls5kxi0.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:e909:7f67:c669:b98]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id F343055A14; Tue, 27 Mar 2018 21:02:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1522177366; bh=cThe7PPBjNRwjDmu+t5CRMpa80tBLNtkx8xICmhTKKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=shG6rcrDKDOPXAR2GPiScsEWE4cdoBdqSjNujztEWkTRRypM7LyZ1TDy58veI9pbl +2le6/BpEn9PCC5NZ+ltaG35Hrh6Xt/gQoDuGyVJvzP5oW20a/CPhZ9au54+QuQll4 gXeYryLdbuc0giD0jotFBA9vCbZ+1RFYeb+bywZ4= From: "Kristof Provost" To: "Reshad Patuck" Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , "Reshad Patuck" Subject: Re: [vnet] [epair] epair interface stops working after some time Date: Tue, 27 Mar 2018 21:02:44 +0200 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> In-Reply-To: References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> 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.25 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, 27 Mar 2018 19:02:48 -0000 On 27 Mar 2018, at 20:59, Reshad Patuck wrote: > The current value of 'net.link.epair.netisr_maxqlen' is 2100, I will > make it 210. > Will this require a reboot? or can I just change the sysctl and reload > the epair module? > ​ You shouldn’t need to reboot or reload the epair module. When I set it to 2 on my box it pretty much immediately lost connectivity over the epair interfaces. I’d expect you to get hit by the bug relatively quickly now, so be aware of that. Regards, Kristof From owner-freebsd-net@freebsd.org Tue Mar 27 19:06:34 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EABEF4FAD8 for ; Tue, 27 Mar 2018 19:06:34 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e: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 EA1007AD83 for ; Tue, 27 Mar 2018 19:06:33 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: by mail-pl0-x229.google.com with SMTP id 9-v6so14687406ple.11 for ; Tue, 27 Mar 2018 12:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=DOPJu9HG8ztUcxcag5w9CoGinNZnild4N25BEolgQk8=; b=j9g2UH1CvC4x+FqXeRkRlUvkSEo15FxHddQobnbjbHKPQSCX3ARcHvSmF8MjWZTd0p ivObbXYXLPue7XSCRMF7JgJ4KDf3A37pGxGIP2T0Y7yuSGdLjQyBzzkC5pkB/S8I6xJz Z4ls6VCQ46voIuieeoDj+UswNdc/SLLqAWGdj3QSH7aUygyRDp7O891AEI9rO992+p6B TwqtEmJQpaCeuG5K3GpfG1fAAD1FWOCqiYVOhDaGBPW5RX5mNY6nHj5dnbn6ypZ1ndf+ fr6DFP79TrnNelBd6JX3nBThF+tugmgS14ajn8DKYYXhDhcubOOgBccZvTT57eZazx8J a4kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=DOPJu9HG8ztUcxcag5w9CoGinNZnild4N25BEolgQk8=; b=sXRFd587uNhEfH84+ZF1JYrlpXm0vR0NNxi3H8Jcr+G8Gzib7Qfm1YRCptqDcm5nub Fv0w/Tp4PiQwKxId65rLryogevoAri6nWBoL3XlgL1IDDSpraNXaV5tVRqKf0hjUXvtA 6dJIpFCDLz1EgCzUq5UchyP7kI5dYm3M2F2fTn2sLvDzE7m0Cr5NCz2uZqhyoE/E2ZBW 6kmCWBlZ6BWCHhM8cmZjkd4tu4YDRHqQWHEipYe9AxKninoD0Q/1C4coMCRvBksYPqU3 wAW6JXE27UogGfvxAnZWmvh4zNXD2KM52YfN2t+g/gXhpgx5doN2v63qU8WCFz4RAGHW Q7jw== X-Gm-Message-State: AElRT7Ho3mMikGcSmFz0kp9eeabf0yd9SaO0hHvzBiS1tcTifDGhSLsd rFMI0t1J7vtb3ikQcYL6n6M= X-Google-Smtp-Source: AIpwx4/1+oOuQyei+XuLgRbQ4jA/ALx/fHaCe2xfhji5eInc4rBrTH3iYsNSD+DaQXa4x42V2cWlqg== X-Received: by 2002:a17:902:6b41:: with SMTP id g1-v6mr521150plt.167.1522177592953; Tue, 27 Mar 2018 12:06:32 -0700 (PDT) Received: from [192.168.1.103] ([60.243.103.35]) by smtp.gmail.com with ESMTPSA id o90sm5664319pfj.102.2018.03.27.12.06.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 12:06:32 -0700 (PDT) Date: Wed, 28 Mar 2018 00:36:26 +0530 User-Agent: K-9 Mail for Android In-Reply-To: <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> MIME-Version: 1.0 Subject: Re: [vnet] [epair] epair interface stops working after some time To: Kristof Provost CC: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Reshad Patuck From: Reshad Patuck Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 19:06:34 -0000 Excellent, will give it a try on a box that I never have this problem on=2E Will let you know of the symptoms are the same when I trigger it=2E Best, Reshad On 28 March 2018 12:32:44 AM IST, Kristof Provost w= rote: >On 27 Mar 2018, at 20:59, Reshad Patuck wrote: >> The current value of 'net=2Elink=2Eepair=2Enetisr_maxqlen' is 2100, I w= ill=20 >> make it 210=2E >> Will this require a reboot? or can I just change the sysctl and >reload=20 >> the epair module? >> =E2=80=8B >You shouldn=E2=80=99t need to reboot or reload the epair module=2E When I= set it=20 >to 2 on my box it pretty much immediately lost connectivity over the=20 >epair interfaces=2E > >I=E2=80=99d expect you to get hit by the bug relatively quickly now, so b= e=20 >aware of that=2E > >Regards, >Kristof From owner-freebsd-net@freebsd.org Tue Mar 27 20:07:02 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDFAAF55082 for ; Tue, 27 Mar 2018 20:07:01 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CDCE7D683 for ; Tue, 27 Mar 2018 20:07:01 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w2RK70ZK051791; Tue, 27 Mar 2018 21:07:00 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w2RK6xu2051790; Tue, 27 Mar 2018 21:06:59 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201803272006.w2RK6xu2051790@donotpassgo.dyslexicfish.net> Date: Tue, 27 Mar 2018 21:06:58 +0100 Organization: Dyslexic Fish To: rfg@tristatelogic.com, jamie@catflap.org, freebsd-net@freebsd.org Subject: Re: Same host or different? How can you tell "over the wire"? References: <22999.1521916685@segfault.tristatelogic.com> In-Reply-To: <22999.1521916685@segfault.tristatelogic.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 27 Mar 2018 21:07:00 +0100 (BST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 20:07:02 -0000 "Ronald F. Guilmette" wrote: > In message <201803241747.w2OHlupR069759@donotpassgo.dyslexicfish.net>, > Jamie Landeg-Jones wrote: > > >Have you thought of examining the TCP timestamp field? Not necessarily > >for accurate uptime, but a way to determine if the hosts are the same. > > No, I certainly didn't, but that appears to be the exact kind of thing > I was looking for, so thanks! (I will have to look into it some more. > I have just skimmed RFC 1323 for the very first time ever, and it will > take me awhile to fully grok this stuff.) > > >Or some of the other fingerprinting methods? nmap has options for uptime > >and other fingerprinting : https://nmap.org/book/osdetect-usage.html > > I'm not seeing a separate option just for the uptime, apart from the > full blown OS detection. Did I just miss it? Sorry for the delay in replying. You're right - I don't think nmap has a seperate option, which seems strange to me, but still, the extra information may also help - especially for systems that block timestamp information leakage. 2 other ideas: You could also try checking the IP ID in a returning packets header. Used primarily for identifying fragments of a fragmented datagram, hosts traditionally increment (and wrap) this 16 bit value for each packet they send. Some hosts randomise this value, making this technique useless, but for those that don't, try this: # ping catflap.dyslexicfish.net & ping catnip.dyslexicfish.net & ping catseye.dyslexicfish.net All 3 should respond. If that's the case, leave that running, and in a new window, do: # tcpdump -lnv icmp and src host catflap.dyslexicfish.net or src host catnip.dyslexicfish.net or src host catseye.dyslexicfish.net | awk '($0 !~ "^[[:blank:]]") {printf "\n"} {printf "%s", $0}' (note the 'v' flag on the tcpdump to show the IP header information. The awk script is just to stop tcpdump wrapping output lines) You'll see something like this: 21:01:34.809142 IP (tos 0x0, ttl 56, id 43497, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 628, length 64 21:01:34.877061 IP (tos 0x0, ttl 50, id 28626, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 628, length 64 21:01:34.945069 IP (tos 0x0, ttl 54, id 25030, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 628, length 64 21:01:35.813005 IP (tos 0x0, ttl 56, id 43508, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 629, length 64 21:01:35.881953 IP (tos 0x0, ttl 50, id 28640, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 629, length 64 21:01:35.949967 IP (tos 0x0, ttl 54, id 25035, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 629, length 64 21:01:36.861471 IP (tos 0x0, ttl 56, id 43520, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 630, length 64 21:01:36.929752 IP (tos 0x0, ttl 50, id 28657, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 630, length 64 21:01:36.997415 IP (tos 0x0, ttl 54, id 25045, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 630, length 64 21:01:37.866177 IP (tos 0x0, ttl 56, id 43526, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 631, length 64 21:01:37.936751 IP (tos 0x0, ttl 50, id 28669, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 631, length 64 21:01:38.004537 IP (tos 0x0, ttl 54, id 25050, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 631, length 64 21:01:38.922487 IP (tos 0x0, ttl 56, id 43538, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 632, length 64 21:01:38.992473 IP (tos 0x0, ttl 50, id 28683, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 632, length 64 21:01:39.059168 IP (tos 0x0, ttl 54, id 25058, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 632, length 64 21:01:39.978330 IP (tos 0x0, ttl 56, id 43565, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 633, length 64 21:01:40.047226 IP (tos 0x0, ttl 50, id 28705, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 633, length 64 21:01:40.114158 IP (tos 0x0, ttl 54, id 25078, offset 0, flags [none], proto ICMP (1), length 84) 108.61.219.111 > 172.20.1.1: ICMP echo reply, id 29315, seq 633, length 64 21:01:41.032534 IP (tos 0x0, ttl 56, id 43577, offset 0, flags [none], proto ICMP (1), length 84) 104.238.172.250 > 172.20.1.1: ICMP echo reply, id 29059, seq 634, length 64 21:01:41.101740 IP (tos 0x0, ttl 50, id 28730, offset 0, flags [none], proto ICMP (1), length 84) 104.156.226.72 > 172.20.1.1: ICMP echo reply, id 28803, seq 634, length 64 If you look at the first id field in each line, you'll clearly see that these are 3 different hosts, as we have id's from 43497-43577, 28626-28730 and 25030-25078. ("missing" id's are simply due to the host replying to other packets, so this can also give a rough idea how busy a host is... If there are no missing id's, you're the only active connection!) The other idea: https://nmap.org/p60-12.html - This has details to help you can detect if any sort of load balancer/firewall etc. exists between you and the target, which is useful as they could cause false positives and false negatives. Hope this helps! Cheers, Jamie From owner-freebsd-net@freebsd.org Tue Mar 27 22:56:29 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D49F7F676E4 for ; Tue, 27 Mar 2018 22:56:29 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 835CD879CD for ; Tue, 27 Mar 2018 22:56:29 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id AA5FD5A9F16; Tue, 27 Mar 2018 22:56:23 +0000 (UTC) Date: Tue, 27 Mar 2018 22:56:23 +0000 From: Brooks Davis To: freebsd-net@freebsd.org Subject: removal of token-ring infrastructure coming soon Message-ID: <20180327225623.GA88362@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 22:56:30 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have posted a revision which removes support for token-ring networking =66rom the tree. There have been no such devices for some time. https://reviews.freebsd.org/D14875 -- Brooks --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJauswWAAoJEKzQXbSebgfAKXQH/1TcAS5pnzprzEE+GVM9tKU7 mbtegDd3DBzVYJpN3BNoVm8dg7FOaF+SGFL3e9sXhljMqDTIi4akvwB70N3AIVId tqxB0/3ioueh82HS4agy9L0ECwVpbvB3KPOQkQZyVMq9qeWLLTVAa6byhX1KBf3U 5L2MIWj4rJRrTPY6ghDa3hIGLcgZRsKEE1DrQeIFQc6wGuiLX1lGZHB6jGqHdrun gctfeJRzPyReya6xLEZkptG+m0noS53POItbIJR/Wwek9Xv6lzfDbuFqrCcs90Jq A4gTliqzDSp8x5VPIcS8NwLPkgA+j21XdyKmQYjOEbqIXsdLSgqibGb4+VhzR8Y= =DbxY -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-net@freebsd.org Tue Mar 27 23:56:38 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8061F6C540 for ; Tue, 27 Mar 2018 23:56:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 487DA69D9A; Tue, 27 Mar 2018 23:56:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2RNuWnT054562; Tue, 27 Mar 2018 16:56:33 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2RNuW4C054561; Tue, 27 Mar 2018 16:56:32 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803272356.w2RNuW4C054561@pdx.rh.CN85.dnsmgr.net> Subject: Re: removal of token-ring infrastructure coming soon In-Reply-To: <20180327225623.GA88362@spindle.one-eyed-alien.net> To: Brooks Davis Date: Tue, 27 Mar 2018 16:56:32 -0700 (PDT) CC: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Mar 2018 23:56:38 -0000 > I have posted a revision which removes support for token-ring networking > from the tree. There have been no such devices for some time. > > https://reviews.freebsd.org/D14875 > Arcnet coming soon? and probably FDDI? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Mar 28 00:29:30 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42F00F6EF78 for ; Wed, 28 Mar 2018 00:29:30 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 D27476B03F for ; Wed, 28 Mar 2018 00:29:29 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-io0-x233.google.com with SMTP id 141so1373737iou.12 for ; Tue, 27 Mar 2018 17:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SxUn+RvpImcZxJsLm+EHYMAz3e8E5qUWzneUXfl4Hl8=; b=CqtaH7nnw3FGqIPWdOQ0Mwu6VFTHBwPuWKoJtxBzuEAPqbHAn8ubEzjKz9eKuFPvzj DqWQqX+f9v4DI/lZG8XRFdmN9Dph3TBxJPd8IRBd6TA4nK+H0+pI8Bmn2GW00Dw5bouk c2lqCiPr1+UlA53ozNvoKV/VvSaIQtrFXPjeU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SxUn+RvpImcZxJsLm+EHYMAz3e8E5qUWzneUXfl4Hl8=; b=tKBuvBerkWTYjjC2Du0re4wruZY1VbwqG+KUiV+Nz7gSXz5nHj52YBtTjlGti2qbr7 T4OgXUYe3RRJldIvlSaapfZPuq/s7Svqefk0XMYfL5n+wAelduFXnTklVm42X0gGr1LY qsCcnCgAG/fOh0aLC2IkpAjn2qgj88LzaMCjTpQaNvHpAgSvYYoYkkdrAhAiUWYkwYJb xZnkNtlKfhlFu9ZJ57IuMC72w3JgB3mYuOHUVyOHN4GItkvAu8MN/q6cuVa9YoTk5n2h DeTw2CEFZ+MQ1j8ZTvC5UPSCZdIshzEP7Z6DH8UrHjq4HyRHuh6y9JO5DtP5DkX39X3f VlIA== X-Gm-Message-State: AElRT7Ex9ho8GQ8Vw3sxIrusyWn9yEBPwjitfMb49rP4zA/AuiO1xC8n S23ge3K1D4LonRtEvFdr3GZNNH+/SQ8= X-Google-Smtp-Source: AIpwx4+Rw+eekIVvsIe9pWsAWTIjBxVhxGA6XGhTszK15dwA6QUyb5imMzWSbH/+zZqI3R2tUAYggw== X-Received: by 10.107.89.10 with SMTP id n10mr26939285iob.67.1522196969096; Tue, 27 Mar 2018 17:29:29 -0700 (PDT) Received: from [172.20.4.35] (50-205-66-99-static.hfc.comcastbusiness.net. [50.205.66.99]) by smtp.gmail.com with ESMTPSA id t134-v6sm1777699itt.43.2018.03.27.17.29.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 17:29:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: removal of token-ring infrastructure coming soon From: Jim Thompson In-Reply-To: <201803272356.w2RNuW4C054561@pdx.rh.CN85.dnsmgr.net> Date: Tue, 27 Mar 2018 18:29:26 -0600 Cc: Brooks Davis , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <540B9C45-C679-481F-99ED-59DD22877A5E@netgate.com> References: <201803272356.w2RNuW4C054561@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 00:29:30 -0000 > On Mar 27, 2018, at 5:56 PM, Rodney W. Grimes = wrote: >=20 >> I have posted a revision which removes support for token-ring = networking >> from the tree. There have been no such devices for some time. >>=20 >> https://reviews.freebsd.org/D14875 >>=20 >=20 > Arcnet coming soon? > and probably FDDI? UUCP From owner-freebsd-net@freebsd.org Wed Mar 28 02:17:17 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7E39F4E933 for ; Wed, 28 Mar 2018 02:17:17 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25E1C6EF23; Wed, 28 Mar 2018 02:17:16 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2S2HD4O054944; Tue, 27 Mar 2018 19:17:13 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2S2HBBw054943; Tue, 27 Mar 2018 19:17:11 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803280217.w2S2HBBw054943@pdx.rh.CN85.dnsmgr.net> Subject: Re: removal of token-ring infrastructure coming soon In-Reply-To: <540B9C45-C679-481F-99ED-59DD22877A5E@netgate.com> To: Jim Thompson Date: Tue, 27 Mar 2018 19:17:11 -0700 (PDT) CC: freebsd-net@freebsd.org, Brooks Davis X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 02:17:17 -0000 > > On Mar 27, 2018, at 5:56 PM, Rodney W. Grimes wrote: > > > >> I have posted a revision which removes support for token-ring networking > >> from the tree. There have been no such devices for some time. > >> > >> https://reviews.freebsd.org/D14875 > >> > > > > Arcnet coming soon? > > and probably FDDI? > > UUCP As far as I am aware the only bit of uucp left around is in sendmail, and removing that should be left up to upstream. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Mar 28 04:11:55 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1441F57AFA for ; Wed, 28 Mar 2018 04:11:55 +0000 (UTC) (envelope-from christian.baltini@gmail.com) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 505F773AE6 for ; Wed, 28 Mar 2018 04:11:55 +0000 (UTC) (envelope-from christian.baltini@gmail.com) Received: by mail-ot0-x230.google.com with SMTP id m7-v6so1246865otd.1 for ; Tue, 27 Mar 2018 21:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0g8MH1ynW/4W9eJzHH+/RRnfZLSu1yp/h63WSc8vgG0=; b=HgNg8MOknC4KoU3BPJ6Gul2iunHTpoe4P5yY6bi7BxCuOZ38w5AlvmQZdmeyd9xyVh oBxzTPuZDTibiyMeODSFsJGLhgg8Aumpxi9jWOZqreOTNRJjIij6+OtUppZgbmaDfzlp dQiwSs8NPB/XRluNsGKE+OE38cSInQEoxjDAqNrrXS75vJIh8UyH4t8LpZQVDw5LhLHv m7NrG9K5YAmis38XvC3PtfSLEh0rY4own48y9NDaZg06vnZD9dZk40Wmwha7A149mG0T XMtSgApfjjOG1Rsu6QoIpUvh8toXDo//H8bstT557qbZolWut4pV1wpmIgl05bryzCYq VX7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0g8MH1ynW/4W9eJzHH+/RRnfZLSu1yp/h63WSc8vgG0=; b=EYQU3aweNdF9oShWbUZ9KC+pzxN7kn0/0/UemjjnFegFE76xWiIv6EqQ/acU00xZbd HI6hv/h6xX0TTzectgiOrjFWAxutowCZiFOp+tEqV8Riorn2MkX/+tzy6fLDVioZ0upk cOeaNhbam8qPn7/kFOYTro7/5PVcxpo8Ls5ctMc4vqJZFcDKckrKmmkos2b0HMYkR384 IoPJLlKnLotQ097zp/t1zT177oTx3XJ/6nY/nWD5Zrup41Z8+YR6Gmv4VdFya4YhnaMA Xv5DkbzmHHIiJ/lxZCIwWzgS5QyCIgFFKKtYyfNMmt3C0JYb5D21s1dc+XD+VmXpZkGy xh6A== X-Gm-Message-State: AElRT7HKdCXRCdAGKYqB/aNU4jDxi3QCVIZ7wklfROtOueacs7OZXS/e Mj0PHyR+dGaV9eRSM5I3kx6cNBRYkjO0f8tdS355a21lPPg= X-Google-Smtp-Source: AIpwx4/U+JkOp0puWr/ggi2mAy2gvgVZHcH91BMMBiKVs+FW0Cux6CZ9BF9Dd6y0n1cBLFhrmlu6oLCrw9aaiqLpFGw= X-Received: by 2002:a9d:618c:: with SMTP id g12-v6mr63332otk.225.1522210314535; Tue, 27 Mar 2018 21:11:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.200.144 with HTTP; Tue, 27 Mar 2018 21:11:54 -0700 (PDT) From: christian russell Date: Tue, 27 Mar 2018 21:11:54 -0700 Message-ID: Subject: Current state of Intel XL710 40G NIC ixl performance To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 04:11:55 -0000 I am having trouble getting an Intel XL710-DA2 NIC to get even close to line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 (FreeNAS in particular). We have tried both 1.7 and 1.9 driver revisions with similar results. The NVM version is 5.05. The card is in a confirmed 8x slot on a SuperMicro X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. After upping the interrupt threshold to 9000 dmesg doesn't log anything unusual. We have added the tunes that are standard for 10 Gbps configurations. On a single-client basis the fastest rates we see are around 5 Gbps. Hitting this server from multiple boxes we see peaks of 20 Gbps at the very highest. More frequently things top off around 13 Gbps. These numbers are coming from iperf tests. We are seeing similar numbers with direct point-to-point as well as switched topologies. These threads from 2015 describe similar issues but fizzled out: https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html Is there very particular tuning required to get these cards working at proper speed? Any insights? >From Googling around it appears frustration with this card and FreeBSD is pretty common. Thanks in advance. Christian From owner-freebsd-net@freebsd.org Wed Mar 28 09:22:49 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D8E9F6E3EC for ; Wed, 28 Mar 2018 09:22:49 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward106p.mail.yandex.net (forward106p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89FBC7F124; Wed, 28 Mar 2018 09:22:48 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback10o.mail.yandex.net (mxback10o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::24]) by forward106p.mail.yandex.net (Yandex) with ESMTP id 6CF982D87130; Wed, 28 Mar 2018 12:22:42 +0300 (MSK) Received: from smtp3p.mail.yandex.net (smtp3p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:8]) by mxback10o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id NUeAdcVK3s-MfwiLjmx; Wed, 28 Mar 2018 12:22:42 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1522228962; bh=63uOuoijpZC+gEFQEu/qEF7t93fNlL8916QhjFTSuf0=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=JNpGaJiSjkxkKgw9q/cAtH4YHkMiy/Dp9q6KQWkYrTKrPVPB947xsXgAkv1epJ/5Q UWDSfa5fdwC+c6ho/TQh98jQmCgOJLbi3rEY9OQfU0SABeP/Kq3ahdfi1CTJnORotk vtTcnp4m9sLyjfcBR6wUMiF0mxRcFVzmiCi11o4U= Received: by smtp3p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id b3JRy5TLVP-Me4ahQ96; Wed, 28 Mar 2018 12:22:40 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1522228960; bh=63uOuoijpZC+gEFQEu/qEF7t93fNlL8916QhjFTSuf0=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=cI/XmfAhRNYCKN/JN2ZxMKMoyBA43QpWsdOH6GIx6QYJHLMUyuNLxB/w80ADvy7FV yA9SWhheucI76eSckWsy70PRp1LAqcO4E41ZXmg8/ZTJkCdfZ6ACu0XpNTFM3FEY36 cbzWEj6IFIZVmt6ZXv6+xIrh9mYimBdDmlQ8YY3U= Authentication-Results: smtp3p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: crash with ipfw nat on mips32 To: Adrian Chadd , Olivier Houchard Cc: FreeBSD Net References: <70a569db-fa82-f2f6-61ea-a0d1a3dd9dae@yandex.ru> <20180322130002.GA65574@ci0.org> <20180322161543.GA66967@ci0.org> <20180323130204.GA74266@ci0.org> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <07ad72f5-bac7-841a-3c32-eed58179fc11@yandex.ru> Date: Wed, 28 Mar 2018 12:20:32 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7pebJYquztar5JH5PzHfHsQPNKB6tZWOu" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 09:22:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7pebJYquztar5JH5PzHfHsQPNKB6tZWOu Content-Type: multipart/mixed; boundary="XKL0ebq5PnUPbiaoMrTDvOprSO9UmcLRO"; protected-headers="v1" From: "Andrey V. Elsukov" To: Adrian Chadd , Olivier Houchard Cc: FreeBSD Net Message-ID: <07ad72f5-bac7-841a-3c32-eed58179fc11@yandex.ru> Subject: Re: crash with ipfw nat on mips32 References: <70a569db-fa82-f2f6-61ea-a0d1a3dd9dae@yandex.ru> <20180322130002.GA65574@ci0.org> <20180322161543.GA66967@ci0.org> <20180323130204.GA74266@ci0.org> In-Reply-To: --XKL0ebq5PnUPbiaoMrTDvOprSO9UmcLRO Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 23.03.2018 20:07, Adrian Chadd wrote: > Hi! >=20 > Just to keep things up to date; I had a chat with people on IRC. >=20 > * I got the regression suite in github compiling and running on amd64. > I'm going to attempt to commit some makefile hilarity to get it to > cross-compile against the copy in sys/contrib/ck > * I'll go get more info when I next power up the AP in question >=20 Hi Adrian, any news about this? I found PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225816 it is also related to the problem. --=20 WBR, Andrey V. Elsukov --XKL0ebq5PnUPbiaoMrTDvOprSO9UmcLRO-- --7pebJYquztar5JH5PzHfHsQPNKB6tZWOu 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/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlq7XmAACgkQAcXqBBDI oXq5LAf7BesOpD0ZFutU4qXw/gfYZx4KuUM/pGbe8qavYYZ+BRdBnUM25LtZ+Zmx I/V6EtJTzQFMQnzcX7iDqasMggwG5C3hF1cbRwFvrRLtnAnHZJSDmx2QnZ9VETp6 RJ20/aoqQOuc6FJOvRYCANqxlyISCserdw9aeMDDJB+qyQfEaVBUF2/mr25RiUKX tPZK3OcS1MBZinPpVNdtnKEE9HdO5/D4iZnFrU2AY5fi/eoSN1MT0U4W/8XyaVbo EJiih+qRryKMyR2ZPWpfl6J60qAccN+6cz6DVB15E3FqzAhnSa2vW2qhvk99L44U oEjtHBgYo7tBTd8nSzMQjtUOm2ZUMA== =VqlO -----END PGP SIGNATURE----- --7pebJYquztar5JH5PzHfHsQPNKB6tZWOu-- From owner-freebsd-net@freebsd.org Wed Mar 28 13:25:39 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3753EF5CBC1 for ; Wed, 28 Mar 2018 13:25:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C915269755 for ; Wed, 28 Mar 2018 13:25:38 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0C75816EFD for ; Wed, 28 Mar 2018 13:25:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2SDPbfG071936 for ; Wed, 28 Mar 2018 13:25:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2SDPbnm071935 for freebsd-net@FreeBSD.org; Wed, 28 Mar 2018 13:25:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 216460] 82599ES 10-Gigabit SFI/SFP+ Network Connection link constantly flaps Date: Wed, 28 Mar 2018 13:25:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tanu_life@yahoo.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: 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.25 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, 28 Mar 2018 13:25:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216460 tanu_life@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tanu_life@yahoo.com --- Comment #3 from tanu_life@yahoo.com --- Hi there=20 I would suggest contacting the reseller you bought this item from or if you= are within UK, you can also call a company called megnet , their website is https://www.megnet.co.uk they have helped me many times with situation like this. You can also email them if you are outside to uk or chat with them on their website. But the first point of contact should be the reseller who sold you this ite= m. I hope this helps --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Mar 28 13:49:25 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7DC4F5F7BC for ; Wed, 28 Mar 2018 13:49:25 +0000 (UTC) (envelope-from Ming.Fu@esentire.com) Received: from mail.esentire.com (mail.esentire.com [52.129.34.132]) (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 72FB06B140 for ; Wed, 28 Mar 2018 13:49:25 +0000 (UTC) (envelope-from Ming.Fu@esentire.com) Received: from exchange.esentire.com (cas01colo01p.internal [10.1.120.115]) by mail.esentire.com (Postfix) with ESMTPS id D76FA1801CD for ; Wed, 28 Mar 2018 13:41:27 +0000 (UTC) Received: from mbx01cmb01p.esentire.local (10.1.120.118) by mbx01cmb01p.esentire.local (10.1.120.118) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 28 Mar 2018 09:41:27 -0400 Received: from mbx01cmb01p.esentire.local ([fe80::c036:855e:1a82:9d34]) by mbx01cmb01p.esentire.local ([fe80::c036:855e:1a82:9d34%14]) with mapi id 15.00.1347.000; Wed, 28 Mar 2018 09:41:27 -0400 From: Ming Fu To: "freebsd-net@freebsd.org" Subject: Netmap on Linux nm_open() fail when receive ring size is set to 4096 Thread-Topic: Netmap on Linux nm_open() fail when receive ring size is set to 4096 Thread-Index: AdPGmnaafMxJ6MGgQPqo+Ei4Y3bW4Q== Date: Wed, 28 Mar 2018 13:41:27 +0000 Message-ID: <092c8d937ff6471fb701d64dcff1c756@mbx01cmb01p.esentire.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.1.120.131] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 13:49:26 -0000 Hi, I was trying netmap on a Linux box with 128G of ram (64G per numa node). If= I set ixgbe interface to 4096 ring size, the nm_open will fail with error = "Cannot allocate memory". What can I tweak to make the card use larger ring= size? The following test was run after fresh reboot. $ ethtool -g enp5s0f0 Ring parameters for enp5s0f0: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 512 RX Mini: 0 RX Jumbo: 0 TX: 512 $ ethtool -G enp5s0f0 rx 1024 $ ./nmtest -i enp5s0f0 ^C $ ethtool -G enp5s0f0 rx 2048 $ nmtest -i enp5s0f0 ^C $ ethtool -G enp5s0f0 rx 4096 $ nmtest -i enp5s0f0 816.039684 nm_open [945] NIOCREGIF failed: Cannot allocate memory netmap:en= p5s0f0 fail to nm_open(netmap:enp5s0f0 ... ): Cannot allocate memory Thanks, Ming From owner-freebsd-net@freebsd.org Wed Mar 28 15:26:56 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA64EF689C6 for ; Wed, 28 Mar 2018 15:26:56 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 424D6715E5 for ; Wed, 28 Mar 2018 15:26:56 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id 132so2804534qkd.5 for ; Wed, 28 Mar 2018 08:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XP3zyOVab/a+FlrQ533P5icAQVWIdZf6uN4wRFzyi7w=; b=M8U8WFOjzbjnF1NU9cLg9OQbEq2l8zy5SyiXub9zVF6Q6Sv+U1BOHG7gMwU4NyCh+H i2WE9tMYf2kO3iBA/PwPTJvw3sA6ATnG8WyVujQI6cY82OIcOvJHmMxRHcZRQv08dfnK nZUEbR7VuaJTweBxm/OBbmuxRIcjKtTgCF7V+vJ2JjNP6zTCWhxB8vP7pEOANqB645t+ zg1Co9i5b7HyP/dku4s76JRarH1C1Lyd2BolMVqYqB1kRr5RXcWy8zysvcs8Ar63cG6W mScLJn64WfLkmJYRKuI9Vcz/HgmVAjG+MaACph4gknTDMoocKJFY+g2wwNK57Hr+YAIn oqkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XP3zyOVab/a+FlrQ533P5icAQVWIdZf6uN4wRFzyi7w=; b=lDBnAzFNThxwvzSXWkVxLQFhSwZcHqWJfOqRqfVloHmcgGnABkrt+xYQKyKmjnAaqC 5hh5Gjy0/5ETw5KwWEBNagDzG5RoXLeY+OertZzdboK80MCHlfY4v0qwho6h8xlLojym +5Cj1cjjEjErNJRwLn4rp9bh/ynC7bIVCSScO41hSDQYJQQeQ4/edkaIBFQrAxq79AcE YXzDPbyNHrd9k4OHPQ78ZN/kr/gbHRvoRxlegYVKoEBBAtUyDt97ohr6/n++H1FbcYe5 k18GSZqdm2QDOscSc96LbEiGXdIadyVhMHAgfBMftUftB+oOc01dq0XWQyzUeJfHfiCU cvFw== X-Gm-Message-State: ALQs6tDdqr9OKfGTCKUFN4ETmNnMojwMPahNshBrjbw6G1RQ5LLkI7ah wG6T1R0kJYibrJFq8z/sRE4HFPgi7hsLhGgJwdw= X-Google-Smtp-Source: AIpwx4/7/UU83brfj2tNqfVkDqpDcAScVHNTxCiKJEixJjP+D2HfY4ZDycP+NH6pk1uL84V5/Ju4pjCvnc+8aCjUbJA= X-Received: by 10.55.7.18 with SMTP id 18mr5716398qkh.249.1522250815443; Wed, 28 Mar 2018 08:26:55 -0700 (PDT) MIME-Version: 1.0 References: <092c8d937ff6471fb701d64dcff1c756@mbx01cmb01p.esentire.local> In-Reply-To: <092c8d937ff6471fb701d64dcff1c756@mbx01cmb01p.esentire.local> From: Vincenzo Maffione Date: Wed, 28 Mar 2018 15:26:44 +0000 Message-ID: Subject: Re: Netmap on Linux nm_open() fail when receive ring size is set to 4096 To: Ming Fu Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 15:26:57 -0000 Hi, You need to increase the value of some netmap module parameter. At least ring_size, maybe also buf_num. Then restart your netmap applications. Keep in mind that performance could worsen with more slots, because of increased cache thrashing. Cheers, Vincenzo On Wed, Mar 28, 2018, 3:50 PM Ming Fu wrote: > Hi, > > I was trying netmap on a Linux box with 128G of ram (64G per numa node). > If I set ixgbe interface to 4096 ring size, the nm_open will fail with > error "Cannot allocate memory". What can I tweak to make the card use > larger ring size? The following test was run after fresh reboot. > > $ ethtool -g enp5s0f0 > Ring parameters for enp5s0f0: > Pre-set maximums: > RX: 4096 > RX Mini: 0 > RX Jumbo: 0 > TX: 4096 > Current hardware settings: > RX: 512 > RX Mini: 0 > RX Jumbo: 0 > TX: 512 > > $ ethtool -G enp5s0f0 rx 1024 > $ ./nmtest -i enp5s0f0 > ^C > $ ethtool -G enp5s0f0 rx 2048 > $ nmtest -i enp5s0f0 > ^C > $ ethtool -G enp5s0f0 rx 4096 > $ nmtest -i enp5s0f0 > 816.039684 nm_open [945] NIOCREGIF failed: Cannot allocate memory > netmap:enp5s0f0 > fail to nm_open(netmap:enp5s0f0 ... ): Cannot allocate memory > > Thanks, > Ming > _______________________________________________ > 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 Wed Mar 28 16:03:54 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C8CFF6A453 for ; Wed, 28 Mar 2018 16:03:54 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 338E07371D for ; Wed, 28 Mar 2018 16:03:54 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 3233C5A9F16; Wed, 28 Mar 2018 16:03:53 +0000 (UTC) Date: Wed, 28 Mar 2018 16:03:53 +0000 From: Brooks Davis To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Subject: Re: removal of token-ring infrastructure coming soon Message-ID: <20180328160353.GC88362@spindle.one-eyed-alien.net> References: <20180327225623.GA88362@spindle.one-eyed-alien.net> <201803272356.w2RNuW4C054561@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <201803272356.w2RNuW4C054561@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 16:03:54 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 27, 2018 at 04:56:32PM -0700, Rodney W. Grimes wrote: > > I have posted a revision which removes support for token-ring networking > > from the tree. There have been no such devices for some time. > >=20 > > https://reviews.freebsd.org/D14875 > >=20 >=20 > Arcnet coming soon? > and probably FDDI? That's my plan. I started with token ring as it doesn't even have drivers (Arcnet and FDDI have one driver each, but ISA and 32-bit PCI respectively AFACT). -- Brooks --98e8jtXdkpgskNou Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJau7zoAAoJEKzQXbSebgfAoB8H/i9pReuV0WP3/Bd8DB/3HHSz PfAvpggPzcZdUH6Y2/wq3oxthqT5A06YrbrdzWNhfQoK9hWU6CTi0b6/esRTWb3T U/PKIcw2iY7ENTmSfq/GaSbZYIhr0ZiIrHT2D6HhDyTaUNz2Z9tTbMAI8ldL/HAm hXhirnFEwsb312lfI/+mfuAi0JzUXxFArkYPxu4Rrtj5hyX0t5GqaSHLJruj6cqm CvBsD3x/S4WO7VjmmlrAoz9IaAPZLPTY6pijQrM7yZDSUoMxZEGvup3p1U6uQv8d O4Zd+lJCI7zqaBU+sToz3jL6hkeA6O5veASIH9pTcs/Y9ifpqoO7eqoMlXdpzR8= =6N4p -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-net@freebsd.org Wed Mar 28 16:16:28 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39929F6AAF0 for ; Wed, 28 Mar 2018 16:16:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF0A174026; Wed, 28 Mar 2018 16:16:27 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2SGGN3c057760; Wed, 28 Mar 2018 09:16:23 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2SGGNJb057759; Wed, 28 Mar 2018 09:16:23 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803281616.w2SGGNJb057759@pdx.rh.CN85.dnsmgr.net> Subject: Re: removal of token-ring infrastructure coming soon In-Reply-To: <20180328160353.GC88362@spindle.one-eyed-alien.net> To: Brooks Davis Date: Wed, 28 Mar 2018 09:16:23 -0700 (PDT) CC: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 16:16:28 -0000 > On Tue, Mar 27, 2018 at 04:56:32PM -0700, Rodney W. Grimes wrote: > > > I have posted a revision which removes support for token-ring networking > > > from the tree. There have been no such devices for some time. > > > > > > https://reviews.freebsd.org/D14875 > > > > > > > Arcnet coming soon? > > and probably FDDI? > > That's my plan. I started with token ring as it doesn't even have > drivers (Arcnet and FDDI have one driver each, but ISA and 32-bit PCI > respectively AFACT). I fully support that arcnet and FDDI are dead. Please be a bit carefull with what your calling "32 bit PCI" as those are also often embedded devices in chipsets that may not have cards avaliable, but are infact built in to systems. Also I have become aware that axing the bt946 support may not be a real good idea, as that is/was a common hypervisor emulation device and just recently found myself using it in to access a disk that was created with a scsi controller that had odd translation and the ata layer would not do the right thing for me. (32 sector, 64 head, which is not really odd for scsi, thats common translation for many scsi cards). I ended up using vmware with a bt946 emulation on scsi with the drive image attached to it, and booted FreeBSD from an ahci attached disk. If the bt946 drive was missing from 11.1 I would of been stuck. As far as I am aware both vmware and virtualbox have support for bt946 emulation, which is also a superset of aha154x. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Mar 28 16:20:09 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D801EF6AD4F for ; Wed, 28 Mar 2018 16:20:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 735D1742A0 for ; Wed, 28 Mar 2018 16:20:09 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 9E09E186A6 for ; Wed, 28 Mar 2018 16:20:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2SGK8Pc008701 for ; Wed, 28 Mar 2018 16:20:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2SGK8O7008700 for freebsd-net@FreeBSD.org; Wed, 28 Mar 2018 16:20:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227033] vxlan(4) does not work with vni larger than 65535 Date: Wed, 28 Mar 2018 16:20:08 +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.1-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.25 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, 28 Mar 2018 16:20:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227033 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 Wed Mar 28 16:26:39 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A447BF6B341 for ; Wed, 28 Mar 2018 16:26:39 +0000 (UTC) (envelope-from m.muenz@spam-fetish.org) Received: from mailout-02.maxonline.de (mailout-02.maxonline.de [81.24.66.23]) (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 3D19974ABF for ; Wed, 28 Mar 2018 16:26:39 +0000 (UTC) (envelope-from m.muenz@spam-fetish.org) Received: from web03-01.max-it.de (web03-01.max-it.de [81.24.64.215]) by mailout-02.maxonline.de (Postfix) with ESMTPS id 014C93B for ; Wed, 28 Mar 2018 18:20:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by web03-01.max-it.de (Postfix) with ESMTP id E286528A2F0 for ; Wed, 28 Mar 2018 18:20:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at web03-01.max-it.de Received: from web03-01.max-it.de ([127.0.0.1]) by localhost (web03-01.max-it.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4TmH1-2TLDA8 for ; Wed, 28 Mar 2018 18:20:39 +0200 (CEST) Received: from [81.24.66.132] (unknown [81.24.66.132]) (Authenticated sender: m.muenz@spam-fetish.org) by web03-01.max-it.de (Postfix) with ESMTPA id A187328A0BB for ; Wed, 28 Mar 2018 18:20:39 +0200 (CEST) Subject: Re: Current state of Intel XL710 40G NIC ixl performance To: freebsd-net@freebsd.org References: From: "Muenz, Michael" Message-ID: <8c3c7375-e299-78c7-6cc6-486bc41c54b1@spam-fetish.org> Date: Wed, 28 Mar 2018 18:20:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 16:26:39 -0000 Am 28.03.2018 um 06:11 schrieb christian russell: > I am having trouble getting an Intel XL710-DA2 NIC to get even close to > line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 (FreeNAS > in particular). > > We have tried both 1.7 and 1.9 driver revisions with similar results. The > NVM version is 5.05. The card is in a confirmed 8x slot on a SuperMicro > X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. After > upping the interrupt threshold to 9000 dmesg doesn't log anything unusual. > > We have added the tunes that are standard for 10 Gbps configurations. > > On a single-client basis the fastest rates we see are around 5 Gbps. > Hitting this server from multiple boxes we see peaks of 20 Gbps at the very > highest. More frequently things top off around 13 Gbps. These numbers are > coming from iperf tests. We are seeing similar numbers with direct > point-to-point as well as switched topologies. > > These threads from 2015 describe similar issues but fizzled out: > https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html > https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html > > Is there very particular tuning required to get these cards working at > proper speed? Any insights? > > >From Googling around it appears frustration with this card and FreeBSD is > pretty common. > > Thanks in advance. > > Christian I can't deliver any special insights but we had many problems with X710 (without L) and Linux. Did some testing a while ago with OPNsense (based on 11.1) and got line rate with iperf and single client. ixl0 in and ixl1 out. So this should be fine. If you like I can send you the sysctl values to compare. Michael From owner-freebsd-net@freebsd.org Wed Mar 28 16:38:34 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C480BF6BA21 for ; Wed, 28 Mar 2018 16:38:34 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 195C175AD1 for ; Wed, 28 Mar 2018 16:38:33 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2SGcWPP057894; Wed, 28 Mar 2018 09:38:32 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2SGcWNp057893; Wed, 28 Mar 2018 09:38:32 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803281638.w2SGcWNp057893@pdx.rh.CN85.dnsmgr.net> Subject: Re: Current state of Intel XL710 40G NIC ixl performance In-Reply-To: <8c3c7375-e299-78c7-6cc6-486bc41c54b1@spam-fetish.org> To: "Muenz, Michael" Date: Wed, 28 Mar 2018 09:38:32 -0700 (PDT) CC: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 16:38:34 -0000 > Am 28.03.2018 um 06:11 schrieb christian russell: > > I am having trouble getting an Intel XL710-DA2 NIC to get even close to > > line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 (FreeNAS > > in particular). > > > > We have tried both 1.7 and 1.9 driver revisions with similar results. The > > NVM version is 5.05. The card is in a confirmed 8x slot on a SuperMicro > > X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. After > > upping the interrupt threshold to 9000 dmesg doesn't log anything unusual. > > > > We have added the tunes that are standard for 10 Gbps configurations. > > > > On a single-client basis the fastest rates we see are around 5 Gbps. > > Hitting this server from multiple boxes we see peaks of 20 Gbps at the very > > highest. More frequently things top off around 13 Gbps. These numbers are > > coming from iperf tests. We are seeing similar numbers with direct > > point-to-point as well as switched topologies. > > > > These threads from 2015 describe similar issues but fizzled out: > > https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html > > https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html > > > > Is there very particular tuning required to get these cards working at > > proper speed? Any insights? > > > > >From Googling around it appears frustration with this card and FreeBSD is > > pretty common. > > > > Thanks in advance. > > > > Christian > > I can't deliver any special insights but we had many problems with X710 > (without L) and Linux. > Did some testing a while ago with OPNsense (based on 11.1) and got line > rate with iperf and single client. > ixl0 in and ixl1 out. So this should be fine. If you like I can send you > the sysctl values to compare. I would be interested in your sysctl values. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Mar 28 17:15:21 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3530AF6D038 for ; Wed, 28 Mar 2018 17:15:21 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 AE0B67838F for ; Wed, 28 Mar 2018 17:15:20 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id DBEF35A9F17; Wed, 28 Mar 2018 17:15:19 +0000 (UTC) Date: Wed, 28 Mar 2018 17:15:19 +0000 From: Brooks Davis To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Subject: Re: removal of token-ring infrastructure coming soon Message-ID: <20180328171519.GE88362@spindle.one-eyed-alien.net> References: <20180328160353.GC88362@spindle.one-eyed-alien.net> <201803281616.w2SGGNJb057759@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline In-Reply-To: <201803281616.w2SGGNJb057759@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 17:15:21 -0000 --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2018 at 09:16:23AM -0700, Rodney W. Grimes wrote: > > On Tue, Mar 27, 2018 at 04:56:32PM -0700, Rodney W. Grimes wrote: > > > > I have posted a revision which removes support for token-ring netwo= rking > > > > from the tree. There have been no such devices for some time. > > > >=20 > > > > https://reviews.freebsd.org/D14875 > > > >=20 > > >=20 > > > Arcnet coming soon? > > > and probably FDDI? > >=20 > > That's my plan. I started with token ring as it doesn't even have > > drivers (Arcnet and FDDI have one driver each, but ISA and 32-bit PCI > > respectively AFACT). >=20 > I fully support that arcnet and FDDI are dead. >=20 >=20 > Please be a bit carefull with what your calling "32 bit PCI" as > those are also often embedded devices in chipsets that may not > have cards avaliable, but are infact built in to systems. I absolutely agree. In this case it's indicative of the fact that this "high-performance" interface didn't get new silicon since the fastest bus it ever ran on was was 32-bit PCI. It's only one of several indicators. > Also I have become aware that axing the bt946 support may not > be a real good idea, as that is/was a common hypervisor emulation > device and just recently found myself using it in to access > a disk that was created with a scsi controller that had odd > translation and the ata layer would not do the right thing > for me. (32 sector, 64 head, which is not really odd for > scsi, thats common translation for many scsi cards). >=20 > I ended up using vmware with a bt946 emulation on scsi with > the drive image attached to it, and booted FreeBSD from an > ahci attached disk. If the bt946 drive was missing from=20 > 11.1 I would of been stuck. >=20 > As far as I am aware both vmware and virtualbox have support > for bt946 emulation, which is also a superset of aha154x. One of the problems we have in the project is that we don't have a way to track how popular devices are and what sort of applications they ended up in. It would be nice if we could find a way to collect information including: Busses: ISA, PCI, PCI-X, PCIe Form factors: ISA, PCMCIA, CardBus, PCI, PCI-X, PCIe, embedded[0], emulated Last ship or product announcement date: Ship volume: FreeBSD users with meaningful deployments: [0] Deployments at scale, not just parts available. I don't know how we'd got about collecting this information, but it would be good to find a way to croudsource it. The cost of maintaining each individual device isn't usually all that high, but it's really frustrating to spend the majority of time on an infrastructure change fixing issues in devices that shouldn't have survived the last release branch (or the one before that). Devices or technologies that failed in the market are the worst because they tend to have drivers with cargo-cult copy-and-paste from the wrong example that never gets fixed. -- Brooks --UfEAyuTBtIjiZzX6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJau82nAAoJEKzQXbSebgfAancH/1Cl8SZWGHA0IAQXhjEMqJCs MH748Iw9TUMuPcdBvpCo+buyKMX1kAFqLcP49ZEV1VmqyStzPV/K2Ta7E/yGHa3u K4T6nS9r5J5M0LOlQROSexkQYSRAZaiOQs+w6DZYDypz29zzVWhjzrYukJvMKHeI 3Jnnq4m4gQHldT1Pr9LKwNj4LneOsZnmhB7ngSCVE+SmTNBEs//S5uINC78MmlnV QMRpJ2V54524ky7xsc0+T4yrwok/65RPCklfldyrqIdGqway/FeaPqGbWspwJ/b1 7cuMekean5iyojjHkf+CQgBcyhImRidNfVxeIrMZMoGSBZmqc+ERZYsSE7CESxU= =g7Zp -----END PGP SIGNATURE----- --UfEAyuTBtIjiZzX6-- From owner-freebsd-net@freebsd.org Wed Mar 28 22:20:46 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9824F4E5AE for ; Wed, 28 Mar 2018 22:20:46 +0000 (UTC) (envelope-from christian.baltini@gmail.com) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 5102F85F88 for ; Wed, 28 Mar 2018 22:20:46 +0000 (UTC) (envelope-from christian.baltini@gmail.com) Received: by mail-pf0-x22c.google.com with SMTP id h69so1787113pfe.13 for ; Wed, 28 Mar 2018 15:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/3P4Q2T1dYUhZZiKEVUR1Dzfy5InYmJUAXdRynpzx98=; b=KfBKSUmEN7CRVGYvDtSy/Zfqxa6CHk4lxjys7rwqRP3zjPsFcoHVJezjtSGLQFRplb XP+6lyBiTHLWwc1AeZCJSUiTXhVpoyCdZ3oWozqRvHghxroDCT7dKVXX4+FFNUr9NguA dgA7jrt+IIKtfks12OFDi0CZX1bbOHJ2G+/Xu1jkBmYApcW4zrREtBm/PEyLnTwqxeYm xW8a5ZmrQUbAV3cc1/N7++D1TxB5Gb6uCe4cl2xEoHolR6elUsYJjCqOGoihhhCwwCyP kp55zMWz+wac7oo9LYk2coAEzq8eVJj+jhy9oTk/JwiaRjR54HnZim4h5ZiBnGVoV1cw jlXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/3P4Q2T1dYUhZZiKEVUR1Dzfy5InYmJUAXdRynpzx98=; b=SySLFN6o1N+Sbtagi2n7xcYz+ZNDxPod5p3Qp9J3EvDyh6ttUEJ208zPH5VFO74ffj SCJmkn+8WoBsEdjNc7q8wCEm0olblthKAAEElTtaTmBI72UOMdPdA6i0YIgDUk4l4JO9 zWq89kemM28jUtlenmBXgRlqMewWJ5rMIyLfeQEHMoPPIHBpXkgEJHdppcfo3IshNrTA X8gJWDz7mYljYmFc+cDI7+xstvkZSqkxvQ/huhQe+lXjW2mdzaeZGpkHIfw0xHUosOUZ ZtEfVmEJWH1FYhId9ngy3Tzr1Ck0/zAhfn4+ZGhWbJk6E4Qbl2A+UzD8ZOTdxyfelzQ4 w8Yw== X-Gm-Message-State: AElRT7H7QVIWs/3XOdueUfuoTaV/ejJeUWgKAajXeuoLzdHNHeTOCtS7 TbeHDmTlsgC6ddS3Fi8GVNh+LISy X-Google-Smtp-Source: AIpwx480CyaQaCEtSu6m64ejJZ4lh8cjzpKIh+Dnx1BH4vKq56tpjs4aCMZZRh0xYYDV2QP8LAA2vw== X-Received: by 2002:a17:902:f24:: with SMTP id 33-v6mr5547168ply.242.1522275645250; Wed, 28 Mar 2018 15:20:45 -0700 (PDT) Received: from [192.168.174.139] (itsupportguys.net. [108.60.33.242]) by smtp.gmail.com with ESMTPSA id r76sm10527677pfl.24.2018.03.28.15.20.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 15:20:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Current state of Intel XL710 40G NIC ixl performance From: christian russell X-Mailer: iPhone Mail (15C202) In-Reply-To: <201803281638.w2SGcWNp057893@pdx.rh.CN85.dnsmgr.net> Date: Wed, 28 Mar 2018 15:20:43 -0700 Cc: "Muenz, Michael" , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6794C8E9-4136-441D-9C48-D0EA7938F566@gmail.com> References: <201803281638.w2SGcWNp057893@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 22:20:47 -0000 As would I.=20 Christian=20 On Mar 28, 2018, at 9:38 AM, Rodney W. Grimes wrote: >>> Am 28.03.2018 um 06:11 schrieb christian russell: >>> I am having trouble getting an Intel XL710-DA2 NIC to get even close to >>> line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 (Free= NAS >>> in particular). >>>=20 >>> We have tried both 1.7 and 1.9 driver revisions with similar results. T= he >>> NVM version is 5.05. The card is in a confirmed 8x slot on a SuperMicro= >>> X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. After >>> upping the interrupt threshold to 9000 dmesg doesn't log anything unusua= l. >>>=20 >>> We have added the tunes that are standard for 10 Gbps configurations. >>>=20 >>> On a single-client basis the fastest rates we see are around 5 Gbps. >>> Hitting this server from multiple boxes we see peaks of 20 Gbps at the v= ery >>> highest. More frequently things top off around 13 Gbps. These numbers a= re >>> coming from iperf tests. We are seeing similar numbers with direct >>> point-to-point as well as switched topologies. >>>=20 >>> These threads from 2015 describe similar issues but fizzled out: >>> https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html >>> https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html= >>>=20 >>> Is there very particular tuning required to get these cards working at >>> proper speed? Any insights? >>>=20 >>>> =46rom Googling around it appears frustration with this card and FreeBS= D is >>> pretty common. >>>=20 >>> Thanks in advance. >>>=20 >>> Christian >>=20 >> I can't deliver any special insights but we had many problems with X710=20= >> (without L) and Linux. >> Did some testing a while ago with OPNsense (based on 11.1) and got line=20= >> rate with iperf and single client. >> ixl0 in and ixl1 out. So this should be fine. If you like I can send you=20= >> the sysctl values to compare. >=20 > I would be interested in your sysctl values. >=20 > --=20 > Rod Grimes rgrimes@freebsd= .org > _______________________________________________ > 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 Wed Mar 28 22:41:47 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01F5FF50126 for ; Wed, 28 Mar 2018 22:41:47 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93AF386E9F for ; Wed, 28 Mar 2018 22:41:46 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ot0-x230.google.com with SMTP id v64-v6so4422478otb.13 for ; Wed, 28 Mar 2018 15:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L/kcyPykq/UMnG2xbulDf5ObqbKGAn85Jhr+aV9DESQ=; b=blHrzkhaGh8j0SCE+O/jR1LOPqADbO/bNpumHohRO7ArQOPNfQlpkr5g8bC8b9KtHn q5tXbvUlAUcd2BE5bUutCbOZuEpMEQ2M8hdDq1+2hDrH+hHDkBsNnRx6rFgloY8/5uoV 0IwEYpCT6fTqZcnPprEZdcojsPCq9Eiqa2hcYpjUWYCP00gPSdrlr/ZzvZrfuYJi/PSY ql1kimzfkbqugM6eGbtG9kiHElkae/l6VAalf7vEYq5rHY2opO1efTbftBtHtlnil43c qnqxTb/SE9tiqwrWEQ7vTqkdp3FUoWsMNRGcTAvD9v0Wy23FpKoKq9giok0Vi8C0oNop ouwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=L/kcyPykq/UMnG2xbulDf5ObqbKGAn85Jhr+aV9DESQ=; b=RHhwcgxGB4MhWzmD/HJ5VEsUicwTagGRj2OXE6XCZEl3UpDbKJb6lbAilyaHrGhtPg W1MUwiUpt2cs2LVcLWSJIM0tCu4gbkc6Yuf9thaQZlisAlQzlfQMeHpV52up23m3QWuP 9JuBhK5xxOQNLnLjAN94wZtDR/lAiBWm4LzaegaMjYmefpJPPAWieXmHE2JBNBaPyNkF vzZCtgSQOqpKggIW45egMMO4o67Kn9sqc7QWDUUws5MeVuNNU/8HTF4HpGt7lSmi9hab CPODk0aGk4xEOvdk15fdrxwN55602HXasqJSk90LFv6w+WdqNUAAo/uBeNIOSC637cc/ KrFg== X-Gm-Message-State: AElRT7HnoSCChtCwfcE5lLyDM8JkmKKPVRxFEfeuXk8X/r7pRDF3dMGe TINjS7ee/80+fTX6T/8HRy6FQ3KKk70XOLxlruk= X-Google-Smtp-Source: AIpwx4+cJWVjrOp/3BMNJ1Tm1Yel7rXA6YlStJhaXfqt5S9rbQgZSEaPVxNmgB0ZQsrI5CCFaM2scbh85EvJGkvUj/U= X-Received: by 2002:a9d:252b:: with SMTP id k40-v6mr3583613otb.141.1522276905737; Wed, 28 Mar 2018 15:41:45 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 2002:a9d:4782:0:0:0:0:0 with HTTP; Wed, 28 Mar 2018 15:41:45 -0700 (PDT) In-Reply-To: References: From: "K. Macy" Date: Wed, 28 Mar 2018 15:41:45 -0700 X-Google-Sender-Auth: Q7kRBpMBGEFc0-ywtLU1CEdH2fQ Message-ID: Subject: Re: Current state of Intel XL710 40G NIC ixl performance To: christian russell Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Mar 2018 22:41:47 -0000 > On a single-client basis the fastest rates we see are around 5 Gbps. > Hitting this server from multiple boxes we see peaks of 20 Gbps at the very > highest. More frequently things top off around 13 Gbps. These numbers are > coming from iperf tests. We are seeing similar numbers with direct > point-to-point as well as switched topologies. > > These threads from 2015 describe similar issues but fizzled out: > https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html > https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html > > Is there very particular tuning required to get these cards working at > proper speed? Any insights? This is unfortunate. The iflib version of the ixl driver performed quite well under NFLX load several years ago. I even saw 39Gbps single stream with v6. Fortunately, Intel will eventually be pushing the iflib version to HEAD. -M From owner-freebsd-net@freebsd.org Thu Mar 29 01:00:12 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4235FF5C902 for ; Thu, 29 Mar 2018 01:00:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45EA86D257 for ; Thu, 29 Mar 2018 01:00:11 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7243D1CE7B for ; Thu, 29 Mar 2018 01:00:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2T10AJq004782 for ; Thu, 29 Mar 2018 01:00:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2T10AgN004547 for freebsd-net@FreeBSD.org; Thu, 29 Mar 2018 01:00:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Thu, 29 Mar 2018 01:00:05 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jason@tubnor.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@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.25 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, 29 Mar 2018 01:00:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 --- Comment #14 from Jason Tubnor --- Has the Intel driver been upstreamed yet to make the 11.2-RELEASE? re@ have just sent a reminder of the release schedule. If the updated vendor driver works for others here that run their own build service, can it be merged in time for 11.2 for those that follow supported updates? Thanks. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 29 02:09:56 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4D11F65592 for ; Thu, 29 Mar 2018 02:09:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E47C70F85 for ; Thu, 29 Mar 2018 02:09:56 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B5B4A1D80B for ; Thu, 29 Mar 2018 02:09:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2T29tOe099430 for ; Thu, 29 Mar 2018 02:09:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2T29txV099429 for freebsd-net@FreeBSD.org; Thu, 29 Mar 2018 02:09:55 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227058] vxge(4): ioctl implementation reads directly from user memory Date: Thu, 29 Mar 2018 02: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: X-Bugzilla-Severity: Affects Only Me 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.25 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, 29 Mar 2018 02:09:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227058 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 Thu Mar 29 07:01:10 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6698CF537CF for ; Thu, 29 Mar 2018 07:01:10 +0000 (UTC) (envelope-from m.muenz@spam-fetish.org) Received: from mailout-02.maxonline.de (mailout-02.maxonline.de [81.24.66.23]) (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 00A127E3E2 for ; Thu, 29 Mar 2018 07:01:09 +0000 (UTC) (envelope-from m.muenz@spam-fetish.org) Received: from web03-01.max-it.de (web03-01.max-it.de [81.24.64.215]) by mailout-02.maxonline.de (Postfix) with ESMTPS id 5AF912A for ; Thu, 29 Mar 2018 09:01:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by web03-01.max-it.de (Postfix) with ESMTP id 5135628A2F8 for ; Thu, 29 Mar 2018 09:01:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at web03-01.max-it.de Received: from web03-01.max-it.de ([127.0.0.1]) by localhost (web03-01.max-it.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4o6eoYBim9c6 for ; Thu, 29 Mar 2018 09:01:08 +0200 (CEST) Received: from [81.24.66.132] (unknown [81.24.66.132]) (Authenticated sender: m.muenz@spam-fetish.org) by web03-01.max-it.de (Postfix) with ESMTPA id 12A1C28A0BB for ; Thu, 29 Mar 2018 09:01:08 +0200 (CEST) Subject: Re: Current state of Intel XL710 40G NIC ixl performance To: freebsd-net@freebsd.org References: <201803281638.w2SGcWNp057893@pdx.rh.CN85.dnsmgr.net> From: "Muenz, Michael" Message-ID: <3bd4855f-3b5a-5db5-c004-845fd86e8191@spam-fetish.org> Date: Thu, 29 Mar 2018 09:01:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201803281638.w2SGcWNp057893@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Mar 2018 07:01:10 -0000 Am 28.03.2018 um 18:38 schrieb Rodney W. Grimes: >> Am 28.03.2018 um 06:11 schrieb christian russell: >>> I am having trouble getting an Intel XL710-DA2 NIC to get even close to >>> line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 (FreeNAS >>> in particular). >>> >>> We have tried both 1.7 and 1.9 driver revisions with similar results. The >>> NVM version is 5.05. The card is in a confirmed 8x slot on a SuperMicro >>> X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. After >>> upping the interrupt threshold to 9000 dmesg doesn't log anything unusual. >>> >>> We have added the tunes that are standard for 10 Gbps configurations. >>> >>> On a single-client basis the fastest rates we see are around 5 Gbps. >>> Hitting this server from multiple boxes we see peaks of 20 Gbps at the very >>> highest. More frequently things top off around 13 Gbps. These numbers are >>> coming from iperf tests. We are seeing similar numbers with direct >>> point-to-point as well as switched topologies. >>> >>> These threads from 2015 describe similar issues but fizzled out: >>> https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html >>> https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html >>> >>> Is there very particular tuning required to get these cards working at >>> proper speed? Any insights? >>> >>> >From Googling around it appears frustration with this card and FreeBSD is >>> pretty common. >>> >>> Thanks in advance. >>> >>> Christian >> I can't deliver any special insights but we had many problems with X710 >> (without L) and Linux. >> Did some testing a while ago with OPNsense (based on 11.1) and got line >> rate with iperf and single client. >> ixl0 in and ixl1 out. So this should be fine. If you like I can send you >> the sysctl values to compare. > I would be interested in your sysctl values. > Hm, perhaps I misinterpreted your post. I recreated the lab and from the history I saw that it was single client but with 10 streams in parallel. If I reduce to 1 stream I also don't come over the 5,6G. If you're still interested I can send you the output. Michael From owner-freebsd-net@freebsd.org Thu Mar 29 08:26:55 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD62AF5A87D for ; Thu, 29 Mar 2018 08:26:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57F1581430 for ; Thu, 29 Mar 2018 08:26: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8495C20C9E for ; Thu, 29 Mar 2018 08:26:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2T8QsWL009825 for ; Thu, 29 Mar 2018 08:26:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2T8QsBh009824 for freebsd-net@FreeBSD.org; Thu, 29 Mar 2018 08:26:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221317] Netmap issue after ixgbe driver update in r320897 Date: Thu, 29 Mar 2018 08:26:54 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sg@efficientip.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@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.25 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, 29 Mar 2018 08:26:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221317 Sylvain Galliano changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sg@efficientip.com --- Comment #14 from Sylvain Galliano --- I have the same issue after running the following script: #!/bin/sh for i in `seq 1 100`; do echo $i ifconfig ix0 down ifconfig ix0 up done After running it, ix0 interface status is 'no carrier'. I'm running latest 11.1 STABLE (ixgbe 3.2.12-k) Just to be sure it's not related to netmap, I've compiled the kernel with 'nodevice netmap': same issue. Doing same test after reverting ixbge 3.2.12-k to 3.1.13-k, the issue is not there anymore. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 29 10:46:15 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED488F6A026 for ; Thu, 29 Mar 2018 10:46:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8327787056 for ; Thu, 29 Mar 2018 10:46:14 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B53BB21FFE for ; Thu, 29 Mar 2018 10:46:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2TAkDNu056535 for ; Thu, 29 Mar 2018 10:46:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2TAkDQ2056534 for freebsd-net@FreeBSD.org; Thu, 29 Mar 2018 10:46:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Thu, 29 Mar 2018 10:46:13 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jeffrey.e.pieper@intel.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@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.25 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, 29 Mar 2018 10:46:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 Jeff Pieper changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffrey.e.pieper@intel.com --- Comment #15 from Jeff Pieper --- We will have a patch ready for Phabricator soon. It should be committed bef= ore code freeze. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 29 10:46:46 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1A9FF6A0E5 for ; Thu, 29 Mar 2018 10:46:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E170870D9 for ; Thu, 29 Mar 2018 10:46: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8261122017 for ; Thu, 29 Mar 2018 10:46:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2TAkjkL057447 for ; Thu, 29 Mar 2018 10:46:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2TAkjUP057446 for freebsd-net@FreeBSD.org; Thu, 29 Mar 2018 10:46:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Thu, 29 Mar 2018 10:46:44 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jeffrey.e.pieper@intel.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@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.25 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, 29 Mar 2018 10:46:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 --- Comment #16 from Jeff Pieper --- We will have a patch ready for Phabricator soon. It should be committed bef= ore code freeze. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 29 12:04:47 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8E94F705F7 for ; Thu, 29 Mar 2018 12:04:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D0D96A596 for ; Thu, 29 Mar 2018 12:04:47 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8C62F22B0D for ; Thu, 29 Mar 2018 12:04:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2TC4k6x077997 for ; Thu, 29 Mar 2018 12:04:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2TC4kV1077996 for freebsd-net@FreeBSD.org; Thu, 29 Mar 2018 12:04:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221317] Netmap issue after ixgbe driver update in r320897 Date: Thu, 29 Mar 2018 12:04:46 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@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.25 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, 29 Mar 2018 12:04:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221317 --- Comment #15 from Cassiano Peixoto --- (In reply to Sylvain Galliano from comment #14) Hi Sylvain, So it's worse than i thought. But unfortunately seems nobody is willing to = fix it. :( I can't take the risk to update my servers until it has been fixed. Thanks for your test. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 29 12:46:10 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 086DDF73310 for ; Thu, 29 Mar 2018 12:46:10 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FF326BC5A for ; Thu, 29 Mar 2018 12:46:09 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2TCk6iQ062960; Thu, 29 Mar 2018 05:46:06 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2TCk67R062959; Thu, 29 Mar 2018 05:46:06 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803291246.w2TCk67R062959@pdx.rh.CN85.dnsmgr.net> Subject: Re: Current state of Intel XL710 40G NIC ixl performance In-Reply-To: <3bd4855f-3b5a-5db5-c004-845fd86e8191@spam-fetish.org> To: "Muenz, Michael" Date: Thu, 29 Mar 2018 05:46:06 -0700 (PDT) CC: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Mar 2018 12:46:10 -0000 > Am 28.03.2018 um 18:38 schrieb Rodney W. Grimes: > >> Am 28.03.2018 um 06:11 schrieb christian russell: > >>> I am having trouble getting an Intel XL710-DA2 NIC to get even close to > >>> line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 (FreeNAS > >>> in particular). > >>> > >>> We have tried both 1.7 and 1.9 driver revisions with similar results. The > >>> NVM version is 5.05. The card is in a confirmed 8x slot on a SuperMicro > >>> X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. After > >>> upping the interrupt threshold to 9000 dmesg doesn't log anything unusual. > >>> > >>> We have added the tunes that are standard for 10 Gbps configurations. > >>> > >>> On a single-client basis the fastest rates we see are around 5 Gbps. > >>> Hitting this server from multiple boxes we see peaks of 20 Gbps at the very > >>> highest. More frequently things top off around 13 Gbps. These numbers are > >>> coming from iperf tests. We are seeing similar numbers with direct > >>> point-to-point as well as switched topologies. > >>> > >>> These threads from 2015 describe similar issues but fizzled out: > >>> https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html > >>> https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html > >>> > >>> Is there very particular tuning required to get these cards working at > >>> proper speed? Any insights? > >>> > >>> >From Googling around it appears frustration with this card and FreeBSD is > >>> pretty common. > >>> > >>> Thanks in advance. > >>> > >>> Christian > >> I can't deliver any special insights but we had many problems with X710 > >> (without L) and Linux. > >> Did some testing a while ago with OPNsense (based on 11.1) and got line > >> rate with iperf and single client. > >> ixl0 in and ixl1 out. So this should be fine. If you like I can send you > >> the sysctl values to compare. > > I would be interested in your sysctl values. > > > > Hm, perhaps I misinterpreted your post. I recreated the lab and from the > history I saw > that it was single client but with 10 streams in parallel. If I reduce > to 1 stream I also > don't come over the 5,6G. > > If you're still interested I can send you the output. We specifically are interested in the sysctl settings you used to obtain a "line rate" results using ixl0 in and ixl1 out, it does not matter if that was 1 stream or 10 stream, we would just like to see what values you found to work well for you to compare to what values others may be using/suggesting. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Thu Mar 29 12:49:05 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9B87F735D5 for ; Thu, 29 Mar 2018 12:49:05 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 447426BEAD for ; Thu, 29 Mar 2018 12:49:05 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: by mail-pg0-x22f.google.com with SMTP id n11so2985942pgp.4 for ; Thu, 29 Mar 2018 05:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=vHCIZqrs/p9LfBZ7qE4cj4u9ZwfwNDbgZSYZeT5pe4c=; b=oYeFF3GmvKyfPWeQncqYp4BECGj2n5cAkv5pAaRpciXVbaiib3hkwe8Pu5yVw/WXmp JmA7nAdW6awuYndVrAVC+LIMKAyUigs4nruvsTpiIyk3rVQ+F/Dty2OAERiwnka1Zij4 OMBVVjd5UktuK4KG25ofSTnu+9ttni6ozHIt9D6RcykE4AODrVYY4F6JgPpuTY9kcIMR 6rmSJl9TmuTsBqNJVqbwHZYp3RdDCOw4UunwRxRU+hPHIIsYjXwapEXDfzvmJjdiXZwc Jipd03zzTQLK7MivZ7FTGYyhhrpCVFGeW9nDhKjjITRIlABXmW62IXnBOyjgS5i5OyIB 9Itg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=vHCIZqrs/p9LfBZ7qE4cj4u9ZwfwNDbgZSYZeT5pe4c=; b=OdTGu3YOrdaU2Tx+thx7b+r9XM0InmBgNQA7GQuYDMVhhgltFEy8qBTDRUKoMpnNAB e89TP6b5V5O+loe6zDbV14fNchkx3h2M3tIYDGwoctMhWakyGcoDMUXKV+k9taQvHVyR Gi7nfDdHSpGb9BCbKZ6Ee3GagJbbhMs87UWGTLJbQtFipMXsz32nu3bPEkd1LFoA1HFH 9CxZhNS0n5cIRBzXXgvyNywUg/FLyGhOptcSN4dlFXxrj0iblqiD8jk3xI9vZEJ6ZoQl OzrwwukGsHM6km+2cmtXFCRnsxAd0RuTMGtx8p5RmuzNnKYLwSmPnf+MkJoLiAwSUcW8 YcWg== X-Gm-Message-State: AElRT7GBj6PkQ4LeWJNpek/8t4sfUJIDmwrxzJmXuublaPOD7a7KjPbH yfFt47RSenh9lkrQykw61KGr2KXnG9fnPg== X-Google-Smtp-Source: AIpwx4+IhBaJvJEF8UKRItyDHjjpYKya2aW1NFdl4yrbCnTjf18Hxk01+mW1RWYOEJ5uaweu2sf0Bw== X-Received: by 10.99.155.2 with SMTP id r2mr5549426pgd.450.1522327744323; Thu, 29 Mar 2018 05:49:04 -0700 (PDT) Received: from [10.190.139.106] ([42.106.196.181]) by smtp.gmail.com with ESMTPSA id a5sm14276117pfl.159.2018.03.29.05.49.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 05:49:03 -0700 (PDT) Date: Thu, 29 Mar 2018 18:18:58 +0530 User-Agent: K-9 Mail for Android In-Reply-To: <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> MIME-Version: 1.0 Subject: Re: [vnet] [epair] epair interface stops working after some time To: Kristof Provost CC: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Reshad Patuck From: Reshad Patuck Message-ID: <97945712-B53E-4CF6-B20E-6001CF40CDFC@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Mar 2018 12:49:06 -0000 =E2=80=8B Hi, pulling the 'net=2Elink=2Eepair=2Enetisr_maxqlen' down does seem to make t= his occur faster=2E =E2=80=8B When I dropped it to 2 like Kristof did and I have the same symptoms on a = box which was not exhibiting the problems manually began to have the same s= ymptoms=2E Bumping it back up to 2100 did not restore the functionality (I don't know= if it should)=2E =E2=80=8B I will create a PR for this later today with all the information I have ga= thered so that we can have it all in one place=2E Till then I have still have access to a box which is naturally in this sta= te=2E Let me know if there is anything you would like me to check =E2=80=8B Thanks for the help, =E2=80=8B Reshad On 28 March 2018 12:32:44 AM IST, Kristof Provost w= rote: >On 27 Mar 2018, at 20:59, Reshad Patuck wrote: >> The current value of 'net=2Elink=2Eepair=2Enetisr_maxqlen' is 2100, I w= ill=20 >> make it 210=2E >> Will this require a reboot? or can I just change the sysctl and >reload=20 >> the epair module? >> =E2=80=8B >You shouldn=E2=80=99t need to reboot or reload the epair module=2E When I= set it=20 >to 2 on my box it pretty much immediately lost connectivity over the=20 >epair interfaces=2E > >I=E2=80=99d expect you to get hit by the bug relatively quickly now, so b= e=20 >aware of that=2E > >Regards, >Kristof From owner-freebsd-net@freebsd.org Thu Mar 29 13:09:17 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46EE4F74B9E for ; Thu, 29 Mar 2018 13:09:17 +0000 (UTC) (envelope-from srs0=hify=gt=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C98EA6CD8A for ; Thu, 29 Mar 2018 13:09:16 +0000 (UTC) (envelope-from srs0=hify=gt=sigsegv.be=kristof@codepro.be) Received: from [10.0.2.164] (ptr-8ripyygcwkmr6opr7m9.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:80e7:f88b:9064:9851]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 264065B28C; Thu, 29 Mar 2018 15:09:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1522328955; bh=+DDtsIhLyMF0eNpfMyJTUq9ZpqNHUvLqeJiIpr3N4n8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=M/zeFpo42YIhN/RVk53BYqQwB0bc5wIGQ3QC+Y10k26G9Vs9ZjiOX9qt2z5Wb0eGt SMcPOL362DPwIrlrGwTV5oDe9WS62fZA3/3EsSzZl2VsEZLBUdDbHO1LM9VygAIWTQ tcMBZ9aXcdZSfEOMPPN4lVhmleY/TSJynQEK6Smw= From: "Kristof Provost" To: "Reshad Patuck" Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , "Reshad Patuck" Subject: Re: [vnet] [epair] epair interface stops working after some time Date: Thu, 29 Mar 2018 15:09:13 +0200 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <10647168-66DF-48CD-9121-9CC2B00848D4@sigsegv.be> In-Reply-To: <97945712-B53E-4CF6-B20E-6001CF40CDFC@gmail.com> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> <97945712-B53E-4CF6-B20E-6001CF40CDFC@gmail.com> 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.25 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, 29 Mar 2018 13:09:17 -0000 On 29 Mar 2018, at 14:48, Reshad Patuck wrote: > pulling the 'net.link.epair.netisr_maxqlen' down does seem to make > this occur faster. > ​ Good, I think my hypothesis about where the issue lies is correct then. You should be able to avoid (or at least reduce the frequency of) the issue by increasing the value on your system(s). > When I dropped it to 2 like Kristof did and I have the same symptoms > on a box which was not exhibiting the problems manually began to have > the same symptoms. > Bumping it back up to 2100 did not restore the functionality (I don't > know if it should). > ​ It’s good to know this. It doesn’t surprise me that it doesn’t fix things. Something’s wrong in the code which handle an overflow of the netisr queue in the epair driver. Once that happens the IFF_DRV_OACTIVE flag gets set, and we keep enqueuing outside the netisr queue. Somehow we never end up back in epair_nh_drainedcpu(), so the flag never gets cleared and the driver never recovers. > I will create a PR for this later today with all the information I > have gathered so that we can have it all in one place. > Thanks. Please cc me on it. I’ll see if I can figure out what the problem is, but we might need someone smarter, so cc Bjoern too. Regards, Kristof From owner-freebsd-net@freebsd.org Thu Mar 29 13:14:37 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17F82F75445 for ; Thu, 29 Mar 2018 13:14:37 +0000 (UTC) (envelope-from m.muenz@spam-fetish.org) Received: from mailout-02.maxonline.de (mailout-02.maxonline.de [81.24.66.23]) (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 9E6056D5C2 for ; Thu, 29 Mar 2018 13:14:36 +0000 (UTC) (envelope-from m.muenz@spam-fetish.org) Received: from web03-01.max-it.de (web03-01.max-it.de [81.24.64.215]) by mailout-02.maxonline.de (Postfix) with ESMTPS id 513E519; Thu, 29 Mar 2018 15:14:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by web03-01.max-it.de (Postfix) with ESMTP id 3F38A28A361; Thu, 29 Mar 2018 15:14:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at web03-01.max-it.de Received: from web03-01.max-it.de ([127.0.0.1]) by localhost (web03-01.max-it.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3FavkZLNx6df; Thu, 29 Mar 2018 15:14:32 +0200 (CEST) Received: from [81.24.66.132] (unknown [81.24.66.132]) (Authenticated sender: m.muenz@spam-fetish.org) by web03-01.max-it.de (Postfix) with ESMTPA id A2FFC28A2F8; Thu, 29 Mar 2018 15:14:32 +0200 (CEST) Subject: Re: Current state of Intel XL710 40G NIC ixl performance To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org References: <201803291246.w2TCk67R062959@pdx.rh.CN85.dnsmgr.net> From: "Muenz, Michael" Message-ID: <39f44655-4d92-8b95-3819-527de665d391@spam-fetish.org> Date: Thu, 29 Mar 2018 15:14:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201803291246.w2TCk67R062959@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Mar 2018 13:14:37 -0000 Am 29.03.2018 um 14:46 schrieb Rodney W. Grimes: >> Am 28.03.2018 um 18:38 schrieb Rodney W. Grimes: >>>> Am 28.03.2018 um 06:11 schrieb christian russell: >>>>> I am having trouble getting an Intel XL710-DA2 NIC to get even clos= e to >>>>> line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 = (FreeNAS >>>>> in particular). >>>>> >>>>> We have tried both 1.7 and 1.9 driver revisions with similar result= s. The >>>>> NVM version is 5.05. The card is in a confirmed 8x slot on a Super= Micro >>>>> X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. Aft= er >>>>> upping the interrupt threshold to 9000 dmesg doesn't log anything u= nusual. >>>>> >>>>> We have added the tunes that are standard for 10 Gbps configuration= s. >>>>> >>>>> On a single-client basis the fastest rates we see are around 5 Gbps= . >>>>> Hitting this server from multiple boxes we see peaks of 20 Gbps at = the very >>>>> highest. More frequently things top off around 13 Gbps. These num= bers are >>>>> coming from iperf tests. We are seeing similar numbers with direct >>>>> point-to-point as well as switched topologies. >>>>> >>>>> These threads from 2015 describe similar issues but fizzled out: >>>>> https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.htm= l >>>>> https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584= .html >>>>> >>>>> Is there very particular tuning required to get these cards working= at >>>>> proper speed? Any insights? >>>>> >>>>> >From Googling around it appears frustration with this card and Fre= eBSD is >>>>> pretty common. >>>>> >>>>> Thanks in advance. >>>>> >>>>> Christian >>>> I can't deliver any special insights but we had many problems with X= 710 >>>> (without L) and Linux. >>>> Did some testing a while ago with OPNsense (based on 11.1) and got l= ine >>>> rate with iperf and single client. >>>> ixl0 in and ixl1 out. So this should be fine. If you like I can send= you >>>> the sysctl values to compare. >>> I would be interested in your sysctl values. >>> >> Hm, perhaps I misinterpreted your post. I recreated the lab and from t= he >> history I saw >> that it was single client but with 10 streams in parallel. If I reduce >> to 1 stream I also >> don't come over the 5,6G. >> >> If you're still interested I can send you the output. > We specifically are interested in the sysctl settings you used > to obtain a "line rate" results using ixl0 in and ixl1 out, > it does not matter if that was 1 stream or 10 stream, we would > just like to see what values you found to work well for you > to compare to what values others may be using/suggesting. > Sure! I just did a test and it's 9,6GBit with 10 streams. The layout is: UBUNTU-A --- 10G DA --- OPN-A --- 10G DA --- OPN-B --- 10G DA --- UBUNTU-= B All system quite acutal, enough RAM and all with X710. This is one of the firewalls (all values are default by OPNsense, no=20 special tuning from my side): root@OPNsense:~ # dmesg | grep Xeon CPU: Intel(R) Xeon(R) CPU E3-1270 v5 @ 3.60GHz (3600.18-MHz K8-class CPU root@OPNsense:~ # ifconfig -vvvvvv ixl0 ixl0: flags=3D8843 metric 0 mtu 1= 500 options=3D6400b8 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ether 3c:fd:fe:9e:e7:48 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hwaddr 3c:fd:fe:9e:e7:48 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet 10.55.1.1 netmask 0xffff= ff00 broadcast 10.55.1.255 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet6 fe80::3efd:feff:fe9e:e7= 48%ixl0 prefixlen 64 scopeid 0x1 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 nd6 options=3D21 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 media: Ethernet autoselect (1= 0Gbase-Twinax ) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status: active =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 plugged: SFP/SFP+/SFP28 Unkno= wn (Copper pigtail) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vendor: CISCO-LOROM PN: LRHSP= B54D020 SN: LRM2014626G DATE:=20 2016-04-15 Class: (null) Length: (null) Tech: Passive Cable Media: (null) Speed: (null) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SFF8472 DUMP (0xA0 0..127 ran= ge): =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 03 04 21 00 00 00 00 00 04 00= 00 00 67 00 00 00 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00 00 02 00 43 49 53 43 4F 2D= 4C 4F 52 4F 4D 20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 20 20 20 20 00 FC 2E 2D 4C 52= 48 53 50 42 35 34 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 44 30 32 30 20 20 20 20 42 32= 20 20 01 00 00 F2 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00 00 00 00 4C 52 4D 32 30 31= 34 36 32 36 47 20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 20 20 20 20 31 36 30 34 31 35= 20 20 00 00 00 A8 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00 00 00 00 00 00 00 00 00 00= 00 00 00 00 00 00 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00 00 00 00 00 00 00 00 00 00= 00 00 E9 77 70 80 root@OPNsense:~ # dmesg | grep ixl ixl0: mem 0xdd000000-0xdd7fffff,0xdd808000-0xdd80ffff irq 16 at=20 device 0.0 on pci1 ixl0: Using MSIX interrupts with 9 vectors ixl0: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem 1.262.0 ixl0: PF-ID[0]: VFs 64, MSIX 129, VF MSIX 5, QPs 768, I2C ixl0: Allocating 8 queues for PF LAN VSI; 8 queues active ixl0: Ethernet address: 3c:fd:fe:9e:e7:48 ixl0: PCI Express Bus: Speed 8.0GT/s Width x8 ixl0: SR-IOV ready ixl0: netmap queues/slots: TX 8/1024, RX 8/1024 ixl1: mem 0xdc800000-0xdcffffff,0xdd800000-0xdd807fff irq 16 at=20 device 0.1 on pci1 ixl1: Using MSIX interrupts with 9 vectors ixl1: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem 1.262.0 ixl1: PF-ID[1]: VFs 64, MSIX 129, VF MSIX 5, QPs 768, I2C ixl1: Allocating 8 queues for PF LAN VSI; 8 queues active ixl1: Ethernet address: 3c:fd:fe:9e:e7:49 ixl1: PCI Express Bus: Speed 8.0GT/s Width x8 ixl1: SR-IOV ready ixl1: netmap queues/slots: TX 8/1024, RX 8/1024 ixl0: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow=20 Control: None ixl0: link state changed to UP ixl1: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow=20 Control: None ixl1: link state changed to UP ixl1: TSO4 requires txcsum, disabling both... ixl0: TSO4 requires txcsum, disabling both... root@OPNsense:~ # sysctl -a | grep ixl device=C2=A0 ixl device=C2=A0 ixlv hw.ixlv.tx_itr: 122 hw.ixlv.rx_itr: 62 hw.ixlv.dynamic_tx_itr: 0 hw.ixlv.dynamic_rx_itr: 0 hw.ixlv.txbr_size: 4096 hw.ixlv.max_queues: 0 hw.ixlv.ring_size: 1024 hw.ixl.tx_itr: 122 hw.ixl.rx_itr: 62 hw.ixl.dynamic_tx_itr: 1 hw.ixl.dynamic_rx_itr: 1 hw.ixl.shared_debug_mask: 0 hw.ixl.core_debug_mask: 0 hw.ixl.enable_tx_fc_filter: 1 hw.ixl.max_queues: 0 hw.ixl.ring_size: 1024 hw.ixl.enable_msix: 1 dev.ixl.1.mac.xoff_recvd: 0 dev.ixl.1.mac.xoff_txd: 0 dev.ixl.1.mac.xon_recvd: 0 dev.ixl.1.mac.xon_txd: 0 dev.ixl.1.mac.tx_frames_big: 0 dev.ixl.1.mac.tx_frames_1024_1522: 126575 dev.ixl.1.mac.tx_frames_512_1023: 53 dev.ixl.1.mac.tx_frames_256_511: 18 dev.ixl.1.mac.tx_frames_128_255: 6273 dev.ixl.1.mac.tx_frames_65_127: 3479052 dev.ixl.1.mac.tx_frames_64: 3015 dev.ixl.1.mac.checksum_errors: 0 dev.ixl.1.mac.rx_jabber: 0 dev.ixl.1.mac.rx_oversized: 0 dev.ixl.1.mac.rx_fragmented: 0 dev.ixl.1.mac.rx_undersize: 0 dev.ixl.1.mac.rx_frames_big: 0 dev.ixl.1.mac.rx_frames_1024_1522: 118340403 dev.ixl.1.mac.rx_frames_512_1023: 2602 dev.ixl.1.mac.rx_frames_256_511: 2588 dev.ixl.1.mac.rx_frames_128_255: 197724 dev.ixl.1.mac.rx_frames_65_127: 101859 dev.ixl.1.mac.rx_frames_64: 2444 dev.ixl.1.mac.rx_length_errors: 0 dev.ixl.1.mac.remote_faults: 0 dev.ixl.1.mac.local_faults: 0 dev.ixl.1.mac.illegal_bytes: 0 dev.ixl.1.mac.crc_errors: 0 dev.ixl.1.mac.bcast_pkts_txd: 581 dev.ixl.1.mac.mcast_pkts_txd: 40987 dev.ixl.1.mac.ucast_pkts_txd: 3573418 dev.ixl.1.mac.good_octets_txd: 437663656 dev.ixl.1.mac.rx_discards: 0 dev.ixl.1.mac.bcast_pkts_rcvd: 0 dev.ixl.1.mac.mcast_pkts_rcvd: 40983 dev.ixl.1.mac.ucast_pkts_rcvd: 118606637 dev.ixl.1.mac.good_octets_rcvd: 179682149054 dev.ixl.1.pf.que7.tx_itr: 5 dev.ixl.1.pf.que7.rx_itr: 13 dev.ixl.1.pf.que7.rx_desc_err: 0 dev.ixl.1.pf.que7.rx_bytes: 15900612562 dev.ixl.1.pf.que7.rx_packets: 10528967 dev.ixl.1.pf.que7.tx_bytes: 24253209 dev.ixl.1.pf.que7.tx_packets: 367274 dev.ixl.1.pf.que7.no_desc_avail: 0 dev.ixl.1.pf.que7.mss_too_small: 0 dev.ixl.1.pf.que7.tx_dmamap_failed: 0 dev.ixl.1.pf.que7.tso_tx: 0 dev.ixl.1.pf.que7.irqs: 393466 dev.ixl.1.pf.que7.mbuf_defrag_failed: 0 dev.ixl.1.pf.que6.tx_itr: 5 dev.ixl.1.pf.que6.rx_itr: 26 dev.ixl.1.pf.que6.rx_desc_err: 0 dev.ixl.1.pf.que6.rx_bytes: 31079009581 dev.ixl.1.pf.que6.rx_packets: 20596797 dev.ixl.1.pf.que6.tx_bytes: 34704872 dev.ixl.1.pf.que6.tx_packets: 525307 dev.ixl.1.pf.que6.no_desc_avail: 0 dev.ixl.1.pf.que6.mss_too_small: 0 dev.ixl.1.pf.que6.tx_dmamap_failed: 0 dev.ixl.1.pf.que6.tso_tx: 0 dev.ixl.1.pf.que6.irqs: 253510 dev.ixl.1.pf.que6.mbuf_defrag_failed: 0 dev.ixl.1.pf.que5.tx_itr: 5 dev.ixl.1.pf.que5.rx_itr: 6 dev.ixl.1.pf.que5.rx_desc_err: 0 dev.ixl.1.pf.que5.rx_bytes: 38281535454 dev.ixl.1.pf.que5.rx_packets: 25296558 dev.ixl.1.pf.que5.tx_bytes: 37044422 dev.ixl.1.pf.que5.tx_packets: 560797 dev.ixl.1.pf.que5.no_desc_avail: 0 dev.ixl.1.pf.que5.mss_too_small: 0 dev.ixl.1.pf.que5.tx_dmamap_failed: 0 dev.ixl.1.pf.que5.tso_tx: 0 dev.ixl.1.pf.que5.irqs: 458887 dev.ixl.1.pf.que5.mbuf_defrag_failed: 0 dev.ixl.1.pf.que4.tx_itr: 5 dev.ixl.1.pf.que4.rx_itr: 11 dev.ixl.1.pf.que4.rx_desc_err: 0 dev.ixl.1.pf.que4.rx_bytes: 22679151508 dev.ixl.1.pf.que4.rx_packets: 14988371 dev.ixl.1.pf.que4.tx_bytes: 7275187 dev.ixl.1.pf.que4.tx_packets: 109641 dev.ixl.1.pf.que4.no_desc_avail: 0 dev.ixl.1.pf.que4.mss_too_small: 0 dev.ixl.1.pf.que4.tx_dmamap_failed: 0 dev.ixl.1.pf.que4.tso_tx: 0 dev.ixl.1.pf.que4.irqs: 355733 dev.ixl.1.pf.que4.mbuf_defrag_failed: 0 dev.ixl.1.pf.que3.tx_itr: 5 dev.ixl.1.pf.que3.rx_itr: 6 dev.ixl.1.pf.que3.rx_desc_err: 0 dev.ixl.1.pf.que3.rx_bytes: 16576036845 dev.ixl.1.pf.que3.rx_packets: 10959252 dev.ixl.1.pf.que3.tx_bytes: 43909635 dev.ixl.1.pf.que3.tx_packets: 560494 dev.ixl.1.pf.que3.no_desc_avail: 0 dev.ixl.1.pf.que3.mss_too_small: 0 dev.ixl.1.pf.que3.tx_dmamap_failed: 0 dev.ixl.1.pf.que3.tso_tx: 0 dev.ixl.1.pf.que3.irqs: 553422 dev.ixl.1.pf.que3.mbuf_defrag_failed: 0 dev.ixl.1.pf.que2.tx_itr: 5 dev.ixl.1.pf.que2.rx_itr: 11 dev.ixl.1.pf.que2.rx_desc_err: 0 dev.ixl.1.pf.que2.rx_bytes: 7991532119 dev.ixl.1.pf.que2.rx_packets: 5290976 dev.ixl.1.pf.que2.tx_bytes: 34801015 dev.ixl.1.pf.que2.tx_packets: 523256 dev.ixl.1.pf.que2.no_desc_avail: 0 dev.ixl.1.pf.que2.mss_too_small: 0 dev.ixl.1.pf.que2.tx_dmamap_failed: 0 dev.ixl.1.pf.que2.tso_tx: 0 dev.ixl.1.pf.que2.irqs: 545889 dev.ixl.1.pf.que2.mbuf_defrag_failed: 0 dev.ixl.1.pf.que1.tx_itr: 5 dev.ixl.1.pf.que1.rx_itr: 17 dev.ixl.1.pf.que1.rx_desc_err: 0 dev.ixl.1.pf.que1.rx_bytes: 32728556836 dev.ixl.1.pf.que1.rx_packets: 21667708 dev.ixl.1.pf.que1.tx_bytes: 146990694 dev.ixl.1.pf.que1.tx_packets: 394694 dev.ixl.1.pf.que1.no_desc_avail: 0 dev.ixl.1.pf.que1.mss_too_small: 0 dev.ixl.1.pf.que1.tx_dmamap_failed: 0 dev.ixl.1.pf.que1.tso_tx: 0 dev.ixl.1.pf.que1.irqs: 447694 dev.ixl.1.pf.que1.mbuf_defrag_failed: 0 dev.ixl.1.pf.que0.tx_itr: 5 dev.ixl.1.pf.que0.rx_itr: 5 dev.ixl.1.pf.que0.rx_desc_err: 0 dev.ixl.1.pf.que0.rx_bytes: 13965229080 dev.ixl.1.pf.que0.rx_packets: 9266714 dev.ixl.1.pf.que0.tx_bytes: 89709749 dev.ixl.1.pf.que0.tx_packets: 522887 dev.ixl.1.pf.que0.no_desc_avail: 0 dev.ixl.1.pf.que0.mss_too_small: 0 dev.ixl.1.pf.que0.tx_dmamap_failed: 0 dev.ixl.1.pf.que0.tso_tx: 0 dev.ixl.1.pf.que0.irqs: 385910 dev.ixl.1.pf.que0.mbuf_defrag_failed: 0 dev.ixl.1.pf.bcast_pkts_txd: 6 dev.ixl.1.pf.mcast_pkts_txd: 1 dev.ixl.1.pf.ucast_pkts_txd: 3480756 dev.ixl.1.pf.good_octets_txd: 292275083 dev.ixl.1.pf.rx_discards: 1158 dev.ixl.1.pf.bcast_pkts_rcvd: 0 dev.ixl.1.pf.mcast_pkts_rcvd: 0 dev.ixl.1.pf.ucast_pkts_rcvd: 118562908 dev.ixl.1.pf.good_octets_rcvd: 179675335351 dev.ixl.1.admin_irq: 0 dev.ixl.1.watchdog_events: 0 dev.ixl.1.dynamic_tx_itr: 1 dev.ixl.1.dynamic_rx_itr: 1 dev.ixl.1.rx_itr: 62 dev.ixl.1.tx_itr: 122 dev.ixl.1.unallocated_queues: 760 dev.ixl.1.fw_version: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem=20 1.262.0 dev.ixl.1.current_speed: 10 Gbps dev.ixl.1.advertise_speed: 6 dev.ixl.1.fc: 0 dev.ixl.1.%parent: pci1 dev.ixl.1.%pnpinfo: vendor=3D0x8086 device=3D0x1572 subvendor=3D0x8086=20 subdevice=3D0x0000 class=3D0x020000 dev.ixl.1.%location: slot=3D0 function=3D1 dbsf=3Dpci0:1:0:1 dev.ixl.1.%driver: ixl dev.ixl.1.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version=20 - 1.7.12-k dev.ixl.0.wake: 0 dev.ixl.0.mac.xoff_recvd: 0 dev.ixl.0.mac.xoff_txd: 0 dev.ixl.0.mac.xon_recvd: 0 dev.ixl.0.mac.xon_txd: 0 dev.ixl.0.mac.tx_frames_big: 0 dev.ixl.0.mac.tx_frames_1024_1522: 118339212 dev.ixl.0.mac.tx_frames_512_1023: 2555 dev.ixl.0.mac.tx_frames_256_511: 2485 dev.ixl.0.mac.tx_frames_128_255: 197213 dev.ixl.0.mac.tx_frames_65_127: 41428 dev.ixl.0.mac.tx_frames_64: 4 dev.ixl.0.mac.checksum_errors: 0 dev.ixl.0.mac.rx_jabber: 0 dev.ixl.0.mac.rx_oversized: 0 dev.ixl.0.mac.rx_fragmented: 0 dev.ixl.0.mac.rx_undersize: 0 dev.ixl.0.mac.rx_frames_big: 0 dev.ixl.0.mac.rx_frames_1024_1522: 0 dev.ixl.0.mac.rx_frames_512_1023: 1 dev.ixl.0.mac.rx_frames_256_511: 2 dev.ixl.0.mac.rx_frames_128_255: 0 dev.ixl.0.mac.rx_frames_65_127: 3476278 dev.ixl.0.mac.rx_frames_64: 600 dev.ixl.0.mac.rx_length_errors: 0 dev.ixl.0.mac.remote_faults: 0 dev.ixl.0.mac.local_faults: 0 dev.ixl.0.mac.illegal_bytes: 0 dev.ixl.0.mac.crc_errors: 0 dev.ixl.0.mac.bcast_pkts_txd: 3 dev.ixl.0.mac.mcast_pkts_txd: 40988 dev.ixl.0.mac.ucast_pkts_txd: 118541906 dev.ixl.0.mac.good_octets_txd: 179675575237 dev.ixl.0.mac.rx_discards: 0 dev.ixl.0.mac.bcast_pkts_rcvd: 0 dev.ixl.0.mac.mcast_pkts_rcvd: 40983 dev.ixl.0.mac.ucast_pkts_rcvd: 3435898 dev.ixl.0.mac.good_octets_rcvd: 244179426 dev.ixl.0.pf.que7.tx_itr: 17 dev.ixl.0.pf.que7.rx_itr: 5 dev.ixl.0.pf.que7.rx_desc_err: 0 dev.ixl.0.pf.que7.rx_bytes: 31998326 dev.ixl.0.pf.que7.rx_packets: 484742 dev.ixl.0.pf.que7.tx_bytes: 31079009601 dev.ixl.0.pf.que7.tx_packets: 20596797 dev.ixl.0.pf.que7.no_desc_avail: 0 dev.ixl.0.pf.que7.mss_too_small: 0 dev.ixl.0.pf.que7.tx_dmamap_failed: 0 dev.ixl.0.pf.que7.tso_tx: 0 dev.ixl.0.pf.que7.irqs: 2436192 dev.ixl.0.pf.que7.mbuf_defrag_failed: 0 dev.ixl.0.pf.que6.tx_itr: 17 dev.ixl.0.pf.que6.rx_itr: 5 dev.ixl.0.pf.que6.rx_desc_err: 0 dev.ixl.0.pf.que6.rx_bytes: 24252610 dev.ixl.0.pf.que6.rx_packets: 367266 dev.ixl.0.pf.que6.tx_bytes: 38281292816 dev.ixl.0.pf.que6.tx_packets: 25295330 dev.ixl.0.pf.que6.no_desc_avail: 0 dev.ixl.0.pf.que6.mss_too_small: 0 dev.ixl.0.pf.que6.tx_dmamap_failed: 0 dev.ixl.0.pf.que6.tso_tx: 0 dev.ixl.0.pf.que6.irqs: 2606798 dev.ixl.0.pf.que6.mbuf_defrag_failed: 0 dev.ixl.0.pf.que5.tx_itr: 25 dev.ixl.0.pf.que5.rx_itr: 5 dev.ixl.0.pf.que5.rx_desc_err: 0 dev.ixl.0.pf.que5.rx_bytes: 34699914 dev.ixl.0.pf.que5.rx_packets: 525289 dev.ixl.0.pf.que5.tx_bytes: 22679149893 dev.ixl.0.pf.que5.tx_packets: 14988356 dev.ixl.0.pf.que5.no_desc_avail: 0 dev.ixl.0.pf.que5.mss_too_small: 0 dev.ixl.0.pf.que5.tx_dmamap_failed: 0 dev.ixl.0.pf.que5.tso_tx: 0 dev.ixl.0.pf.que5.irqs: 2108645 dev.ixl.0.pf.que5.mbuf_defrag_failed: 0 dev.ixl.0.pf.que4.tx_itr: 25 dev.ixl.0.pf.que4.rx_itr: 5 dev.ixl.0.pf.que4.rx_desc_err: 0 dev.ixl.0.pf.que4.rx_bytes: 37045024 dev.ixl.0.pf.que4.rx_packets: 560793 dev.ixl.0.pf.que4.tx_bytes: 16575971600 dev.ixl.0.pf.que4.tx_packets: 10958352 dev.ixl.0.pf.que4.no_desc_avail: 0 dev.ixl.0.pf.que4.mss_too_small: 0 dev.ixl.0.pf.que4.tx_dmamap_failed: 0 dev.ixl.0.pf.que4.tso_tx: 0 dev.ixl.0.pf.que4.irqs: 1404550 dev.ixl.0.pf.que4.mbuf_defrag_failed: 0 dev.ixl.0.pf.que3.tx_itr: 25 dev.ixl.0.pf.que3.rx_itr: 6 dev.ixl.0.pf.que3.rx_desc_err: 0 dev.ixl.0.pf.que3.rx_bytes: 7138590 dev.ixl.0.pf.que3.rx_packets: 108040 dev.ixl.0.pf.que3.tx_bytes: 7991529147 dev.ixl.0.pf.que3.tx_packets: 5290940 dev.ixl.0.pf.que3.no_desc_avail: 0 dev.ixl.0.pf.que3.mss_too_small: 0 dev.ixl.0.pf.que3.tx_dmamap_failed: 0 dev.ixl.0.pf.que3.tso_tx: 0 dev.ixl.0.pf.que3.irqs: 583274 dev.ixl.0.pf.que3.mbuf_defrag_failed: 0 dev.ixl.0.pf.que2.tx_itr: 25 dev.ixl.0.pf.que2.rx_itr: 5 dev.ixl.0.pf.que2.rx_desc_err: 0 dev.ixl.0.pf.que2.rx_bytes: 36674966 dev.ixl.0.pf.que2.rx_packets: 555676 dev.ixl.0.pf.que2.tx_bytes: 32728554073 dev.ixl.0.pf.que2.tx_packets: 21667691 dev.ixl.0.pf.que2.no_desc_avail: 0 dev.ixl.0.pf.que2.mss_too_small: 0 dev.ixl.0.pf.que2.tx_dmamap_failed: 0 dev.ixl.0.pf.que2.tso_tx: 0 dev.ixl.0.pf.que2.irqs: 2476458 dev.ixl.0.pf.que2.mbuf_defrag_failed: 0 dev.ixl.0.pf.que1.tx_itr: 17 dev.ixl.0.pf.que1.rx_itr: 5 dev.ixl.0.pf.que1.rx_desc_err: 0 dev.ixl.0.pf.que1.rx_bytes: 34520252 dev.ixl.0.pf.que1.rx_packets: 523028 dev.ixl.0.pf.que1.tx_bytes: 13962850814 dev.ixl.0.pf.que1.tx_packets: 9232475 dev.ixl.0.pf.que1.no_desc_avail: 0 dev.ixl.0.pf.que1.mss_too_small: 0 dev.ixl.0.pf.que1.tx_dmamap_failed: 0 dev.ixl.0.pf.que1.tso_tx: 0 dev.ixl.0.pf.que1.irqs: 1566042 dev.ixl.0.pf.que1.mbuf_defrag_failed: 0 dev.ixl.0.pf.que0.tx_itr: 17 dev.ixl.0.pf.que0.rx_itr: 5 dev.ixl.0.pf.que0.rx_desc_err: 0 dev.ixl.0.pf.que0.rx_bytes: 20540631 dev.ixl.0.pf.que0.rx_packets: 311064 dev.ixl.0.pf.que0.tx_bytes: 15899484048 dev.ixl.0.pf.que0.tx_packets: 10511973 dev.ixl.0.pf.que0.no_desc_avail: 0 dev.ixl.0.pf.que0.mss_too_small: 0 dev.ixl.0.pf.que0.tx_dmamap_failed: 0 dev.ixl.0.pf.que0.tso_tx: 0 dev.ixl.0.pf.que0.irqs: 950955 dev.ixl.0.pf.que0.mbuf_defrag_failed: 0 dev.ixl.0.pf.bcast_pkts_txd: 2 dev.ixl.0.pf.mcast_pkts_txd: 2 dev.ixl.0.pf.ucast_pkts_txd: 118541906 dev.ixl.0.pf.good_octets_txd: 179197841664 dev.ixl.0.pf.rx_discards: 0 dev.ixl.0.pf.bcast_pkts_rcvd: 0 dev.ixl.0.pf.mcast_pkts_rcvd: 0 dev.ixl.0.pf.ucast_pkts_rcvd: 3435898 dev.ixl.0.pf.good_octets_rcvd: 240613905 dev.ixl.0.admin_irq: 0 dev.ixl.0.watchdog_events: 0 dev.ixl.0.dynamic_tx_itr: 1 dev.ixl.0.dynamic_rx_itr: 1 dev.ixl.0.rx_itr: 62 dev.ixl.0.tx_itr: 122 dev.ixl.0.unallocated_queues: 760 dev.ixl.0.fw_version: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem=20 1.262.0 dev.ixl.0.current_speed: 10 Gbps dev.ixl.0.advertise_speed: 6 dev.ixl.0.fc: 0 dev.ixl.0.%parent: pci1 dev.ixl.0.%pnpinfo: vendor=3D0x8086 device=3D0x1572 subvendor=3D0x8086=20 subdevice=3D0x0008 class=3D0x020000 dev.ixl.0.%location: slot=3D0 function=3D0 dbsf=3Dpci0:1:0:0=20 handle=3D\_SB_.PCI0.PEG0.PEGP dev.ixl.0.%driver: ixl dev.ixl.0.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version=20 - 1.7.12-k dev.ixl.%parent: dev.netmap.ixl_rx_miss_bufs: 305 dev.netmap.ixl_rx_miss: 255 root@OPNsense:~ # sysctl -a | grep net kern.features.inet6: 1 kern.features.inet: 1 device=C2=A0 vtnet device=C2=A0 netmap net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.seqpacket.recvspace: 8192 net.local.seqpacket.maxseqpacket: 8192 net.local.taskcount: 3 net.local.recycled: 0 net.local.deferred: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 1000 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.gifttl: 30 net.inet.ip.dummynet.fqpie.limit: 10240 net.inet.ip.dummynet.fqpie.flows: 1024 net.inet.ip.dummynet.fqpie.quantum: 1514 net.inet.ip.dummynet.fqpie.beta: 1250 net.inet.ip.dummynet.fqpie.alpha: 125 net.inet.ip.dummynet.fqpie.max_ecnth: 99 net.inet.ip.dummynet.fqpie.max_burst: 150000 net.inet.ip.dummynet.fqpie.tupdate: 15000 net.inet.ip.dummynet.fqpie.target: 15000 net.inet.ip.dummynet.fqcodel.limit: 10240 net.inet.ip.dummynet.fqcodel.flows: 1024 net.inet.ip.dummynet.fqcodel.quantum: 1514 net.inet.ip.dummynet.fqcodel.interval: 100000 net.inet.ip.dummynet.fqcodel.target: 5000 net.inet.ip.dummynet.pie.beta: 1250 net.inet.ip.dummynet.pie.alpha: 125 net.inet.ip.dummynet.pie.max_ecnth: 99 net.inet.ip.dummynet.pie.max_burst: 150000 net.inet.ip.dummynet.pie.tupdate: 15000 net.inet.ip.dummynet.pie.target: 15000 net.inet.ip.dummynet.codel.interval: 100000 net.inet.ip.dummynet.codel.target: 5000 net.inet.ip.dummynet.io_pkt_drop: 0 net.inet.ip.dummynet.io_pkt_fast: 0 net.inet.ip.dummynet.io_pkt: 0 net.inet.ip.dummynet.queue_count: 0 net.inet.ip.dummynet.fsk_count: 2 net.inet.ip.dummynet.si_count: 0 net.inet.ip.dummynet.schk_count: 2 net.inet.ip.dummynet.expire_cycle: 0 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 3680 net.inet.ip.dummynet.tick_adjustment: 234 net.inet.ip.dummynet.tick_delta_sum: -452 net.inet.ip.dummynet.tick_delta: 1 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.hash_size: 256 net.inet.ip.fw.dyn_keep_states: 0 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_max: 16384 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.enable: 1 net.inet.ip.fw.static_count: 29 net.inet.ip.fw.default_to_accept: 1 net.inet.ip.fw.tables_sets: 0 net.inet.ip.fw.tables_max: 128 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.one_pass: 1 net.inet.ip.grettl: 30 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.maxfragpackets: 31311 net.inet.ip.process_options: 1 net.inet.ip.stealth: 0 net.inet.ip.check_interface: 0 net.inet.ip.mcast.loop: 1 net.inet.ip.mcast.maxsocksrc: 128 net.inet.ip.mcast.maxgrpsrc: 512 net.inet.ip.random_id_total: 1201727 net.inet.ip.random_id_collisions: 170700 net.inet.ip.random_id_period: 8192 net.inet.ip.rfc6864: 1 net.inet.ip.random_id: 1 net.inet.ip.no_same_prefix: 0 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 0 net.inet.icmp.tstamprepl: 1 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.icmp.icmplim_output: 1 net.inet.igmp.gsrdelay: 10 net.inet.igmp.default_version: 3 net.inet.igmp.legacysupp: 0 net.inet.igmp.v2enable: 1 net.inet.igmp.v1enable: 1 net.inet.igmp.sendlocal: 1 net.inet.igmp.sendra: 1 net.inet.igmp.recvifkludge: 1 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 536 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 65228 net.inet.tcp.recvspace: 65228 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1220 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 32255 net.inet.tcp.per_cpu_timers: 0 net.inet.tcp.v6pmtud_blackhole_mss: 1220 net.inet.tcp.pmtud_blackhole_mss: 1200 net.inet.tcp.pmtud_blackhole_failed: 0 net.inet.tcp.pmtud_blackhole_activated_min_mss: 0 net.inet.tcp.pmtud_blackhole_activated: 0 net.inet.tcp.pmtud_blackhole_detection: 0 net.inet.tcp.rexmit_drop_options: 0 net.inet.tcp.keepcnt: 8 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.persmax: 60000 net.inet.tcp.persmin: 5000 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15364 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.functions_available: net.inet.tcp.functions_default: default net.inet.tcp.soreceive_stream: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 10 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 131072 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 62500 net.inet.tcp.sendbuf_max: 2097152 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.lro.entries: 8 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.insecure_syn: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 2 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.initcwnd_segments: 10 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.rfc6675_pipe: 0 net.inet.tcp.drop_synfin: 1 net.inet.tcp.delayed_ack: 0 net.inet.tcp.blackhole: 2 net.inet.tcp.log_in_vain: 0 net.inet.tcp.hostcache.purgenow: 0 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 0 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.hostcache.enable: 1 net.inet.tcp.cc.available: newreno net.inet.tcp.cc.algorithm: newreno net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 57344 net.inet.udp.recvspace: 42080 net.inet.udp.blackhole: 1 net.inet.udp.log_in_vain: 0 net.inet.esp.esp_enable: 1 net.inet.ah.ah_cleartos: 1 net.inet.ah.ah_enable: 1 net.inet.pim.squelch_wholepkt: 0 net.inet.ipcomp.ipcomp_enable: 1 net.inet.carp.ifdown_demotion_factor: 240 net.inet.carp.senderr_demotion_factor: 240 net.inet.carp.demotion: 0 net.inet.carp.log: 1 net.inet.carp.preempt: 1 net.inet.carp.allow: 1 net.inet.sctp.diag_info_code: 0 net.inet.sctp.blackhole: 0 net.inet.sctp.use_dcccecn: 1 net.inet.sctp.rttvar_steady_step: 20 net.inet.sctp.rttvar_eqret: 0 net.inet.sctp.rttvar_rtt: 5 net.inet.sctp.rttvar_bw: 4 net.inet.sctp.initial_cwnd: 3 net.inet.sctp.buffer_splitting: 0 net.inet.sctp.vtag_time_wait: 60 net.inet.sctp.nat_friendly_init: 0 net.inet.sctp.enable_sack_immediately: 1 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.mobility_base: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.default_ss_module: 0 net.inet.sctp.default_cc_module: 0 net.inet.sctp.log_level: 0 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.min_residual: 1452 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.abc_l_var: 2 net.inet.sctp.nat_friendly: 1 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.incoming_streams: 2048 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.path_pf_threshold: 65535 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_max: 60000 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.shutdown_guard_time: 0 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.sys_resource: 1000 net.inet.sctp.sack_freq: 2 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.chunkscale: 10 net.inet.sctp.min_split_point: 2904 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.maxchunks: 125000 net.inet.sctp.fr_maxburst: 4 net.inet.sctp.maxburst: 4 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.pktdrop_enable: 0 net.inet.sctp.nrsack_enable: 0 net.inet.sctp.reconfig_enable: 1 net.inet.sctp.asconf_enable: 1 net.inet.sctp.auth_enable: 1 net.inet.sctp.pr_enable: 1 net.inet.sctp.ecn_enable: 1 net.inet.sctp.auto_asconf: 1 net.inet.sctp.recvspace: 1864135 net.inet.sctp.sendspace: 1864135 net.inet.ipsec.def_policy: 1 net.inet.ipsec.esp_trans_deflev: 1 net.inet.ipsec.esp_net_deflev: 1 net.inet.ipsec.ah_trans_deflev: 1 net.inet.ipsec.ah_net_deflev: 1 net.inet.ipsec.ah_cleartos: 1 net.inet.ipsec.ah_offsetmask: 0 net.inet.ipsec.dfbit: 0 net.inet.ipsec.ecn: 0 net.inet.ipsec.debug: 0 net.inet.ipsec.filtertunnel: 0 net.inet.ipsec.natt_cksum_policy: 0 net.inet.ipsec.check_policy_history: 0 net.inet.ipsec.crypto_support: 50331648 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.link.generic.system.ifcount: 9 net.link.ether.inet.allow_multicast: 0 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.garp_rexmit_count: 0 net.link.ether.inet.max_log_per_second: 1 net.link.ether.inet.maxhold: 1 net.link.ether.inet.wait: 20 net.link.ether.inet.proxyall: 0 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.ipfw: 0 net.link.gre.max_nesting: 1 net.link.vlan.mtag_pcp: 0 net.link.vlan.soft_pad: 0 net.link.bridge.ipfw: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 net.link.gif.parallel_tunnels: 0 net.link.gif.max_nesting: 1 net.link.lagg.lacp.default_strict_mode: 1 net.link.lagg.lacp.debug: 0 net.link.lagg.default_flowid_shift: 16 net.link.lagg.default_use_flowid: 1 net.link.lagg.failover_rx_all: 0 net.link.tap.debug: 0 net.link.tap.devfs_cloning: 1 net.link.tap.up_on_open: 0 net.link.tap.user_open: 1 net.link.tun.devfs_cloning: 1 net.link.log_promisc_mode_change: 1 net.link.log_link_state_change: 1 net.link.ifqmaxlen: 8192 net.key.debug: 0 net.key.spi_trycnt: 1000 net.key.spi_minval: 256 net.key.spi_maxval: 268435455 net.key.int_random: 60 net.key.larval_lifetime: 30 net.key.blockacq_count: 10 net.key.blockacq_lifetime: 20 net.key.esp_keymin: 256 net.key.esp_auth: 0 net.key.ah_keymin: 128 net.key.preferred_oldsa: 0 net.inet6.ip6.forwarding: 1 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 250000 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 250000 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.stealth: 0 net.inet6.ip6.no_radr: 0 net.inet6.ip6.norbit_raif: 0 net.inet6.ip6.rfc6204w3: 0 net.inet6.ip6.intr_queue_maxlen: 256 net.inet6.ip6.fw.enable: 1 net.inet6.ip6.fw.permit_single_frag6: 1 net.inet6.ip6.fw.deny_unknown_exthdrs: 1 net.inet6.ip6.grehlim: 64 net.inet6.ip6.deembed_scopeid: 1 net.inet6.ip6.dad_enhanced: 1 net.inet6.ip6.mcast.loop: 1 net.inet6.ip6.mcast.maxsocksrc: 128 net.inet6.ip6.mcast.maxgrpsrc: 512 net.inet6.ipsec6.def_policy: 1 net.inet6.ipsec6.esp_trans_deflev: 1 net.inet6.ipsec6.esp_net_deflev: 1 net.inet6.ipsec6.ah_trans_deflev: 1 net.inet6.ipsec6.ah_net_deflev: 1 net.inet6.ipsec6.ecn: 0 net.inet6.ipsec6.debug: 0 net.inet6.ipsec6.filtertunnel: 0 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.inet6.icmp6.nd6_maxqueuelen: 1 net.inet6.icmp6.nodeinfo_oldmcprefix: 1 net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 net.inet6.icmp6.nd6_gctimer: 86400 net.inet6.mld.use_allow: 1 net.inet6.mld.v1enable: 1 net.inet6.mld.gsrdelay: 10 net.pfsync.carp_demotion_factor: 240 net.enc.out.ipsec_bpf_mask: 1 net.enc.out.ipsec_filter_mask: 1 net.enc.in.ipsec_bpf_mask: 2 net.enc.in.ipsec_filter_mask: 2 net.graph.control.proto: 2 net.graph.data.proto: 1 net.graph.family: 32 net.graph.recvspace: 20480 net.graph.maxdgram: 20480 net.graph.mppe.max_rekey: 1000 net.graph.mppe.log_max_rekey: 1 net.graph.mppe.block_on_max_rekey: 0 net.graph.msg_version: 8 net.graph.abi_version: 12 net.graph.maxdata: 4096 net.graph.maxalloc: 4096 net.graph.threads: 8 net.pf.share_forward6: 1 net.pf.share_forward: 1 net.pf.source_nodes_hashsize: 8192 net.pf.states_hashsize: 32768 net.wlan.mesh.maxholding: 2 net.wlan.mesh.maxretries: 2 net.wlan.mesh.backofftimeout: 5000 net.wlan.mesh.confirmtimeout: 40 net.wlan.mesh.holdingtimeout: 40 net.wlan.mesh.retrytimeout: 40 net.wlan.mesh.gateint: 10000 net.wlan.hwmp.inact: 5000 net.wlan.hwmp.rootconfint: 2000 net.wlan.hwmp.rannint: 1000 net.wlan.hwmp.rootint: 2000 net.wlan.hwmp.roottimeout: 5000 net.wlan.hwmp.net_diameter_traversal_time: 512 net.wlan.hwmp.maxpreq_retries: 3 net.wlan.hwmp.pathlifetime: 5000 net.wlan.hwmp.targetonly: 0 net.wlan.addba_maxtries: 3 net.wlan.addba_backoff: 10000 net.wlan.addba_timeout: 250 net.wlan.recv_bar: 1 net.wlan.ampdu_age: 500 net.wlan.debug: 0 net.wlan.cac_timeout: 60 net.wlan.nol_timeout: 1800 net.wlan.devices: net.route.netisr_maxqlen: 256 net.my_fibnum: 0 net.add_addr_allfibs: 1 net.fibs: 1 net.raw.recvspace: 8192 net.raw.sendspace: 8192 net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.dispatch: direct net.iflib.min_tx_latency: 0 net.ifdescr_maxlen: 1024 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.bpf.optimize_writers: 0 net.bpf.zerocopy_enable: 0 net.bpf.maxinsns: 512 net.accf.unloadable: 0 hw.vtnet.rx_process_limit: 512 hw.vtnet.mq_max_pairs: 8 hw.vtnet.mq_disable: 0 hw.vtnet.lro_disable: 0 hw.vtnet.tso_disable: 0 hw.vtnet.csum_disable: 0 dev.ixl.1.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version=20 - 1.7.12-k dev.ixl.0.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version=20 - 1.7.12-k dev.netmap.ixl_rx_miss_bufs: 305 dev.netmap.ixl_rx_miss: 255 dev.netmap.iflib_rx_miss_bufs: 0 dev.netmap.iflib_rx_miss: 0 dev.netmap.iflib_crcstrip: 1 dev.netmap.bridge_batch: 1024 dev.netmap.default_pipes: 0 dev.netmap.priv_buf_num: 4098 dev.netmap.priv_buf_size: 2048 dev.netmap.buf_curr_num: 163840 dev.netmap.buf_num: 163840 dev.netmap.buf_curr_size: 2048 dev.netmap.buf_size: 2048 dev.netmap.priv_ring_num: 4 dev.netmap.priv_ring_size: 20480 dev.netmap.ring_curr_num: 200 dev.netmap.ring_num: 200 dev.netmap.ring_curr_size: 73728 dev.netmap.ring_size: 73728 dev.netmap.priv_if_num: 1 dev.netmap.priv_if_size: 1024 dev.netmap.if_curr_num: 100 dev.netmap.if_num: 100 dev.netmap.if_curr_size: 1024 dev.netmap.if_size: 1024 dev.netmap.generic_rings: 1 dev.netmap.generic_ringsize: 1024 dev.netmap.generic_mit: 100000 dev.netmap.admode: 0 dev.netmap.fwd: 0 dev.netmap.flags: 0 dev.netmap.adaptive_io: 0 dev.netmap.txsync_retry: 2 dev.netmap.no_pendintr: 1 dev.netmap.mitigate: 1 dev.netmap.no_timestamp: 0 dev.netmap.verbose: 0 dev.netmap.ix_rx_miss_bufs: 0 dev.netmap.ix_rx_miss: 0 dev.netmap.ix_crcstrip: 0 security.jail.vnet: 0 From owner-freebsd-net@freebsd.org Thu Mar 29 15:55:41 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2F4AF56E9B for ; Thu, 29 Mar 2018 15:55:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E2917545C for ; Thu, 29 Mar 2018 15:55:41 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 80CEF24A82 for ; Thu, 29 Mar 2018 15:55:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2TFtePE047715 for ; Thu, 29 Mar 2018 15:55:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2TFtegL047714 for freebsd-net@FreeBSD.org; Thu, 29 Mar 2018 15:55:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227058] vxge(4): ioctl implementation reads directly from user memory Date: Thu, 29 Mar 2018 15:55:40 +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: easy X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: brooks@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 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.25 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, 29 Mar 2018 15:55:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227058 Brooks Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |easy --- Comment #1 from Brooks Davis --- Actually fixing this shouldn't be too hard (see other examples recently fix= ed in nxge(4)). Finding someone to do more than compile test this might be a challenge. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 29 19:49:29 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD031F71422 for ; Thu, 29 Mar 2018 19:49:28 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orsmga102.jf.intel.com", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0845780BD7 for ; Thu, 29 Mar 2018 19:49:25 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2018 12:49:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,378,1517904000"; d="scan'208";a="37969124" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by FMSMGA003.fm.intel.com with ESMTP; 29 Mar 2018 12:49:21 -0700 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 29 Mar 2018 12:49:20 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.250]) by ORSMSX156.amr.corp.intel.com ([169.254.8.180]) with mapi id 14.03.0319.002; Thu, 29 Mar 2018 12:49:20 -0700 From: "Pieper, Jeffrey E" To: "Muenz, Michael" , "Rodney W. Grimes" CC: "freebsd-net@freebsd.org" Subject: Re: Current state of Intel XL710 40G NIC ixl performance Thread-Topic: Current state of Intel XL710 40G NIC ixl performance Thread-Index: AQHTxkswolF7J/Q5q0+3Am2mjJqrS6PmSiwAgAAFAQCAAPEAgIAAYGMAgAAH8YD///j1gA== Date: Thu, 29 Mar 2018 19:49:19 +0000 Message-ID: <49887EF8-FAFE-45DF-BB2F-6007E5BB7485@intel.com> References: <201803291246.w2TCk67R062959@pdx.rh.CN85.dnsmgr.net> <39f44655-4d92-8b95-3819-527de665d391@spam-fetish.org> In-Reply-To: <39f44655-4d92-8b95-3819-527de665d391@spam-fetish.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.0.180327 x-originating-ip: [134.134.172.154] Content-Type: text/plain; charset="utf-8" Content-ID: <178F8B69BA6ADA4A92798334D23A3F4A@intel.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Mar 2018 19:49:29 -0000 SGkgUm9kbmV5LA0KDQpTbyB0aGlzIGlzIGEgWEw3MTAtUURBMiB0aGF0IGlzIHNldCB0byA0eDEw PyAoZGVmYXVsdCBpcyAyeDQwKS4gSWYgeW91IGNhbiB5b3UgZ2l2ZSBtZSB0aGUgb3V0cHV0IG9m IHN5c2N0bCBkZXYuaXhsfGVncmVwICdwbnB8bG9jYXRpfFZlcnNpb24nLCB0aGF0IHdvdWxkIGJl IGhlbHBmdWwuIA0KDQpUaGFua3MsDQpKZWZmDQoNCu+7v09uIDMvMjkvMTgsIDY6MTYgQU0sICJv d25lci1mcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBvbiBiZWhhbGYgb2YgTXVlbnosIE1pY2hhZWwi IDxvd25lci1mcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBvbiBiZWhhbGYgb2YgbS5tdWVuekBzcGFt LWZldGlzaC5vcmc+IHdyb3RlOg0KDQogICAgQW0gMjkuMDMuMjAxOCB1bSAxNDo0NiBzY2hyaWVi IFJvZG5leSBXLiBHcmltZXM6DQogICAgPj4gQW0gMjguMDMuMjAxOCB1bSAxODozOCBzY2hyaWVi IFJvZG5leSBXLiBHcmltZXM6DQogICAgPj4+PiBBbSAyOC4wMy4yMDE4IHVtIDA2OjExIHNjaHJp ZWIgY2hyaXN0aWFuIHJ1c3NlbGw6DQogICAgPj4+Pj4gSSBhbSBoYXZpbmcgdHJvdWJsZSBnZXR0 aW5nIGFuIEludGVsIFhMNzEwLURBMiBOSUMgdG8gZ2V0IGV2ZW4gY2xvc2UgdG8NCiAgICA+Pj4+ PiBsaW5lIHJhdGUuICBJdCBpcyBhIDR4MTAgR2JwcyBjYXJkLiAgVGhlIGJveCBpcyBydW5uaW5n IEZyZWVCU0QgMTEgKEZyZWVOQVMNCiAgICA+Pj4+PiBpbiBwYXJ0aWN1bGFyKS4NCiAgICA+Pj4+ Pg0KICAgID4+Pj4+IFdlIGhhdmUgdHJpZWQgYm90aCAxLjcgYW5kIDEuOSBkcml2ZXIgcmV2aXNp b25zIHdpdGggc2ltaWxhciByZXN1bHRzLiAgVGhlDQogICAgPj4+Pj4gTlZNIHZlcnNpb24gaXMg NS4wNS4gIFRoZSBjYXJkIGlzIGluIGEgY29uZmlybWVkIDh4IHNsb3Qgb24gYSBTdXBlck1pY3Jv DQogICAgPj4+Pj4gWDEwRFJMLWkgd2l0aCB0d28gWGVvbiBFNS0yNjAwIHByb2Nlc3NvcnMgYW5k IDI1NiBHQiBERFI0IFJBTS4gIEFmdGVyDQogICAgPj4+Pj4gdXBwaW5nIHRoZSBpbnRlcnJ1cHQg dGhyZXNob2xkIHRvIDkwMDAgZG1lc2cgZG9lc24ndCBsb2cgYW55dGhpbmcgdW51c3VhbC4NCiAg ICA+Pj4+Pg0KICAgID4+Pj4+IFdlIGhhdmUgYWRkZWQgdGhlIHR1bmVzIHRoYXQgYXJlIHN0YW5k YXJkIGZvciAxMCBHYnBzIGNvbmZpZ3VyYXRpb25zLg0KICAgID4+Pj4+DQogICAgPj4+Pj4gT24g YSBzaW5nbGUtY2xpZW50IGJhc2lzIHRoZSBmYXN0ZXN0IHJhdGVzIHdlIHNlZSBhcmUgYXJvdW5k IDUgR2Jwcy4NCiAgICA+Pj4+PiBIaXR0aW5nIHRoaXMgc2VydmVyIGZyb20gbXVsdGlwbGUgYm94 ZXMgd2Ugc2VlIHBlYWtzIG9mIDIwIEdicHMgYXQgdGhlIHZlcnkNCiAgICA+Pj4+PiBoaWdoZXN0 LiAgTW9yZSBmcmVxdWVudGx5IHRoaW5ncyB0b3Agb2ZmIGFyb3VuZCAxMyBHYnBzLiAgVGhlc2Ug bnVtYmVycyBhcmUNCiAgICA+Pj4+PiBjb21pbmcgZnJvbSBpcGVyZiB0ZXN0cy4gIFdlIGFyZSBz ZWVpbmcgc2ltaWxhciBudW1iZXJzIHdpdGggZGlyZWN0DQogICAgPj4+Pj4gcG9pbnQtdG8tcG9p bnQgYXMgd2VsbCBhcyBzd2l0Y2hlZCB0b3BvbG9naWVzLg0KICAgID4+Pj4+DQogICAgPj4+Pj4g VGhlc2UgdGhyZWFkcyBmcm9tIDIwMTUgZGVzY3JpYmUgc2ltaWxhciBpc3N1ZXMgYnV0IGZpenps ZWQgb3V0Og0KICAgID4+Pj4+IGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvcGlwZXJtYWlsL2Zy ZWVic2QtbmV0LzIwMTUtTWF5LzA0MjI3My5odG1sDQogICAgPj4+Pj4gaHR0cHM6Ly9saXN0cy5m cmVlYnNkLm9yZy9waXBlcm1haWwvZnJlZWJzZC1uZXQvMjAxNS1PY3RvYmVyLzA0MzU4NC5odG1s DQogICAgPj4+Pj4NCiAgICA+Pj4+PiBJcyB0aGVyZSB2ZXJ5IHBhcnRpY3VsYXIgdHVuaW5nIHJl cXVpcmVkIHRvIGdldCB0aGVzZSBjYXJkcyB3b3JraW5nIGF0DQogICAgPj4+Pj4gcHJvcGVyIHNw ZWVkPyAgQW55IGluc2lnaHRzPw0KICAgID4+Pj4+DQogICAgPj4+Pj4gPkZyb20gR29vZ2xpbmcg YXJvdW5kIGl0IGFwcGVhcnMgZnJ1c3RyYXRpb24gd2l0aCB0aGlzIGNhcmQgYW5kIEZyZWVCU0Qg aXMNCiAgICA+Pj4+PiBwcmV0dHkgY29tbW9uLg0KICAgID4+Pj4+DQogICAgPj4+Pj4gVGhhbmtz IGluIGFkdmFuY2UuDQogICAgPj4+Pj4NCiAgICA+Pj4+PiBDaHJpc3RpYW4NCiAgICA+Pj4+IEkg Y2FuJ3QgZGVsaXZlciBhbnkgc3BlY2lhbCBpbnNpZ2h0cyBidXQgd2UgaGFkIG1hbnkgcHJvYmxl bXMgd2l0aCBYNzEwDQogICAgPj4+PiAod2l0aG91dCBMKSBhbmQgTGludXguDQogICAgPj4+PiBE aWQgc29tZSB0ZXN0aW5nIGEgd2hpbGUgYWdvIHdpdGggT1BOc2Vuc2UgKGJhc2VkIG9uIDExLjEp IGFuZCBnb3QgbGluZQ0KICAgID4+Pj4gcmF0ZSB3aXRoIGlwZXJmIGFuZCBzaW5nbGUgY2xpZW50 Lg0KICAgID4+Pj4gaXhsMCBpbiBhbmQgaXhsMSBvdXQuIFNvIHRoaXMgc2hvdWxkIGJlIGZpbmUu IElmIHlvdSBsaWtlIEkgY2FuIHNlbmQgeW91DQogICAgPj4+PiB0aGUgc3lzY3RsIHZhbHVlcyB0 byBjb21wYXJlLg0KICAgID4+PiBJIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4geW91ciBzeXNjdGwg dmFsdWVzLg0KICAgID4+Pg0KICAgID4+IEhtLCBwZXJoYXBzIEkgbWlzaW50ZXJwcmV0ZWQgeW91 ciBwb3N0LiBJIHJlY3JlYXRlZCB0aGUgbGFiIGFuZCBmcm9tIHRoZQ0KICAgID4+IGhpc3Rvcnkg SSBzYXcNCiAgICA+PiB0aGF0IGl0IHdhcyBzaW5nbGUgY2xpZW50IGJ1dCB3aXRoIDEwIHN0cmVh bXMgaW4gcGFyYWxsZWwuIElmIEkgcmVkdWNlDQogICAgPj4gdG8gMSBzdHJlYW0gSSBhbHNvDQog ICAgPj4gZG9uJ3QgY29tZSBvdmVyIHRoZSA1LDZHLg0KICAgID4+DQogICAgPj4gSWYgeW91J3Jl IHN0aWxsIGludGVyZXN0ZWQgSSBjYW4gc2VuZCB5b3UgdGhlIG91dHB1dC4NCiAgICA+IFdlIHNw ZWNpZmljYWxseSBhcmUgaW50ZXJlc3RlZCBpbiB0aGUgc3lzY3RsIHNldHRpbmdzIHlvdSB1c2Vk DQogICAgPiB0byBvYnRhaW4gYSAibGluZSByYXRlIiByZXN1bHRzIHVzaW5nIGl4bDAgaW4gYW5k IGl4bDEgb3V0LA0KICAgID4gaXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoYXQgd2FzIDEgc3RyZWFt IG9yIDEwIHN0cmVhbSwgd2Ugd291bGQNCiAgICA+IGp1c3QgbGlrZSB0byBzZWUgd2hhdCB2YWx1 ZXMgeW91IGZvdW5kIHRvIHdvcmsgd2VsbCBmb3IgeW91DQogICAgPiB0byBjb21wYXJlIHRvIHdo YXQgdmFsdWVzIG90aGVycyBtYXkgYmUgdXNpbmcvc3VnZ2VzdGluZy4NCiAgICA+DQogICAgU3Vy ZSEgSSBqdXN0IGRpZCBhIHRlc3QgYW5kIGl0J3MgOSw2R0JpdCB3aXRoIDEwIHN0cmVhbXMuDQog ICAgDQogICAgVGhlIGxheW91dCBpczoNCiAgICANCiAgICBVQlVOVFUtQSAtLS0gMTBHIERBIC0t LSBPUE4tQSAtLS0gMTBHIERBIC0tLSBPUE4tQiAtLS0gMTBHIERBIC0tLSBVQlVOVFUtQg0KICAg IA0KICAgIEFsbCBzeXN0ZW0gcXVpdGUgYWN1dGFsLCBlbm91Z2ggUkFNIGFuZCBhbGwgd2l0aCBY NzEwLg0KICAgIA0KICAgIFRoaXMgaXMgb25lIG9mIHRoZSBmaXJld2FsbHMgKGFsbCB2YWx1ZXMg YXJlIGRlZmF1bHQgYnkgT1BOc2Vuc2UsIG5vIA0KICAgIHNwZWNpYWwgdHVuaW5nDQogICAgDQog ICAgZnJvbSBteSBzaWRlKToNCiAgICANCiAgICANCiAgICByb290QE9QTnNlbnNlOn4gIyBkbWVz ZyB8IGdyZXAgWGVvbg0KICAgIENQVTogSW50ZWwoUikgWGVvbihSKSBDUFUgRTMtMTI3MCB2NSBA IDMuNjBHSHogKDM2MDAuMTgtTUh6IEs4LWNsYXNzIENQVQ0KICAgIA0KICAgIA0KICAgIHJvb3RA T1BOc2Vuc2U6fiAjIGlmY29uZmlnIC12dnZ2dnYgaXhsMA0KICAgIGl4bDA6IGZsYWdzPTg4NDM8 VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAw DQogICAgb3B0aW9ucz02NDAwYjg8VkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsSlVNQk9fTVRVLFZM QU5fSFdDU1VNLFZMQU5fSFdUU08sUlhDU1VNX0lQVjYsVFhDU1VNX0lQVjY+DQogICAgICAgICAg ICAgZXRoZXIgM2M6ZmQ6ZmU6OWU6ZTc6NDgNCiAgICAgICAgICAgICBod2FkZHIgM2M6ZmQ6ZmU6 OWU6ZTc6NDgNCiAgICAgICAgICAgICBpbmV0IDEwLjU1LjEuMSBuZXRtYXNrIDB4ZmZmZmZmMDAg YnJvYWRjYXN0IDEwLjU1LjEuMjU1DQogICAgICAgICAgICAgaW5ldDYgZmU4MDo6M2VmZDpmZWZm OmZlOWU6ZTc0OCVpeGwwIHByZWZpeGxlbiA2NCBzY29wZWlkIDB4MQ0KICAgICAgICAgICAgIG5k NiBvcHRpb25zPTIxPFBFUkZPUk1OVUQsQVVUT19MSU5LTE9DQUw+DQogICAgICAgICAgICAgbWVk aWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwR2Jhc2UtVHdpbmF4IDxmdWxsLWR1cGxleD4pDQog ICAgICAgICAgICAgc3RhdHVzOiBhY3RpdmUNCiAgICAgICAgICAgICBwbHVnZ2VkOiBTRlAvU0ZQ Ky9TRlAyOCBVbmtub3duIChDb3BwZXIgcGlndGFpbCkNCiAgICAgICAgICAgICB2ZW5kb3I6IENJ U0NPLUxPUk9NIFBOOiBMUkhTUEI1NEQwMjAgU046IExSTTIwMTQ2MjZHIERBVEU6IA0KICAgIDIw MTYtMDQtMTUNCiAgICBDbGFzczogKG51bGwpDQogICAgTGVuZ3RoOiAobnVsbCkNCiAgICBUZWNo OiBQYXNzaXZlIENhYmxlDQogICAgTWVkaWE6IChudWxsKQ0KICAgIFNwZWVkOiAobnVsbCkNCiAg ICANCiAgICAgICAgICAgICBTRkY4NDcyIERVTVAgKDB4QTAgMC4uMTI3IHJhbmdlKToNCiAgICAg ICAgICAgICAwMyAwNCAyMSAwMCAwMCAwMCAwMCAwMCAwNCAwMCAwMCAwMCA2NyAwMCAwMCAwMA0K ICAgICAgICAgICAgIDAwIDAwIDAyIDAwIDQzIDQ5IDUzIDQzIDRGIDJEIDRDIDRGIDUyIDRGIDRE IDIwDQogICAgICAgICAgICAgMjAgMjAgMjAgMjAgMDAgRkMgMkUgMkQgNEMgNTIgNDggNTMgNTAg NDIgMzUgMzQNCiAgICAgICAgICAgICA0NCAzMCAzMiAzMCAyMCAyMCAyMCAyMCA0MiAzMiAyMCAy MCAwMSAwMCAwMCBGMg0KICAgICAgICAgICAgIDAwIDAwIDAwIDAwIDRDIDUyIDREIDMyIDMwIDMx IDM0IDM2IDMyIDM2IDQ3IDIwDQogICAgICAgICAgICAgMjAgMjAgMjAgMjAgMzEgMzYgMzAgMzQg MzEgMzUgMjAgMjAgMDAgMDAgMDAgQTgNCiAgICAgICAgICAgICAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAgICAgICAgIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIEU5IDc3IDcwIDgwDQogICAgDQogICAgDQogICAgDQogICAg DQogICAgcm9vdEBPUE5zZW5zZTp+ICMgZG1lc2cgfCBncmVwIGl4bA0KICAgIGl4bDA6IDxJbnRl bChSKSBFdGhlcm5ldCBDb25uZWN0aW9uIFhMNzEwL1g3MjIgRHJpdmVyLCBWZXJzaW9uIC0gDQog ICAgMS43LjEyLWs+IG1lbSAweGRkMDAwMDAwLTB4ZGQ3ZmZmZmYsMHhkZDgwODAwMC0weGRkODBm ZmZmIGlycSAxNiBhdCANCiAgICBkZXZpY2UgMC4wIG9uIHBjaTENCiAgICBpeGwwOiBVc2luZyBN U0lYIGludGVycnVwdHMgd2l0aCA5IHZlY3RvcnMNCiAgICBpeGwwOiBmdyA1LjAuNDAwNDMgYXBp IDEuNSBudm0gNS4wNSBldGlkIDgwMDAyODkyIG9lbSAxLjI2Mi4wDQogICAgaXhsMDogUEYtSURb MF06IFZGcyA2NCwgTVNJWCAxMjksIFZGIE1TSVggNSwgUVBzIDc2OCwgSTJDDQogICAgaXhsMDog QWxsb2NhdGluZyA4IHF1ZXVlcyBmb3IgUEYgTEFOIFZTSTsgOCBxdWV1ZXMgYWN0aXZlDQogICAg aXhsMDogRXRoZXJuZXQgYWRkcmVzczogM2M6ZmQ6ZmU6OWU6ZTc6NDgNCiAgICBpeGwwOiBQQ0kg RXhwcmVzcyBCdXM6IFNwZWVkIDguMEdUL3MgV2lkdGggeDgNCiAgICBpeGwwOiBTUi1JT1YgcmVh ZHkNCiAgICBpeGwwOiBuZXRtYXAgcXVldWVzL3Nsb3RzOiBUWCA4LzEwMjQsIFJYIDgvMTAyNA0K ICAgIGl4bDE6IDxJbnRlbChSKSBFdGhlcm5ldCBDb25uZWN0aW9uIFhMNzEwL1g3MjIgRHJpdmVy LCBWZXJzaW9uIC0gDQogICAgMS43LjEyLWs+IG1lbSAweGRjODAwMDAwLTB4ZGNmZmZmZmYsMHhk ZDgwMDAwMC0weGRkODA3ZmZmIGlycSAxNiBhdCANCiAgICBkZXZpY2UgMC4xIG9uIHBjaTENCiAg ICBpeGwxOiBVc2luZyBNU0lYIGludGVycnVwdHMgd2l0aCA5IHZlY3RvcnMNCiAgICBpeGwxOiBm dyA1LjAuNDAwNDMgYXBpIDEuNSBudm0gNS4wNSBldGlkIDgwMDAyODkyIG9lbSAxLjI2Mi4wDQog ICAgaXhsMTogUEYtSURbMV06IFZGcyA2NCwgTVNJWCAxMjksIFZGIE1TSVggNSwgUVBzIDc2OCwg STJDDQogICAgaXhsMTogQWxsb2NhdGluZyA4IHF1ZXVlcyBmb3IgUEYgTEFOIFZTSTsgOCBxdWV1 ZXMgYWN0aXZlDQogICAgaXhsMTogRXRoZXJuZXQgYWRkcmVzczogM2M6ZmQ6ZmU6OWU6ZTc6NDkN CiAgICBpeGwxOiBQQ0kgRXhwcmVzcyBCdXM6IFNwZWVkIDguMEdUL3MgV2lkdGggeDgNCiAgICBp eGwxOiBTUi1JT1YgcmVhZHkNCiAgICBpeGwxOiBuZXRtYXAgcXVldWVzL3Nsb3RzOiBUWCA4LzEw MjQsIFJYIDgvMTAyNA0KICAgIGl4bDA6IExpbmsgaXMgdXAsIDEwIEdicHMgRnVsbCBEdXBsZXgs IEZFQzogTm9uZSwgQXV0b25lZzogRmFsc2UsIEZsb3cgDQogICAgQ29udHJvbDogTm9uZQ0KICAg IGl4bDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KICAgIGl4bDE6IExpbmsgaXMgdXAsIDEw IEdicHMgRnVsbCBEdXBsZXgsIEZFQzogTm9uZSwgQXV0b25lZzogRmFsc2UsIEZsb3cgDQogICAg Q29udHJvbDogTm9uZQ0KICAgIGl4bDE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KICAgIGl4 bDE6IFRTTzQgcmVxdWlyZXMgdHhjc3VtLCBkaXNhYmxpbmcgYm90aC4uLg0KICAgIGl4bDA6IFRT TzQgcmVxdWlyZXMgdHhjc3VtLCBkaXNhYmxpbmcgYm90aC4uLg0KICAgIA0KICAgIA0KICAgIA0K ICAgIA0KICAgIHJvb3RAT1BOc2Vuc2U6fiAjIHN5c2N0bCAtYSB8IGdyZXAgaXhsDQogICAgZGV2 aWNlICBpeGwNCiAgICBkZXZpY2UgIGl4bHYNCiAgICBody5peGx2LnR4X2l0cjogMTIyDQogICAg aHcuaXhsdi5yeF9pdHI6IDYyDQogICAgaHcuaXhsdi5keW5hbWljX3R4X2l0cjogMA0KICAgIGh3 Lml4bHYuZHluYW1pY19yeF9pdHI6IDANCiAgICBody5peGx2LnR4YnJfc2l6ZTogNDA5Ng0KICAg IGh3Lml4bHYubWF4X3F1ZXVlczogMA0KICAgIGh3Lml4bHYucmluZ19zaXplOiAxMDI0DQogICAg aHcuaXhsLnR4X2l0cjogMTIyDQogICAgaHcuaXhsLnJ4X2l0cjogNjINCiAgICBody5peGwuZHlu YW1pY190eF9pdHI6IDENCiAgICBody5peGwuZHluYW1pY19yeF9pdHI6IDENCiAgICBody5peGwu c2hhcmVkX2RlYnVnX21hc2s6IDANCiAgICBody5peGwuY29yZV9kZWJ1Z19tYXNrOiAwDQogICAg aHcuaXhsLmVuYWJsZV90eF9mY19maWx0ZXI6IDENCiAgICBody5peGwubWF4X3F1ZXVlczogMA0K ICAgIGh3Lml4bC5yaW5nX3NpemU6IDEwMjQNCiAgICBody5peGwuZW5hYmxlX21zaXg6IDENCiAg ICBkZXYuaXhsLjEubWFjLnhvZmZfcmVjdmQ6IDANCiAgICBkZXYuaXhsLjEubWFjLnhvZmZfdHhk OiAwDQogICAgZGV2Lml4bC4xLm1hYy54b25fcmVjdmQ6IDANCiAgICBkZXYuaXhsLjEubWFjLnhv bl90eGQ6IDANCiAgICBkZXYuaXhsLjEubWFjLnR4X2ZyYW1lc19iaWc6IDANCiAgICBkZXYuaXhs LjEubWFjLnR4X2ZyYW1lc18xMDI0XzE1MjI6IDEyNjU3NQ0KICAgIGRldi5peGwuMS5tYWMudHhf ZnJhbWVzXzUxMl8xMDIzOiA1Mw0KICAgIGRldi5peGwuMS5tYWMudHhfZnJhbWVzXzI1Nl81MTE6 IDE4DQogICAgZGV2Lml4bC4xLm1hYy50eF9mcmFtZXNfMTI4XzI1NTogNjI3Mw0KICAgIGRldi5p eGwuMS5tYWMudHhfZnJhbWVzXzY1XzEyNzogMzQ3OTA1Mg0KICAgIGRldi5peGwuMS5tYWMudHhf ZnJhbWVzXzY0OiAzMDE1DQogICAgZGV2Lml4bC4xLm1hYy5jaGVja3N1bV9lcnJvcnM6IDANCiAg ICBkZXYuaXhsLjEubWFjLnJ4X2phYmJlcjogMA0KICAgIGRldi5peGwuMS5tYWMucnhfb3ZlcnNp emVkOiAwDQogICAgZGV2Lml4bC4xLm1hYy5yeF9mcmFnbWVudGVkOiAwDQogICAgZGV2Lml4bC4x Lm1hYy5yeF91bmRlcnNpemU6IDANCiAgICBkZXYuaXhsLjEubWFjLnJ4X2ZyYW1lc19iaWc6IDAN CiAgICBkZXYuaXhsLjEubWFjLnJ4X2ZyYW1lc18xMDI0XzE1MjI6IDExODM0MDQwMw0KICAgIGRl di5peGwuMS5tYWMucnhfZnJhbWVzXzUxMl8xMDIzOiAyNjAyDQogICAgZGV2Lml4bC4xLm1hYy5y eF9mcmFtZXNfMjU2XzUxMTogMjU4OA0KICAgIGRldi5peGwuMS5tYWMucnhfZnJhbWVzXzEyOF8y NTU6IDE5NzcyNA0KICAgIGRldi5peGwuMS5tYWMucnhfZnJhbWVzXzY1XzEyNzogMTAxODU5DQog ICAgZGV2Lml4bC4xLm1hYy5yeF9mcmFtZXNfNjQ6IDI0NDQNCiAgICBkZXYuaXhsLjEubWFjLnJ4 X2xlbmd0aF9lcnJvcnM6IDANCiAgICBkZXYuaXhsLjEubWFjLnJlbW90ZV9mYXVsdHM6IDANCiAg ICBkZXYuaXhsLjEubWFjLmxvY2FsX2ZhdWx0czogMA0KICAgIGRldi5peGwuMS5tYWMuaWxsZWdh bF9ieXRlczogMA0KICAgIGRldi5peGwuMS5tYWMuY3JjX2Vycm9yczogMA0KICAgIGRldi5peGwu MS5tYWMuYmNhc3RfcGt0c190eGQ6IDU4MQ0KICAgIGRldi5peGwuMS5tYWMubWNhc3RfcGt0c190 eGQ6IDQwOTg3DQogICAgZGV2Lml4bC4xLm1hYy51Y2FzdF9wa3RzX3R4ZDogMzU3MzQxOA0KICAg IGRldi5peGwuMS5tYWMuZ29vZF9vY3RldHNfdHhkOiA0Mzc2NjM2NTYNCiAgICBkZXYuaXhsLjEu bWFjLnJ4X2Rpc2NhcmRzOiAwDQogICAgZGV2Lml4bC4xLm1hYy5iY2FzdF9wa3RzX3JjdmQ6IDAN CiAgICBkZXYuaXhsLjEubWFjLm1jYXN0X3BrdHNfcmN2ZDogNDA5ODMNCiAgICBkZXYuaXhsLjEu bWFjLnVjYXN0X3BrdHNfcmN2ZDogMTE4NjA2NjM3DQogICAgZGV2Lml4bC4xLm1hYy5nb29kX29j dGV0c19yY3ZkOiAxNzk2ODIxNDkwNTQNCiAgICBkZXYuaXhsLjEucGYucXVlNy50eF9pdHI6IDUN CiAgICBkZXYuaXhsLjEucGYucXVlNy5yeF9pdHI6IDEzDQogICAgZGV2Lml4bC4xLnBmLnF1ZTcu cnhfZGVzY19lcnI6IDANCiAgICBkZXYuaXhsLjEucGYucXVlNy5yeF9ieXRlczogMTU5MDA2MTI1 NjINCiAgICBkZXYuaXhsLjEucGYucXVlNy5yeF9wYWNrZXRzOiAxMDUyODk2Nw0KICAgIGRldi5p eGwuMS5wZi5xdWU3LnR4X2J5dGVzOiAyNDI1MzIwOQ0KICAgIGRldi5peGwuMS5wZi5xdWU3LnR4 X3BhY2tldHM6IDM2NzI3NA0KICAgIGRldi5peGwuMS5wZi5xdWU3Lm5vX2Rlc2NfYXZhaWw6IDAN CiAgICBkZXYuaXhsLjEucGYucXVlNy5tc3NfdG9vX3NtYWxsOiAwDQogICAgZGV2Lml4bC4xLnBm LnF1ZTcudHhfZG1hbWFwX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMS5wZi5xdWU3LnRzb190eDog MA0KICAgIGRldi5peGwuMS5wZi5xdWU3LmlycXM6IDM5MzQ2Ng0KICAgIGRldi5peGwuMS5wZi5x dWU3Lm1idWZfZGVmcmFnX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMS5wZi5xdWU2LnR4X2l0cjog NQ0KICAgIGRldi5peGwuMS5wZi5xdWU2LnJ4X2l0cjogMjYNCiAgICBkZXYuaXhsLjEucGYucXVl Ni5yeF9kZXNjX2VycjogMA0KICAgIGRldi5peGwuMS5wZi5xdWU2LnJ4X2J5dGVzOiAzMTA3OTAw OTU4MQ0KICAgIGRldi5peGwuMS5wZi5xdWU2LnJ4X3BhY2tldHM6IDIwNTk2Nzk3DQogICAgZGV2 Lml4bC4xLnBmLnF1ZTYudHhfYnl0ZXM6IDM0NzA0ODcyDQogICAgZGV2Lml4bC4xLnBmLnF1ZTYu dHhfcGFja2V0czogNTI1MzA3DQogICAgZGV2Lml4bC4xLnBmLnF1ZTYubm9fZGVzY19hdmFpbDog MA0KICAgIGRldi5peGwuMS5wZi5xdWU2Lm1zc190b29fc21hbGw6IDANCiAgICBkZXYuaXhsLjEu cGYucXVlNi50eF9kbWFtYXBfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTYudHNvX3R4 OiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTYuaXJxczogMjUzNTEwDQogICAgZGV2Lml4bC4xLnBm LnF1ZTYubWJ1Zl9kZWZyYWdfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTUudHhfaXRy OiA1DQogICAgZGV2Lml4bC4xLnBmLnF1ZTUucnhfaXRyOiA2DQogICAgZGV2Lml4bC4xLnBmLnF1 ZTUucnhfZGVzY19lcnI6IDANCiAgICBkZXYuaXhsLjEucGYucXVlNS5yeF9ieXRlczogMzgyODE1 MzU0NTQNCiAgICBkZXYuaXhsLjEucGYucXVlNS5yeF9wYWNrZXRzOiAyNTI5NjU1OA0KICAgIGRl di5peGwuMS5wZi5xdWU1LnR4X2J5dGVzOiAzNzA0NDQyMg0KICAgIGRldi5peGwuMS5wZi5xdWU1 LnR4X3BhY2tldHM6IDU2MDc5Nw0KICAgIGRldi5peGwuMS5wZi5xdWU1Lm5vX2Rlc2NfYXZhaWw6 IDANCiAgICBkZXYuaXhsLjEucGYucXVlNS5tc3NfdG9vX3NtYWxsOiAwDQogICAgZGV2Lml4bC4x LnBmLnF1ZTUudHhfZG1hbWFwX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMS5wZi5xdWU1LnRzb190 eDogMA0KICAgIGRldi5peGwuMS5wZi5xdWU1LmlycXM6IDQ1ODg4Nw0KICAgIGRldi5peGwuMS5w Zi5xdWU1Lm1idWZfZGVmcmFnX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMS5wZi5xdWU0LnR4X2l0 cjogNQ0KICAgIGRldi5peGwuMS5wZi5xdWU0LnJ4X2l0cjogMTENCiAgICBkZXYuaXhsLjEucGYu cXVlNC5yeF9kZXNjX2VycjogMA0KICAgIGRldi5peGwuMS5wZi5xdWU0LnJ4X2J5dGVzOiAyMjY3 OTE1MTUwOA0KICAgIGRldi5peGwuMS5wZi5xdWU0LnJ4X3BhY2tldHM6IDE0OTg4MzcxDQogICAg ZGV2Lml4bC4xLnBmLnF1ZTQudHhfYnl0ZXM6IDcyNzUxODcNCiAgICBkZXYuaXhsLjEucGYucXVl NC50eF9wYWNrZXRzOiAxMDk2NDENCiAgICBkZXYuaXhsLjEucGYucXVlNC5ub19kZXNjX2F2YWls OiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTQubXNzX3Rvb19zbWFsbDogMA0KICAgIGRldi5peGwu MS5wZi5xdWU0LnR4X2RtYW1hcF9mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjEucGYucXVlNC50c29f dHg6IDANCiAgICBkZXYuaXhsLjEucGYucXVlNC5pcnFzOiAzNTU3MzMNCiAgICBkZXYuaXhsLjEu cGYucXVlNC5tYnVmX2RlZnJhZ19mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjEucGYucXVlMy50eF9p dHI6IDUNCiAgICBkZXYuaXhsLjEucGYucXVlMy5yeF9pdHI6IDYNCiAgICBkZXYuaXhsLjEucGYu cXVlMy5yeF9kZXNjX2VycjogMA0KICAgIGRldi5peGwuMS5wZi5xdWUzLnJ4X2J5dGVzOiAxNjU3 NjAzNjg0NQ0KICAgIGRldi5peGwuMS5wZi5xdWUzLnJ4X3BhY2tldHM6IDEwOTU5MjUyDQogICAg ZGV2Lml4bC4xLnBmLnF1ZTMudHhfYnl0ZXM6IDQzOTA5NjM1DQogICAgZGV2Lml4bC4xLnBmLnF1 ZTMudHhfcGFja2V0czogNTYwNDk0DQogICAgZGV2Lml4bC4xLnBmLnF1ZTMubm9fZGVzY19hdmFp bDogMA0KICAgIGRldi5peGwuMS5wZi5xdWUzLm1zc190b29fc21hbGw6IDANCiAgICBkZXYuaXhs LjEucGYucXVlMy50eF9kbWFtYXBfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTMudHNv X3R4OiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTMuaXJxczogNTUzNDIyDQogICAgZGV2Lml4bC4x LnBmLnF1ZTMubWJ1Zl9kZWZyYWdfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTIudHhf aXRyOiA1DQogICAgZGV2Lml4bC4xLnBmLnF1ZTIucnhfaXRyOiAxMQ0KICAgIGRldi5peGwuMS5w Zi5xdWUyLnJ4X2Rlc2NfZXJyOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTIucnhfYnl0ZXM6IDc5 OTE1MzIxMTkNCiAgICBkZXYuaXhsLjEucGYucXVlMi5yeF9wYWNrZXRzOiA1MjkwOTc2DQogICAg ZGV2Lml4bC4xLnBmLnF1ZTIudHhfYnl0ZXM6IDM0ODAxMDE1DQogICAgZGV2Lml4bC4xLnBmLnF1 ZTIudHhfcGFja2V0czogNTIzMjU2DQogICAgZGV2Lml4bC4xLnBmLnF1ZTIubm9fZGVzY19hdmFp bDogMA0KICAgIGRldi5peGwuMS5wZi5xdWUyLm1zc190b29fc21hbGw6IDANCiAgICBkZXYuaXhs LjEucGYucXVlMi50eF9kbWFtYXBfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTIudHNv X3R4OiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTIuaXJxczogNTQ1ODg5DQogICAgZGV2Lml4bC4x LnBmLnF1ZTIubWJ1Zl9kZWZyYWdfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTEudHhf aXRyOiA1DQogICAgZGV2Lml4bC4xLnBmLnF1ZTEucnhfaXRyOiAxNw0KICAgIGRldi5peGwuMS5w Zi5xdWUxLnJ4X2Rlc2NfZXJyOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTEucnhfYnl0ZXM6IDMy NzI4NTU2ODM2DQogICAgZGV2Lml4bC4xLnBmLnF1ZTEucnhfcGFja2V0czogMjE2Njc3MDgNCiAg ICBkZXYuaXhsLjEucGYucXVlMS50eF9ieXRlczogMTQ2OTkwNjk0DQogICAgZGV2Lml4bC4xLnBm LnF1ZTEudHhfcGFja2V0czogMzk0Njk0DQogICAgZGV2Lml4bC4xLnBmLnF1ZTEubm9fZGVzY19h dmFpbDogMA0KICAgIGRldi5peGwuMS5wZi5xdWUxLm1zc190b29fc21hbGw6IDANCiAgICBkZXYu aXhsLjEucGYucXVlMS50eF9kbWFtYXBfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTEu dHNvX3R4OiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTEuaXJxczogNDQ3Njk0DQogICAgZGV2Lml4 bC4xLnBmLnF1ZTEubWJ1Zl9kZWZyYWdfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTAu dHhfaXRyOiA1DQogICAgZGV2Lml4bC4xLnBmLnF1ZTAucnhfaXRyOiA1DQogICAgZGV2Lml4bC4x LnBmLnF1ZTAucnhfZGVzY19lcnI6IDANCiAgICBkZXYuaXhsLjEucGYucXVlMC5yeF9ieXRlczog MTM5NjUyMjkwODANCiAgICBkZXYuaXhsLjEucGYucXVlMC5yeF9wYWNrZXRzOiA5MjY2NzE0DQog ICAgZGV2Lml4bC4xLnBmLnF1ZTAudHhfYnl0ZXM6IDg5NzA5NzQ5DQogICAgZGV2Lml4bC4xLnBm LnF1ZTAudHhfcGFja2V0czogNTIyODg3DQogICAgZGV2Lml4bC4xLnBmLnF1ZTAubm9fZGVzY19h dmFpbDogMA0KICAgIGRldi5peGwuMS5wZi5xdWUwLm1zc190b29fc21hbGw6IDANCiAgICBkZXYu aXhsLjEucGYucXVlMC50eF9kbWFtYXBfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTAu dHNvX3R4OiAwDQogICAgZGV2Lml4bC4xLnBmLnF1ZTAuaXJxczogMzg1OTEwDQogICAgZGV2Lml4 bC4xLnBmLnF1ZTAubWJ1Zl9kZWZyYWdfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4xLnBmLmJjYXN0 X3BrdHNfdHhkOiA2DQogICAgZGV2Lml4bC4xLnBmLm1jYXN0X3BrdHNfdHhkOiAxDQogICAgZGV2 Lml4bC4xLnBmLnVjYXN0X3BrdHNfdHhkOiAzNDgwNzU2DQogICAgZGV2Lml4bC4xLnBmLmdvb2Rf b2N0ZXRzX3R4ZDogMjkyMjc1MDgzDQogICAgZGV2Lml4bC4xLnBmLnJ4X2Rpc2NhcmRzOiAxMTU4 DQogICAgZGV2Lml4bC4xLnBmLmJjYXN0X3BrdHNfcmN2ZDogMA0KICAgIGRldi5peGwuMS5wZi5t Y2FzdF9wa3RzX3JjdmQ6IDANCiAgICBkZXYuaXhsLjEucGYudWNhc3RfcGt0c19yY3ZkOiAxMTg1 NjI5MDgNCiAgICBkZXYuaXhsLjEucGYuZ29vZF9vY3RldHNfcmN2ZDogMTc5Njc1MzM1MzUxDQog ICAgZGV2Lml4bC4xLmFkbWluX2lycTogMA0KICAgIGRldi5peGwuMS53YXRjaGRvZ19ldmVudHM6 IDANCiAgICBkZXYuaXhsLjEuZHluYW1pY190eF9pdHI6IDENCiAgICBkZXYuaXhsLjEuZHluYW1p Y19yeF9pdHI6IDENCiAgICBkZXYuaXhsLjEucnhfaXRyOiA2Mg0KICAgIGRldi5peGwuMS50eF9p dHI6IDEyMg0KICAgIGRldi5peGwuMS51bmFsbG9jYXRlZF9xdWV1ZXM6IDc2MA0KICAgIGRldi5p eGwuMS5md192ZXJzaW9uOiBmdyA1LjAuNDAwNDMgYXBpIDEuNSBudm0gNS4wNSBldGlkIDgwMDAy ODkyIG9lbSANCiAgICAxLjI2Mi4wDQogICAgZGV2Lml4bC4xLmN1cnJlbnRfc3BlZWQ6IDEwIEdi cHMNCiAgICBkZXYuaXhsLjEuYWR2ZXJ0aXNlX3NwZWVkOiA2DQogICAgZGV2Lml4bC4xLmZjOiAw DQogICAgZGV2Lml4bC4xLiVwYXJlbnQ6IHBjaTENCiAgICBkZXYuaXhsLjEuJXBucGluZm86IHZl bmRvcj0weDgwODYgZGV2aWNlPTB4MTU3MiBzdWJ2ZW5kb3I9MHg4MDg2IA0KICAgIHN1YmRldmlj ZT0weDAwMDAgY2xhc3M9MHgwMjAwMDANCiAgICBkZXYuaXhsLjEuJWxvY2F0aW9uOiBzbG90PTAg ZnVuY3Rpb249MSBkYnNmPXBjaTA6MTowOjENCiAgICBkZXYuaXhsLjEuJWRyaXZlcjogaXhsDQog ICAgZGV2Lml4bC4xLiVkZXNjOiBJbnRlbChSKSBFdGhlcm5ldCBDb25uZWN0aW9uIFhMNzEwL1g3 MjIgRHJpdmVyLCBWZXJzaW9uIA0KICAgIC0gMS43LjEyLWsNCiAgICBkZXYuaXhsLjAud2FrZTog MA0KICAgIGRldi5peGwuMC5tYWMueG9mZl9yZWN2ZDogMA0KICAgIGRldi5peGwuMC5tYWMueG9m Zl90eGQ6IDANCiAgICBkZXYuaXhsLjAubWFjLnhvbl9yZWN2ZDogMA0KICAgIGRldi5peGwuMC5t YWMueG9uX3R4ZDogMA0KICAgIGRldi5peGwuMC5tYWMudHhfZnJhbWVzX2JpZzogMA0KICAgIGRl di5peGwuMC5tYWMudHhfZnJhbWVzXzEwMjRfMTUyMjogMTE4MzM5MjEyDQogICAgZGV2Lml4bC4w Lm1hYy50eF9mcmFtZXNfNTEyXzEwMjM6IDI1NTUNCiAgICBkZXYuaXhsLjAubWFjLnR4X2ZyYW1l c18yNTZfNTExOiAyNDg1DQogICAgZGV2Lml4bC4wLm1hYy50eF9mcmFtZXNfMTI4XzI1NTogMTk3 MjEzDQogICAgZGV2Lml4bC4wLm1hYy50eF9mcmFtZXNfNjVfMTI3OiA0MTQyOA0KICAgIGRldi5p eGwuMC5tYWMudHhfZnJhbWVzXzY0OiA0DQogICAgZGV2Lml4bC4wLm1hYy5jaGVja3N1bV9lcnJv cnM6IDANCiAgICBkZXYuaXhsLjAubWFjLnJ4X2phYmJlcjogMA0KICAgIGRldi5peGwuMC5tYWMu cnhfb3ZlcnNpemVkOiAwDQogICAgZGV2Lml4bC4wLm1hYy5yeF9mcmFnbWVudGVkOiAwDQogICAg ZGV2Lml4bC4wLm1hYy5yeF91bmRlcnNpemU6IDANCiAgICBkZXYuaXhsLjAubWFjLnJ4X2ZyYW1l c19iaWc6IDANCiAgICBkZXYuaXhsLjAubWFjLnJ4X2ZyYW1lc18xMDI0XzE1MjI6IDANCiAgICBk ZXYuaXhsLjAubWFjLnJ4X2ZyYW1lc181MTJfMTAyMzogMQ0KICAgIGRldi5peGwuMC5tYWMucnhf ZnJhbWVzXzI1Nl81MTE6IDINCiAgICBkZXYuaXhsLjAubWFjLnJ4X2ZyYW1lc18xMjhfMjU1OiAw DQogICAgZGV2Lml4bC4wLm1hYy5yeF9mcmFtZXNfNjVfMTI3OiAzNDc2Mjc4DQogICAgZGV2Lml4 bC4wLm1hYy5yeF9mcmFtZXNfNjQ6IDYwMA0KICAgIGRldi5peGwuMC5tYWMucnhfbGVuZ3RoX2Vy cm9yczogMA0KICAgIGRldi5peGwuMC5tYWMucmVtb3RlX2ZhdWx0czogMA0KICAgIGRldi5peGwu MC5tYWMubG9jYWxfZmF1bHRzOiAwDQogICAgZGV2Lml4bC4wLm1hYy5pbGxlZ2FsX2J5dGVzOiAw DQogICAgZGV2Lml4bC4wLm1hYy5jcmNfZXJyb3JzOiAwDQogICAgZGV2Lml4bC4wLm1hYy5iY2Fz dF9wa3RzX3R4ZDogMw0KICAgIGRldi5peGwuMC5tYWMubWNhc3RfcGt0c190eGQ6IDQwOTg4DQog ICAgZGV2Lml4bC4wLm1hYy51Y2FzdF9wa3RzX3R4ZDogMTE4NTQxOTA2DQogICAgZGV2Lml4bC4w Lm1hYy5nb29kX29jdGV0c190eGQ6IDE3OTY3NTU3NTIzNw0KICAgIGRldi5peGwuMC5tYWMucnhf ZGlzY2FyZHM6IDANCiAgICBkZXYuaXhsLjAubWFjLmJjYXN0X3BrdHNfcmN2ZDogMA0KICAgIGRl di5peGwuMC5tYWMubWNhc3RfcGt0c19yY3ZkOiA0MDk4Mw0KICAgIGRldi5peGwuMC5tYWMudWNh c3RfcGt0c19yY3ZkOiAzNDM1ODk4DQogICAgZGV2Lml4bC4wLm1hYy5nb29kX29jdGV0c19yY3Zk OiAyNDQxNzk0MjYNCiAgICBkZXYuaXhsLjAucGYucXVlNy50eF9pdHI6IDE3DQogICAgZGV2Lml4 bC4wLnBmLnF1ZTcucnhfaXRyOiA1DQogICAgZGV2Lml4bC4wLnBmLnF1ZTcucnhfZGVzY19lcnI6 IDANCiAgICBkZXYuaXhsLjAucGYucXVlNy5yeF9ieXRlczogMzE5OTgzMjYNCiAgICBkZXYuaXhs LjAucGYucXVlNy5yeF9wYWNrZXRzOiA0ODQ3NDINCiAgICBkZXYuaXhsLjAucGYucXVlNy50eF9i eXRlczogMzEwNzkwMDk2MDENCiAgICBkZXYuaXhsLjAucGYucXVlNy50eF9wYWNrZXRzOiAyMDU5 Njc5Nw0KICAgIGRldi5peGwuMC5wZi5xdWU3Lm5vX2Rlc2NfYXZhaWw6IDANCiAgICBkZXYuaXhs LjAucGYucXVlNy5tc3NfdG9vX3NtYWxsOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1ZTcudHhfZG1h bWFwX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMC5wZi5xdWU3LnRzb190eDogMA0KICAgIGRldi5p eGwuMC5wZi5xdWU3LmlycXM6IDI0MzYxOTINCiAgICBkZXYuaXhsLjAucGYucXVlNy5tYnVmX2Rl ZnJhZ19mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjAucGYucXVlNi50eF9pdHI6IDE3DQogICAgZGV2 Lml4bC4wLnBmLnF1ZTYucnhfaXRyOiA1DQogICAgZGV2Lml4bC4wLnBmLnF1ZTYucnhfZGVzY19l cnI6IDANCiAgICBkZXYuaXhsLjAucGYucXVlNi5yeF9ieXRlczogMjQyNTI2MTANCiAgICBkZXYu aXhsLjAucGYucXVlNi5yeF9wYWNrZXRzOiAzNjcyNjYNCiAgICBkZXYuaXhsLjAucGYucXVlNi50 eF9ieXRlczogMzgyODEyOTI4MTYNCiAgICBkZXYuaXhsLjAucGYucXVlNi50eF9wYWNrZXRzOiAy NTI5NTMzMA0KICAgIGRldi5peGwuMC5wZi5xdWU2Lm5vX2Rlc2NfYXZhaWw6IDANCiAgICBkZXYu aXhsLjAucGYucXVlNi5tc3NfdG9vX3NtYWxsOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1ZTYudHhf ZG1hbWFwX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMC5wZi5xdWU2LnRzb190eDogMA0KICAgIGRl di5peGwuMC5wZi5xdWU2LmlycXM6IDI2MDY3OTgNCiAgICBkZXYuaXhsLjAucGYucXVlNi5tYnVm X2RlZnJhZ19mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjAucGYucXVlNS50eF9pdHI6IDI1DQogICAg ZGV2Lml4bC4wLnBmLnF1ZTUucnhfaXRyOiA1DQogICAgZGV2Lml4bC4wLnBmLnF1ZTUucnhfZGVz Y19lcnI6IDANCiAgICBkZXYuaXhsLjAucGYucXVlNS5yeF9ieXRlczogMzQ2OTk5MTQNCiAgICBk ZXYuaXhsLjAucGYucXVlNS5yeF9wYWNrZXRzOiA1MjUyODkNCiAgICBkZXYuaXhsLjAucGYucXVl NS50eF9ieXRlczogMjI2NzkxNDk4OTMNCiAgICBkZXYuaXhsLjAucGYucXVlNS50eF9wYWNrZXRz OiAxNDk4ODM1Ng0KICAgIGRldi5peGwuMC5wZi5xdWU1Lm5vX2Rlc2NfYXZhaWw6IDANCiAgICBk ZXYuaXhsLjAucGYucXVlNS5tc3NfdG9vX3NtYWxsOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1ZTUu dHhfZG1hbWFwX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMC5wZi5xdWU1LnRzb190eDogMA0KICAg IGRldi5peGwuMC5wZi5xdWU1LmlycXM6IDIxMDg2NDUNCiAgICBkZXYuaXhsLjAucGYucXVlNS5t YnVmX2RlZnJhZ19mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjAucGYucXVlNC50eF9pdHI6IDI1DQog ICAgZGV2Lml4bC4wLnBmLnF1ZTQucnhfaXRyOiA1DQogICAgZGV2Lml4bC4wLnBmLnF1ZTQucnhf ZGVzY19lcnI6IDANCiAgICBkZXYuaXhsLjAucGYucXVlNC5yeF9ieXRlczogMzcwNDUwMjQNCiAg ICBkZXYuaXhsLjAucGYucXVlNC5yeF9wYWNrZXRzOiA1NjA3OTMNCiAgICBkZXYuaXhsLjAucGYu cXVlNC50eF9ieXRlczogMTY1NzU5NzE2MDANCiAgICBkZXYuaXhsLjAucGYucXVlNC50eF9wYWNr ZXRzOiAxMDk1ODM1Mg0KICAgIGRldi5peGwuMC5wZi5xdWU0Lm5vX2Rlc2NfYXZhaWw6IDANCiAg ICBkZXYuaXhsLjAucGYucXVlNC5tc3NfdG9vX3NtYWxsOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1 ZTQudHhfZG1hbWFwX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMC5wZi5xdWU0LnRzb190eDogMA0K ICAgIGRldi5peGwuMC5wZi5xdWU0LmlycXM6IDE0MDQ1NTANCiAgICBkZXYuaXhsLjAucGYucXVl NC5tYnVmX2RlZnJhZ19mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjAucGYucXVlMy50eF9pdHI6IDI1 DQogICAgZGV2Lml4bC4wLnBmLnF1ZTMucnhfaXRyOiA2DQogICAgZGV2Lml4bC4wLnBmLnF1ZTMu cnhfZGVzY19lcnI6IDANCiAgICBkZXYuaXhsLjAucGYucXVlMy5yeF9ieXRlczogNzEzODU5MA0K ICAgIGRldi5peGwuMC5wZi5xdWUzLnJ4X3BhY2tldHM6IDEwODA0MA0KICAgIGRldi5peGwuMC5w Zi5xdWUzLnR4X2J5dGVzOiA3OTkxNTI5MTQ3DQogICAgZGV2Lml4bC4wLnBmLnF1ZTMudHhfcGFj a2V0czogNTI5MDk0MA0KICAgIGRldi5peGwuMC5wZi5xdWUzLm5vX2Rlc2NfYXZhaWw6IDANCiAg ICBkZXYuaXhsLjAucGYucXVlMy5tc3NfdG9vX3NtYWxsOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1 ZTMudHhfZG1hbWFwX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMC5wZi5xdWUzLnRzb190eDogMA0K ICAgIGRldi5peGwuMC5wZi5xdWUzLmlycXM6IDU4MzI3NA0KICAgIGRldi5peGwuMC5wZi5xdWUz Lm1idWZfZGVmcmFnX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMC5wZi5xdWUyLnR4X2l0cjogMjUN CiAgICBkZXYuaXhsLjAucGYucXVlMi5yeF9pdHI6IDUNCiAgICBkZXYuaXhsLjAucGYucXVlMi5y eF9kZXNjX2VycjogMA0KICAgIGRldi5peGwuMC5wZi5xdWUyLnJ4X2J5dGVzOiAzNjY3NDk2Ng0K ICAgIGRldi5peGwuMC5wZi5xdWUyLnJ4X3BhY2tldHM6IDU1NTY3Ng0KICAgIGRldi5peGwuMC5w Zi5xdWUyLnR4X2J5dGVzOiAzMjcyODU1NDA3Mw0KICAgIGRldi5peGwuMC5wZi5xdWUyLnR4X3Bh Y2tldHM6IDIxNjY3NjkxDQogICAgZGV2Lml4bC4wLnBmLnF1ZTIubm9fZGVzY19hdmFpbDogMA0K ICAgIGRldi5peGwuMC5wZi5xdWUyLm1zc190b29fc21hbGw6IDANCiAgICBkZXYuaXhsLjAucGYu cXVlMi50eF9kbWFtYXBfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1ZTIudHNvX3R4OiAw DQogICAgZGV2Lml4bC4wLnBmLnF1ZTIuaXJxczogMjQ3NjQ1OA0KICAgIGRldi5peGwuMC5wZi5x dWUyLm1idWZfZGVmcmFnX2ZhaWxlZDogMA0KICAgIGRldi5peGwuMC5wZi5xdWUxLnR4X2l0cjog MTcNCiAgICBkZXYuaXhsLjAucGYucXVlMS5yeF9pdHI6IDUNCiAgICBkZXYuaXhsLjAucGYucXVl MS5yeF9kZXNjX2VycjogMA0KICAgIGRldi5peGwuMC5wZi5xdWUxLnJ4X2J5dGVzOiAzNDUyMDI1 Mg0KICAgIGRldi5peGwuMC5wZi5xdWUxLnJ4X3BhY2tldHM6IDUyMzAyOA0KICAgIGRldi5peGwu MC5wZi5xdWUxLnR4X2J5dGVzOiAxMzk2Mjg1MDgxNA0KICAgIGRldi5peGwuMC5wZi5xdWUxLnR4 X3BhY2tldHM6IDkyMzI0NzUNCiAgICBkZXYuaXhsLjAucGYucXVlMS5ub19kZXNjX2F2YWlsOiAw DQogICAgZGV2Lml4bC4wLnBmLnF1ZTEubXNzX3Rvb19zbWFsbDogMA0KICAgIGRldi5peGwuMC5w Zi5xdWUxLnR4X2RtYW1hcF9mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjAucGYucXVlMS50c29fdHg6 IDANCiAgICBkZXYuaXhsLjAucGYucXVlMS5pcnFzOiAxNTY2MDQyDQogICAgZGV2Lml4bC4wLnBm LnF1ZTEubWJ1Zl9kZWZyYWdfZmFpbGVkOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1ZTAudHhfaXRy OiAxNw0KICAgIGRldi5peGwuMC5wZi5xdWUwLnJ4X2l0cjogNQ0KICAgIGRldi5peGwuMC5wZi5x dWUwLnJ4X2Rlc2NfZXJyOiAwDQogICAgZGV2Lml4bC4wLnBmLnF1ZTAucnhfYnl0ZXM6IDIwNTQw NjMxDQogICAgZGV2Lml4bC4wLnBmLnF1ZTAucnhfcGFja2V0czogMzExMDY0DQogICAgZGV2Lml4 bC4wLnBmLnF1ZTAudHhfYnl0ZXM6IDE1ODk5NDg0MDQ4DQogICAgZGV2Lml4bC4wLnBmLnF1ZTAu dHhfcGFja2V0czogMTA1MTE5NzMNCiAgICBkZXYuaXhsLjAucGYucXVlMC5ub19kZXNjX2F2YWls OiAwDQogICAgZGV2Lml4bC4wLnBmLnF1ZTAubXNzX3Rvb19zbWFsbDogMA0KICAgIGRldi5peGwu MC5wZi5xdWUwLnR4X2RtYW1hcF9mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjAucGYucXVlMC50c29f dHg6IDANCiAgICBkZXYuaXhsLjAucGYucXVlMC5pcnFzOiA5NTA5NTUNCiAgICBkZXYuaXhsLjAu cGYucXVlMC5tYnVmX2RlZnJhZ19mYWlsZWQ6IDANCiAgICBkZXYuaXhsLjAucGYuYmNhc3RfcGt0 c190eGQ6IDINCiAgICBkZXYuaXhsLjAucGYubWNhc3RfcGt0c190eGQ6IDINCiAgICBkZXYuaXhs LjAucGYudWNhc3RfcGt0c190eGQ6IDExODU0MTkwNg0KICAgIGRldi5peGwuMC5wZi5nb29kX29j dGV0c190eGQ6IDE3OTE5Nzg0MTY2NA0KICAgIGRldi5peGwuMC5wZi5yeF9kaXNjYXJkczogMA0K ICAgIGRldi5peGwuMC5wZi5iY2FzdF9wa3RzX3JjdmQ6IDANCiAgICBkZXYuaXhsLjAucGYubWNh c3RfcGt0c19yY3ZkOiAwDQogICAgZGV2Lml4bC4wLnBmLnVjYXN0X3BrdHNfcmN2ZDogMzQzNTg5 OA0KICAgIGRldi5peGwuMC5wZi5nb29kX29jdGV0c19yY3ZkOiAyNDA2MTM5MDUNCiAgICBkZXYu aXhsLjAuYWRtaW5faXJxOiAwDQogICAgZGV2Lml4bC4wLndhdGNoZG9nX2V2ZW50czogMA0KICAg IGRldi5peGwuMC5keW5hbWljX3R4X2l0cjogMQ0KICAgIGRldi5peGwuMC5keW5hbWljX3J4X2l0 cjogMQ0KICAgIGRldi5peGwuMC5yeF9pdHI6IDYyDQogICAgZGV2Lml4bC4wLnR4X2l0cjogMTIy DQogICAgZGV2Lml4bC4wLnVuYWxsb2NhdGVkX3F1ZXVlczogNzYwDQogICAgZGV2Lml4bC4wLmZ3 X3ZlcnNpb246IGZ3IDUuMC40MDA0MyBhcGkgMS41IG52bSA1LjA1IGV0aWQgODAwMDI4OTIgb2Vt IA0KICAgIDEuMjYyLjANCiAgICBkZXYuaXhsLjAuY3VycmVudF9zcGVlZDogMTAgR2Jwcw0KICAg IGRldi5peGwuMC5hZHZlcnRpc2Vfc3BlZWQ6IDYNCiAgICBkZXYuaXhsLjAuZmM6IDANCiAgICBk ZXYuaXhsLjAuJXBhcmVudDogcGNpMQ0KICAgIGRldi5peGwuMC4lcG5waW5mbzogdmVuZG9yPTB4 ODA4NiBkZXZpY2U9MHgxNTcyIHN1YnZlbmRvcj0weDgwODYgDQogICAgc3ViZGV2aWNlPTB4MDAw OCBjbGFzcz0weDAyMDAwMA0KICAgIGRldi5peGwuMC4lbG9jYXRpb246IHNsb3Q9MCBmdW5jdGlv bj0wIGRic2Y9cGNpMDoxOjA6MCANCiAgICBoYW5kbGU9XF9TQl8uUENJMC5QRUcwLlBFR1ANCiAg ICBkZXYuaXhsLjAuJWRyaXZlcjogaXhsDQogICAgZGV2Lml4bC4wLiVkZXNjOiBJbnRlbChSKSBF dGhlcm5ldCBDb25uZWN0aW9uIFhMNzEwL1g3MjIgRHJpdmVyLCBWZXJzaW9uIA0KICAgIC0gMS43 LjEyLWsNCiAgICBkZXYuaXhsLiVwYXJlbnQ6DQogICAgZGV2Lm5ldG1hcC5peGxfcnhfbWlzc19i dWZzOiAzMDUNCiAgICBkZXYubmV0bWFwLml4bF9yeF9taXNzOiAyNTUNCiAgICANCiAgICANCiAg ICANCiAgICANCiAgICByb290QE9QTnNlbnNlOn4gIyBzeXNjdGwgLWEgfCBncmVwIG5ldA0KICAg IGtlcm4uZmVhdHVyZXMuaW5ldDY6IDENCiAgICBrZXJuLmZlYXR1cmVzLmluZXQ6IDENCiAgICBk ZXZpY2UgIHZ0bmV0DQogICAgZGV2aWNlICBuZXRtYXANCiAgICBuZXQubG9jYWwuc3RyZWFtLnJl Y3ZzcGFjZTogODE5Mg0KICAgIG5ldC5sb2NhbC5zdHJlYW0uc2VuZHNwYWNlOiA4MTkyDQogICAg bmV0LmxvY2FsLmRncmFtLnJlY3ZzcGFjZTogNDA5Ng0KICAgIG5ldC5sb2NhbC5kZ3JhbS5tYXhk Z3JhbTogMjA0OA0KICAgIG5ldC5sb2NhbC5zZXFwYWNrZXQucmVjdnNwYWNlOiA4MTkyDQogICAg bmV0LmxvY2FsLnNlcXBhY2tldC5tYXhzZXFwYWNrZXQ6IDgxOTINCiAgICBuZXQubG9jYWwudGFz a2NvdW50OiAzDQogICAgbmV0LmxvY2FsLnJlY3ljbGVkOiAwDQogICAgbmV0LmxvY2FsLmRlZmVy cmVkOiAwDQogICAgbmV0LmxvY2FsLmluZmxpZ2h0OiAwDQogICAgbmV0LmluZXQuaXAucG9ydHJh bmdlLnJhbmRvbXRpbWU6IDQ1DQogICAgbmV0LmluZXQuaXAucG9ydHJhbmdlLnJhbmRvbWNwczog MTANCiAgICBuZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmFuZG9taXplZDogMQ0KICAgIG5ldC5pbmV0 LmlwLnBvcnRyYW5nZS5yZXNlcnZlZGxvdzogMA0KICAgIG5ldC5pbmV0LmlwLnBvcnRyYW5nZS5y ZXNlcnZlZGhpZ2g6IDEwMjMNCiAgICBuZXQuaW5ldC5pcC5wb3J0cmFuZ2UuaGlsYXN0OiA2NTUz NQ0KICAgIG5ldC5pbmV0LmlwLnBvcnRyYW5nZS5oaWZpcnN0OiA0OTE1Mg0KICAgIG5ldC5pbmV0 LmlwLnBvcnRyYW5nZS5sYXN0OiA2NTUzNQ0KICAgIG5ldC5pbmV0LmlwLnBvcnRyYW5nZS5maXJz dDogMTAyNA0KICAgIG5ldC5pbmV0LmlwLnBvcnRyYW5nZS5sb3dsYXN0OiA2MDANCiAgICBuZXQu aW5ldC5pcC5wb3J0cmFuZ2UubG93Zmlyc3Q6IDEwMjMNCiAgICBuZXQuaW5ldC5pcC5mb3J3YXJk aW5nOiAxDQogICAgbmV0LmluZXQuaXAucmVkaXJlY3Q6IDENCiAgICBuZXQuaW5ldC5pcC50dGw6 IDY0DQogICAgbmV0LmluZXQuaXAuc291cmNlcm91dGU6IDANCiAgICBuZXQuaW5ldC5pcC5pbnRy X3F1ZXVlX21heGxlbjogMTAwMA0KICAgIG5ldC5pbmV0LmlwLmludHJfcXVldWVfZHJvcHM6IDAN CiAgICBuZXQuaW5ldC5pcC5hY2NlcHRfc291cmNlcm91dGU6IDANCiAgICBuZXQuaW5ldC5pcC5n aWZ0dGw6IDMwDQogICAgbmV0LmluZXQuaXAuZHVtbXluZXQuZnFwaWUubGltaXQ6IDEwMjQwDQog ICAgbmV0LmluZXQuaXAuZHVtbXluZXQuZnFwaWUuZmxvd3M6IDEwMjQNCiAgICBuZXQuaW5ldC5p cC5kdW1teW5ldC5mcXBpZS5xdWFudHVtOiAxNTE0DQogICAgbmV0LmluZXQuaXAuZHVtbXluZXQu ZnFwaWUuYmV0YTogMTI1MA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LmZxcGllLmFscGhhOiAx MjUNCiAgICBuZXQuaW5ldC5pcC5kdW1teW5ldC5mcXBpZS5tYXhfZWNudGg6IDk5DQogICAgbmV0 LmluZXQuaXAuZHVtbXluZXQuZnFwaWUubWF4X2J1cnN0OiAxNTAwMDANCiAgICBuZXQuaW5ldC5p cC5kdW1teW5ldC5mcXBpZS50dXBkYXRlOiAxNTAwMA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0 LmZxcGllLnRhcmdldDogMTUwMDANCiAgICBuZXQuaW5ldC5pcC5kdW1teW5ldC5mcWNvZGVsLmxp bWl0OiAxMDI0MA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LmZxY29kZWwuZmxvd3M6IDEwMjQN CiAgICBuZXQuaW5ldC5pcC5kdW1teW5ldC5mcWNvZGVsLnF1YW50dW06IDE1MTQNCiAgICBuZXQu aW5ldC5pcC5kdW1teW5ldC5mcWNvZGVsLmludGVydmFsOiAxMDAwMDANCiAgICBuZXQuaW5ldC5p cC5kdW1teW5ldC5mcWNvZGVsLnRhcmdldDogNTAwMA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0 LnBpZS5iZXRhOiAxMjUwDQogICAgbmV0LmluZXQuaXAuZHVtbXluZXQucGllLmFscGhhOiAxMjUN CiAgICBuZXQuaW5ldC5pcC5kdW1teW5ldC5waWUubWF4X2VjbnRoOiA5OQ0KICAgIG5ldC5pbmV0 LmlwLmR1bW15bmV0LnBpZS5tYXhfYnVyc3Q6IDE1MDAwMA0KICAgIG5ldC5pbmV0LmlwLmR1bW15 bmV0LnBpZS50dXBkYXRlOiAxNTAwMA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LnBpZS50YXJn ZXQ6IDE1MDAwDQogICAgbmV0LmluZXQuaXAuZHVtbXluZXQuY29kZWwuaW50ZXJ2YWw6IDEwMDAw MA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LmNvZGVsLnRhcmdldDogNTAwMA0KICAgIG5ldC5p bmV0LmlwLmR1bW15bmV0LmlvX3BrdF9kcm9wOiAwDQogICAgbmV0LmluZXQuaXAuZHVtbXluZXQu aW9fcGt0X2Zhc3Q6IDANCiAgICBuZXQuaW5ldC5pcC5kdW1teW5ldC5pb19wa3Q6IDANCiAgICBu ZXQuaW5ldC5pcC5kdW1teW5ldC5xdWV1ZV9jb3VudDogMA0KICAgIG5ldC5pbmV0LmlwLmR1bW15 bmV0LmZza19jb3VudDogMg0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LnNpX2NvdW50OiAwDQog ICAgbmV0LmluZXQuaXAuZHVtbXluZXQuc2Noa19jb3VudDogMg0KICAgIG5ldC5pbmV0LmlwLmR1 bW15bmV0LmV4cGlyZV9jeWNsZTogMA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LmV4cGlyZTog MQ0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LnRpY2tfbG9zdDogMA0KICAgIG5ldC5pbmV0Lmlw LmR1bW15bmV0LnRpY2tfZGlmZjogMzY4MA0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LnRpY2tf YWRqdXN0bWVudDogMjM0DQogICAgbmV0LmluZXQuaXAuZHVtbXluZXQudGlja19kZWx0YV9zdW06 IC00NTINCiAgICBuZXQuaW5ldC5pcC5kdW1teW5ldC50aWNrX2RlbHRhOiAxDQogICAgbmV0Lmlu ZXQuaXAuZHVtbXluZXQucmVkX21heF9wa3Rfc2l6ZTogMTUwMA0KICAgIG5ldC5pbmV0LmlwLmR1 bW15bmV0LnJlZF9hdmdfcGt0X3NpemU6IDUxMg0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LnJl ZF9sb29rdXBfZGVwdGg6IDI1Ng0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LmRlYnVnOiAwDQog ICAgbmV0LmluZXQuaXAuZHVtbXluZXQuaW9fZmFzdDogMQ0KICAgIG5ldC5pbmV0LmlwLmR1bW15 bmV0LnBpcGVfYnl0ZV9saW1pdDogMTA0ODU3Ng0KICAgIG5ldC5pbmV0LmlwLmR1bW15bmV0LnBp cGVfc2xvdF9saW1pdDogMTAwDQogICAgbmV0LmluZXQuaXAuZHVtbXluZXQuaGFzaF9zaXplOiAy NTYNCiAgICBuZXQuaW5ldC5pcC5mdy5keW5fa2VlcF9zdGF0ZXM6IDANCiAgICBuZXQuaW5ldC5p cC5mdy5keW5fa2VlcGFsaXZlOiAxDQogICAgbmV0LmluZXQuaXAuZncuZHluX3Nob3J0X2xpZmV0 aW1lOiA1DQogICAgbmV0LmluZXQuaXAuZncuZHluX3VkcF9saWZldGltZTogMTANCiAgICBuZXQu aW5ldC5pcC5mdy5keW5fcnN0X2xpZmV0aW1lOiAxDQogICAgbmV0LmluZXQuaXAuZncuZHluX2Zp bl9saWZldGltZTogMQ0KICAgIG5ldC5pbmV0LmlwLmZ3LmR5bl9zeW5fbGlmZXRpbWU6IDIwDQog ICAgbmV0LmluZXQuaXAuZncuZHluX2Fja19saWZldGltZTogMzAwDQogICAgbmV0LmluZXQuaXAu ZncuZHluX21heDogMTYzODQNCiAgICBuZXQuaW5ldC5pcC5mdy5keW5fY291bnQ6IDANCiAgICBu ZXQuaW5ldC5pcC5mdy5jdXJyX2R5bl9idWNrZXRzOiAyNTYNCiAgICBuZXQuaW5ldC5pcC5mdy5k eW5fYnVja2V0czogMjU2DQogICAgbmV0LmluZXQuaXAuZncuZW5hYmxlOiAxDQogICAgbmV0Lmlu ZXQuaXAuZncuc3RhdGljX2NvdW50OiAyOQ0KICAgIG5ldC5pbmV0LmlwLmZ3LmRlZmF1bHRfdG9f YWNjZXB0OiAxDQogICAgbmV0LmluZXQuaXAuZncudGFibGVzX3NldHM6IDANCiAgICBuZXQuaW5l dC5pcC5mdy50YWJsZXNfbWF4OiAxMjgNCiAgICBuZXQuaW5ldC5pcC5mdy5kZWZhdWx0X3J1bGU6 IDY1NTM1DQogICAgbmV0LmluZXQuaXAuZncudmVyYm9zZV9saW1pdDogMA0KICAgIG5ldC5pbmV0 LmlwLmZ3LnZlcmJvc2U6IDENCiAgICBuZXQuaW5ldC5pcC5mdy5hdXRvaW5jX3N0ZXA6IDEwMA0K ICAgIG5ldC5pbmV0LmlwLmZ3Lm9uZV9wYXNzOiAxDQogICAgbmV0LmluZXQuaXAuZ3JldHRsOiAz MA0KICAgIG5ldC5pbmV0LmlwLm1heGZyYWdzcGVycGFja2V0OiAxNg0KICAgIG5ldC5pbmV0Lmlw LmZyYWdwYWNrZXRzOiAwDQogICAgbmV0LmluZXQuaXAubWF4ZnJhZ3BhY2tldHM6IDMxMzExDQog ICAgbmV0LmluZXQuaXAucHJvY2Vzc19vcHRpb25zOiAxDQogICAgbmV0LmluZXQuaXAuc3RlYWx0 aDogMA0KICAgIG5ldC5pbmV0LmlwLmNoZWNrX2ludGVyZmFjZTogMA0KICAgIG5ldC5pbmV0Lmlw Lm1jYXN0Lmxvb3A6IDENCiAgICBuZXQuaW5ldC5pcC5tY2FzdC5tYXhzb2Nrc3JjOiAxMjgNCiAg ICBuZXQuaW5ldC5pcC5tY2FzdC5tYXhncnBzcmM6IDUxMg0KICAgIG5ldC5pbmV0LmlwLnJhbmRv bV9pZF90b3RhbDogMTIwMTcyNw0KICAgIG5ldC5pbmV0LmlwLnJhbmRvbV9pZF9jb2xsaXNpb25z OiAxNzA3MDANCiAgICBuZXQuaW5ldC5pcC5yYW5kb21faWRfcGVyaW9kOiA4MTkyDQogICAgbmV0 LmluZXQuaXAucmZjNjg2NDogMQ0KICAgIG5ldC5pbmV0LmlwLnJhbmRvbV9pZDogMQ0KICAgIG5l dC5pbmV0LmlwLm5vX3NhbWVfcHJlZml4OiAwDQogICAgbmV0LmluZXQuaWNtcC5tYXNrcmVwbDog MA0KICAgIG5ldC5pbmV0LmljbXAuaWNtcGxpbTogMA0KICAgIG5ldC5pbmV0LmljbXAudHN0YW1w cmVwbDogMQ0KICAgIG5ldC5pbmV0LmljbXAuYm1jYXN0ZWNobzogMA0KICAgIG5ldC5pbmV0Lmlj bXAucXVvdGVsZW46IDgNCiAgICBuZXQuaW5ldC5pY21wLnJlcGx5X2Zyb21faW50ZXJmYWNlOiAw DQogICAgbmV0LmluZXQuaWNtcC5yZXBseV9zcmM6DQogICAgbmV0LmluZXQuaWNtcC5sb2dfcmVk aXJlY3Q6IDANCiAgICBuZXQuaW5ldC5pY21wLmRyb3BfcmVkaXJlY3Q6IDANCiAgICBuZXQuaW5l dC5pY21wLm1hc2tmYWtlOiAwDQogICAgbmV0LmluZXQuaWNtcC5pY21wbGltX291dHB1dDogMQ0K ICAgIG5ldC5pbmV0LmlnbXAuZ3NyZGVsYXk6IDEwDQogICAgbmV0LmluZXQuaWdtcC5kZWZhdWx0 X3ZlcnNpb246IDMNCiAgICBuZXQuaW5ldC5pZ21wLmxlZ2FjeXN1cHA6IDANCiAgICBuZXQuaW5l dC5pZ21wLnYyZW5hYmxlOiAxDQogICAgbmV0LmluZXQuaWdtcC52MWVuYWJsZTogMQ0KICAgIG5l dC5pbmV0LmlnbXAuc2VuZGxvY2FsOiAxDQogICAgbmV0LmluZXQuaWdtcC5zZW5kcmE6IDENCiAg ICBuZXQuaW5ldC5pZ21wLnJlY3ZpZmtsdWRnZTogMQ0KICAgIG5ldC5pbmV0LnRjcC5yZmMxMzIz OiAxDQogICAgbmV0LmluZXQudGNwLm1zc2RmbHQ6IDUzNg0KICAgIG5ldC5pbmV0LnRjcC5rZWVw aWRsZTogNzIwMDAwMA0KICAgIG5ldC5pbmV0LnRjcC5rZWVwaW50dmw6IDc1MDAwDQogICAgbmV0 LmluZXQudGNwLnNlbmRzcGFjZTogNjUyMjgNCiAgICBuZXQuaW5ldC50Y3AucmVjdnNwYWNlOiA2 NTIyOA0KICAgIG5ldC5pbmV0LnRjcC5rZWVwaW5pdDogNzUwMDANCiAgICBuZXQuaW5ldC50Y3Au ZGVsYWNrdGltZTogMTAwDQogICAgbmV0LmluZXQudGNwLnY2bXNzZGZsdDogMTIyMA0KICAgIG5l dC5pbmV0LnRjcC5ub2xvY2FsdGltZXdhaXQ6IDANCiAgICBuZXQuaW5ldC50Y3AubWF4dGNwdHc6 IDMyMjU1DQogICAgbmV0LmluZXQudGNwLnBlcl9jcHVfdGltZXJzOiAwDQogICAgbmV0LmluZXQu dGNwLnY2cG10dWRfYmxhY2tob2xlX21zczogMTIyMA0KICAgIG5ldC5pbmV0LnRjcC5wbXR1ZF9i bGFja2hvbGVfbXNzOiAxMjAwDQogICAgbmV0LmluZXQudGNwLnBtdHVkX2JsYWNraG9sZV9mYWls ZWQ6IDANCiAgICBuZXQuaW5ldC50Y3AucG10dWRfYmxhY2tob2xlX2FjdGl2YXRlZF9taW5fbXNz OiAwDQogICAgbmV0LmluZXQudGNwLnBtdHVkX2JsYWNraG9sZV9hY3RpdmF0ZWQ6IDANCiAgICBu ZXQuaW5ldC50Y3AucG10dWRfYmxhY2tob2xlX2RldGVjdGlvbjogMA0KICAgIG5ldC5pbmV0LnRj cC5yZXhtaXRfZHJvcF9vcHRpb25zOiAwDQogICAgbmV0LmluZXQudGNwLmtlZXBjbnQ6IDgNCiAg ICBuZXQuaW5ldC50Y3AuZmlud2FpdDJfdGltZW91dDogNjAwMDANCiAgICBuZXQuaW5ldC50Y3Au ZmFzdF9maW53YWl0Ml9yZWN5Y2xlOiAwDQogICAgbmV0LmluZXQudGNwLmFsd2F5c19rZWVwYWxp dmU6IDENCiAgICBuZXQuaW5ldC50Y3AucmV4bWl0X3Nsb3A6IDIwMA0KICAgIG5ldC5pbmV0LnRj cC5yZXhtaXRfbWluOiAzMA0KICAgIG5ldC5pbmV0LnRjcC5tc2w6IDMwMDAwDQogICAgbmV0Lmlu ZXQudGNwLnBlcnNtYXg6IDYwMDAwDQogICAgbmV0LmluZXQudGNwLnBlcnNtaW46IDUwMDANCiAg ICBuZXQuaW5ldC50Y3Auc3luY2FjaGUucnN0X29uX3NvY2tfZmFpbDogMQ0KICAgIG5ldC5pbmV0 LnRjcC5zeW5jYWNoZS5yZXhtdGxpbWl0OiAzDQogICAgbmV0LmluZXQudGNwLnN5bmNhY2hlLmhh c2hzaXplOiA1MTINCiAgICBuZXQuaW5ldC50Y3Auc3luY2FjaGUuY291bnQ6IDANCiAgICBuZXQu aW5ldC50Y3Auc3luY2FjaGUuY2FjaGVsaW1pdDogMTUzNjQNCiAgICBuZXQuaW5ldC50Y3Auc3lu Y2FjaGUuYnVja2V0bGltaXQ6IDMwDQogICAgbmV0LmluZXQudGNwLnN5bmNvb2tpZXNfb25seTog MA0KICAgIG5ldC5pbmV0LnRjcC5zeW5jb29raWVzOiAxDQogICAgbmV0LmluZXQudGNwLmZ1bmN0 aW9uc19hdmFpbGFibGU6DQogICAgbmV0LmluZXQudGNwLmZ1bmN0aW9uc19kZWZhdWx0OiBkZWZh dWx0DQogICAgbmV0LmluZXQudGNwLnNvcmVjZWl2ZV9zdHJlYW06IDANCiAgICBuZXQuaW5ldC50 Y3AuaXNuX3Jlc2VlZF9pbnRlcnZhbDogMA0KICAgIG5ldC5pbmV0LnRjcC5pY21wX21heV9yc3Q6 IDENCiAgICBuZXQuaW5ldC50Y3AucGNiY291bnQ6IDEwDQogICAgbmV0LmluZXQudGNwLmRvX3Rj cGRyYWluOiAxDQogICAgbmV0LmluZXQudGNwLnRjYmhhc2hzaXplOiAxMzEwNzINCiAgICBuZXQu aW5ldC50Y3AubG9nX2RlYnVnOiAwDQogICAgbmV0LmluZXQudGNwLm1pbm1zczogMjE2DQogICAg bmV0LmluZXQudGNwLnNhY2suZ2xvYmFsaG9sZXM6IDANCiAgICBuZXQuaW5ldC50Y3Auc2Fjay5n bG9iYWxtYXhob2xlczogNjU1MzYNCiAgICBuZXQuaW5ldC50Y3Auc2Fjay5tYXhob2xlczogMTI4 DQogICAgbmV0LmluZXQudGNwLnNhY2suZW5hYmxlOiAxDQogICAgbmV0LmluZXQudGNwLnJlYXNz LmN1cnNlZ21lbnRzOiAwDQogICAgbmV0LmluZXQudGNwLnJlYXNzLm1heHNlZ21lbnRzOiA2MjUw MA0KICAgIG5ldC5pbmV0LnRjcC5zZW5kYnVmX21heDogMjA5NzE1Mg0KICAgIG5ldC5pbmV0LnRj cC5zZW5kYnVmX2luYzogODE5Mg0KICAgIG5ldC5pbmV0LnRjcC5zZW5kYnVmX2F1dG86IDENCiAg ICBuZXQuaW5ldC50Y3AudHNvOiAxDQogICAgbmV0LmluZXQudGNwLnBhdGhfbXR1X2Rpc2NvdmVy eTogMQ0KICAgIG5ldC5pbmV0LnRjcC5scm8uZW50cmllczogOA0KICAgIG5ldC5pbmV0LnRjcC5y ZWN2YnVmX21heDogMjA5NzE1Mg0KICAgIG5ldC5pbmV0LnRjcC5yZWN2YnVmX2luYzogMTYzODQN CiAgICBuZXQuaW5ldC50Y3AucmVjdmJ1Zl9hdXRvOiAxDQogICAgbmV0LmluZXQudGNwLmluc2Vj dXJlX3JzdDogMA0KICAgIG5ldC5pbmV0LnRjcC5pbnNlY3VyZV9zeW46IDANCiAgICBuZXQuaW5l dC50Y3AuZWNuLm1heHJldHJpZXM6IDENCiAgICBuZXQuaW5ldC50Y3AuZWNuLmVuYWJsZTogMg0K ICAgIG5ldC5pbmV0LnRjcC5hYmNfbF92YXI6IDINCiAgICBuZXQuaW5ldC50Y3AucmZjMzQ2NTog MQ0KICAgIG5ldC5pbmV0LnRjcC5pbml0Y3duZF9zZWdtZW50czogMTANCiAgICBuZXQuaW5ldC50 Y3AucmZjMzM5MDogMQ0KICAgIG5ldC5pbmV0LnRjcC5yZmMzMDQyOiAxDQogICAgbmV0LmluZXQu dGNwLnJmYzY2NzVfcGlwZTogMA0KICAgIG5ldC5pbmV0LnRjcC5kcm9wX3N5bmZpbjogMQ0KICAg IG5ldC5pbmV0LnRjcC5kZWxheWVkX2FjazogMA0KICAgIG5ldC5pbmV0LnRjcC5ibGFja2hvbGU6 IDINCiAgICBuZXQuaW5ldC50Y3AubG9nX2luX3ZhaW46IDANCiAgICBuZXQuaW5ldC50Y3AuaG9z dGNhY2hlLnB1cmdlbm93OiAwDQogICAgbmV0LmluZXQudGNwLmhvc3RjYWNoZS5wdXJnZTogMA0K ICAgIG5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUucHJ1bmU6IDMwMA0KICAgIG5ldC5pbmV0LnRjcC5o b3N0Y2FjaGUuZXhwaXJlOiAzNjAwDQogICAgbmV0LmluZXQudGNwLmhvc3RjYWNoZS5jb3VudDog MA0KICAgIG5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUuYnVja2V0bGltaXQ6IDMwDQogICAgbmV0Lmlu ZXQudGNwLmhvc3RjYWNoZS5oYXNoc2l6ZTogNTEyDQogICAgbmV0LmluZXQudGNwLmhvc3RjYWNo ZS5jYWNoZWxpbWl0OiAxNTM2MA0KICAgIG5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUuZW5hYmxlOiAx DQogICAgbmV0LmluZXQudGNwLmNjLmF2YWlsYWJsZTogbmV3cmVubw0KICAgIG5ldC5pbmV0LnRj cC5jYy5hbGdvcml0aG06IG5ld3Jlbm8NCiAgICBuZXQuaW5ldC51ZHAuY2hlY2tzdW06IDENCiAg ICBuZXQuaW5ldC51ZHAubWF4ZGdyYW06IDU3MzQ0DQogICAgbmV0LmluZXQudWRwLnJlY3ZzcGFj ZTogNDIwODANCiAgICBuZXQuaW5ldC51ZHAuYmxhY2tob2xlOiAxDQogICAgbmV0LmluZXQudWRw LmxvZ19pbl92YWluOiAwDQogICAgbmV0LmluZXQuZXNwLmVzcF9lbmFibGU6IDENCiAgICBuZXQu aW5ldC5haC5haF9jbGVhcnRvczogMQ0KICAgIG5ldC5pbmV0LmFoLmFoX2VuYWJsZTogMQ0KICAg IG5ldC5pbmV0LnBpbS5zcXVlbGNoX3dob2xlcGt0OiAwDQogICAgbmV0LmluZXQuaXBjb21wLmlw Y29tcF9lbmFibGU6IDENCiAgICBuZXQuaW5ldC5jYXJwLmlmZG93bl9kZW1vdGlvbl9mYWN0b3I6 IDI0MA0KICAgIG5ldC5pbmV0LmNhcnAuc2VuZGVycl9kZW1vdGlvbl9mYWN0b3I6IDI0MA0KICAg IG5ldC5pbmV0LmNhcnAuZGVtb3Rpb246IDANCiAgICBuZXQuaW5ldC5jYXJwLmxvZzogMQ0KICAg IG5ldC5pbmV0LmNhcnAucHJlZW1wdDogMQ0KICAgIG5ldC5pbmV0LmNhcnAuYWxsb3c6IDENCiAg ICBuZXQuaW5ldC5zY3RwLmRpYWdfaW5mb19jb2RlOiAwDQogICAgbmV0LmluZXQuc2N0cC5ibGFj a2hvbGU6IDANCiAgICBuZXQuaW5ldC5zY3RwLnVzZV9kY2NjZWNuOiAxDQogICAgbmV0LmluZXQu c2N0cC5ydHR2YXJfc3RlYWR5X3N0ZXA6IDIwDQogICAgbmV0LmluZXQuc2N0cC5ydHR2YXJfZXFy ZXQ6IDANCiAgICBuZXQuaW5ldC5zY3RwLnJ0dHZhcl9ydHQ6IDUNCiAgICBuZXQuaW5ldC5zY3Rw LnJ0dHZhcl9idzogNA0KICAgIG5ldC5pbmV0LnNjdHAuaW5pdGlhbF9jd25kOiAzDQogICAgbmV0 LmluZXQuc2N0cC5idWZmZXJfc3BsaXR0aW5nOiAwDQogICAgbmV0LmluZXQuc2N0cC52dGFnX3Rp bWVfd2FpdDogNjANCiAgICBuZXQuaW5ldC5zY3RwLm5hdF9mcmllbmRseV9pbml0OiAwDQogICAg bmV0LmluZXQuc2N0cC5lbmFibGVfc2Fja19pbW1lZGlhdGVseTogMQ0KICAgIG5ldC5pbmV0LnNj dHAudWRwX3R1bm5lbGluZ19wb3J0OiAwDQogICAgbmV0LmluZXQuc2N0cC5tb2JpbGl0eV9mYXN0 aGFuZG9mZjogMA0KICAgIG5ldC5pbmV0LnNjdHAubW9iaWxpdHlfYmFzZTogMA0KICAgIG5ldC5p bmV0LnNjdHAuZGVmYXVsdF9mcmFnX2ludGVybGVhdmU6IDENCiAgICBuZXQuaW5ldC5zY3RwLmRl ZmF1bHRfc3NfbW9kdWxlOiAwDQogICAgbmV0LmluZXQuc2N0cC5kZWZhdWx0X2NjX21vZHVsZTog MA0KICAgIG5ldC5pbmV0LnNjdHAubG9nX2xldmVsOiAwDQogICAgbmV0LmluZXQuc2N0cC5tYXhf cmV0cmFuX2NodW5rOiAzMA0KICAgIG5ldC5pbmV0LnNjdHAubWluX3Jlc2lkdWFsOiAxNDUyDQog ICAgbmV0LmluZXQuc2N0cC5hYm9ydF9hdF9saW1pdDogMA0KICAgIG5ldC5pbmV0LnNjdHAuaGJf bWF4X2J1cnN0OiA0DQogICAgbmV0LmluZXQuc2N0cC5kb19zY3RwX2RyYWluOiAxDQogICAgbmV0 LmluZXQuc2N0cC5tYXhfY2hhaW5lZF9tYnVmczogNQ0KICAgIG5ldC5pbmV0LnNjdHAuYWJjX2xf dmFyOiAyDQogICAgbmV0LmluZXQuc2N0cC5uYXRfZnJpZW5kbHk6IDENCiAgICBuZXQuaW5ldC5z Y3RwLmN3bmRfbWF4YnVyc3Q6IDENCiAgICBuZXQuaW5ldC5zY3RwLmNtdF91c2VfZGFjOiAwDQog ICAgbmV0LmluZXQuc2N0cC5jbXRfb25fb2ZmOiAwDQogICAgbmV0LmluZXQuc2N0cC5vdXRnb2lu Z19zdHJlYW1zOiAxMA0KICAgIG5ldC5pbmV0LnNjdHAuaW5jb21pbmdfc3RyZWFtczogMjA0OA0K ICAgIG5ldC5pbmV0LnNjdHAuYWRkX21vcmVfb25fb3V0cHV0OiAxNDUyDQogICAgbmV0LmluZXQu c2N0cC5wYXRoX3BmX3RocmVzaG9sZDogNjU1MzUNCiAgICBuZXQuaW5ldC5zY3RwLnBhdGhfcnR4 X21heDogNQ0KICAgIG5ldC5pbmV0LnNjdHAuYXNzb2NfcnR4X21heDogMTANCiAgICBuZXQuaW5l dC5zY3RwLmluaXRfcnR4X21heDogOA0KICAgIG5ldC5pbmV0LnNjdHAudmFsaWRfY29va2llX2xp ZmU6IDYwMDAwDQogICAgbmV0LmluZXQuc2N0cC5pbml0X3J0b19tYXg6IDYwMDAwDQogICAgbmV0 LmluZXQuc2N0cC5ydG9faW5pdGlhbDogMzAwMA0KICAgIG5ldC5pbmV0LnNjdHAucnRvX21pbjog MTAwMA0KICAgIG5ldC5pbmV0LnNjdHAucnRvX21heDogNjAwMDANCiAgICBuZXQuaW5ldC5zY3Rw LnNlY3JldF9saWZldGltZTogMzYwMA0KICAgIG5ldC5pbmV0LnNjdHAuc2h1dGRvd25fZ3VhcmRf dGltZTogMA0KICAgIG5ldC5pbmV0LnNjdHAucG10dV9yYWlzZV90aW1lOiA2MDANCiAgICBuZXQu aW5ldC5zY3RwLmhlYXJ0YmVhdF9pbnRlcnZhbDogMzAwMDANCiAgICBuZXQuaW5ldC5zY3RwLmFz b2NfcmVzb3VyY2U6IDEwDQogICAgbmV0LmluZXQuc2N0cC5zeXNfcmVzb3VyY2U6IDEwMDANCiAg ICBuZXQuaW5ldC5zY3RwLnNhY2tfZnJlcTogMg0KICAgIG5ldC5pbmV0LnNjdHAuZGVsYXllZF9z YWNrX3RpbWU6IDIwMA0KICAgIG5ldC5pbmV0LnNjdHAuY2h1bmtzY2FsZTogMTANCiAgICBuZXQu aW5ldC5zY3RwLm1pbl9zcGxpdF9wb2ludDogMjkwNA0KICAgIG5ldC5pbmV0LnNjdHAucGNiaGFz aHNpemU6IDI1Ng0KICAgIG5ldC5pbmV0LnNjdHAudGNiaGFzaHNpemU6IDEwMjQNCiAgICBuZXQu aW5ldC5zY3RwLm1heGNodW5rczogMTI1MDAwDQogICAgbmV0LmluZXQuc2N0cC5mcl9tYXhidXJz dDogNA0KICAgIG5ldC5pbmV0LnNjdHAubWF4YnVyc3Q6IDQNCiAgICBuZXQuaW5ldC5zY3RwLnBl ZXJfY2hrb2g6IDI1Ng0KICAgIG5ldC5pbmV0LnNjdHAucGt0ZHJvcF9lbmFibGU6IDANCiAgICBu ZXQuaW5ldC5zY3RwLm5yc2Fja19lbmFibGU6IDANCiAgICBuZXQuaW5ldC5zY3RwLnJlY29uZmln X2VuYWJsZTogMQ0KICAgIG5ldC5pbmV0LnNjdHAuYXNjb25mX2VuYWJsZTogMQ0KICAgIG5ldC5p bmV0LnNjdHAuYXV0aF9lbmFibGU6IDENCiAgICBuZXQuaW5ldC5zY3RwLnByX2VuYWJsZTogMQ0K ICAgIG5ldC5pbmV0LnNjdHAuZWNuX2VuYWJsZTogMQ0KICAgIG5ldC5pbmV0LnNjdHAuYXV0b19h c2NvbmY6IDENCiAgICBuZXQuaW5ldC5zY3RwLnJlY3ZzcGFjZTogMTg2NDEzNQ0KICAgIG5ldC5p bmV0LnNjdHAuc2VuZHNwYWNlOiAxODY0MTM1DQogICAgbmV0LmluZXQuaXBzZWMuZGVmX3BvbGlj eTogMQ0KICAgIG5ldC5pbmV0Lmlwc2VjLmVzcF90cmFuc19kZWZsZXY6IDENCiAgICBuZXQuaW5l dC5pcHNlYy5lc3BfbmV0X2RlZmxldjogMQ0KICAgIG5ldC5pbmV0Lmlwc2VjLmFoX3RyYW5zX2Rl ZmxldjogMQ0KICAgIG5ldC5pbmV0Lmlwc2VjLmFoX25ldF9kZWZsZXY6IDENCiAgICBuZXQuaW5l dC5pcHNlYy5haF9jbGVhcnRvczogMQ0KICAgIG5ldC5pbmV0Lmlwc2VjLmFoX29mZnNldG1hc2s6 IDANCiAgICBuZXQuaW5ldC5pcHNlYy5kZmJpdDogMA0KICAgIG5ldC5pbmV0Lmlwc2VjLmVjbjog MA0KICAgIG5ldC5pbmV0Lmlwc2VjLmRlYnVnOiAwDQogICAgbmV0LmluZXQuaXBzZWMuZmlsdGVy dHVubmVsOiAwDQogICAgbmV0LmluZXQuaXBzZWMubmF0dF9ja3N1bV9wb2xpY3k6IDANCiAgICBu ZXQuaW5ldC5pcHNlYy5jaGVja19wb2xpY3lfaGlzdG9yeTogMA0KICAgIG5ldC5pbmV0Lmlwc2Vj LmNyeXB0b19zdXBwb3J0OiA1MDMzMTY0OA0KICAgIG5ldC5pbmV0LnJhdy5yZWN2c3BhY2U6IDky MTYNCiAgICBuZXQuaW5ldC5yYXcubWF4ZGdyYW06IDkyMTYNCiAgICBuZXQubGluay5nZW5lcmlj LnN5c3RlbS5pZmNvdW50OiA5DQogICAgbmV0LmxpbmsuZXRoZXIuaW5ldC5hbGxvd19tdWx0aWNh c3Q6IDANCiAgICBuZXQubGluay5ldGhlci5pbmV0LmxvZ19hcnBfcGVybWFuZW50X21vZGlmeTog MQ0KICAgIG5ldC5saW5rLmV0aGVyLmluZXQubG9nX2FycF9tb3ZlbWVudHM6IDENCiAgICBuZXQu bGluay5ldGhlci5pbmV0LmxvZ19hcnBfd3JvbmdfaWZhY2U6IDENCiAgICBuZXQubGluay5ldGhl ci5pbmV0LmdhcnBfcmV4bWl0X2NvdW50OiAwDQogICAgbmV0LmxpbmsuZXRoZXIuaW5ldC5tYXhf bG9nX3Blcl9zZWNvbmQ6IDENCiAgICBuZXQubGluay5ldGhlci5pbmV0Lm1heGhvbGQ6IDENCiAg ICBuZXQubGluay5ldGhlci5pbmV0LndhaXQ6IDIwDQogICAgbmV0LmxpbmsuZXRoZXIuaW5ldC5w cm94eWFsbDogMA0KICAgIG5ldC5saW5rLmV0aGVyLmluZXQubWF4dHJpZXM6IDUNCiAgICBuZXQu bGluay5ldGhlci5pbmV0Lm1heF9hZ2U6IDEyMDANCiAgICBuZXQubGluay5ldGhlci5pcGZ3OiAw DQogICAgbmV0LmxpbmsuZ3JlLm1heF9uZXN0aW5nOiAxDQogICAgbmV0Lmxpbmsudmxhbi5tdGFn X3BjcDogMA0KICAgIG5ldC5saW5rLnZsYW4uc29mdF9wYWQ6IDANCiAgICBuZXQubGluay5icmlk Z2UuaXBmdzogMA0KICAgIG5ldC5saW5rLmJyaWRnZS5hbGxvd19sbHpfb3ZlcmxhcDogMA0KICAg IG5ldC5saW5rLmJyaWRnZS5pbmhlcml0X21hYzogMA0KICAgIG5ldC5saW5rLmJyaWRnZS5sb2df c3RwOiAwDQogICAgbmV0LmxpbmsuYnJpZGdlLnBmaWxfbG9jYWxfcGh5czogMA0KICAgIG5ldC5s aW5rLmJyaWRnZS5wZmlsX21lbWJlcjogMQ0KICAgIG5ldC5saW5rLmJyaWRnZS5pcGZ3X2FycDog MA0KICAgIG5ldC5saW5rLmJyaWRnZS5wZmlsX2JyaWRnZTogMA0KICAgIG5ldC5saW5rLmJyaWRn ZS5wZmlsX29ubHlpcDogMA0KICAgIG5ldC5saW5rLmdpZi5wYXJhbGxlbF90dW5uZWxzOiAwDQog ICAgbmV0LmxpbmsuZ2lmLm1heF9uZXN0aW5nOiAxDQogICAgbmV0LmxpbmsubGFnZy5sYWNwLmRl ZmF1bHRfc3RyaWN0X21vZGU6IDENCiAgICBuZXQubGluay5sYWdnLmxhY3AuZGVidWc6IDANCiAg ICBuZXQubGluay5sYWdnLmRlZmF1bHRfZmxvd2lkX3NoaWZ0OiAxNg0KICAgIG5ldC5saW5rLmxh Z2cuZGVmYXVsdF91c2VfZmxvd2lkOiAxDQogICAgbmV0LmxpbmsubGFnZy5mYWlsb3Zlcl9yeF9h bGw6IDANCiAgICBuZXQubGluay50YXAuZGVidWc6IDANCiAgICBuZXQubGluay50YXAuZGV2ZnNf Y2xvbmluZzogMQ0KICAgIG5ldC5saW5rLnRhcC51cF9vbl9vcGVuOiAwDQogICAgbmV0Lmxpbmsu dGFwLnVzZXJfb3BlbjogMQ0KICAgIG5ldC5saW5rLnR1bi5kZXZmc19jbG9uaW5nOiAxDQogICAg bmV0LmxpbmsubG9nX3Byb21pc2NfbW9kZV9jaGFuZ2U6IDENCiAgICBuZXQubGluay5sb2dfbGlu a19zdGF0ZV9jaGFuZ2U6IDENCiAgICBuZXQubGluay5pZnFtYXhsZW46IDgxOTINCiAgICBuZXQu a2V5LmRlYnVnOiAwDQogICAgbmV0LmtleS5zcGlfdHJ5Y250OiAxMDAwDQogICAgbmV0LmtleS5z cGlfbWludmFsOiAyNTYNCiAgICBuZXQua2V5LnNwaV9tYXh2YWw6IDI2ODQzNTQ1NQ0KICAgIG5l dC5rZXkuaW50X3JhbmRvbTogNjANCiAgICBuZXQua2V5LmxhcnZhbF9saWZldGltZTogMzANCiAg ICBuZXQua2V5LmJsb2NrYWNxX2NvdW50OiAxMA0KICAgIG5ldC5rZXkuYmxvY2thY3FfbGlmZXRp bWU6IDIwDQogICAgbmV0LmtleS5lc3Bfa2V5bWluOiAyNTYNCiAgICBuZXQua2V5LmVzcF9hdXRo OiAwDQogICAgbmV0LmtleS5haF9rZXltaW46IDEyOA0KICAgIG5ldC5rZXkucHJlZmVycmVkX29s ZHNhOiAwDQogICAgbmV0LmluZXQ2LmlwNi5mb3J3YXJkaW5nOiAxDQogICAgbmV0LmluZXQ2Lmlw Ni5yZWRpcmVjdDogMQ0KICAgIG5ldC5pbmV0Ni5pcDYuaGxpbTogNjQNCiAgICBuZXQuaW5ldDYu aXA2Lm1heGZyYWdwYWNrZXRzOiAyNTAwMDANCiAgICBuZXQuaW5ldDYuaXA2LmFjY2VwdF9ydGFk djogMA0KICAgIG5ldC5pbmV0Ni5pcDYubG9nX2ludGVydmFsOiA1DQogICAgbmV0LmluZXQ2Lmlw Ni5oZHJuZXN0bGltaXQ6IDE1DQogICAgbmV0LmluZXQ2LmlwNi5kYWRfY291bnQ6IDENCiAgICBu ZXQuaW5ldDYuaXA2LmF1dG9fZmxvd2xhYmVsOiAxDQogICAgbmV0LmluZXQ2LmlwNi5kZWZtY2Fz dGhsaW06IDENCiAgICBuZXQuaW5ldDYuaXA2LmdpZmhsaW06IDMwDQogICAgbmV0LmluZXQ2Lmlw Ni5rYW1lX3ZlcnNpb246IEZyZWVCU0QNCiAgICBuZXQuaW5ldDYuaXA2LnVzZV9kZXByZWNhdGVk OiAxDQogICAgbmV0LmluZXQ2LmlwNi5ycl9wcnVuZTogNQ0KICAgIG5ldC5pbmV0Ni5pcDYudjZv bmx5OiAxDQogICAgbmV0LmluZXQ2LmlwNi51c2VfdGVtcGFkZHI6IDANCiAgICBuZXQuaW5ldDYu aXA2LnRlbXBwbHRpbWU6IDg2NDAwDQogICAgbmV0LmluZXQ2LmlwNi50ZW1wdmx0aW1lOiA2MDQ4 MDANCiAgICBuZXQuaW5ldDYuaXA2LmF1dG9fbGlua2xvY2FsOiAxDQogICAgbmV0LmluZXQ2Lmlw Ni5wcmVmZXJfdGVtcGFkZHI6IDANCiAgICBuZXQuaW5ldDYuaXA2LnVzZV9kZWZhdWx0em9uZTog MA0KICAgIG5ldC5pbmV0Ni5pcDYubWF4ZnJhZ3M6IDI1MDAwMA0KICAgIG5ldC5pbmV0Ni5pcDYu bWNhc3RfcG10dTogMA0KICAgIG5ldC5pbmV0Ni5pcDYuc3RlYWx0aDogMA0KICAgIG5ldC5pbmV0 Ni5pcDYubm9fcmFkcjogMA0KICAgIG5ldC5pbmV0Ni5pcDYubm9yYml0X3JhaWY6IDANCiAgICBu ZXQuaW5ldDYuaXA2LnJmYzYyMDR3MzogMA0KICAgIG5ldC5pbmV0Ni5pcDYuaW50cl9xdWV1ZV9t YXhsZW46IDI1Ng0KICAgIG5ldC5pbmV0Ni5pcDYuZncuZW5hYmxlOiAxDQogICAgbmV0LmluZXQ2 LmlwNi5mdy5wZXJtaXRfc2luZ2xlX2ZyYWc2OiAxDQogICAgbmV0LmluZXQ2LmlwNi5mdy5kZW55 X3Vua25vd25fZXh0aGRyczogMQ0KICAgIG5ldC5pbmV0Ni5pcDYuZ3JlaGxpbTogNjQNCiAgICBu ZXQuaW5ldDYuaXA2LmRlZW1iZWRfc2NvcGVpZDogMQ0KICAgIG5ldC5pbmV0Ni5pcDYuZGFkX2Vu aGFuY2VkOiAxDQogICAgbmV0LmluZXQ2LmlwNi5tY2FzdC5sb29wOiAxDQogICAgbmV0LmluZXQ2 LmlwNi5tY2FzdC5tYXhzb2Nrc3JjOiAxMjgNCiAgICBuZXQuaW5ldDYuaXA2Lm1jYXN0Lm1heGdy cHNyYzogNTEyDQogICAgbmV0LmluZXQ2Lmlwc2VjNi5kZWZfcG9saWN5OiAxDQogICAgbmV0Lmlu ZXQ2Lmlwc2VjNi5lc3BfdHJhbnNfZGVmbGV2OiAxDQogICAgbmV0LmluZXQ2Lmlwc2VjNi5lc3Bf bmV0X2RlZmxldjogMQ0KICAgIG5ldC5pbmV0Ni5pcHNlYzYuYWhfdHJhbnNfZGVmbGV2OiAxDQog ICAgbmV0LmluZXQ2Lmlwc2VjNi5haF9uZXRfZGVmbGV2OiAxDQogICAgbmV0LmluZXQ2Lmlwc2Vj Ni5lY246IDANCiAgICBuZXQuaW5ldDYuaXBzZWM2LmRlYnVnOiAwDQogICAgbmV0LmluZXQ2Lmlw c2VjNi5maWx0ZXJ0dW5uZWw6IDANCiAgICBuZXQuaW5ldDYuaWNtcDYucmVkaXJhY2NlcHQ6IDEN CiAgICBuZXQuaW5ldDYuaWNtcDYucmVkaXJ0aW1lb3V0OiA2MDANCiAgICBuZXQuaW5ldDYuaWNt cDYubmQ2X3BydW5lOiAxDQogICAgbmV0LmluZXQ2LmljbXA2Lm5kNl9kZWxheTogNQ0KICAgIG5l dC5pbmV0Ni5pY21wNi5uZDZfdW1heHRyaWVzOiAzDQogICAgbmV0LmluZXQ2LmljbXA2Lm5kNl9t bWF4dHJpZXM6IDMNCiAgICBuZXQuaW5ldDYuaWNtcDYubmQ2X3VzZWxvb3BiYWNrOiAxDQogICAg bmV0LmluZXQ2LmljbXA2Lm5vZGVpbmZvOiAzDQogICAgbmV0LmluZXQ2LmljbXA2LmVycnBwc2xp bWl0OiAxMDANCiAgICBuZXQuaW5ldDYuaWNtcDYubmQ2X21heG51ZGhpbnQ6IDANCiAgICBuZXQu aW5ldDYuaWNtcDYubmQ2X2RlYnVnOiAwDQogICAgbmV0LmluZXQ2LmljbXA2Lm5kNl9tYXhxdWV1 ZWxlbjogMQ0KICAgIG5ldC5pbmV0Ni5pY21wNi5ub2RlaW5mb19vbGRtY3ByZWZpeDogMQ0KICAg IG5ldC5pbmV0Ni5pY21wNi5uZDZfb25saW5rX25zX3JmYzQ4NjE6IDANCiAgICBuZXQuaW5ldDYu aWNtcDYubmQ2X2djdGltZXI6IDg2NDAwDQogICAgbmV0LmluZXQ2Lm1sZC51c2VfYWxsb3c6IDEN CiAgICBuZXQuaW5ldDYubWxkLnYxZW5hYmxlOiAxDQogICAgbmV0LmluZXQ2Lm1sZC5nc3JkZWxh eTogMTANCiAgICBuZXQucGZzeW5jLmNhcnBfZGVtb3Rpb25fZmFjdG9yOiAyNDANCiAgICBuZXQu ZW5jLm91dC5pcHNlY19icGZfbWFzazogMQ0KICAgIG5ldC5lbmMub3V0Lmlwc2VjX2ZpbHRlcl9t YXNrOiAxDQogICAgbmV0LmVuYy5pbi5pcHNlY19icGZfbWFzazogMg0KICAgIG5ldC5lbmMuaW4u aXBzZWNfZmlsdGVyX21hc2s6IDINCiAgICBuZXQuZ3JhcGguY29udHJvbC5wcm90bzogMg0KICAg IG5ldC5ncmFwaC5kYXRhLnByb3RvOiAxDQogICAgbmV0LmdyYXBoLmZhbWlseTogMzINCiAgICBu ZXQuZ3JhcGgucmVjdnNwYWNlOiAyMDQ4MA0KICAgIG5ldC5ncmFwaC5tYXhkZ3JhbTogMjA0ODAN CiAgICBuZXQuZ3JhcGgubXBwZS5tYXhfcmVrZXk6IDEwMDANCiAgICBuZXQuZ3JhcGgubXBwZS5s b2dfbWF4X3Jla2V5OiAxDQogICAgbmV0LmdyYXBoLm1wcGUuYmxvY2tfb25fbWF4X3Jla2V5OiAw DQogICAgbmV0LmdyYXBoLm1zZ192ZXJzaW9uOiA4DQogICAgbmV0LmdyYXBoLmFiaV92ZXJzaW9u OiAxMg0KICAgIG5ldC5ncmFwaC5tYXhkYXRhOiA0MDk2DQogICAgbmV0LmdyYXBoLm1heGFsbG9j OiA0MDk2DQogICAgbmV0LmdyYXBoLnRocmVhZHM6IDgNCiAgICBuZXQucGYuc2hhcmVfZm9yd2Fy ZDY6IDENCiAgICBuZXQucGYuc2hhcmVfZm9yd2FyZDogMQ0KICAgIG5ldC5wZi5zb3VyY2Vfbm9k ZXNfaGFzaHNpemU6IDgxOTINCiAgICBuZXQucGYuc3RhdGVzX2hhc2hzaXplOiAzMjc2OA0KICAg IG5ldC53bGFuLm1lc2gubWF4aG9sZGluZzogMg0KICAgIG5ldC53bGFuLm1lc2gubWF4cmV0cmll czogMg0KICAgIG5ldC53bGFuLm1lc2guYmFja29mZnRpbWVvdXQ6IDUwMDANCiAgICBuZXQud2xh bi5tZXNoLmNvbmZpcm10aW1lb3V0OiA0MA0KICAgIG5ldC53bGFuLm1lc2guaG9sZGluZ3RpbWVv dXQ6IDQwDQogICAgbmV0LndsYW4ubWVzaC5yZXRyeXRpbWVvdXQ6IDQwDQogICAgbmV0LndsYW4u bWVzaC5nYXRlaW50OiAxMDAwMA0KICAgIG5ldC53bGFuLmh3bXAuaW5hY3Q6IDUwMDANCiAgICBu ZXQud2xhbi5od21wLnJvb3Rjb25maW50OiAyMDAwDQogICAgbmV0LndsYW4uaHdtcC5yYW5uaW50 OiAxMDAwDQogICAgbmV0LndsYW4uaHdtcC5yb290aW50OiAyMDAwDQogICAgbmV0LndsYW4uaHdt cC5yb290dGltZW91dDogNTAwMA0KICAgIG5ldC53bGFuLmh3bXAubmV0X2RpYW1ldGVyX3RyYXZl cnNhbF90aW1lOiA1MTINCiAgICBuZXQud2xhbi5od21wLm1heHByZXFfcmV0cmllczogMw0KICAg IG5ldC53bGFuLmh3bXAucGF0aGxpZmV0aW1lOiA1MDAwDQogICAgbmV0LndsYW4uaHdtcC50YXJn ZXRvbmx5OiAwDQogICAgbmV0LndsYW4uYWRkYmFfbWF4dHJpZXM6IDMNCiAgICBuZXQud2xhbi5h ZGRiYV9iYWNrb2ZmOiAxMDAwMA0KICAgIG5ldC53bGFuLmFkZGJhX3RpbWVvdXQ6IDI1MA0KICAg IG5ldC53bGFuLnJlY3ZfYmFyOiAxDQogICAgbmV0LndsYW4uYW1wZHVfYWdlOiA1MDANCiAgICBu ZXQud2xhbi5kZWJ1ZzogMA0KICAgIG5ldC53bGFuLmNhY190aW1lb3V0OiA2MA0KICAgIG5ldC53 bGFuLm5vbF90aW1lb3V0OiAxODAwDQogICAgbmV0LndsYW4uZGV2aWNlczoNCiAgICBuZXQucm91 dGUubmV0aXNyX21heHFsZW46IDI1Ng0KICAgIG5ldC5teV9maWJudW06IDANCiAgICBuZXQuYWRk X2FkZHJfYWxsZmliczogMQ0KICAgIG5ldC5maWJzOiAxDQogICAgbmV0LnJhdy5yZWN2c3BhY2U6 IDgxOTINCiAgICBuZXQucmF3LnNlbmRzcGFjZTogODE5Mg0KICAgIG5ldC5pc3IubnVtdGhyZWFk czogMQ0KICAgIG5ldC5pc3IubWF4cHJvdDogMTYNCiAgICBuZXQuaXNyLmRlZmF1bHRxbGltaXQ6 IDI1Ng0KICAgIG5ldC5pc3IubWF4cWxpbWl0OiAxMDI0MA0KICAgIG5ldC5pc3IuYmluZHRocmVh ZHM6IDANCiAgICBuZXQuaXNyLm1heHRocmVhZHM6IDENCiAgICBuZXQuaXNyLmRpc3BhdGNoOiBk aXJlY3QNCiAgICBuZXQuaWZsaWIubWluX3R4X2xhdGVuY3k6IDANCiAgICBuZXQuaWZkZXNjcl9t YXhsZW46IDEwMjQNCiAgICBuZXQuYnBmLm1heGJ1ZnNpemU6IDUyNDI4OA0KICAgIG5ldC5icGYu YnVmc2l6ZTogNDA5Ng0KICAgIG5ldC5icGYub3B0aW1pemVfd3JpdGVyczogMA0KICAgIG5ldC5i cGYuemVyb2NvcHlfZW5hYmxlOiAwDQogICAgbmV0LmJwZi5tYXhpbnNuczogNTEyDQogICAgbmV0 LmFjY2YudW5sb2FkYWJsZTogMA0KICAgIGh3LnZ0bmV0LnJ4X3Byb2Nlc3NfbGltaXQ6IDUxMg0K ICAgIGh3LnZ0bmV0Lm1xX21heF9wYWlyczogOA0KICAgIGh3LnZ0bmV0Lm1xX2Rpc2FibGU6IDAN CiAgICBody52dG5ldC5scm9fZGlzYWJsZTogMA0KICAgIGh3LnZ0bmV0LnRzb19kaXNhYmxlOiAw DQogICAgaHcudnRuZXQuY3N1bV9kaXNhYmxlOiAwDQogICAgZGV2Lml4bC4xLiVkZXNjOiBJbnRl bChSKSBFdGhlcm5ldCBDb25uZWN0aW9uIFhMNzEwL1g3MjIgRHJpdmVyLCBWZXJzaW9uIA0KICAg IC0gMS43LjEyLWsNCiAgICBkZXYuaXhsLjAuJWRlc2M6IEludGVsKFIpIEV0aGVybmV0IENvbm5l Y3Rpb24gWEw3MTAvWDcyMiBEcml2ZXIsIFZlcnNpb24gDQogICAgLSAxLjcuMTItaw0KICAgIGRl di5uZXRtYXAuaXhsX3J4X21pc3NfYnVmczogMzA1DQogICAgZGV2Lm5ldG1hcC5peGxfcnhfbWlz czogMjU1DQogICAgZGV2Lm5ldG1hcC5pZmxpYl9yeF9taXNzX2J1ZnM6IDANCiAgICBkZXYubmV0 bWFwLmlmbGliX3J4X21pc3M6IDANCiAgICBkZXYubmV0bWFwLmlmbGliX2NyY3N0cmlwOiAxDQog ICAgZGV2Lm5ldG1hcC5icmlkZ2VfYmF0Y2g6IDEwMjQNCiAgICBkZXYubmV0bWFwLmRlZmF1bHRf cGlwZXM6IDANCiAgICBkZXYubmV0bWFwLnByaXZfYnVmX251bTogNDA5OA0KICAgIGRldi5uZXRt YXAucHJpdl9idWZfc2l6ZTogMjA0OA0KICAgIGRldi5uZXRtYXAuYnVmX2N1cnJfbnVtOiAxNjM4 NDANCiAgICBkZXYubmV0bWFwLmJ1Zl9udW06IDE2Mzg0MA0KICAgIGRldi5uZXRtYXAuYnVmX2N1 cnJfc2l6ZTogMjA0OA0KICAgIGRldi5uZXRtYXAuYnVmX3NpemU6IDIwNDgNCiAgICBkZXYubmV0 bWFwLnByaXZfcmluZ19udW06IDQNCiAgICBkZXYubmV0bWFwLnByaXZfcmluZ19zaXplOiAyMDQ4 MA0KICAgIGRldi5uZXRtYXAucmluZ19jdXJyX251bTogMjAwDQogICAgZGV2Lm5ldG1hcC5yaW5n X251bTogMjAwDQogICAgZGV2Lm5ldG1hcC5yaW5nX2N1cnJfc2l6ZTogNzM3MjgNCiAgICBkZXYu bmV0bWFwLnJpbmdfc2l6ZTogNzM3MjgNCiAgICBkZXYubmV0bWFwLnByaXZfaWZfbnVtOiAxDQog ICAgZGV2Lm5ldG1hcC5wcml2X2lmX3NpemU6IDEwMjQNCiAgICBkZXYubmV0bWFwLmlmX2N1cnJf bnVtOiAxMDANCiAgICBkZXYubmV0bWFwLmlmX251bTogMTAwDQogICAgZGV2Lm5ldG1hcC5pZl9j dXJyX3NpemU6IDEwMjQNCiAgICBkZXYubmV0bWFwLmlmX3NpemU6IDEwMjQNCiAgICBkZXYubmV0 bWFwLmdlbmVyaWNfcmluZ3M6IDENCiAgICBkZXYubmV0bWFwLmdlbmVyaWNfcmluZ3NpemU6IDEw MjQNCiAgICBkZXYubmV0bWFwLmdlbmVyaWNfbWl0OiAxMDAwMDANCiAgICBkZXYubmV0bWFwLmFk bW9kZTogMA0KICAgIGRldi5uZXRtYXAuZndkOiAwDQogICAgZGV2Lm5ldG1hcC5mbGFnczogMA0K ICAgIGRldi5uZXRtYXAuYWRhcHRpdmVfaW86IDANCiAgICBkZXYubmV0bWFwLnR4c3luY19yZXRy eTogMg0KICAgIGRldi5uZXRtYXAubm9fcGVuZGludHI6IDENCiAgICBkZXYubmV0bWFwLm1pdGln YXRlOiAxDQogICAgZGV2Lm5ldG1hcC5ub190aW1lc3RhbXA6IDANCiAgICBkZXYubmV0bWFwLnZl cmJvc2U6IDANCiAgICBkZXYubmV0bWFwLml4X3J4X21pc3NfYnVmczogMA0KICAgIGRldi5uZXRt YXAuaXhfcnhfbWlzczogMA0KICAgIGRldi5uZXRtYXAuaXhfY3Jjc3RyaXA6IDANCiAgICBzZWN1 cml0eS5qYWlsLnZuZXQ6IDANCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGZyZWVic2QtbmV0QGZyZWVic2Qub3JnIG1h aWxpbmcgbGlzdA0KICAgIGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5m by9mcmVlYnNkLW5ldA0KICAgIFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVl YnNkLW5ldC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCiAgICANCg0K From owner-freebsd-net@freebsd.org Thu Mar 29 20:34:57 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D42BAF74D8A for ; Thu, 29 Mar 2018 20:34:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1F10839EE for ; Thu, 29 Mar 2018 20:34:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2TKYkBT065136; Thu, 29 Mar 2018 13:34:46 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2TKYhBL065135; Thu, 29 Mar 2018 13:34:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803292034.w2TKYhBL065135@pdx.rh.CN85.dnsmgr.net> Subject: Re: Current state of Intel XL710 40G NIC ixl performance In-Reply-To: <49887EF8-FAFE-45DF-BB2F-6007E5BB7485@intel.com> To: "Pieper, Jeffrey E" Date: Thu, 29 Mar 2018 13:34:43 -0700 (PDT) CC: "Muenz, Michael" , "freebsd-net@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Mar 2018 20:34:57 -0000 > Hi Rodney, > > So this is a XL710-QDA2 that is set to 4x10? (default is 2x40). If you can you give me the output of sysctl dev.ixl|egrep 'pnp|locati|Version', that would be helpful. Hello Jeff, I dont have a XL710-QDA2, it is Michael who has one. > Thanks, > Jeff Regards, Rod > ?On 3/29/18, 6:16 AM, "owner-freebsd-net@freebsd.org on behalf of Muenz, Michael" wrote: > > Am 29.03.2018 um 14:46 schrieb Rodney W. Grimes: > >> Am 28.03.2018 um 18:38 schrieb Rodney W. Grimes: > >>>> Am 28.03.2018 um 06:11 schrieb christian russell: > >>>>> I am having trouble getting an Intel XL710-DA2 NIC to get even close to > >>>>> line rate. It is a 4x10 Gbps card. The box is running FreeBSD 11 (FreeNAS > >>>>> in particular). > >>>>> > >>>>> We have tried both 1.7 and 1.9 driver revisions with similar results. The > >>>>> NVM version is 5.05. The card is in a confirmed 8x slot on a SuperMicro > >>>>> X10DRL-i with two Xeon E5-2600 processors and 256 GB DDR4 RAM. After > >>>>> upping the interrupt threshold to 9000 dmesg doesn't log anything unusual. > >>>>> > >>>>> We have added the tunes that are standard for 10 Gbps configurations. > >>>>> > >>>>> On a single-client basis the fastest rates we see are around 5 Gbps. > >>>>> Hitting this server from multiple boxes we see peaks of 20 Gbps at the very > >>>>> highest. More frequently things top off around 13 Gbps. These numbers are > >>>>> coming from iperf tests. We are seeing similar numbers with direct > >>>>> point-to-point as well as switched topologies. > >>>>> > >>>>> These threads from 2015 describe similar issues but fizzled out: > >>>>> https://lists.freebsd.org/pipermail/freebsd-net/2015-May/042273.html > >>>>> https://lists.freebsd.org/pipermail/freebsd-net/2015-October/043584.html > >>>>> > >>>>> Is there very particular tuning required to get these cards working at > >>>>> proper speed? Any insights? > >>>>> > >>>>> >From Googling around it appears frustration with this card and FreeBSD is > >>>>> pretty common. > >>>>> > >>>>> Thanks in advance. > >>>>> > >>>>> Christian > >>>> I can't deliver any special insights but we had many problems with X710 > >>>> (without L) and Linux. > >>>> Did some testing a while ago with OPNsense (based on 11.1) and got line > >>>> rate with iperf and single client. > >>>> ixl0 in and ixl1 out. So this should be fine. If you like I can send you > >>>> the sysctl values to compare. > >>> I would be interested in your sysctl values. > >>> > >> Hm, perhaps I misinterpreted your post. I recreated the lab and from the > >> history I saw > >> that it was single client but with 10 streams in parallel. If I reduce > >> to 1 stream I also > >> don't come over the 5,6G. > >> > >> If you're still interested I can send you the output. > > We specifically are interested in the sysctl settings you used > > to obtain a "line rate" results using ixl0 in and ixl1 out, > > it does not matter if that was 1 stream or 10 stream, we would > > just like to see what values you found to work well for you > > to compare to what values others may be using/suggesting. > > > Sure! I just did a test and it's 9,6GBit with 10 streams. > > The layout is: > > UBUNTU-A --- 10G DA --- OPN-A --- 10G DA --- OPN-B --- 10G DA --- UBUNTU-B > > All system quite acutal, enough RAM and all with X710. > > This is one of the firewalls (all values are default by OPNsense, no > special tuning > > from my side): > > > root@OPNsense:~ # dmesg | grep Xeon > CPU: Intel(R) Xeon(R) CPU E3-1270 v5 @ 3.60GHz (3600.18-MHz K8-class CPU > > > root@OPNsense:~ # ifconfig -vvvvvv ixl0 > ixl0: flags=8843 metric 0 mtu 1500 > options=6400b8 > ether 3c:fd:fe:9e:e7:48 > hwaddr 3c:fd:fe:9e:e7:48 > inet 10.55.1.1 netmask 0xffffff00 broadcast 10.55.1.255 > inet6 fe80::3efd:feff:fe9e:e748%ixl0 prefixlen 64 scopeid 0x1 > nd6 options=21 > media: Ethernet autoselect (10Gbase-Twinax ) > status: active > plugged: SFP/SFP+/SFP28 Unknown (Copper pigtail) > vendor: CISCO-LOROM PN: LRHSPB54D020 SN: LRM2014626G DATE: > 2016-04-15 > Class: (null) > Length: (null) > Tech: Passive Cable > Media: (null) > Speed: (null) > > SFF8472 DUMP (0xA0 0..127 range): > 03 04 21 00 00 00 00 00 04 00 00 00 67 00 00 00 > 00 00 02 00 43 49 53 43 4F 2D 4C 4F 52 4F 4D 20 > 20 20 20 20 00 FC 2E 2D 4C 52 48 53 50 42 35 34 > 44 30 32 30 20 20 20 20 42 32 20 20 01 00 00 F2 > 00 00 00 00 4C 52 4D 32 30 31 34 36 32 36 47 20 > 20 20 20 20 31 36 30 34 31 35 20 20 00 00 00 A8 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 E9 77 70 80 > > > > > root@OPNsense:~ # dmesg | grep ixl > ixl0: 1.7.12-k> mem 0xdd000000-0xdd7fffff,0xdd808000-0xdd80ffff irq 16 at > device 0.0 on pci1 > ixl0: Using MSIX interrupts with 9 vectors > ixl0: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem 1.262.0 > ixl0: PF-ID[0]: VFs 64, MSIX 129, VF MSIX 5, QPs 768, I2C > ixl0: Allocating 8 queues for PF LAN VSI; 8 queues active > ixl0: Ethernet address: 3c:fd:fe:9e:e7:48 > ixl0: PCI Express Bus: Speed 8.0GT/s Width x8 > ixl0: SR-IOV ready > ixl0: netmap queues/slots: TX 8/1024, RX 8/1024 > ixl1: 1.7.12-k> mem 0xdc800000-0xdcffffff,0xdd800000-0xdd807fff irq 16 at > device 0.1 on pci1 > ixl1: Using MSIX interrupts with 9 vectors > ixl1: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem 1.262.0 > ixl1: PF-ID[1]: VFs 64, MSIX 129, VF MSIX 5, QPs 768, I2C > ixl1: Allocating 8 queues for PF LAN VSI; 8 queues active > ixl1: Ethernet address: 3c:fd:fe:9e:e7:49 > ixl1: PCI Express Bus: Speed 8.0GT/s Width x8 > ixl1: SR-IOV ready > ixl1: netmap queues/slots: TX 8/1024, RX 8/1024 > ixl0: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow > Control: None > ixl0: link state changed to UP > ixl1: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow > Control: None > ixl1: link state changed to UP > ixl1: TSO4 requires txcsum, disabling both... > ixl0: TSO4 requires txcsum, disabling both... > > > > > root@OPNsense:~ # sysctl -a | grep ixl > device ixl > device ixlv > hw.ixlv.tx_itr: 122 > hw.ixlv.rx_itr: 62 > hw.ixlv.dynamic_tx_itr: 0 > hw.ixlv.dynamic_rx_itr: 0 > hw.ixlv.txbr_size: 4096 > hw.ixlv.max_queues: 0 > hw.ixlv.ring_size: 1024 > hw.ixl.tx_itr: 122 > hw.ixl.rx_itr: 62 > hw.ixl.dynamic_tx_itr: 1 > hw.ixl.dynamic_rx_itr: 1 > hw.ixl.shared_debug_mask: 0 > hw.ixl.core_debug_mask: 0 > hw.ixl.enable_tx_fc_filter: 1 > hw.ixl.max_queues: 0 > hw.ixl.ring_size: 1024 > hw.ixl.enable_msix: 1 > dev.ixl.1.mac.xoff_recvd: 0 > dev.ixl.1.mac.xoff_txd: 0 > dev.ixl.1.mac.xon_recvd: 0 > dev.ixl.1.mac.xon_txd: 0 > dev.ixl.1.mac.tx_frames_big: 0 > dev.ixl.1.mac.tx_frames_1024_1522: 126575 > dev.ixl.1.mac.tx_frames_512_1023: 53 > dev.ixl.1.mac.tx_frames_256_511: 18 > dev.ixl.1.mac.tx_frames_128_255: 6273 > dev.ixl.1.mac.tx_frames_65_127: 3479052 > dev.ixl.1.mac.tx_frames_64: 3015 > dev.ixl.1.mac.checksum_errors: 0 > dev.ixl.1.mac.rx_jabber: 0 > dev.ixl.1.mac.rx_oversized: 0 > dev.ixl.1.mac.rx_fragmented: 0 > dev.ixl.1.mac.rx_undersize: 0 > dev.ixl.1.mac.rx_frames_big: 0 > dev.ixl.1.mac.rx_frames_1024_1522: 118340403 > dev.ixl.1.mac.rx_frames_512_1023: 2602 > dev.ixl.1.mac.rx_frames_256_511: 2588 > dev.ixl.1.mac.rx_frames_128_255: 197724 > dev.ixl.1.mac.rx_frames_65_127: 101859 > dev.ixl.1.mac.rx_frames_64: 2444 > dev.ixl.1.mac.rx_length_errors: 0 > dev.ixl.1.mac.remote_faults: 0 > dev.ixl.1.mac.local_faults: 0 > dev.ixl.1.mac.illegal_bytes: 0 > dev.ixl.1.mac.crc_errors: 0 > dev.ixl.1.mac.bcast_pkts_txd: 581 > dev.ixl.1.mac.mcast_pkts_txd: 40987 > dev.ixl.1.mac.ucast_pkts_txd: 3573418 > dev.ixl.1.mac.good_octets_txd: 437663656 > dev.ixl.1.mac.rx_discards: 0 > dev.ixl.1.mac.bcast_pkts_rcvd: 0 > dev.ixl.1.mac.mcast_pkts_rcvd: 40983 > dev.ixl.1.mac.ucast_pkts_rcvd: 118606637 > dev.ixl.1.mac.good_octets_rcvd: 179682149054 > dev.ixl.1.pf.que7.tx_itr: 5 > dev.ixl.1.pf.que7.rx_itr: 13 > dev.ixl.1.pf.que7.rx_desc_err: 0 > dev.ixl.1.pf.que7.rx_bytes: 15900612562 > dev.ixl.1.pf.que7.rx_packets: 10528967 > dev.ixl.1.pf.que7.tx_bytes: 24253209 > dev.ixl.1.pf.que7.tx_packets: 367274 > dev.ixl.1.pf.que7.no_desc_avail: 0 > dev.ixl.1.pf.que7.mss_too_small: 0 > dev.ixl.1.pf.que7.tx_dmamap_failed: 0 > dev.ixl.1.pf.que7.tso_tx: 0 > dev.ixl.1.pf.que7.irqs: 393466 > dev.ixl.1.pf.que7.mbuf_defrag_failed: 0 > dev.ixl.1.pf.que6.tx_itr: 5 > dev.ixl.1.pf.que6.rx_itr: 26 > dev.ixl.1.pf.que6.rx_desc_err: 0 > dev.ixl.1.pf.que6.rx_bytes: 31079009581 > dev.ixl.1.pf.que6.rx_packets: 20596797 > dev.ixl.1.pf.que6.tx_bytes: 34704872 > dev.ixl.1.pf.que6.tx_packets: 525307 > dev.ixl.1.pf.que6.no_desc_avail: 0 > dev.ixl.1.pf.que6.mss_too_small: 0 > dev.ixl.1.pf.que6.tx_dmamap_failed: 0 > dev.ixl.1.pf.que6.tso_tx: 0 > dev.ixl.1.pf.que6.irqs: 253510 > dev.ixl.1.pf.que6.mbuf_defrag_failed: 0 > dev.ixl.1.pf.que5.tx_itr: 5 > dev.ixl.1.pf.que5.rx_itr: 6 > dev.ixl.1.pf.que5.rx_desc_err: 0 > dev.ixl.1.pf.que5.rx_bytes: 38281535454 > dev.ixl.1.pf.que5.rx_packets: 25296558 > dev.ixl.1.pf.que5.tx_bytes: 37044422 > dev.ixl.1.pf.que5.tx_packets: 560797 > dev.ixl.1.pf.que5.no_desc_avail: 0 > dev.ixl.1.pf.que5.mss_too_small: 0 > dev.ixl.1.pf.que5.tx_dmamap_failed: 0 > dev.ixl.1.pf.que5.tso_tx: 0 > dev.ixl.1.pf.que5.irqs: 458887 > dev.ixl.1.pf.que5.mbuf_defrag_failed: 0 > dev.ixl.1.pf.que4.tx_itr: 5 > dev.ixl.1.pf.que4.rx_itr: 11 > dev.ixl.1.pf.que4.rx_desc_err: 0 > dev.ixl.1.pf.que4.rx_bytes: 22679151508 > dev.ixl.1.pf.que4.rx_packets: 14988371 > dev.ixl.1.pf.que4.tx_bytes: 7275187 > dev.ixl.1.pf.que4.tx_packets: 109641 > dev.ixl.1.pf.que4.no_desc_avail: 0 > dev.ixl.1.pf.que4.mss_too_small: 0 > dev.ixl.1.pf.que4.tx_dmamap_failed: 0 > dev.ixl.1.pf.que4.tso_tx: 0 > dev.ixl.1.pf.que4.irqs: 355733 > dev.ixl.1.pf.que4.mbuf_defrag_failed: 0 > dev.ixl.1.pf.que3.tx_itr: 5 > dev.ixl.1.pf.que3.rx_itr: 6 > dev.ixl.1.pf.que3.rx_desc_err: 0 > dev.ixl.1.pf.que3.rx_bytes: 16576036845 > dev.ixl.1.pf.que3.rx_packets: 10959252 > dev.ixl.1.pf.que3.tx_bytes: 43909635 > dev.ixl.1.pf.que3.tx_packets: 560494 > dev.ixl.1.pf.que3.no_desc_avail: 0 > dev.ixl.1.pf.que3.mss_too_small: 0 > dev.ixl.1.pf.que3.tx_dmamap_failed: 0 > dev.ixl.1.pf.que3.tso_tx: 0 > dev.ixl.1.pf.que3.irqs: 553422 > dev.ixl.1.pf.que3.mbuf_defrag_failed: 0 > dev.ixl.1.pf.que2.tx_itr: 5 > dev.ixl.1.pf.que2.rx_itr: 11 > dev.ixl.1.pf.que2.rx_desc_err: 0 > dev.ixl.1.pf.que2.rx_bytes: 7991532119 > dev.ixl.1.pf.que2.rx_packets: 5290976 > dev.ixl.1.pf.que2.tx_bytes: 34801015 > dev.ixl.1.pf.que2.tx_packets: 523256 > dev.ixl.1.pf.que2.no_desc_avail: 0 > dev.ixl.1.pf.que2.mss_too_small: 0 > dev.ixl.1.pf.que2.tx_dmamap_failed: 0 > dev.ixl.1.pf.que2.tso_tx: 0 > dev.ixl.1.pf.que2.irqs: 545889 > dev.ixl.1.pf.que2.mbuf_defrag_failed: 0 > dev.ixl.1.pf.que1.tx_itr: 5 > dev.ixl.1.pf.que1.rx_itr: 17 > dev.ixl.1.pf.que1.rx_desc_err: 0 > dev.ixl.1.pf.que1.rx_bytes: 32728556836 > dev.ixl.1.pf.que1.rx_packets: 21667708 > dev.ixl.1.pf.que1.tx_bytes: 146990694 > dev.ixl.1.pf.que1.tx_packets: 394694 > dev.ixl.1.pf.que1.no_desc_avail: 0 > dev.ixl.1.pf.que1.mss_too_small: 0 > dev.ixl.1.pf.que1.tx_dmamap_failed: 0 > dev.ixl.1.pf.que1.tso_tx: 0 > dev.ixl.1.pf.que1.irqs: 447694 > dev.ixl.1.pf.que1.mbuf_defrag_failed: 0 > dev.ixl.1.pf.que0.tx_itr: 5 > dev.ixl.1.pf.que0.rx_itr: 5 > dev.ixl.1.pf.que0.rx_desc_err: 0 > dev.ixl.1.pf.que0.rx_bytes: 13965229080 > dev.ixl.1.pf.que0.rx_packets: 9266714 > dev.ixl.1.pf.que0.tx_bytes: 89709749 > dev.ixl.1.pf.que0.tx_packets: 522887 > dev.ixl.1.pf.que0.no_desc_avail: 0 > dev.ixl.1.pf.que0.mss_too_small: 0 > dev.ixl.1.pf.que0.tx_dmamap_failed: 0 > dev.ixl.1.pf.que0.tso_tx: 0 > dev.ixl.1.pf.que0.irqs: 385910 > dev.ixl.1.pf.que0.mbuf_defrag_failed: 0 > dev.ixl.1.pf.bcast_pkts_txd: 6 > dev.ixl.1.pf.mcast_pkts_txd: 1 > dev.ixl.1.pf.ucast_pkts_txd: 3480756 > dev.ixl.1.pf.good_octets_txd: 292275083 > dev.ixl.1.pf.rx_discards: 1158 > dev.ixl.1.pf.bcast_pkts_rcvd: 0 > dev.ixl.1.pf.mcast_pkts_rcvd: 0 > dev.ixl.1.pf.ucast_pkts_rcvd: 118562908 > dev.ixl.1.pf.good_octets_rcvd: 179675335351 > dev.ixl.1.admin_irq: 0 > dev.ixl.1.watchdog_events: 0 > dev.ixl.1.dynamic_tx_itr: 1 > dev.ixl.1.dynamic_rx_itr: 1 > dev.ixl.1.rx_itr: 62 > dev.ixl.1.tx_itr: 122 > dev.ixl.1.unallocated_queues: 760 > dev.ixl.1.fw_version: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem > 1.262.0 > dev.ixl.1.current_speed: 10 Gbps > dev.ixl.1.advertise_speed: 6 > dev.ixl.1.fc: 0 > dev.ixl.1.%parent: pci1 > dev.ixl.1.%pnpinfo: vendor=0x8086 device=0x1572 subvendor=0x8086 > subdevice=0x0000 class=0x020000 > dev.ixl.1.%location: slot=0 function=1 dbsf=pci0:1:0:1 > dev.ixl.1.%driver: ixl > dev.ixl.1.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version > - 1.7.12-k > dev.ixl.0.wake: 0 > dev.ixl.0.mac.xoff_recvd: 0 > dev.ixl.0.mac.xoff_txd: 0 > dev.ixl.0.mac.xon_recvd: 0 > dev.ixl.0.mac.xon_txd: 0 > dev.ixl.0.mac.tx_frames_big: 0 > dev.ixl.0.mac.tx_frames_1024_1522: 118339212 > dev.ixl.0.mac.tx_frames_512_1023: 2555 > dev.ixl.0.mac.tx_frames_256_511: 2485 > dev.ixl.0.mac.tx_frames_128_255: 197213 > dev.ixl.0.mac.tx_frames_65_127: 41428 > dev.ixl.0.mac.tx_frames_64: 4 > dev.ixl.0.mac.checksum_errors: 0 > dev.ixl.0.mac.rx_jabber: 0 > dev.ixl.0.mac.rx_oversized: 0 > dev.ixl.0.mac.rx_fragmented: 0 > dev.ixl.0.mac.rx_undersize: 0 > dev.ixl.0.mac.rx_frames_big: 0 > dev.ixl.0.mac.rx_frames_1024_1522: 0 > dev.ixl.0.mac.rx_frames_512_1023: 1 > dev.ixl.0.mac.rx_frames_256_511: 2 > dev.ixl.0.mac.rx_frames_128_255: 0 > dev.ixl.0.mac.rx_frames_65_127: 3476278 > dev.ixl.0.mac.rx_frames_64: 600 > dev.ixl.0.mac.rx_length_errors: 0 > dev.ixl.0.mac.remote_faults: 0 > dev.ixl.0.mac.local_faults: 0 > dev.ixl.0.mac.illegal_bytes: 0 > dev.ixl.0.mac.crc_errors: 0 > dev.ixl.0.mac.bcast_pkts_txd: 3 > dev.ixl.0.mac.mcast_pkts_txd: 40988 > dev.ixl.0.mac.ucast_pkts_txd: 118541906 > dev.ixl.0.mac.good_octets_txd: 179675575237 > dev.ixl.0.mac.rx_discards: 0 > dev.ixl.0.mac.bcast_pkts_rcvd: 0 > dev.ixl.0.mac.mcast_pkts_rcvd: 40983 > dev.ixl.0.mac.ucast_pkts_rcvd: 3435898 > dev.ixl.0.mac.good_octets_rcvd: 244179426 > dev.ixl.0.pf.que7.tx_itr: 17 > dev.ixl.0.pf.que7.rx_itr: 5 > dev.ixl.0.pf.que7.rx_desc_err: 0 > dev.ixl.0.pf.que7.rx_bytes: 31998326 > dev.ixl.0.pf.que7.rx_packets: 484742 > dev.ixl.0.pf.que7.tx_bytes: 31079009601 > dev.ixl.0.pf.que7.tx_packets: 20596797 > dev.ixl.0.pf.que7.no_desc_avail: 0 > dev.ixl.0.pf.que7.mss_too_small: 0 > dev.ixl.0.pf.que7.tx_dmamap_failed: 0 > dev.ixl.0.pf.que7.tso_tx: 0 > dev.ixl.0.pf.que7.irqs: 2436192 > dev.ixl.0.pf.que7.mbuf_defrag_failed: 0 > dev.ixl.0.pf.que6.tx_itr: 17 > dev.ixl.0.pf.que6.rx_itr: 5 > dev.ixl.0.pf.que6.rx_desc_err: 0 > dev.ixl.0.pf.que6.rx_bytes: 24252610 > dev.ixl.0.pf.que6.rx_packets: 367266 > dev.ixl.0.pf.que6.tx_bytes: 38281292816 > dev.ixl.0.pf.que6.tx_packets: 25295330 > dev.ixl.0.pf.que6.no_desc_avail: 0 > dev.ixl.0.pf.que6.mss_too_small: 0 > dev.ixl.0.pf.que6.tx_dmamap_failed: 0 > dev.ixl.0.pf.que6.tso_tx: 0 > dev.ixl.0.pf.que6.irqs: 2606798 > dev.ixl.0.pf.que6.mbuf_defrag_failed: 0 > dev.ixl.0.pf.que5.tx_itr: 25 > dev.ixl.0.pf.que5.rx_itr: 5 > dev.ixl.0.pf.que5.rx_desc_err: 0 > dev.ixl.0.pf.que5.rx_bytes: 34699914 > dev.ixl.0.pf.que5.rx_packets: 525289 > dev.ixl.0.pf.que5.tx_bytes: 22679149893 > dev.ixl.0.pf.que5.tx_packets: 14988356 > dev.ixl.0.pf.que5.no_desc_avail: 0 > dev.ixl.0.pf.que5.mss_too_small: 0 > dev.ixl.0.pf.que5.tx_dmamap_failed: 0 > dev.ixl.0.pf.que5.tso_tx: 0 > dev.ixl.0.pf.que5.irqs: 2108645 > dev.ixl.0.pf.que5.mbuf_defrag_failed: 0 > dev.ixl.0.pf.que4.tx_itr: 25 > dev.ixl.0.pf.que4.rx_itr: 5 > dev.ixl.0.pf.que4.rx_desc_err: 0 > dev.ixl.0.pf.que4.rx_bytes: 37045024 > dev.ixl.0.pf.que4.rx_packets: 560793 > dev.ixl.0.pf.que4.tx_bytes: 16575971600 > dev.ixl.0.pf.que4.tx_packets: 10958352 > dev.ixl.0.pf.que4.no_desc_avail: 0 > dev.ixl.0.pf.que4.mss_too_small: 0 > dev.ixl.0.pf.que4.tx_dmamap_failed: 0 > dev.ixl.0.pf.que4.tso_tx: 0 > dev.ixl.0.pf.que4.irqs: 1404550 > dev.ixl.0.pf.que4.mbuf_defrag_failed: 0 > dev.ixl.0.pf.que3.tx_itr: 25 > dev.ixl.0.pf.que3.rx_itr: 6 > dev.ixl.0.pf.que3.rx_desc_err: 0 > dev.ixl.0.pf.que3.rx_bytes: 7138590 > dev.ixl.0.pf.que3.rx_packets: 108040 > dev.ixl.0.pf.que3.tx_bytes: 7991529147 > dev.ixl.0.pf.que3.tx_packets: 5290940 > dev.ixl.0.pf.que3.no_desc_avail: 0 > dev.ixl.0.pf.que3.mss_too_small: 0 > dev.ixl.0.pf.que3.tx_dmamap_failed: 0 > dev.ixl.0.pf.que3.tso_tx: 0 > dev.ixl.0.pf.que3.irqs: 583274 > dev.ixl.0.pf.que3.mbuf_defrag_failed: 0 > dev.ixl.0.pf.que2.tx_itr: 25 > dev.ixl.0.pf.que2.rx_itr: 5 > dev.ixl.0.pf.que2.rx_desc_err: 0 > dev.ixl.0.pf.que2.rx_bytes: 36674966 > dev.ixl.0.pf.que2.rx_packets: 555676 > dev.ixl.0.pf.que2.tx_bytes: 32728554073 > dev.ixl.0.pf.que2.tx_packets: 21667691 > dev.ixl.0.pf.que2.no_desc_avail: 0 > dev.ixl.0.pf.que2.mss_too_small: 0 > dev.ixl.0.pf.que2.tx_dmamap_failed: 0 > dev.ixl.0.pf.que2.tso_tx: 0 > dev.ixl.0.pf.que2.irqs: 2476458 > dev.ixl.0.pf.que2.mbuf_defrag_failed: 0 > dev.ixl.0.pf.que1.tx_itr: 17 > dev.ixl.0.pf.que1.rx_itr: 5 > dev.ixl.0.pf.que1.rx_desc_err: 0 > dev.ixl.0.pf.que1.rx_bytes: 34520252 > dev.ixl.0.pf.que1.rx_packets: 523028 > dev.ixl.0.pf.que1.tx_bytes: 13962850814 > dev.ixl.0.pf.que1.tx_packets: 9232475 > dev.ixl.0.pf.que1.no_desc_avail: 0 > dev.ixl.0.pf.que1.mss_too_small: 0 > dev.ixl.0.pf.que1.tx_dmamap_failed: 0 > dev.ixl.0.pf.que1.tso_tx: 0 > dev.ixl.0.pf.que1.irqs: 1566042 > dev.ixl.0.pf.que1.mbuf_defrag_failed: 0 > dev.ixl.0.pf.que0.tx_itr: 17 > dev.ixl.0.pf.que0.rx_itr: 5 > dev.ixl.0.pf.que0.rx_desc_err: 0 > dev.ixl.0.pf.que0.rx_bytes: 20540631 > dev.ixl.0.pf.que0.rx_packets: 311064 > dev.ixl.0.pf.que0.tx_bytes: 15899484048 > dev.ixl.0.pf.que0.tx_packets: 10511973 > dev.ixl.0.pf.que0.no_desc_avail: 0 > dev.ixl.0.pf.que0.mss_too_small: 0 > dev.ixl.0.pf.que0.tx_dmamap_failed: 0 > dev.ixl.0.pf.que0.tso_tx: 0 > dev.ixl.0.pf.que0.irqs: 950955 > dev.ixl.0.pf.que0.mbuf_defrag_failed: 0 > dev.ixl.0.pf.bcast_pkts_txd: 2 > dev.ixl.0.pf.mcast_pkts_txd: 2 > dev.ixl.0.pf.ucast_pkts_txd: 118541906 > dev.ixl.0.pf.good_octets_txd: 179197841664 > dev.ixl.0.pf.rx_discards: 0 > dev.ixl.0.pf.bcast_pkts_rcvd: 0 > dev.ixl.0.pf.mcast_pkts_rcvd: 0 > dev.ixl.0.pf.ucast_pkts_rcvd: 3435898 > dev.ixl.0.pf.good_octets_rcvd: 240613905 > dev.ixl.0.admin_irq: 0 > dev.ixl.0.watchdog_events: 0 > dev.ixl.0.dynamic_tx_itr: 1 > dev.ixl.0.dynamic_rx_itr: 1 > dev.ixl.0.rx_itr: 62 > dev.ixl.0.tx_itr: 122 > dev.ixl.0.unallocated_queues: 760 > dev.ixl.0.fw_version: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002892 oem > 1.262.0 > dev.ixl.0.current_speed: 10 Gbps > dev.ixl.0.advertise_speed: 6 > dev.ixl.0.fc: 0 > dev.ixl.0.%parent: pci1 > dev.ixl.0.%pnpinfo: vendor=0x8086 device=0x1572 subvendor=0x8086 > subdevice=0x0008 class=0x020000 > dev.ixl.0.%location: slot=0 function=0 dbsf=pci0:1:0:0 > handle=\_SB_.PCI0.PEG0.PEGP > dev.ixl.0.%driver: ixl > dev.ixl.0.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version > - 1.7.12-k > dev.ixl.%parent: > dev.netmap.ixl_rx_miss_bufs: 305 > dev.netmap.ixl_rx_miss: 255 > > > > > root@OPNsense:~ # sysctl -a | grep net > kern.features.inet6: 1 > kern.features.inet: 1 > device vtnet > device netmap > net.local.stream.recvspace: 8192 > net.local.stream.sendspace: 8192 > net.local.dgram.recvspace: 4096 > net.local.dgram.maxdgram: 2048 > net.local.seqpacket.recvspace: 8192 > net.local.seqpacket.maxseqpacket: 8192 > net.local.taskcount: 3 > net.local.recycled: 0 > net.local.deferred: 0 > net.local.inflight: 0 > net.inet.ip.portrange.randomtime: 45 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomized: 1 > net.inet.ip.portrange.reservedlow: 0 > net.inet.ip.portrange.reservedhigh: 1023 > net.inet.ip.portrange.hilast: 65535 > net.inet.ip.portrange.hifirst: 49152 > net.inet.ip.portrange.last: 65535 > net.inet.ip.portrange.first: 1024 > net.inet.ip.portrange.lowlast: 600 > net.inet.ip.portrange.lowfirst: 1023 > net.inet.ip.forwarding: 1 > net.inet.ip.redirect: 1 > net.inet.ip.ttl: 64 > net.inet.ip.sourceroute: 0 > net.inet.ip.intr_queue_maxlen: 1000 > net.inet.ip.intr_queue_drops: 0 > net.inet.ip.accept_sourceroute: 0 > net.inet.ip.gifttl: 30 > net.inet.ip.dummynet.fqpie.limit: 10240 > net.inet.ip.dummynet.fqpie.flows: 1024 > net.inet.ip.dummynet.fqpie.quantum: 1514 > net.inet.ip.dummynet.fqpie.beta: 1250 > net.inet.ip.dummynet.fqpie.alpha: 125 > net.inet.ip.dummynet.fqpie.max_ecnth: 99 > net.inet.ip.dummynet.fqpie.max_burst: 150000 > net.inet.ip.dummynet.fqpie.tupdate: 15000 > net.inet.ip.dummynet.fqpie.target: 15000 > net.inet.ip.dummynet.fqcodel.limit: 10240 > net.inet.ip.dummynet.fqcodel.flows: 1024 > net.inet.ip.dummynet.fqcodel.quantum: 1514 > net.inet.ip.dummynet.fqcodel.interval: 100000 > net.inet.ip.dummynet.fqcodel.target: 5000 > net.inet.ip.dummynet.pie.beta: 1250 > net.inet.ip.dummynet.pie.alpha: 125 > net.inet.ip.dummynet.pie.max_ecnth: 99 > net.inet.ip.dummynet.pie.max_burst: 150000 > net.inet.ip.dummynet.pie.tupdate: 15000 > net.inet.ip.dummynet.pie.target: 15000 > net.inet.ip.dummynet.codel.interval: 100000 > net.inet.ip.dummynet.codel.target: 5000 > net.inet.ip.dummynet.io_pkt_drop: 0 > net.inet.ip.dummynet.io_pkt_fast: 0 > net.inet.ip.dummynet.io_pkt: 0 > net.inet.ip.dummynet.queue_count: 0 > net.inet.ip.dummynet.fsk_count: 2 > net.inet.ip.dummynet.si_count: 0 > net.inet.ip.dummynet.schk_count: 2 > net.inet.ip.dummynet.expire_cycle: 0 > net.inet.ip.dummynet.expire: 1 > net.inet.ip.dummynet.tick_lost: 0 > net.inet.ip.dummynet.tick_diff: 3680 > net.inet.ip.dummynet.tick_adjustment: 234 > net.inet.ip.dummynet.tick_delta_sum: -452 > net.inet.ip.dummynet.tick_delta: 1 > net.inet.ip.dummynet.red_max_pkt_size: 1500 > net.inet.ip.dummynet.red_avg_pkt_size: 512 > net.inet.ip.dummynet.red_lookup_depth: 256 > net.inet.ip.dummynet.debug: 0 > net.inet.ip.dummynet.io_fast: 1 > net.inet.ip.dummynet.pipe_byte_limit: 1048576 > net.inet.ip.dummynet.pipe_slot_limit: 100 > net.inet.ip.dummynet.hash_size: 256 > net.inet.ip.fw.dyn_keep_states: 0 > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.dyn_max: 16384 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 256 > net.inet.ip.fw.enable: 1 > net.inet.ip.fw.static_count: 29 > net.inet.ip.fw.default_to_accept: 1 > net.inet.ip.fw.tables_sets: 0 > net.inet.ip.fw.tables_max: 128 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.grettl: 30 > net.inet.ip.maxfragsperpacket: 16 > net.inet.ip.fragpackets: 0 > net.inet.ip.maxfragpackets: 31311 > net.inet.ip.process_options: 1 > net.inet.ip.stealth: 0 > net.inet.ip.check_interface: 0 > net.inet.ip.mcast.loop: 1 > net.inet.ip.mcast.maxsocksrc: 128 > net.inet.ip.mcast.maxgrpsrc: 512 > net.inet.ip.random_id_total: 1201727 > net.inet.ip.random_id_collisions: 170700 > net.inet.ip.random_id_period: 8192 > net.inet.ip.rfc6864: 1 > net.inet.ip.random_id: 1 > net.inet.ip.no_same_prefix: 0 > net.inet.icmp.maskrepl: 0 > net.inet.icmp.icmplim: 0 > net.inet.icmp.tstamprepl: 1 > net.inet.icmp.bmcastecho: 0 > net.inet.icmp.quotelen: 8 > net.inet.icmp.reply_from_interface: 0 > net.inet.icmp.reply_src: > net.inet.icmp.log_redirect: 0 > net.inet.icmp.drop_redirect: 0 > net.inet.icmp.maskfake: 0 > net.inet.icmp.icmplim_output: 1 > net.inet.igmp.gsrdelay: 10 > net.inet.igmp.default_version: 3 > net.inet.igmp.legacysupp: 0 > net.inet.igmp.v2enable: 1 > net.inet.igmp.v1enable: 1 > net.inet.igmp.sendlocal: 1 > net.inet.igmp.sendra: 1 > net.inet.igmp.recvifkludge: 1 > net.inet.tcp.rfc1323: 1 > net.inet.tcp.mssdflt: 536 > net.inet.tcp.keepidle: 7200000 > net.inet.tcp.keepintvl: 75000 > net.inet.tcp.sendspace: 65228 > net.inet.tcp.recvspace: 65228 > net.inet.tcp.keepinit: 75000 > net.inet.tcp.delacktime: 100 > net.inet.tcp.v6mssdflt: 1220 > net.inet.tcp.nolocaltimewait: 0 > net.inet.tcp.maxtcptw: 32255 > net.inet.tcp.per_cpu_timers: 0 > net.inet.tcp.v6pmtud_blackhole_mss: 1220 > net.inet.tcp.pmtud_blackhole_mss: 1200 > net.inet.tcp.pmtud_blackhole_failed: 0 > net.inet.tcp.pmtud_blackhole_activated_min_mss: 0 > net.inet.tcp.pmtud_blackhole_activated: 0 > net.inet.tcp.pmtud_blackhole_detection: 0 > net.inet.tcp.rexmit_drop_options: 0 > net.inet.tcp.keepcnt: 8 > net.inet.tcp.finwait2_timeout: 60000 > net.inet.tcp.fast_finwait2_recycle: 0 > net.inet.tcp.always_keepalive: 1 > net.inet.tcp.rexmit_slop: 200 > net.inet.tcp.rexmit_min: 30 > net.inet.tcp.msl: 30000 > net.inet.tcp.persmax: 60000 > net.inet.tcp.persmin: 5000 > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 512 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 15364 > net.inet.tcp.syncache.bucketlimit: 30 > net.inet.tcp.syncookies_only: 0 > net.inet.tcp.syncookies: 1 > net.inet.tcp.functions_available: > net.inet.tcp.functions_default: default > net.inet.tcp.soreceive_stream: 0 > net.inet.tcp.isn_reseed_interval: 0 > net.inet.tcp.icmp_may_rst: 1 > net.inet.tcp.pcbcount: 10 > net.inet.tcp.do_tcpdrain: 1 > net.inet.tcp.tcbhashsize: 131072 > net.inet.tcp.log_debug: 0 > net.inet.tcp.minmss: 216 > net.inet.tcp.sack.globalholes: 0 > net.inet.tcp.sack.globalmaxholes: 65536 > net.inet.tcp.sack.maxholes: 128 > net.inet.tcp.sack.enable: 1 > net.inet.tcp.reass.cursegments: 0 > net.inet.tcp.reass.maxsegments: 62500 > net.inet.tcp.sendbuf_max: 2097152 > net.inet.tcp.sendbuf_inc: 8192 > net.inet.tcp.sendbuf_auto: 1 > net.inet.tcp.tso: 1 > net.inet.tcp.path_mtu_discovery: 1 > net.inet.tcp.lro.entries: 8 > net.inet.tcp.recvbuf_max: 2097152 > net.inet.tcp.recvbuf_inc: 16384 > net.inet.tcp.recvbuf_auto: 1 > net.inet.tcp.insecure_rst: 0 > net.inet.tcp.insecure_syn: 0 > net.inet.tcp.ecn.maxretries: 1 > net.inet.tcp.ecn.enable: 2 > net.inet.tcp.abc_l_var: 2 > net.inet.tcp.rfc3465: 1 > net.inet.tcp.initcwnd_segments: 10 > net.inet.tcp.rfc3390: 1 > net.inet.tcp.rfc3042: 1 > net.inet.tcp.rfc6675_pipe: 0 > net.inet.tcp.drop_synfin: 1 > net.inet.tcp.delayed_ack: 0 > net.inet.tcp.blackhole: 2 > net.inet.tcp.log_in_vain: 0 > net.inet.tcp.hostcache.purgenow: 0 > net.inet.tcp.hostcache.purge: 0 > net.inet.tcp.hostcache.prune: 300 > net.inet.tcp.hostcache.expire: 3600 > net.inet.tcp.hostcache.count: 0 > net.inet.tcp.hostcache.bucketlimit: 30 > net.inet.tcp.hostcache.hashsize: 512 > net.inet.tcp.hostcache.cachelimit: 15360 > net.inet.tcp.hostcache.enable: 1 > net.inet.tcp.cc.available: newreno > net.inet.tcp.cc.algorithm: newreno > net.inet.udp.checksum: 1 > net.inet.udp.maxdgram: 57344 > net.inet.udp.recvspace: 42080 > net.inet.udp.blackhole: 1 > net.inet.udp.log_in_vain: 0 > net.inet.esp.esp_enable: 1 > net.inet.ah.ah_cleartos: 1 > net.inet.ah.ah_enable: 1 > net.inet.pim.squelch_wholepkt: 0 > net.inet.ipcomp.ipcomp_enable: 1 > net.inet.carp.ifdown_demotion_factor: 240 > net.inet.carp.senderr_demotion_factor: 240 > net.inet.carp.demotion: 0 > net.inet.carp.log: 1 > net.inet.carp.preempt: 1 > net.inet.carp.allow: 1 > net.inet.sctp.diag_info_code: 0 > net.inet.sctp.blackhole: 0 > net.inet.sctp.use_dcccecn: 1 > net.inet.sctp.rttvar_steady_step: 20 > net.inet.sctp.rttvar_eqret: 0 > net.inet.sctp.rttvar_rtt: 5 > net.inet.sctp.rttvar_bw: 4 > net.inet.sctp.initial_cwnd: 3 > net.inet.sctp.buffer_splitting: 0 > net.inet.sctp.vtag_time_wait: 60 > net.inet.sctp.nat_friendly_init: 0 > net.inet.sctp.enable_sack_immediately: 1 > net.inet.sctp.udp_tunneling_port: 0 > net.inet.sctp.mobility_fasthandoff: 0 > net.inet.sctp.mobility_base: 0 > net.inet.sctp.default_frag_interleave: 1 > net.inet.sctp.default_ss_module: 0 > net.inet.sctp.default_cc_module: 0 > net.inet.sctp.log_level: 0 > net.inet.sctp.max_retran_chunk: 30 > net.inet.sctp.min_residual: 1452 > net.inet.sctp.abort_at_limit: 0 > net.inet.sctp.hb_max_burst: 4 > net.inet.sctp.do_sctp_drain: 1 > net.inet.sctp.max_chained_mbufs: 5 > net.inet.sctp.abc_l_var: 2 > net.inet.sctp.nat_friendly: 1 > net.inet.sctp.cwnd_maxburst: 1 > net.inet.sctp.cmt_use_dac: 0 > net.inet.sctp.cmt_on_off: 0 > net.inet.sctp.outgoing_streams: 10 > net.inet.sctp.incoming_streams: 2048 > net.inet.sctp.add_more_on_output: 1452 > net.inet.sctp.path_pf_threshold: 65535 > net.inet.sctp.path_rtx_max: 5 > net.inet.sctp.assoc_rtx_max: 10 > net.inet.sctp.init_rtx_max: 8 > net.inet.sctp.valid_cookie_life: 60000 > net.inet.sctp.init_rto_max: 60000 > net.inet.sctp.rto_initial: 3000 > net.inet.sctp.rto_min: 1000 > net.inet.sctp.rto_max: 60000 > net.inet.sctp.secret_lifetime: 3600 > net.inet.sctp.shutdown_guard_time: 0 > net.inet.sctp.pmtu_raise_time: 600 > net.inet.sctp.heartbeat_interval: 30000 > net.inet.sctp.asoc_resource: 10 > net.inet.sctp.sys_resource: 1000 > net.inet.sctp.sack_freq: 2 > net.inet.sctp.delayed_sack_time: 200 > net.inet.sctp.chunkscale: 10 > net.inet.sctp.min_split_point: 2904 > net.inet.sctp.pcbhashsize: 256 > net.inet.sctp.tcbhashsize: 1024 > net.inet.sctp.maxchunks: 125000 > net.inet.sctp.fr_maxburst: 4 > net.inet.sctp.maxburst: 4 > net.inet.sctp.peer_chkoh: 256 > net.inet.sctp.pktdrop_enable: 0 > net.inet.sctp.nrsack_enable: 0 > net.inet.sctp.reconfig_enable: 1 > net.inet.sctp.asconf_enable: 1 > net.inet.sctp.auth_enable: 1 > net.inet.sctp.pr_enable: 1 > net.inet.sctp.ecn_enable: 1 > net.inet.sctp.auto_asconf: 1 > net.inet.sctp.recvspace: 1864135 > net.inet.sctp.sendspace: 1864135 > net.inet.ipsec.def_policy: 1 > net.inet.ipsec.esp_trans_deflev: 1 > net.inet.ipsec.esp_net_deflev: 1 > net.inet.ipsec.ah_trans_deflev: 1 > net.inet.ipsec.ah_net_deflev: 1 > net.inet.ipsec.ah_cleartos: 1 > net.inet.ipsec.ah_offsetmask: 0 > net.inet.ipsec.dfbit: 0 > net.inet.ipsec.ecn: 0 > net.inet.ipsec.debug: 0 > net.inet.ipsec.filtertunnel: 0 > net.inet.ipsec.natt_cksum_policy: 0 > net.inet.ipsec.check_policy_history: 0 > net.inet.ipsec.crypto_support: 50331648 > net.inet.raw.recvspace: 9216 > net.inet.raw.maxdgram: 9216 > net.link.generic.system.ifcount: 9 > net.link.ether.inet.allow_multicast: 0 > net.link.ether.inet.log_arp_permanent_modify: 1 > net.link.ether.inet.log_arp_movements: 1 > net.link.ether.inet.log_arp_wrong_iface: 1 > net.link.ether.inet.garp_rexmit_count: 0 > net.link.ether.inet.max_log_per_second: 1 > net.link.ether.inet.maxhold: 1 > net.link.ether.inet.wait: 20 > net.link.ether.inet.proxyall: 0 > net.link.ether.inet.maxtries: 5 > net.link.ether.inet.max_age: 1200 > net.link.ether.ipfw: 0 > net.link.gre.max_nesting: 1 > net.link.vlan.mtag_pcp: 0 > net.link.vlan.soft_pad: 0 > net.link.bridge.ipfw: 0 > net.link.bridge.allow_llz_overlap: 0 > net.link.bridge.inherit_mac: 0 > net.link.bridge.log_stp: 0 > net.link.bridge.pfil_local_phys: 0 > net.link.bridge.pfil_member: 1 > net.link.bridge.ipfw_arp: 0 > net.link.bridge.pfil_bridge: 0 > net.link.bridge.pfil_onlyip: 0 > net.link.gif.parallel_tunnels: 0 > net.link.gif.max_nesting: 1 > net.link.lagg.lacp.default_strict_mode: 1 > net.link.lagg.lacp.debug: 0 > net.link.lagg.default_flowid_shift: 16 > net.link.lagg.default_use_flowid: 1 > net.link.lagg.failover_rx_all: 0 > net.link.tap.debug: 0 > net.link.tap.devfs_cloning: 1 > net.link.tap.up_on_open: 0 > net.link.tap.user_open: 1 > net.link.tun.devfs_cloning: 1 > net.link.log_promisc_mode_change: 1 > net.link.log_link_state_change: 1 > net.link.ifqmaxlen: 8192 > net.key.debug: 0 > net.key.spi_trycnt: 1000 > net.key.spi_minval: 256 > net.key.spi_maxval: 268435455 > net.key.int_random: 60 > net.key.larval_lifetime: 30 > net.key.blockacq_count: 10 > net.key.blockacq_lifetime: 20 > net.key.esp_keymin: 256 > net.key.esp_auth: 0 > net.key.ah_keymin: 128 > net.key.preferred_oldsa: 0 > net.inet6.ip6.forwarding: 1 > net.inet6.ip6.redirect: 1 > net.inet6.ip6.hlim: 64 > net.inet6.ip6.maxfragpackets: 250000 > net.inet6.ip6.accept_rtadv: 0 > net.inet6.ip6.log_interval: 5 > net.inet6.ip6.hdrnestlimit: 15 > net.inet6.ip6.dad_count: 1 > net.inet6.ip6.auto_flowlabel: 1 > net.inet6.ip6.defmcasthlim: 1 > net.inet6.ip6.gifhlim: 30 > net.inet6.ip6.kame_version: FreeBSD > net.inet6.ip6.use_deprecated: 1 > net.inet6.ip6.rr_prune: 5 > net.inet6.ip6.v6only: 1 > net.inet6.ip6.use_tempaddr: 0 > net.inet6.ip6.temppltime: 86400 > net.inet6.ip6.tempvltime: 604800 > net.inet6.ip6.auto_linklocal: 1 > net.inet6.ip6.prefer_tempaddr: 0 > net.inet6.ip6.use_defaultzone: 0 > net.inet6.ip6.maxfrags: 250000 > net.inet6.ip6.mcast_pmtu: 0 > net.inet6.ip6.stealth: 0 > net.inet6.ip6.no_radr: 0 > net.inet6.ip6.norbit_raif: 0 > net.inet6.ip6.rfc6204w3: 0 > net.inet6.ip6.intr_queue_maxlen: 256 > net.inet6.ip6.fw.enable: 1 > net.inet6.ip6.fw.permit_single_frag6: 1 > net.inet6.ip6.fw.deny_unknown_exthdrs: 1 > net.inet6.ip6.grehlim: 64 > net.inet6.ip6.deembed_scopeid: 1 > net.inet6.ip6.dad_enhanced: 1 > net.inet6.ip6.mcast.loop: 1 > net.inet6.ip6.mcast.maxsocksrc: 128 > net.inet6.ip6.mcast.maxgrpsrc: 512 > net.inet6.ipsec6.def_policy: 1 > net.inet6.ipsec6.esp_trans_deflev: 1 > net.inet6.ipsec6.esp_net_deflev: 1 > net.inet6.ipsec6.ah_trans_deflev: 1 > net.inet6.ipsec6.ah_net_deflev: 1 > net.inet6.ipsec6.ecn: 0 > net.inet6.ipsec6.debug: 0 > net.inet6.ipsec6.filtertunnel: 0 > net.inet6.icmp6.rediraccept: 1 > net.inet6.icmp6.redirtimeout: 600 > net.inet6.icmp6.nd6_prune: 1 > net.inet6.icmp6.nd6_delay: 5 > net.inet6.icmp6.nd6_umaxtries: 3 > net.inet6.icmp6.nd6_mmaxtries: 3 > net.inet6.icmp6.nd6_useloopback: 1 > net.inet6.icmp6.nodeinfo: 3 > net.inet6.icmp6.errppslimit: 100 > net.inet6.icmp6.nd6_maxnudhint: 0 > net.inet6.icmp6.nd6_debug: 0 > net.inet6.icmp6.nd6_maxqueuelen: 1 > net.inet6.icmp6.nodeinfo_oldmcprefix: 1 > net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 > net.inet6.icmp6.nd6_gctimer: 86400 > net.inet6.mld.use_allow: 1 > net.inet6.mld.v1enable: 1 > net.inet6.mld.gsrdelay: 10 > net.pfsync.carp_demotion_factor: 240 > net.enc.out.ipsec_bpf_mask: 1 > net.enc.out.ipsec_filter_mask: 1 > net.enc.in.ipsec_bpf_mask: 2 > net.enc.in.ipsec_filter_mask: 2 > net.graph.control.proto: 2 > net.graph.data.proto: 1 > net.graph.family: 32 > net.graph.recvspace: 20480 > net.graph.maxdgram: 20480 > net.graph.mppe.max_rekey: 1000 > net.graph.mppe.log_max_rekey: 1 > net.graph.mppe.block_on_max_rekey: 0 > net.graph.msg_version: 8 > net.graph.abi_version: 12 > net.graph.maxdata: 4096 > net.graph.maxalloc: 4096 > net.graph.threads: 8 > net.pf.share_forward6: 1 > net.pf.share_forward: 1 > net.pf.source_nodes_hashsize: 8192 > net.pf.states_hashsize: 32768 > net.wlan.mesh.maxholding: 2 > net.wlan.mesh.maxretries: 2 > net.wlan.mesh.backofftimeout: 5000 > net.wlan.mesh.confirmtimeout: 40 > net.wlan.mesh.holdingtimeout: 40 > net.wlan.mesh.retrytimeout: 40 > net.wlan.mesh.gateint: 10000 > net.wlan.hwmp.inact: 5000 > net.wlan.hwmp.rootconfint: 2000 > net.wlan.hwmp.rannint: 1000 > net.wlan.hwmp.rootint: 2000 > net.wlan.hwmp.roottimeout: 5000 > net.wlan.hwmp.net_diameter_traversal_time: 512 > net.wlan.hwmp.maxpreq_retries: 3 > net.wlan.hwmp.pathlifetime: 5000 > net.wlan.hwmp.targetonly: 0 > net.wlan.addba_maxtries: 3 > net.wlan.addba_backoff: 10000 > net.wlan.addba_timeout: 250 > net.wlan.recv_bar: 1 > net.wlan.ampdu_age: 500 > net.wlan.debug: 0 > net.wlan.cac_timeout: 60 > net.wlan.nol_timeout: 1800 > net.wlan.devices: > net.route.netisr_maxqlen: 256 > net.my_fibnum: 0 > net.add_addr_allfibs: 1 > net.fibs: 1 > net.raw.recvspace: 8192 > net.raw.sendspace: 8192 > net.isr.numthreads: 1 > net.isr.maxprot: 16 > net.isr.defaultqlimit: 256 > net.isr.maxqlimit: 10240 > net.isr.bindthreads: 0 > net.isr.maxthreads: 1 > net.isr.dispatch: direct > net.iflib.min_tx_latency: 0 > net.ifdescr_maxlen: 1024 > net.bpf.maxbufsize: 524288 > net.bpf.bufsize: 4096 > net.bpf.optimize_writers: 0 > net.bpf.zerocopy_enable: 0 > net.bpf.maxinsns: 512 > net.accf.unloadable: 0 > hw.vtnet.rx_process_limit: 512 > hw.vtnet.mq_max_pairs: 8 > hw.vtnet.mq_disable: 0 > hw.vtnet.lro_disable: 0 > hw.vtnet.tso_disable: 0 > hw.vtnet.csum_disable: 0 > dev.ixl.1.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version > - 1.7.12-k > dev.ixl.0.%desc: Intel(R) Ethernet Connection XL710/X722 Driver, Version > - 1.7.12-k > dev.netmap.ixl_rx_miss_bufs: 305 > dev.netmap.ixl_rx_miss: 255 > dev.netmap.iflib_rx_miss_bufs: 0 > dev.netmap.iflib_rx_miss: 0 > dev.netmap.iflib_crcstrip: 1 > dev.netmap.bridge_batch: 1024 > dev.netmap.default_pipes: 0 > dev.netmap.priv_buf_num: 4098 > dev.netmap.priv_buf_size: 2048 > dev.netmap.buf_curr_num: 163840 > dev.netmap.buf_num: 163840 > dev.netmap.buf_curr_size: 2048 > dev.netmap.buf_size: 2048 > dev.netmap.priv_ring_num: 4 > dev.netmap.priv_ring_size: 20480 > dev.netmap.ring_curr_num: 200 > dev.netmap.ring_num: 200 > dev.netmap.ring_curr_size: 73728 > dev.netmap.ring_size: 73728 > dev.netmap.priv_if_num: 1 > dev.netmap.priv_if_size: 1024 > dev.netmap.if_curr_num: 100 > dev.netmap.if_num: 100 > dev.netmap.if_curr_size: 1024 > dev.netmap.if_size: 1024 > dev.netmap.generic_rings: 1 > dev.netmap.generic_ringsize: 1024 > dev.netmap.generic_mit: 100000 > dev.netmap.admode: 0 > dev.netmap.fwd: 0 > dev.netmap.flags: 0 > dev.netmap.adaptive_io: 0 > dev.netmap.txsync_retry: 2 > dev.netmap.no_pendintr: 1 > dev.netmap.mitigate: 1 > dev.netmap.no_timestamp: 0 > dev.netmap.verbose: 0 > dev.netmap.ix_rx_miss_bufs: 0 > dev.netmap.ix_rx_miss: 0 > dev.netmap.ix_crcstrip: 0 > security.jail.vnet: 0 > > > _______________________________________________ > 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" > > > _______________________________________________ > 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" > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Fri Mar 30 03:24:26 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FF6CF6B2E4 for ; Fri, 30 Mar 2018 03:24:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB46D733A3 for ; Fri, 30 Mar 2018 03:24:25 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 48F0F29EC for ; Fri, 30 Mar 2018 03:24:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U3OPBf087187 for ; Fri, 30 Mar 2018 03:24:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U3OPgt087186 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 03:24:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227086] Upgraded world - broken OpenVPN second tun - ifconfig: ioctl (SIOCAIFADDR): File exists Date: Fri, 30 Mar 2018 03:24:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me 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 keywords 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.25 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, 30 Mar 2018 03:24:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227086 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |regression --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 04:00:30 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 368D5F6DA99 for ; Fri, 30 Mar 2018 04:00:30 +0000 (UTC) (envelope-from Ming.Fu@esentire.com) Received: from mail.esentire.com (mail.esentire.com [52.129.34.132]) (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 CB13C74933 for ; Fri, 30 Mar 2018 04:00:29 +0000 (UTC) (envelope-from Ming.Fu@esentire.com) Received: from exchange.esentire.com (cas01cmb01p.internal [10.1.120.116]) by mail.esentire.com (Postfix) with ESMTPS id DCFA3180C13 for ; Fri, 30 Mar 2018 04:00:16 +0000 (UTC) Received: from mbx01cmb01p.esentire.local (10.1.120.118) by mbx02cmb01p.esentire.local (10.1.120.125) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 30 Mar 2018 00:00:16 -0400 Received: from mbx01cmb01p.esentire.local ([fe80::c159:1a2d:8a3:d44b]) by mbx01cmb01p.esentire.local ([fe80::c159:1a2d:8a3:d44b%14]) with mapi id 15.00.1365.000; Fri, 30 Mar 2018 00:00:16 -0400 From: Ming Fu To: "freebsd-net@freebsd.org" Subject: netmap: How the buf_num of buffers is used by driver and monitor app Thread-Topic: netmap: How the buf_num of buffers is used by driver and monitor app Thread-Index: AdPH2el7Gg10RcF+QIGs5CCTcZiD5Q== Date: Fri, 30 Mar 2018 04:00:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.1.120.131] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Mar 2018 04:00:30 -0000 Hi, I am wondering about the netmap module parameters buf_num. The default buf_= num 163840 seems fairly big compare to intel 10G ixgbe of max 4096 queue si= ze. A full queue of the interface can only use a very small portion of the = buf_num. Can the netmap enabled driver like ixgbe use more buffers than the= "ethtool -G" configured rx/tx queue size? I need to feed packages captured from netmap device to a few traffic monito= rs on the same box. The monitor application attach to the device as netmap = monitor with the /r at the end of device name. My question is if the primar= y read of the device calls poll(), the netmap buffer is synced with the ker= nel. Can the other monitor application still access the packet that the pri= mary read just returned to the kernel? If one of the monitor on the netmap = device is slow, will it cause trouble for the primary reader and other moni= tors? How can I cache a lot of packets in the buffer in case one of the mon= itor application had a temporary slow down? Thanks, Ming From owner-freebsd-net@freebsd.org Fri Mar 30 04:35:35 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 698A6F7017D for ; Fri, 30 Mar 2018 04:35:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 039EA75DD5 for ; Fri, 30 Mar 2018 04:35:35 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 35CEC33A1 for ; Fri, 30 Mar 2018 04:35:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U4ZYCl079924 for ; Fri, 30 Mar 2018 04:35:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U4ZYXt079923 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 04:35:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227100] [epair] epair interface stops working when it reaches the hardware queue limit Date: Fri, 30 Mar 2018 04:35:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me 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 keywords 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.25 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, 30 Mar 2018 04:35:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227100 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 05:30:05 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD505F72E81 for ; Fri, 30 Mar 2018 05:30:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D50477557 for ; Fri, 30 Mar 2018 05:30:05 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A1F243EA3 for ; Fri, 30 Mar 2018 05:30:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U5U4Sd017457 for ; Fri, 30 Mar 2018 05:30:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U5U4R8017455 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 05:30:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227086] Upgraded world - broken OpenVPN second tun - ifconfig: ioctl (SIOCAIFADDR): File exists Date: Fri, 30 Mar 2018 05:30:02 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status 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.25 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, 30 Mar 2018 05:30:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227086 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@freebsd.org, | |freebsd-net@FreeBSD.org Status|New |Open Assignee|freebsd-net@FreeBSD.org |eugen@freebsd.org --- Comment #1 from Eugene Grosbein --- Please supply more details: output of "ifconfig" and "netstat -rn" for older version after OpenVPN tunnel successfully established. What is the task you need OpenVPN within single host for? Does the problem vanish for recent version if you change netmask from 255.255.255.0 to 255.255.255.255 for point-to-point tun interfaces? --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 06:19:20 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2002FF74E6B for ; Fri, 30 Mar 2018 06:19:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B19BE78C1C for ; Fri, 30 Mar 2018 06:19:19 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id EAB3D45B3 for ; Fri, 30 Mar 2018 06:19:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U6JIW0009464 for ; Fri, 30 Mar 2018 06:19:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U6JIob009463 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 06:19:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227086] Upgraded world - broken OpenVPN second tun - ifconfig: ioctl (SIOCAIFADDR): File exists Date: Fri, 30 Mar 2018 06:19:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: zillion1@o2.pl X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@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.25 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, 30 Mar 2018 06:19:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227086 --- Comment #2 from Marek --- Hi Eugene, I can test old revision only (home server "in production") :) Some more outputs from working/current configuration: # ifconfig tun0 tun0: flags=3D8051 metric 0 mtu 1500 options=3D80000 inet 10.20.20.1 --> 10.20.20.2 netmask 0xffffff00 groups: tun Opened by PID 789 # ifconfig tun1 tun1: flags=3D8051 metric 0 mtu 1500 options=3D80000 inet 10.20.20.10 --> 10.20.20.1 netmask 0xffffff00 groups: tun Opened by PID 24835 # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 11.22.33.44 UGS igb1 10.20.20.0/24 10.20.20.2 UGS tun0 10.20.20.1 link#9 UH tun1 10.20.20.2 link#5 UH tun0 10.20.20.10 link#9 UHS lo0 11.22.33.0/22 link#2 U igb1 11.22.33.44 link#2 UHS lo0 127.0.0.1 link#3 UH lo0 192.168.0.0/24 link#1 U igb0 192.168.0.1 link#1 UHS lo0 192.168.8.0/24 link#4 U ue0 192.168.8.100 link#4 UHS lo0 # ps ax | grep openvpn 789 - Ss 1:01,30 /usr/local/sbin/openvpn --cd /usr/local/etc/openv= pn --daemon openvpn --config /usr/local/etc/openvpn/server.conf --writepid /var/run/openvpn.pid 24835 - Ss 0:06,92 /usr/local/sbin/openvpn --cd /usr/local/etc/openv= pn --daemon openvpn_client --config /usr/local/etc/openvpn/client.conf --write= pid /var/run/openvpn_client.pid My home host is "master" OpenVPN server for about 20 other remote family clients. They're connecting to the server without any problems (after install world there was no probem with them too). The OpenVPN client (tun1) on master host is configured to listen some servi= ces like mail, www, and couple of others. Additionaly I have failover server in remote localization, so in case connectivity problems to master host, the failover takes over with 10.20.20= .1 IP address. Clients reconnect after some timeout to the failover. The failover is not FreeBSD based system, and there's no services like mail, www, and so on, its task is to keep connectivity beetween other clients if = main host is temporarily down. To aviod unnecessary requests to the failover from clients, I created on ma= ster host the VPN client next to server with 10.20.20.10 IP address. Regards, Marek --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 06:51:58 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5F7EF76CEC for ; Fri, 30 Mar 2018 06:51:57 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 539DF79E4B for ; Fri, 30 Mar 2018 06:51:57 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: by mail-pg0-x22c.google.com with SMTP id n11so4592181pgp.4 for ; Thu, 29 Mar 2018 23:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=DepBnULdPdJWoq92JrtKlWr3tmiC+vmgMD2AhhE4lNc=; b=r9juvM3OF4ZNGUYdSFVNWCv9SD65lWUZboPjUZ7lbgsmFmIiHZwAJwx/s6oyBRI8UM OjX6mMu3xdc1JmzGzaGcX8ZV3klQZqew3wPbc8rJRl9b5FhyGMdaaOXlPKXEmeVOhX4w HpKvgpAy3X6M06e+9E3qcdxOi4qU72fiaFnmqN8x1StqAaPITbWbhCd+WT0gW7XH767a S/rxT56imNRF3kK9XSeUl4xSkDSQwMS3gvYbYPcN/hLM1YhHnln7VXkxOVxTosb2mQpz 6AoXR7xrrwqY9npN2qqN5a2qlJtEUcAUToCVoXiiPDUjkyRg/uOGJPNcIgBkz33IURof FKvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=DepBnULdPdJWoq92JrtKlWr3tmiC+vmgMD2AhhE4lNc=; b=fX9tatq3508HO3C3yswNET/i+bs3wCQryFfp4pyxAzdxZbfzCPGoCHPiEVVi1P6NG3 VoVAHAtvLzpqvcbKpzBKFCsgVRnUlR9BWpAol7lDQykWCVFy7u0uaZHnw+L3c/5bMgxX elt8z6QDevRZdN4tuZaKJiIT56k4NidMHu14F1u7gS/h4JPI33UB0w/IY7UrBtHE7MGM LhcauEiyTpgfBSJJq9IgnYNOUEZ6NrfqthgWbiuM/rQg9Xt9ZCqs9JH7rgvCQp3tvtw0 PDnv0nxYE01Ayyg1HNtSMjCEQC4A9LQJzw8QgP3BXm1YO30RAw3wgIC5QQ4Ossuds3sr CIHw== X-Gm-Message-State: AElRT7GjqaOMUHRJLIHwDDGK35AMulY05xivUQm/sIZAW1KgYIaZlS1s 1lzDReMilq+wLSfUz4jRlriJnFmkzoY= X-Google-Smtp-Source: AIpwx4/ouIIm89nskZl90lXCcNvicA41szonMuG07K8QIsoPmrigCte9kxj2JuIJHjfIJGhnoqhJPA== X-Received: by 2002:a17:902:7045:: with SMTP id h5-v6mr6296382plt.1.1522392716270; Thu, 29 Mar 2018 23:51:56 -0700 (PDT) Received: from ?IPv6:2402:3a80:654:6bfb:d0df:e42a:63a5:b4f1? ([2402:3a80:654:6bfb:d0df:e42a:63a5:b4f1]) by smtp.gmail.com with ESMTPSA id r9sm16165766pfg.128.2018.03.29.23.51.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 23:51:55 -0700 (PDT) Date: Fri, 30 Mar 2018 12:21:50 +0530 User-Agent: K-9 Mail for Android In-Reply-To: <10647168-66DF-48CD-9121-9CC2B00848D4@sigsegv.be> References: <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> <97945712-B53E-4CF6-B20E-6001CF40CDFC@gmail.com> <10647168-66DF-48CD-9121-9CC2B00848D4@sigsegv.be> MIME-Version: 1.0 Subject: Re: [vnet] [epair] epair interface stops working after some time To: Kristof Provost CC: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Reshad Patuck From: Reshad Patuck Message-ID: <6FF884DA-1AA9-4488-9798-7B16AAFED243@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Mar 2018 06:51:58 -0000 Hi, I have filed a bug for this issue and cc'd both of you in it=2E https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D227100 Best, Reshad On 29 March 2018 6:39:13 PM IST, Kristof Provost wr= ote: >On 29 Mar 2018, at 14:48, Reshad Patuck wrote: >> pulling the 'net=2Elink=2Eepair=2Enetisr_maxqlen' down does seem to mak= e=20 >> this occur faster=2E >> =E2=80=8B >Good, I think my hypothesis about where the issue lies is correct then=2E >You should be able to avoid (or at least reduce the frequency of) the=20 >issue by increasing the value on your system(s)=2E > >> When I dropped it to 2 like Kristof did and I have the same symptoms=20 >> on a box which was not exhibiting the problems manually began to have > >> the same symptoms=2E >> Bumping it back up to 2100 did not restore the functionality (I don't > >> know if it should)=2E >> =E2=80=8B >It=E2=80=99s good to know this=2E It doesn=E2=80=99t surprise me that it = doesn=E2=80=99t fix=20 >things=2E >Something=E2=80=99s wrong in the code which handle an overflow of the net= isr=20 >queue in the epair driver=2E Once that happens the IFF_DRV_OACTIVE flag= =20 >gets set, and we keep enqueuing outside the netisr queue=2E >Somehow we never end up back in epair_nh_drainedcpu(), so the flag >never=20 >gets cleared and the driver never recovers=2E > >> I will create a PR for this later today with all the information I=20 >> have gathered so that we can have it all in one place=2E >> >Thanks=2E Please cc me on it=2E I=E2=80=99ll see if I can figure out what= the=20 >problem is, but we might need someone smarter, so cc Bjoern too=2E > >Regards, >Kristof From owner-freebsd-net@freebsd.org Fri Mar 30 08:01:01 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 202E2F7A7C3 for ; Fri, 30 Mar 2018 08:01:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B20077C0DD for ; Fri, 30 Mar 2018 08:01:00 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 018F8547F for ; Fri, 30 Mar 2018 08:01:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U80xvG090960 for ; Fri, 30 Mar 2018 08:00:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U80x6g090959 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 08:00:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 223835] BGP session not established with md5 password via FRRouting Date: Fri, 30 Mar 2018 08:00:57 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: pautina@kharkiv.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@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.25 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, 30 Mar 2018 08:01:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223835 --- Comment #37 from Alexey --- (In reply to Andrey V. Elsukov from comment #19) Hello. Today I was able to update and test everything. Everything is working fine. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 08:26:29 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A526FF4FE8E for ; Fri, 30 Mar 2018 08:26:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DB7F7CC4C for ; Fri, 30 Mar 2018 08:26:29 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 68F435785 for ; Fri, 30 Mar 2018 08:26:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U8QSAD056714 for ; Fri, 30 Mar 2018 08:26:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U8QSDO056713 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 08:26:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227086] Upgraded world - broken OpenVPN second tun - ifconfig: ioctl (SIOCAIFADDR): File exists Date: Fri, 30 Mar 2018 08:26:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@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.25 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, 30 Mar 2018 08:26:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227086 --- Comment #3 from Eugene Grosbein --- (In reply to Marek from comment #2) The problem is the address 10.20.20.1 that is bounded first to "local syste= m" by means of assigning it to local side of tun0. Then, an attempt is made to assign it to "remote" part of tun1 that is accomplished with creation of another route to 10.20.20.1/32 overriding existing one. Such configuration worked in older versions of FreeBSD breaking traffic flow to such an address via loopback interface but recent versions does not allow overrides to loop= back routes anymore. However, your task can be solved with much simplier configuration. In fact,= you need not local "client" OpenVPN/tun1 at all. Just assign 10.20.20.10/32 to loopback interface as alias in /etc/rc.conf: ifconfig_lo0_alias0=3D"inet 10.20.20.10/32" And your services like mail, www, etc. will work as usual. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 09:44:27 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B76A6F55602 for ; Fri, 30 Mar 2018 09:44:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E52F7FA25 for ; Fri, 30 Mar 2018 09:44: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A3D666265 for ; Fri, 30 Mar 2018 09:44:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U9iQba013556 for ; Fri, 30 Mar 2018 09:44:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U9iQpG013555 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 09:44:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195197] [patch] [netinet6] ipv6 prefix lifetime is not updated for existing address updated through SIOCAIFADDR_IN6 Date: Fri, 30 Mar 2018 09:44:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: guyyur@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: attachments.isobsolete 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.25 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, 30 Mar 2018 09:44:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195197 guyyur@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #149617|0 |1 is obsolete| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 09:45:04 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2063F55676 for ; Fri, 30 Mar 2018 09:45:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42DC47FA8A for ; Fri, 30 Mar 2018 09:45:04 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 85FFE626B for ; Fri, 30 Mar 2018 09:45:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U9j30Y014512 for ; Fri, 30 Mar 2018 09:45:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U9j3Va014511 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 09:45:03 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195197] [patch] [netinet6] ipv6 prefix lifetime is not updated for existing address updated through SIOCAIFADDR_IN6 Date: Fri, 30 Mar 2018 09:45:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: guyyur@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: attachments.isobsolete 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.25 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, 30 Mar 2018 09:45:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195197 guyyur@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #149619|0 |1 is obsolete| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 09:45:23 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B61EF5572C for ; Fri, 30 Mar 2018 09:45:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCC0D7FAEC for ; Fri, 30 Mar 2018 09:45:22 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0A975626E for ; Fri, 30 Mar 2018 09:45:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U9jLjR015038 for ; Fri, 30 Mar 2018 09:45:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U9jLpk015037 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 09:45:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195197] [patch] [netinet6] ipv6 prefix lifetime is not updated for existing address updated through SIOCAIFADDR_IN6 Date: Fri, 30 Mar 2018 09:45:21 +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 Only Me X-Bugzilla-Who: guyyur@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: attachments.isobsolete 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.25 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, 30 Mar 2018 09:45:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195197 guyyur@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #149620|0 |1 is obsolete| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 09:46:19 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 195ACF558D5 for ; Fri, 30 Mar 2018 09:46:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4C507FBA1 for ; Fri, 30 Mar 2018 09:46:18 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E3C506270 for ; Fri, 30 Mar 2018 09:46:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U9kHo8016154 for ; Fri, 30 Mar 2018 09:46:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U9kHnh016153 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 09:46:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195197] [netinet6] ipv6 prefix not renewed when managed by userspace daemon with pltime and vltime Date: Fri, 30 Mar 2018 09:46:18 +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 Only Me X-Bugzilla-Who: guyyur@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: short_desc 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.25 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, 30 Mar 2018 09:46:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195197 guyyur@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[patch] [netinet6] ipv6 |[netinet6] ipv6 prefix not |prefix lifetime is not |renewed when managed by |updated for existing |userspace daemon with |address updated through |pltime and vltime |SIOCAIFADDR_IN6 | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 09:58:09 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FDA2F566F3 for ; Fri, 30 Mar 2018 09:58:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A07AC80269 for ; Fri, 30 Mar 2018 09:58:08 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id EFB6663C3 for ; Fri, 30 Mar 2018 09:58:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2U9w7Y2041368 for ; Fri, 30 Mar 2018 09:58:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2U9w754041367 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 09:58:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195197] [netinet6] ipv6 prefix not renewed when managed by userspace daemon with pltime and vltime Date: Fri, 30 Mar 2018 09:58:08 +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 Only Me X-Bugzilla-Who: guyyur@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.25 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, 30 Mar 2018 09:58:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195197 --- Comment #4 from guyyur@gmail.com --- There is an additional problem that SIOCSPFXFLUSH_IN6 will trigger a KASSER= T in nd6_prefix_del "prefix %p has referencing addresses" when kernel is built w= ith INVARIANTS and you add a static address by rc.conf or ifconfig. Example: ifconfig vtnet0 inet6 2001:db8::1 ndp -P I removed my old patches. The NetBSD changes are the correct way and fix both issues. I am on my second attempt at porting them, need to do further adjustments to get fully working. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 13:32:27 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B03F4F6DC01 for ; Fri, 30 Mar 2018 13:32:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40FC5686F1 for ; Fri, 30 Mar 2018 13:32: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 6D8CF101F1 for ; Fri, 30 Mar 2018 13:32:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2UDWQm2071200 for ; Fri, 30 Mar 2018 13:32:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2UDWQt7071183 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 13:32:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 227086] Upgraded world - broken OpenVPN second tun - ifconfig: ioctl (SIOCAIFADDR): File exists Date: Fri, 30 Mar 2018 13:32:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: zillion1@o2.pl X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution 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.25 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, 30 Mar 2018 13:32:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227086 Marek changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Not A Bug Status|Open |Closed --- Comment #4 from Marek --- (In reply to Eugene Grosbein from comment #3) I've just tested your suggestion on my current old system by stopping OpenV= PN client, and manually adding alias to the lo0 interface. Well, now my OpenVPN configuration is thinner (server only), everything just works like a charm! Just one alias... Huh! Now I can build the world again =3D) Thank you very much for your help and clarification. Much appreciated. Marek --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 16:44:46 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 658F8F79DBD for ; Fri, 30 Mar 2018 16:44:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F24B770304 for ; Fri, 30 Mar 2018 16:44: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 41C1011C26 for ; Fri, 30 Mar 2018 16:44:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2UGijHv019051 for ; Fri, 30 Mar 2018 16:44:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2UGijFv019050 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 16:44:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221317] Netmap issue after ixgbe driver update in r320897 Date: Fri, 30 Mar 2018 16:44:44 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sg@efficientip.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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.25 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, 30 Mar 2018 16:44:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221317 --- Comment #16 from Sylvain Galliano --- Created attachment 191979 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D191979&action= =3Dedit Patch to add a 1s delay before stopping ixgbe interface (no carrier issue on stable) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 16:45:23 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCB49F79EAE for ; Fri, 30 Mar 2018 16:45:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D92A70570 for ; Fri, 30 Mar 2018 16:45:23 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id C011F11C2D for ; Fri, 30 Mar 2018 16:45:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2UGjMq3020101 for ; Fri, 30 Mar 2018 16:45:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2UGjM8j020100 for freebsd-net@FreeBSD.org; Fri, 30 Mar 2018 16:45:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221317] Netmap issue after ixgbe driver update in r320897 Date: Fri, 30 Mar 2018 16:45:22 +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.1-STABLE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sg@efficientip.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@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.25 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, 30 Mar 2018 16:45:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221317 --- Comment #17 from Sylvain Galliano --- (In reply to Cassiano Peixoto from comment #15) Hello Cassiano, can you try to recompile kernel using attached patch. It add a 1s delay before stopping ixgbe interface (i.e. ifconfig down or ne= tmap initialisation) I know it's a TERRIBLE patch but I had no issue after stressing my servers. If it's also work for you, I hope this can help driver maintainer to find a= nd correct the issue. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Mar 30 17:46:08 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 435B3F50DA9 for ; Fri, 30 Mar 2018 17:46:08 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B73C1729E5 for ; Fri, 30 Mar 2018 17:46:07 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id w2UHk4og002090; Fri, 30 Mar 2018 19:46:04 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 6AA32DC9; Fri, 30 Mar 2018 19:46:04 +0200 (CEST) Message-ID: <5ABE77DB.3030501@omnilan.de> Date: Fri, 30 Mar 2018 19:46:03 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Grzegorz Junka CC: "freebsd-net@freebsd.org" Subject: Re: Default network device References: <5237ec10-c906-db3c-f62f-cc7478a31dc0@yoonka.com> In-Reply-To: <5237ec10-c906-db3c-f62f-cc7478a31dc0@yoonka.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 30 Mar 2018 19:46:05 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Mar 2018 17:46:08 -0000 Bezüglich Grzegorz Junka's Nachricht vom 24.03.2018 17:21 (localtime): > Hi, > > In my laptop I have both, wlan0 and ue0 (ethernet). When both are > connected, FreeBSD chooses to use wlan0 by default. Only when I > disable wlan0 it switches to use ue0. Since ue0 is ethernet it's > obviously much faster than wlan0. > > Why FreeBSD is selecting wlan rather than ue? How to configure the > network so that wlan0 is only used when ue0 isn't available? > Hello GrzegorzJ, I don't know the internal details of FreeBSDs source address selection, but I as far as I know it doesn't care about the type of interface in any way, including it's capabilities like bandwidth. You can use if_lagg(4) and configure your 802.11 device as fallback only. Otehrwise simple IP matching algorithms are in place. So if the host, you're connecting to, is reachable via two lo0 routes (netstat -nr -f inet and look for /32 and /?? routes – the /32 is on the interface and the real network is on lo0), you could adjust it's metric probably... Never done so, but these are the places to start. -harry From owner-freebsd-net@freebsd.org Fri Mar 30 19:23:26 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BB5BF5AC5E for ; Fri, 30 Mar 2018 19:23:26 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 3CA9A7A645 for ; Fri, 30 Mar 2018 19:23:26 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id c188so9936842qkg.2 for ; Fri, 30 Mar 2018 12:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X9zSYqjam8RVI6Am09DPui0fzdWbaJDNlRdm4L/A/1Q=; b=XINTda93MYOaLnPEGplvBSJOAVOHYft5aE+g/Rk1MX5cHJJ0l+xVX9+xP0RE9udJ49 ck+vVgiMvHbBxc7Qd4AK5kc9Ci1kHUnCdNf5heCd8DuRGNkxSYhFruaNkpLkFwxsxsOa 6mTb7TQWUAM4ZWEouX1fYoEM8Ew1+aIvKmRzw07AWk1Y2gv1KNglxnBHN4yyGEFGp3lh ecnSV10e7NKo7lDfXVWWqQuoJiLxQvzUv4/mDlWibQfQdL0I3V1AxDhgUdIIJoqywwE3 6faxM1jcq7BdMco6JZcV+wkorOTcfw9xZw03MfSO+ECpRz16ifQsI0cpyBQadj7Vmi9b /28w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X9zSYqjam8RVI6Am09DPui0fzdWbaJDNlRdm4L/A/1Q=; b=sSgEhpFhDmlc/wT6legyoNAC0u95AbOkjTevaR/kGEcqC1OVRUkJcv60+31mmaQ7Nj k8qM/Oz9T42+WlJ1rduw79t9pbcLz9C8Fy9cRdf2H9DbgYnKesUiM+hdJT0/rV38QZmZ 0tWXCXp1HgEGb3ECqwGWyRRtc29jvdoUh0tvA6u5Hi5bwHxKUo75I8AG9IKGN/baQvyV Xk1r1lYkI7r4Q9o5adaBucgAl0j+HTxfsEoYL+CzsUx6183Gs+VSzXCy8MgVHWujM/Pd OIaYslvbupabdieOZyUqoc5WAxQDTj2V/tAC3no6LFeSiqgjJeXbLLdTn0aOiBYjlX+f lk7g== X-Gm-Message-State: ALQs6tCso19wOYdfD8iCwlwrIueatpX6kMI2DMZpi1zUoLJpFCRQjobx a/9hYJlr7hhDEh4s1TzTRhsixD4tfV66efyYMIFFKg== X-Google-Smtp-Source: AIpwx4+Rn+zNf+IZzJ0IC5RnKKt10gXsfkspFG632S2T/0e6NWpUqo7/o0zj0inTUmPH1PmUtF/Ga/XbEW3yGH+b5vY= X-Received: by 10.55.9.211 with SMTP id 202mr305824qkj.183.1522437805586; Fri, 30 Mar 2018 12:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.195.204 with HTTP; Fri, 30 Mar 2018 12:23:25 -0700 (PDT) In-Reply-To: References: From: Vincenzo Maffione Date: Fri, 30 Mar 2018 21:23:25 +0200 Message-ID: Subject: Re: netmap: How the buf_num of buffers is used by driver and monitor app To: Ming Fu Cc: "freebsd-net@freebsd.org" , Giuseppe Lettieri Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Mar 2018 19:23:26 -0000 Hi, 2018-03-30 6:00 GMT+02:00 Ming Fu : > Hi, > > I am wondering about the netmap module parameters buf_num. The default > buf_num 163840 seems fairly big compare to intel 10G ixgbe of max 4096 > queue size. A full queue of the interface can only use a very small portion > of the buf_num. Can the netmap enabled driver like ixgbe use more buffers > than the "ethtool -G" configured rx/tx queue size? > No, netmap will just the same number of buffers as configured with ethtool -G. The default buf_num is just a default that covers many things that you can do. First of all you would need 4096 for each TX and RX ring (so typically 2*8*4096). Then you need additional 2*4096 buffers for the host rings. If you create netmap pipes like 'netmap:eth0{1' you need more buffers for the pipe TX and RX ring. If you know how many netmap buffers you really need for your purpose you can just lower buf_num to the minimun number that won't cause your application to fail with ENOMEM. > > I need to feed packages captured from netmap device to a few traffic > monitors on the same box. The monitor application attach to the device as > netmap monitor with the /r at the end of device name. My question is if the > primary read of the device calls poll(), the netmap buffer is synced with > the kernel. Can the other monitor application still access the packet that > the primary read just returned to the kernel? If one of the monitor on the > netmap device is slow, will it cause trouble for the primary reader and > other monitors? How can I cache a lot of packets in the buffer in case one > of the monitor application had a temporary slow down? > If you use copy-based monitor (no 'z') each monitor will receive an independent copy of the traffic going through monitored rings. So I think if one of the monitoring applications slows down there should be no effect on the others. If you use zerocopy monitor, the same intercepted buffer is passed between the various monitoring applications (and the main application), so I think if one stops or slows down, then all the monitors will stop. There is some explanation in the comment here https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_monitor.c#L30-L69 Feel free to open a ticket on github ( https://github.com/luigirizzo/netmap/issues) if you have a more specific question. Cheers, Vincenzo > > Thanks, > Ming > _______________________________________________ > 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 From owner-freebsd-net@freebsd.org Sat Mar 31 13:46:07 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B7D0F5AB1E for ; Sat, 31 Mar 2018 13:46:07 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 D41E18464D for ; Sat, 31 Mar 2018 13:46:06 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: by mail-pf0-x229.google.com with SMTP id y69so7119625pfb.5 for ; Sat, 31 Mar 2018 06:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:mime-version:content-transfer-encoding:subject:to :from:message-id; bh=pM+dvDc0BD6QpcHcFbsHMg+5FE+N/O9FtzIp7GNUqy0=; b=bX9shs5hPuM9SgCDAhudoUhf8UrYfY6h/QkcsvzN02EIXu6Xa1x0rdT+lr++iPNHWK 2N9wQG5vJl/uTSWbvutRGdPRs3pERhIhCayvQwBzrwH2uur+B96mycLuXxJUpT2tobE1 rFh+il6KnkYp8+rAwxLmFipk9IsRf0O0TZdvwaok1l+aXaeybtaPxjI2pGyVy4WdDUaX zwD08P0YntstxGVeW4Ek3YcOk1+/11mKQwlvdM7586kFGnfbe/mKfglCHBBr/EwB8Uai 5MaKu8o4KeN/h3f4tUGW/AD5Mp3YdxbtaHn389s89umJqu26RsjVevHGaC7xC3op2UMs zuMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=pM+dvDc0BD6QpcHcFbsHMg+5FE+N/O9FtzIp7GNUqy0=; b=rhIzyLX88SHFo4Z89oO4Wi9D9GULtUDiADLDNBK2uIyzx75Jlmv9f353BOkMHeG+/V FuGzXVwbWs5zRJ/cx2sljvUMtiHvSDDK3KJKwgRthYidqrqfzU/kOEF/3KPksLZd4bHV 1ul37SHDzi2X9KyaxfINxXft4B/ioXPIEkqVjDmrtrhU/Z5TCXwb7YUxpr7Efo/bzOwJ rETCJR/g/yH5LZmFXtD2NqGKa2lKHIdMpHdd8jeV4CM9AfwHeOtuzafaeazqOuP30PlO ctmWoRR2dwBQRTjQYPesAXtfcrwLV2BWy33B1rEdsPEHpiHD3pUn+0qyuAofDFQc6znp wgLw== X-Gm-Message-State: AElRT7Eg7L1xgcRyuDjEn5VP3jO/VEbPG7ZD3WLyHkhpBMnm2CJIVZpj 8R4GNqFhjT/8BeiDh+nOYFaC8qjn3WU= X-Google-Smtp-Source: AIpwx4//D2oeLRpOnOvImQ+RtgmCw7ZwNoGl7wHH30g9DNUyhSL/tRx9jVQ6nWg+Q29uN6hj5ZWpuQ== X-Received: by 10.99.149.86 with SMTP id t22mr1951230pgn.144.1522503965565; Sat, 31 Mar 2018 06:46:05 -0700 (PDT) Received: from ?IPv6:2402:3a80:690:709c:6704:6ca5:9bd0:6a05? ([2402:3a80:690:709c:6704:6ca5:9bd0:6a05]) by smtp.gmail.com with ESMTPSA id z28sm18900879pgc.15.2018.03.31.06.46.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 06:46:05 -0700 (PDT) Date: Sat, 31 Mar 2018 19:16:01 +0530 User-Agent: K-9 Mail for Android MIME-Version: 1.0 Subject: [netgraph] ng_bpf filter large list of IP addresses To: freebsd-net@freebsd.org From: Reshad Patuck Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 31 Mar 2018 13:46:07 -0000 Hey, =E2=80=8B I am trying to load a bpf filter into netgraph's ng_bpf for filtering out = thousands of separate individual IP addresses=2E =E2=80=8B I am using a simple c program to generate output that I can load into ng_b= pf using a shell=2E =E2=80=8B This works fine for upto a list of about 250 IP addresses, but as I get up= to larger IP lists I hit kern=2Eargmax (262144 bytes)=2E =E2=80=8B Whenever I try to load a larger filter into ng_bpf using a file I run into= an error saying: ``` ngctl: send msg: Invalid argument ngctl: line 1: error in file ``` I have attached debug output for the same=2E =E2=80=8B My ng_bpf node 'em1-bpf' has two hooks, 'in' and 'out'=2E =E2=80=8B I have linked to a paste with the following files: - ngtl-command -> the ngctl command which runs correctly from a command li= ne - ngctl-config -> the ngctl config file with the same filter - bpf=2Ec -> a c file that takes netgraph node details a pcap-filter and c= onverts it to a ngctl command - ngctl -> debug 5 in a ngctl shell for running the config file =E2=80=8B Please let me know what I am doing wrong with the ngctl config file and if= there is another way, maybe something more direct to load a binary bpf fil= ter directly into ng_bpf=2E =E2=80=8B As a hack around this I plan to have two ng_bpfs with multiple nodes betwe= en themselves filtering parts of the IP list=2E This works but I am not sure of the performance implications of this=2E =E2=80=8B Any suggestions/improvements general tips would be really helpful=2E =E2=80=8B Link to files: https://paste=2Eee/p/BHOoG =E2=80=8B Thanks and best regards, =E2=80=8B Reshad From owner-freebsd-net@freebsd.org Sat Mar 31 14:12:38 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F9DCF63D47 for ; Sat, 31 Mar 2018 14:12:38 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF3DF85767 for ; Sat, 31 Mar 2018 14:12:37 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2VECMDf089249 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 31 Mar 2018 16:12:23 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: reshadpatuck1@gmail.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w2VECHh4047808 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Mar 2018 21:12:18 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: [netgraph] ng_bpf filter large list of IP addresses To: Reshad Patuck , freebsd-net@freebsd.org References: From: Eugene Grosbein Message-ID: <5ABF973D.5070009@grosbein.net> Date: Sat, 31 Mar 2018 21:12:13 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 31 Mar 2018 14:12:38 -0000 31.03.2018 20:46, Reshad Patuck wrote: [skip] > Please let me know what I am doing wrong with the ngctl config file and if there is another way, > maybe something more direct to load a binary bpf filter directly into ng_bpf. [skip] Please read ngctl(8) manual page carefully. There are other ways. First, you may move all arguments to ngctl from command line to a file and run ngctl -f filename. Second, as for many other utilities, you can use dash (-) instead of filename to make ngctl read its arguments from standard input, e.g. this is the same as "ngctl ls": # echo ls | ngctl -f - There are 9 total nodes: Name: em0 Type: ether ID: 00000001 Num hooks: 0 Then, for shell script, you can use << such as: #!/bin/sh ngctl -f - << EOF msg em1-bpf: setprogram $program EOF All these methods impose no limits on size of such control messages. However, there is loader tunnable net.graph.maxdgram that imposes another limit on size of binary representation of control message that ngctl passes to a kernel and you may need to increase it at some point. I increase it upto 8 megabytes for my purposes. From owner-freebsd-net@freebsd.org Sat Mar 31 17:28:49 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20034F7253A for ; Sat, 31 Mar 2018 17:28:49 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C24426D599 for ; Sat, 31 Mar 2018 17:28:48 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (unknown [IPv6:2610:1c1:1:607c::16:10]) by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id B77491AD49 for ; Sat, 31 Mar 2018 17:28:48 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id B68974BC1E; Sat, 31 Mar 2018 17:28:48 +0000 (UTC) Date: Sat, 31 Mar 2018 17:28:48 +0000 To: freebsd-net@freebsd.org From: Phabricator Reply-to: D4090+325+3b0e398d354b0e86@reviews.freebsd.org Subject: [Differential] D4090: mbuf(9): unbreak m_fragment() 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: D4090: mbuf(9): unbreak m_fragment() X-Herald-Rules: <28> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NGMzZGUyODg0ODA5ZmU5NDFmYjZkMzllMWJlIFq/xVA= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_f07de0dd928626a6400f951a70c9fa87" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 17:28:49 -0000 --b1_f07de0dd928626a6400f951a70c9fa87 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 VGhpcyByZXZpc2lvbiB3YXMgYXV0b21hdGljYWxseSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIGNv bW1pdHRlZCBjaGFuZ2VzLgpDbG9zZWQgYnkgY29tbWl0IHJTMzMxODQ3OiBNRkMgcjMyNDY3Mzog KGF1dGhvcmVkIGJ5IGF2b3MpLgoKQ0hBTkdFRCBQUklPUiBUTyBDT01NSVQKICBodHRwczovL3Jl dmlld3MzLmZyZWVic2Qub3JnL0Q0MDkwP3ZzPTk5NzMmaWQ9MjU4NDcjdG9jCgpSRVBPU0lUT1JZ CiAgclMgRnJlZUJTRCBzcmMgcmVwb3NpdG9yeQoKQ0hBTkdFUyBTSU5DRSBMQVNUIFVQREFURQog IGh0dHBzOi8vcmV2aWV3czMuZnJlZWJzZC5vcmcvRDQwOTA/dnM9OTk3MyZpZD0yNTg0NwoKUkVW SVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzMy5mcmVlYnNkLm9yZy9ENDA5MAoKQUZGRUNU RUQgRklMRVMKICBzdGFibGUvMTEKICBzdGFibGUvMTEvc3lzL2tlcm4vdWlwY19tYnVmLmMKCkVN QUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzMy5mcmVlYnNkLm9yZy9zZXR0aW5ncy9w YW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IHMzZXJpb3NfZ21haWwuY29tLCBhZHJpYW4sIGds ZWJpdXMsIGZyZWVic2QtbmV0LWxpc3QKQ2M6IGltcAo= --b1_f07de0dd928626a6400f951a70c9fa87 Content-Type: text/x-patch; charset=utf-8; name="D4090.25847.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D4090.25847.patch" ZGlmZiAtLWdpdCBhL3N0YWJsZS8xMSBiL3N0YWJsZS8xMQpkaWZmIC0tZ2l0IGEvc3RhYmxlLzEx L3N5cy9rZXJuL3VpcGNfbWJ1Zi5jIGIvc3RhYmxlLzExL3N5cy9rZXJuL3VpcGNfbWJ1Zi5jCi0t LSBhL3N0YWJsZS8xMS9zeXMva2Vybi91aXBjX21idWYuYworKysgYi9zdGFibGUvMTEvc3lzL2tl cm4vdWlwY19tYnVmLmMKQEAgLTE0MzksNjIgKzE0MzksNTkgQEAKIHN0cnVjdCBtYnVmICoKIG1f ZnJhZ21lbnQoc3RydWN0IG1idWYgKm0wLCBpbnQgaG93LCBpbnQgbGVuZ3RoKQogewotCXN0cnVj dCBtYnVmICptX25ldyA9IE5VTEwsICptX2ZpbmFsID0gTlVMTDsKLQlpbnQgcHJvZ3Jlc3MgPSAw OworCXN0cnVjdCBtYnVmICptX2ZpcnN0LCAqbV9sYXN0OworCWludCBkaXZpc29yID0gMjU1LCBw cm9ncmVzcyA9IDAsIGZyYWdsZW47CiAKIAlpZiAoIShtMC0+bV9mbGFncyAmIE1fUEtUSERSKSkK IAkJcmV0dXJuIChtMCk7CiAKLQlpZiAoKGxlbmd0aCA9PSAwKSB8fCAobGVuZ3RoIDwgLTIpKQor CWlmIChsZW5ndGggPT0gMCB8fCBsZW5ndGggPCAtMikKIAkJcmV0dXJuIChtMCk7CisJaWYgKGxl bmd0aCA+IE1DTEJZVEVTKQorCQlsZW5ndGggPSBNQ0xCWVRFUzsKKwlpZiAobGVuZ3RoIDwgMCAm JiBkaXZpc29yID4gTUNMQllURVMpCisJCWRpdmlzb3IgPSBNQ0xCWVRFUzsKKwlpZiAobGVuZ3Ro ID09IC0xKQorCQlsZW5ndGggPSAxICsgKGFyYzRyYW5kb20oKSAlIGRpdmlzb3IpOworCWlmIChs ZW5ndGggPiAwKQorCQlmcmFnbGVuID0gbGVuZ3RoOwogCiAJbV9maXhoZHIobTApOyAvKiBOZWVk ZWQgc2FuaXR5IGNoZWNrICovCiAKLQltX2ZpbmFsID0gbV9nZXRjbChob3csIE1UX0RBVEEsIE1f UEtUSERSKTsKLQotCWlmIChtX2ZpbmFsID09IE5VTEwpCisJbV9maXJzdCA9IG1fZ2V0Y2woaG93 LCBNVF9EQVRBLCBNX1BLVEhEUik7CisJaWYgKG1fZmlyc3QgPT0gTlVMTCkKIAkJZ290byBub3Nw YWNlOwogCi0JaWYgKG1fZHVwX3BrdGhkcihtX2ZpbmFsLCBtMCwgaG93KSA9PSAwKQorCWlmICht X2R1cF9wa3RoZHIobV9maXJzdCwgbTAsIGhvdykgPT0gMCkKIAkJZ290byBub3NwYWNlOwogCi0J bV9uZXcgPSBtX2ZpbmFsOworCW1fbGFzdCA9IG1fZmlyc3Q7CiAKLQlpZiAobGVuZ3RoID09IC0x KQotCQlsZW5ndGggPSAxICsgKGFyYzRyYW5kb20oKSAmIDI1NSk7Ci0KIAl3aGlsZSAocHJvZ3Jl c3MgPCBtMC0+bV9wa3RoZHIubGVuKSB7Ci0JCWludCBmcmFnbGVuOwotCi0JCWlmIChsZW5ndGgg PiAwKQotCQkJZnJhZ2xlbiA9IGxlbmd0aDsKLQkJZWxzZQotCQkJZnJhZ2xlbiA9IDEgKyAoYXJj NHJhbmRvbSgpICYgMjU1KTsKKwkJaWYgKGxlbmd0aCA9PSAtMikKKwkJCWZyYWdsZW4gPSAxICsg KGFyYzRyYW5kb20oKSAlIGRpdmlzb3IpOwogCQlpZiAoZnJhZ2xlbiA+IG0wLT5tX3BrdGhkci5s ZW4gLSBwcm9ncmVzcykKIAkJCWZyYWdsZW4gPSBtMC0+bV9wa3RoZHIubGVuIC0gcHJvZ3Jlc3M7 CiAKLQkJaWYgKGZyYWdsZW4gPiBNQ0xCWVRFUykKLQkJCWZyYWdsZW4gPSBNQ0xCWVRFUzsKLQot CQlpZiAobV9uZXcgPT0gTlVMTCkgewotCQkJbV9uZXcgPSBtX2dldGNsKGhvdywgTVRfREFUQSwg MCk7CisJCWlmIChwcm9ncmVzcyAhPSAwKSB7CisJCQlzdHJ1Y3QgbWJ1ZiAqbV9uZXcgPSBtX2dl dGNsKGhvdywgTVRfREFUQSwgMCk7CiAJCQlpZiAobV9uZXcgPT0gTlVMTCkKIAkJCQlnb3RvIG5v c3BhY2U7CisKKwkJCW1fbGFzdC0+bV9uZXh0ID0gbV9uZXc7CisJCQltX2xhc3QgPSBtX25ldzsK IAkJfQogCi0JCW1fY29weWRhdGEobTAsIHByb2dyZXNzLCBmcmFnbGVuLCBtdG9kKG1fbmV3LCBj YWRkcl90KSk7CisJCW1fY29weWRhdGEobTAsIHByb2dyZXNzLCBmcmFnbGVuLCBtdG9kKG1fbGFz dCwgY2FkZHJfdCkpOwogCQlwcm9ncmVzcyArPSBmcmFnbGVuOwotCQltX25ldy0+bV9sZW4gPSBm cmFnbGVuOwotCQlpZiAobV9uZXcgIT0gbV9maW5hbCkKLQkJCW1fY2F0KG1fZmluYWwsIG1fbmV3 KTsKLQkJbV9uZXcgPSBOVUxMOworCQltX2xhc3QtPm1fbGVuID0gZnJhZ2xlbjsKIAl9CiAJbV9m cmVlbShtMCk7Ci0JbTAgPSBtX2ZpbmFsOworCW0wID0gbV9maXJzdDsKIAlyZXR1cm4gKG0wKTsK IG5vc3BhY2U6Ci0JaWYgKG1fZmluYWwpCi0JCW1fZnJlZW0obV9maW5hbCk7CisJaWYgKG1fZmly c3QpCisJCW1fZnJlZW0obV9maXJzdCk7CiAJLyogUmV0dXJuIHRoZSBvcmlnaW5hbCBjaGFpbiBv biBmYWlsdXJlICovCiAJcmV0dXJuIChtMCk7CiB9Cgo= --b1_f07de0dd928626a6400f951a70c9fa87-- From owner-freebsd-net@freebsd.org Sat Mar 31 20:02:03 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09656F7C878 for ; Sat, 31 Mar 2018 20:02:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9401874102 for ; Sat, 31 Mar 2018 20:02: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id EFF8A1FDCA for ; Sat, 31 Mar 2018 20:02:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2VK21bt092212 for ; Sat, 31 Mar 2018 20:02:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2VK21Mp092207 for freebsd-net@FreeBSD.org; Sat, 31 Mar 2018 20:02:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195197] [netinet6] ipv6 prefix not renewed when managed by userspace daemon with pltime and vltime Date: Sat, 31 Mar 2018 20:02:01 +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 Only Me X-Bugzilla-Who: guyyur@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.25 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, 31 Mar 2018 20:02:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195197 --- Comment #5 from guyyur@gmail.com --- Bug 194485 patch is needed before the NetBSD "Separate ioctl address prefix management from RA prefix management" changes otherwise the interface route generated by the address won't be used for address neighbor matching. Changes to add RTF_CONNECTED are also needed to get routes added by dhcpcd 7.0.2 working. dhcpcd adds the interface route with RTF_STATIC but the patch in bug 194485 currently checks RTF_STATIC is not set (because there is no RTF_CONNECTED) = so the address neighbor matching will still not work. My WIP with bug 194485 and "Separate ioctl address prefix management from RA prefix management" ported over to 12-CURRENT but missing RTF_CONNECTED: https://github.com/guyyur/freebsd/tree/fix_ipv6_address_prefix --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Mar 31 23:42:05 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6DC4F66841 for ; Sat, 31 Mar 2018 23:42:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4572B7CAA0 for ; Sat, 31 Mar 2018 23:42:05 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 909C621BB9 for ; Sat, 31 Mar 2018 23:42:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2VNg4HR093553 for ; Sat, 31 Mar 2018 23:42:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2VNg4st093552 for freebsd-net@FreeBSD.org; Sat, 31 Mar 2018 23:42:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 195197] [netinet6] ipv6 prefix not renewed when managed by userspace daemon with pltime and vltime Date: Sat, 31 Mar 2018 23:42:04 +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 Only Me X-Bugzilla-Who: markj@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: cc attachments.created 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.25 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, 31 Mar 2018 23:42:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195197 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org --- Comment #6 from Mark Johnston --- Created attachment 192020 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D192020&action= =3Dedit ndp -P panic (In reply to guyyur from comment #4) The attached minimal patch ought to address this. SIOCSPFXFLUSH_IN6 ought to leave the associated prefix alone in your example, I believe. --=20 You are receiving this mail because: You are the assignee for the bug.=