From owner-freebsd-current@freebsd.org Sun Mar 15 11:34:18 2020 Return-Path: Delivered-To: freebsd-current@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 16CDB276A3A for ; Sun, 15 Mar 2020 11:34:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48gHQK3fl7z3QnR; Sun, 15 Mar 2020 11:34:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id BC4697ED5; Sun, 15 Mar 2020 11:34:16 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.10.132.20] (unknown [IPv6:2001:2c0:ce03:c605:195f:4624:8e6e:276f]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 329F73C87C; Sun, 15 Mar 2020 12:34:12 +0100 (CET) From: "Kristof Provost" To: FreeBSD-Current Subject: bridge project update (Week of March 9th) Date: Sun, 15 Mar 2020 20:34:08 +0900 X-Mailer: MailMate (1.13.1r5671) Message-ID: <621E7E68-2ACC-4B56-A551-51D1275F78BF@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 11:34:18 -0000 Hi, As this is the first status report sent to a wider audience I’ll try to give a bit of background information. I’m working on a performance improvement project for if_bridge. Right now it’s a big bottleneck for a number of different scenarios (e.g. for VNET jail or VM hosts). if_bridge currently has a single mutex to protect its internal data structures. As a result it’s nowhere near as fast as it could be. I’ve started the project by adding a number of tests to ensure that I don’t break things (or at least not everything) during this project. A number of tests have already been committed. One more will go in soon (https://reviews.freebsd.org/D23961). They all live in /usr/tests/sys/net/if_bridge_test. Aside from that I’ve been investigating the possibility of using the NET_EPOCH to improve bridge throughput. It’s very early, of course, but I’m investigating the possibility of keeping the bridge lock, but removing it from bridge_input/bridge_output/… (i.e. the data path), instead relying on NET_EPOCH to ensure that the important data structures don’t go away while we’re processing packets. Part of that work was building my own understanding of how the epoch system is supposed to work. Very briefly (and with the caveat that I’ve only just started looking at it): Use lockless lists (CK_*). Objects should remain valid (i.e. not free()d) in between NET_EPOCH_ENTER() and NET_EPOCH_EXIT(). To accomplish this the object can be freed through a NET_EPOCH_CALL() callback, which will only be done once all CPUs have left their NET_EPOCH_(ENTER|EXIT) sections. This requires an epoch_context, which can best be placed in the to-be freed structure. Feel free to get in touch if you have questions, remarks or suggestions. Best regards, Kristof