From nobody Tue Aug 5 10:35:58 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bx8wR6j18z64JZp for ; Tue, 05 Aug 2025 10:36:07 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bx8wQ6sfZz3jsG for ; Tue, 05 Aug 2025 10:36:06 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuxpowered-net.20230601.gappssmtp.com header.s=20230601 header.b=hCQ9nW8T; spf=pass (mx1.freebsd.org: domain of vegeta@tuxpowered.net designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=vegeta@tuxpowered.net; dmarc=none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-61592ff5ebbso9381461a12.3 for ; Tue, 05 Aug 2025 03:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxpowered-net.20230601.gappssmtp.com; s=20230601; t=1754390160; x=1754994960; darn=freebsd.org; h=in-reply-to:autocrypt:from:references:cc:to:content-language :subject:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=3MCK5WdqVGMFoKbPmqgS2hJrkwgUS4inqaMhbDAjinU=; b=hCQ9nW8T+Ey3H+1wkhs4SLqO+HUGT7wjfQd70D9sjDdt76Q8jfzkNMRxOreRv8eleU 5LH6l87dzoM1vAWf5uyZHaweUiY6NBsBMpdqgFv89W05DhtVwe9KtwLuyR9Gx+qRjdkO gkgyP063994Qqd3eK2EjgmUpgsKdr2ugFFPAXMG3FJt30a6ls1Q8Z3MoPxTPGl0vTCRZ mXsDq4aaSI8/xlQ48v2YPJ0igCtChiGr1848IREBGEk2hlz0HDYiwKLcWSz7tnYnqzsK PGg+887gZ15Quw0XKGTzml3bkNfwSFk7LcLoVEDVb62/bEBTmnCM4dUWluMRedR8gBsF OkIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754390160; x=1754994960; h=in-reply-to:autocrypt:from:references:cc:to:content-language :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3MCK5WdqVGMFoKbPmqgS2hJrkwgUS4inqaMhbDAjinU=; b=Pk200gaylLezz3DcREd5B5TWVsYoD4VUJCVI6qeVtsfl6+IVUOZN3sFIHiJPZ/SIkt +P9UjvB/o88uN/7smixlLGSQ4PIGHcjDYskXx16ohEU8YBPpAeHhfSec+DwYOPVpUEIe qVnptODpjVl9K9wOIok0N7WNplFyjWacNFrnw2oYIfYbE08CNKkaKALeQnRENguA+b5d yyKANiVq2Bm1Tv0rpeHSj9wHP69EzxJ2JCEARzcVBKtaqnQYMrLTLRt0zYZoz2PSzm/b M/4lzXfkAASLjkAQNM6+ZIhtjEQc9/esS/MaQ+9DXF2siQYva+CIj9XihavLKPC8g8TM 5P9g== X-Gm-Message-State: AOJu0Yz28ssz1g3mCRWNl+CJFoT54/KysOecvIbz3c4RGiP2xN9RloxC yRVbfwTybsdybFWAxasn7WO6vx3mHyuNNkFzu+iWKcfV7NeEkesliJKPwt0pz0IHP74= X-Gm-Gg: ASbGncsAfpVXaUTUVFRVF8ymN2zydIngjtXWI4mw5ten1GHY6p4vtNumvu7gCLY8CLO oCKHJyoZVolo5evJNt1y5MRlfUqwrkWbfSGNSjK12THHZbi2rKyAzZ4ZjcyvVqN06oW9tjGVhuV hnpTkAjRjN5XAVuov4RU5jrYp9aJse4Rl5w9NwYhuEGxlHO+eRBBc0FtonUyrERuejmxrkSHQnY zR+ZB7Awmzgwe5mY2jFW4WM33DIK1OloflQqF9+8qSAVGbpR6vEisCpo4u4RU650QxSdXWVpw0T gkhz3IcpQu0XmBi6ZoMxllrdXuVjmOwlhc+n3uqAFFB40qfbQodt7ogTjPBM0T4KQKv+SKbIb62 yTnb/p3xQYLNMEAFNNktqQep5aDMTuFJAROUtjU3v1gf/mt0O0vCjeFA3Q0B2kRb4bPV7bkxMnZ ABQgLwcDxhYy4eIKpjyU1GKOXChrQdMY4= X-Google-Smtp-Source: AGHT+IGfVKnKF2RvdjB/2mREQ2OlS4ydZGe5p94BtmSn1XsvRhtnpDRW0TEHo0L806ahOLP+cnbJcg== X-Received: by 2002:a17:907:2da0:b0:ae3:a604:b1fe with SMTP id a640c23a62f3a-af9401acd29mr1411260166b.38.1754390160310; Tue, 05 Aug 2025 03:36:00 -0700 (PDT) Received: from [192.168.178.107] (192.119.57.206.dynamic-pppoe.dt.ipv4.wtnet.de. [192.119.57.206]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-af91a241bdfsm883285866b.131.2025.08.05.03.35.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Aug 2025 03:35:59 -0700 (PDT) Message-ID: <41726ad6-9620-4902-bd66-5f1a0606becd@tuxpowered.net> Date: Tue, 5 Aug 2025 12:35:58 +0200 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: adding fields to struct mbuf Content-Language: en-GB To: Vadim Goncharov Cc: net@FreeBSD.org References: <20250731155550.529ce1fb@nuclight.lan> From: Kajetan Staszkiewicz Autocrypt: addr=vegeta@tuxpowered.net; keydata= xsFNBGSvtwgBEADIx3vgFBaDsFD4MOGIsWSmHag9q8x3J5OrqBR9aIdeeDW4ghnPM1NgD8EQ HQvaAufffQ/vYXSWWJyDdquVARWprEXXQIMQZcDhw0pHtSrNK6NFF5UWfBkxYxAr2hTlRp0b R7QZk3ezGUElBpf+SJq5cCOy//32hnzJiKb+5hlL0QOheWKwKignhLckW8Yat+kjhsxw7pR8 vn/XSCwyejx3I8v2DZsTuXVOvbKr6kNwDryjl6JJwKFoQ/aNUeD7dmLP2ieB9HCHBBBIi16Z JcUCyJw8LI6GPrfr5zPEP38Up/psDQWoldbO2Kf5DyCN2HGFKLrK9StyjiMs4dgaA0ZXxIdn JTzdAP6+d1qIfvv5mGhbqTvHgX6ReR7l93eE3Q6WJqGiuFGUtKdU5qaRHd4IdbFnhNK/rWjg ZoKAlZwhnZ9BWZC8Vb9DznURYQUubt2Gr7Sutt0043d/WoWyGS2p7dEfXaeE1WE7n/6KqbBU zG/rF/20eeT0lmrNAy9pgFD5WmTtzHnljBzQSBDMTxZP3iEmFa0pXP+Ch/H26AxV99MXs7Tz Xj6VF5NKcIJ67m1pwJSW2vO9UhL2OVBJI3571C+9qn52QJjZdm4R4gHpgjbr4EoCUdlchCa1 iUQ1gV6SJI70WqgwmVprYwvaN1Rdld2iQFX+W6aOq6be1VzrwQARAQABzSxLYWpldGFuIFN0 YXN6a2lld2ljeiA8dmVnZXRhQHR1eHBvd2VyZWQubmV0PsLBlwQTAQgAQQIbAwUJB4YelwUL CQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBH0hCHMWPZA3mb0mbICq13+m8wBTBQJkr7gjAhkB AAoJEICq13+m8wBT14sQAKj1sG3yLeRfoKmmMgdbCErSrEg0uCChvWhRz/PCNfJB4SrUfSBj unM56CeCVUf1SBI7cq6tJDujMor433OpiuZvtlgJezfoeyTvgjiGshVnstNAik77+B6lnhvJ VwA7O3aT19kW/wUiVx9bATAleE4SQjyXq1z0onzh+FLeYZucfzISzUgOx2Ggb/eseDZ+v2re ja47WmMl/iU6ERvG3+GbmgZuYGRDIhzsa0l1YFzMrCmqrZ6ysW2JMwH+wkbw94yyLmF1k7uU KkRrejDiQjDk8Db2Smf7MaLGOCQGrz0Q2vSuETIavw2zQYs0bsQLuhV2/TlXegdfbe4wNhsD t4Zs2KEr8lHrXfIckxDn/vwlh2TWnPLQqlN13dctesfK/HFWqReIhfYu2B9WQCugLR2NAlO+ hw9wuOzBu8SfOX+CIcqHfX2Q+c7KrHFSsscENu2QnE27my5vqjkig4cpjZDLitKTyqKm8UNI f2O1xF137zA5byn/4rQFlfn8LbhuPdLBexvasjIQzuSgTZZ7cjUqbXFXssYsU0CFUHCoH5yF VrW8RGvx+W1l2nZQr03cZEoQEL+La4+LIRiuwFfohpz5xCsP0GdBDVIinC9vAkW7I6Y6ssCv ykMhaOGXZzs8mR47KCt6aFPX3vir9WmHQvHvSXaSxLNzfzmwl1e1hXD1zsFNBGSvtwgBEACw 4wl+FEyUehwSjs6/jhECE9r4fzwG+nUg1Q2ct8BneAjjUV/0UcMPQtphIGKqlJTxnxIEiz8D R3kb3Y535qkAeAU4RV8ONCUrJLyXoLei/Ymk7161Gui9x3AB1Z2Yi3x76MuRAFH7QIAxhXYo MN97IpgFDrv/ALwCD/eROFWEm5vNP8fvvpKBxtNaolebXWMfSFo3GJ8C73x+L8vW3D0uOp43 9MKUVAm6SMZXvYQA2P5+q15gxVUs0uhT69gHTrUMPHqPvARxZK5vpY+n3Phys9CZw84WaXcz qLjvmpKqqs/ody3r7caXZcN7eg3sihI0ud6R3UufM4WJ1UV8YLdwIi8dRMx0ozzjw+3E5ji0 gatXhhdZ9N7MsEOfy2o4IxukxJSvsDO9WRqIY2PgyXHlpiM026hhXiJRyCeV0TN1MAwId8YM 2+Ujce9n+Cu78d8+1lLVx82kvArm5zEL/Dj9b4SAZbyzQd5JzkiEWcYtZvTBG+NiAXgm9DR9 i4IC0TuEXfxT+vuriDKYhlyXzPhvaCngIkQ574YwGOrbjfCsSvZCrrSHtb+Mw1uC7kNvegfW 9ZUegD7knKXCt+4AX1xP27JB+ERdFoi7Ri7ROZLJB3Ne8oDS/aN40roKHj8mkm15lAMwrYB1 7ct/J8UCfQH4eagW8SwS2M6Tut6B4VWG+wARAQABwsF8BBgBCAAmFiEEfSEIcxY9kDeZvSZs gKrXf6bzAFMFAmSvtwgCGwwFCQeGHpcACgkQgKrXf6bzAFNbXRAAgFwTrMTEZDO79izcm/uU uGBoa3SKkxIwfhjYWwkHoLyr9P8fqRX6NjW///e8YWdLmf1jBESRnQYEbuSvociDpc7CJ57f 3GaKlHZs2ci5u0tqM0H/VKI/cAuPBGXli/unnbozlsU1fU4uZfY/4Tl2P8FNApJh2vbNalIt Mc9l0Iz3d5URPWAe7Pnb29tEVu5TNR/bJg7ihLsTY18XcePkHRRrnPF9ui9egB5FbCAQ/VSg Pl7/kD/PkOT/3kc+C4RhddRMUmPxH0G4hvBPLRuvLgwtaj8vnurN1NxbllzK33ZWkvbUhIrw Qcv23jfhQmg/cpzsQKeyu7L53bgUc4+zYoq/wd3n9SMCO5vTMUrswNqmD4wyopjblCGSeKNy kiiFA70umn5tB+Ra8H5k+n/e2QluKns+DoIg1Hm5chk/emBG42JYTdrMhLFQGZnzJU3WJf1j cVzOFLcqDuq+IwRPJrCZXsLft2O79uU+zbla+RdWd0uIzjbM4R8jch470h5cK61kcaQ7UwSb OpdPyq9PqFl26x2g4jDNmFLAuQDEBJoxmZA2bNfQk+DwYYTuoTItN3F674nb8Fk+tQyXL6fl 5CXOJOTJArKmokrPLcr3HXGUQpfBzXRDuK0UKgn3m9UXq2laaODgswuoZqm0vqWuWIRMm84J Wbiwhrslf0hn78s= In-Reply-To: <20250731155550.529ce1fb@nuclight.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0KVcCtCfg3aRZPbdQ1nxXhEr" X-Spamd-Result: default: False [-5.60 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[tuxpowered-net.20230601.gappssmtp.com:s=20230601]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[tuxpowered-net.20230601.gappssmtp.com:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; DMARC_NA(0.00)[tuxpowered.net]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[net@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[net@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from] X-Rspamd-Queue-Id: 4bx8wQ6sfZz3jsG X-Spamd-Bar: ----- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0KVcCtCfg3aRZPbdQ1nxXhEr Content-Type: multipart/mixed; boundary="------------Ew89eC0ZVGnJ0os9j80K42hm"; protected-headers="v1" From: Kajetan Staszkiewicz To: Vadim Goncharov Cc: net@FreeBSD.org Message-ID: <41726ad6-9620-4902-bd66-5f1a0606becd@tuxpowered.net> Subject: Re: adding fields to struct mbuf References: <20250731155550.529ce1fb@nuclight.lan> In-Reply-To: <20250731155550.529ce1fb@nuclight.lan> --------------Ew89eC0ZVGnJ0os9j80K42hm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2025-07-31 14:55, Vadim Goncharov wrote: > On Thu, 31 Jul 2025 13:03:22 +0200 > Kajetan Staszkiewicz wrote: >=20 >> 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 wi= th >> 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 changin= g >> that struct something that can be easily done and approved and merged?= >=20 > First, you certainly don't need it in every mbuf - just first in chain = with > struct pkthdr (where mtags also start). True. > Second. > The "last hook ptr" does not look like general solution for all cases a= nd > occupies 8 bytes. What about idea from network itself - TTL ? It occupi= es less > bytes, the main problem is to decide where to decrement (e.g. each netg= raph > hook, etc.) The loop prevention I'm talking about is not as much about the packet looping through the network stack, but rather packet looping through pfil hooks. Consider those 2 scenarios: 1. Dummynet reinjection, this is how it works in the current pf: a) A packet enters via ip6_input() b) pfil_mbuf_in() sends it to pf_check6_in() which then sends it to pf_test() c) pf sends it to dummynet configured for a delay pipe d) dummynet consumes the packet, pfil_mbuf_in()'s loop is interrupted e) later dummynet re-injects the packet using netisr_dispatch() f) the packet goes through ip6_input() and pfil_mbuf_in() again g) pf_check6_in()/pf_test() perform their own logic to determine that the packet has already went through pf_test() h) the packet continues through pfil_mbuf_in() and finally goes through ip6_(try)?forward and so on In this case we could benefit from marking the packet/mbuf that it has already went through pf_check6_in() in pfil_mbuf_in()'s loop. When the loop is run again, all pfil hooks before and including pf_check_in6() can be skipped. 2. af-to Address Family translation, the algorithm below is for the experimental pf code I've mentioned: a) A packet enters via ip6_input() b) pfil_mbuf_in() sends it to pf_check6_in() which then sends it to pf_test() c) pf_test() translates the packet from IPv6 to IPv4 d) pf marks the packet as if it has went through pf_check_in() even though it has really went through pf_check6_in() e) the translated packet is sent through dummynet, as in the previous scenario f) dummynet reinjects the packet using netisr_dispatch() g) the packet goes through pfil_mbuf_in() and pf_check_in() is skipped > Third. > What about redoing mtag allocator so that it reuses m_pktdat[] when M_E= XT is > set? This could optimize performance for many tags, not just yours. I'm not sure I understand this idea. Storing mtags directly in m_pktdat? --=20 | pozdrawiam / regards | Powered by Debian and FreeBSD | | Kajetan Staszkiewicz | www: http://tuxpowered.net | | | matrix: @vegeta:tuxpowered.net | `----------------------^--------------------------------' --------------Ew89eC0ZVGnJ0os9j80K42hm-- --------------0KVcCtCfg3aRZPbdQ1nxXhEr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEfSEIcxY9kDeZvSZsgKrXf6bzAFMFAmiR3o4FAwAAAAAACgkQgKrXf6bzAFO0 3A/8DE2d1/hzgMtTldkpz5qagadZvZ0IgsOrEzoYyZpaW7avKBhi+XfJP5Dr34RioYoUCO8Ohd4q xeBDV7s4nx6WN9qx95eKKoGRr05AZeevnCUs4cpDrmVwzHcpLn49Ev0XlU+6kQS4HT1g/DQZSjwB UStpzycc5fgJ2vjaKXiJhHYfYyEW18IawXj0nEvtZWgDqCDVHOGaozS0Mo6WTDRN0ZVgj+NoC0mT Wo70C9AsuGZt+3V0jWAWqdhPd/q4K0WGhlfweq0k8EGNMmt0dvTVpiOaupmZeyAhqAJD/y8HkNDo pL7CrZQQd4+lwnXY03vDsWPGxDkHCKQgTp7v64eOlw/H62dRea5I4IrFp5jnxEpptBXQ7JUJVuvZ gb74vXHCoaPXK5OfJPKFO6sPDq/2kbcWLj+ayr8Y27dBDX7PlZ50FpWQkI6Gc3ItOqJx9aVdOnt6 F+o96ZFhj9axd8b51gFYs9zHACfvXHUZI6SSrdsIgdPXzFKjjpzeGUB2MklsiO1jCeA+bPpW0NC0 xH4YUlInKLO76332akKfMT6+sfmj8V15PU34oNbo+mvrqfwlI/gslXLPLnE18yVZinmPCLiyl8bw Gzj7qOV6aweLqUQQqtnFJBwxbq8PopPLBOxsPKm1qHOAPL7pG4B6LyXnIS9PSPHEe2YasbOlkWa7 weY= =rhjT -----END PGP SIGNATURE----- --------------0KVcCtCfg3aRZPbdQ1nxXhEr--