Date: Tue, 9 Feb 2021 21:32:10 +0100 From: Lutz Donnerhacke <lutz@donnerhacke.de> To: Mateusz Guzik <mjguzik@gmail.com> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 011b7317dbb5 - main - netgraph/ng_bridge: Document staleness in multithreaded operation Message-ID: <20210209203210.GA16222@belenus.iks-jena.de> In-Reply-To: <CAGudoHFb6=LSs%2BU9_sY%2Bd1bZwEEdcyjuQQzihsctggqYOqYmnQ@mail.gmail.com> References: <202102091925.119JPSho062759@gitrepo.freebsd.org> <CAGudoHFb6=LSs%2BU9_sY%2Bd1bZwEEdcyjuQQzihsctggqYOqYmnQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 09, 2021 at 08:42:38PM +0100, Mateusz Guzik wrote:
> Things like this are best sorted out with atomic_store, otherwise you
> may fall victim of various compiler mischief (even if it happens to be
> harmless for the time being).
>
> iow all ->staleness accesses should be converted to atomic_*.
>
> grep finds this in ng_bridge_timeout:
>
> if (++host->staleness >= priv->conf.maxStaleness) {
>
> the code should probably explain how this is synchronized against said zeroing
There is no risk, because all other access to this variable is done under a
WRITER lock of the whole node. Even this one, you are quoting here. The
lock comes from the netgraph framework itself.
The only remaining access, which can be run in parallel, is the mentioned
setting to zero. In order to document all this reasoning the comment was
extended.
At the moment the ng_bridge(4) node is completely singlethreaded, any call
runs under the WRITER lock. The purpose of all the commits and all the open
reviews are to remove this limitation in order to give the node a major
performance boost.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210209203210.GA16222>