From nobody Fri May 27 22:40:25 2022 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 5B3171B50B2A for ; Fri, 27 May 2022 22:42:41 +0000 (UTC) (envelope-from misho@elwix.org) Received: from mail.elwix.net (ns.aitbg.com [95.87.254.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4L90Dw3pYBz3rRK for ; Fri, 27 May 2022 22:42:40 +0000 (UTC) (envelope-from misho@elwix.org) Received: from localhost (unknown [172.17.0.36]) by mail.elwix.net (Postfix) with ESMTPA id 1B62E1788C; Sat, 28 May 2022 01:40:26 +0300 (EEST) 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 Date: Sat, 28 May 2022 01:40:25 +0300 From: Michael Pounov To: Lutz Donnerhacke Cc: cm@linktel.net, net@freebsd.org Subject: Re: LibAlias in FreeBSD In-Reply-To: <20220527153552.GA28822@belenus.iks-jena.de> References: <20220527161854.86fd52906c712221c71a7dc6@elwix.org> <20220527153552.GA28822@belenus.iks-jena.de> User-Agent: Roundcube Webmail/1.4.12 Message-ID: <832c88580a3c66eca2a90d6b2f0c84d8@elwix.org> X-Sender: misho@elwix.org Organization: ELWIX Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L90Dw3pYBz3rRK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of misho@elwix.org has no SPF policy when checking 95.87.254.42) smtp.mailfrom=misho@elwix.org X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.985]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[elwix.org]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.51)[-0.515]; MLMMJ_DEST(0.00)[net]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:43561, ipnet:95.87.192.0/18, country:BG]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On this callback I will attach my function from ipfw_sync driver. This callback will return immediately with passed address. It will transfer just particular created list item like const pointer from In or Out arrays. I will read such data direct from Alias DB item without additional memory operations. About ringbuffer in libalias. Now db is organized on two hash arrays with 4001 count of elements, which contains heads of the lists. I have second way which also can do the work. It was made from me like shadow tables for broadcom chip states into switch firmware before more then 10 years ago. This approach don't touch original libalias structure, but have huge drawback. Delay from regular time by driven updates of shadow structures. I'm sure that isn't ok for router cluster cases. Because we have too small time when various packets can come on another router's ingress interface. I still believe that way with hooks on Alias DB updates with export of original address of DB list member will be right approach to be done. Most fastest and efficient Thanks from feedback. On 2022-05-27 18:35, Lutz Donnerhacke wrote: > On Fri, May 27, 2022 at 04:18:54PM +0300, Michael Pounov wrote: >> Hello Charles Mott >> >> I wrote this mail about my work with IPFW firewall. >> I am started my work over IPFW Sync driver and protocol similar like >> in PF firewall. >> My primery goal is to do sync on NAT states in firewall router >> cluster. About it, I need to know when NAT driver add, readd or delete >> alias to be notify from libalias >> I see one good approach to achieve this, but I must to asking if >> existing hidden drawbacks for such approach the author of libalias. > > As long as the callback is internal to the kernel, it might work. > libalias is CPU bound, any additional work will slow down the system, > especially when libalias is called from the interrupt level of network > drivers. > >> What are you thinking about such approach, change and hook of the >> existing code? > > One can think about a ringbuffer which is filled by libalias and read > by a > different type of code. If the other code is too slow, the ringbuffer > will > override the entries. Please do not consider a dynamically allocated > buffer.