From owner-freebsd-net@freebsd.org Wed Oct 21 20:53:55 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C2B8942D64A for ; Wed, 21 Oct 2020 20:53:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CGjQW4r6mz3XNw for ; Wed, 21 Oct 2020 20:53:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A458E42D649; Wed, 21 Oct 2020 20:53:55 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A420C42D648 for ; Wed, 21 Oct 2020 20:53:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGjQW3wqGz3X94 for ; Wed, 21 Oct 2020 20:53:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6A278BC26 for ; Wed, 21 Oct 2020 20:53:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 09LKrtJX097733 for ; Wed, 21 Oct 2020 20:53:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 09LKrtu1097732 for net@FreeBSD.org; Wed, 21 Oct 2020 20:53: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: net@FreeBSD.org Subject: [Bug 248652] iflib: netmap pkt-gen large TX performance difference between 11-STABLE and 12-STABLE/CURRENT on ix & ixl NIC Date: Wed, 21 Oct 2020 20:53:53 +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: 12.0-STABLE X-Bugzilla-Keywords: iflib, needs-qa, performance, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vmaffione@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? maintainer-feedback? mfc-stable12? mfc-stable11- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 20:53:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248652 --- Comment #31 from Vincenzo Maffione --- (In reply to Krzysztof Galazka from comment #30) Hi Krzysztof, I agree, and created a separate review for this possible change: https://reviews.freebsd.org/D26896 It would be nice if you guys could run some tests to validate the change against normal TCP/IP stack usage (e.g. non-netmap). Speaking about the non-iflib driver, I guess it is acceptable for the ixl_x= mit routine to always set the report flag on the EOP packet. However, this is not acceptable for netmap, and indeed the non-iflib netmap= ixl driver is only setting it twice per ring (see https://github.com/freebsd/freebsd/blob/stable/11/sys/dev/netmap/if_ixl_net= map.h#L221-L223). This is, in my opinion, what explains the huge difference in performance between non-iflib and iflib for ixl. If my understanding is correct, and according to our past experience with netmap, the report flag will cause the NIC to initiate a DMA transaction to either set the DD bit in the descriptor, or perform a memory write to update the shadow TDH. This is particularly expensive in netmap when done for each descriptor, specially because netmap uses single-descriptor packets. Interrupt moderation can also help a lot to mitigate the CPU overhead, but = as far as I see it does not limit the writeback DMA transactions, and therefor= e it does not help in the netmap use-case. Moreover, my understanding is that if= lib is not using hardware interrupts on ixl (nor ix), but rather is using "softirqs", so I guess that interrupt moderation does not play a role here.= I may be wrong on this last point. I suspect the 1-queue pkt-gen hang problem may be due to something else, ra= ther than the report flag change. As a matter of facts, the same logic was worki= ng fine on the non-iflib driver. --=20 You are receiving this mail because: You are on the CC list for the bug.=