Date: Thu, 31 Jul 2025 15:55:50 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: Kajetan Staszkiewicz <vegeta@tuxpowered.net> Cc: net@FreeBSD.org Subject: Re: adding fields to struct mbuf Message-ID: <20250731155550.529ce1fb@nuclight.lan> In-Reply-To: <e315d113-2a8a-4e17-8299-0e892a0b0ef3@tuxpowered.net> References: <e315d113-2a8a-4e17-8299-0e892a0b0ef3@tuxpowered.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Jul 2025 13:03:22 +0200 Kajetan Staszkiewicz <vegeta@tuxpowered.net> wrote: > Hello group, > > I'm researching loop prevention in pfil. There are cases where packets > are reinjected into the network stack and would be handled by the same > hooks again, i.e. pf + dummynet where currently pf itself handles loop > prevention on its own. My current experiment's approach to making loop > prevention a general, non-pf-specific thing is to create a new mtag with > pointer to the last hook and update it in pfil.c/pfil_mbuf_common(). > That works good so far, but it means memory allocation when pfil hooks > are involved. I'm unsure what the impact on performance would be. > Another approach would be to extend struct mbuf, or probably rather > struct m_pkthdr, to contain the aforementioned pointer. But is changing > that struct something that can be easily done and approved and merged? First, you certainly don't need it in every mbuf - just first in chain with struct pkthdr (where mtags also start). Second. The "last hook ptr" does not look like general solution for all cases and occupies 8 bytes. What about idea from network itself - TTL ? It occupies less bytes, the main problem is to decide where to decrement (e.g. each netgraph hook, etc.) Third. What about redoing mtag allocator so that it reuses m_pktdat[] when M_EXT is set? This could optimize performance for many tags, not just yours. > For those curious the experiment will be uploaded to Phabricator soon-ish. -- WBR, @nuclight
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250731155550.529ce1fb>