From owner-freebsd-arm@freebsd.org Sun Apr 7 14:35:45 2019 Return-Path: Delivered-To: freebsd-arm@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 5124B1553EC3 for ; Sun, 7 Apr 2019 14:35:45 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A328D926FA for ; Sun, 7 Apr 2019 14:35:44 +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 D9B62559B for ; Sun, 7 Apr 2019 14:35:43 +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 x37EZh9c034130 for ; Sun, 7 Apr 2019 14:35:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x37EZhAd034129 for freebsd-arm@FreeBSD.org; Sun, 7 Apr 2019 14:35:43 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-arm@FreeBSD.org Subject: [Bug 237072] netgraph(4): performance issue? Date: Sun, 07 Apr 2019 14:35:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ler@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 14:35:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237072 Bug ID: 237072 Summary: netgraph(4): performance issue? Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: ler@FreeBSD.org >From my post to the #hardenedbsd IRC, but this *MAY* be a generic netgraph(= 4) perf issue. Hey all: I'm having a performance issue with netgraph(4) on OPNSense (based on HBSD-11.2).=20=20 I've got https://github.com/aus/pfatt loading / configuring netgraph(= 4), and a 1g/1g ATT Fiber link. with this setup, my Download side is ~600 meg. with my previous setup, a ubiquiti USG, I got ~900+ meg I'm currently using a https://protectli.com/product/fw4a/ as the fire= wall I also have a https://protectli.com/product/fw6b/ coming monday I'm using OPNSense's 19.1.4-netmap kernel, and have done some of the em(4) tuning from their IPS/IDS forum topic. The tuning DEFINITELY helped the UPLOAD side, but did nothing for the DOWNLOAD side. I'm looking for ideas on how to troubleshoot this. I'm more than happy to work with whoever, including making access available to the FW. the manufacturer (protectli.com) has run iperf tests on the raw hardw= are (without the netgraph(4) stuff in play) and gets ~940meg across it. (using OPNSense 19.1.4) so that's why I'm pointing the finger at netgraph(4). I see the same issue on a https://protectli.com/product/fw1/=20 Let me know what all you need/want, and I'll supply it. - {Day changed to April 7, 2019} Can your installation be done without netgraph? No. Needs to be there to do the 802.1X dance with the ATT ONT. Read = the README at https://github.com/aus/pfatt for more details. And tag all the packets going to the ONT as VLAN0. Ok. l/ 45 ler: for opnsense questions, #opnsense would be the right channel This is more a hardendbsd perf issue. did you test in freebsd? No, as this is a FW issue, and I refuse to try pfSense. I have philosophical issues with them. understood. but, to help me out, I'd prefer if you tested your se= tup with vanilla fbsd. hbsd's only changes to the networking stack were to use = ipv6 privacy extensions by default and ASLR ASLR affects userland, not kernel, which is where the bulk of net= work performance occurs https://github.com/HardenedBSD/hardenedBSD/wiki#generic-system-hardening we do set net.inet.ip.random_id, too so you could unset that to start with, I guess it's definitely netgraph(4) related, see the statement above re: protectli testing on the same HW/SW w/o netgraph(4), and getting expected p= erf. I doubt that random_id is affecting this, for that same reason. agreed. can you file a bug report with us? https://github.com/HardenedBSD/hardenedBSD/issues sure. --=20 You are receiving this mail because: You are the assignee for the bug.=