Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 May 2019 14:55:32 -0700
From:      Gleb Smirnoff <glebius@freebsd.org>
To:        "Andrey V. Elsukov" <bu7cher@yandex.ru>
Cc:        "Andrey V. Elsukov" <ae@freebsd.org>, kib@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r348303 - head/sys/net
Message-ID:  <20190529215532.GG21836@FreeBSD.org>
In-Reply-To: <effb5434-f446-1fb8-7054-0e46137d2457@yandex.ru>
References:  <201905271241.x4RCffTm047128@repo.freebsd.org> <20190529001046.GC21836@FreeBSD.org> <a7694fb5-2353-fcc1-5bfe-04064fc5825c@yandex.ru> <20190529031256.GE21836@FreeBSD.org> <effb5434-f446-1fb8-7054-0e46137d2457@yandex.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 29, 2019 at 08:56:23PM +0300, Andrey V. Elsukov wrote:
A> On 29.05.2019 06:12, Gleb Smirnoff wrote:
A> > A> bpf_mtap() is not the only consumer of bd_bif, some of them expect it
A> > A> becomes NULL when descriptor is detached.
A> > 
A> > May be then make a flag attached/detached?
A> 
A> Do you have benchmark results that show some benefits in performance? :)
A> I prefer to wait some time after MFC to get a bit wide testing, before
A> doing another performance optimizations.

I was mostly motivated not by performance but by design, so that it conforms
to delayed free architecture.

Btw, now I see that my one liner isn't sufficient, since we bpfif_rele() not in
the deferred context but right after CK_LIST_REMOVE().

-- 
Gleb Smirnoff



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190529215532.GG21836>