From owner-freebsd-stable@freebsd.org Mon Feb 8 18:32:42 2021 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C14053CABF for ; Mon, 8 Feb 2021 18:32:42 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward500j.mail.yandex.net (forward500j.mail.yandex.net [5.45.198.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZF4n2lhpz4dQW for ; Mon, 8 Feb 2021 18:32:41 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from sas1-6b94a3a85f37.qloud-c.yandex.net (sas1-6b94a3a85f37.qloud-c.yandex.net [IPv6:2a02:6b8:c14:3924:0:640:6b94:a3a8]) by forward500j.mail.yandex.net (Yandex) with ESMTP id 3018211C12E0; Mon, 8 Feb 2021 21:32:38 +0300 (MSK) Received: from localhost (localhost [::1]) by sas1-6b94a3a85f37.qloud-c.yandex.net (mxback/Yandex) with ESMTP id pjCuDPqc5q-WaIOj1vO; Mon, 08 Feb 2021 21:32:37 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1612809157; bh=kkGiQBUrjX2xY2OdyomxBJKzx4RmxEI347+SYv9ngxw=; h=References:Date:Message-Id:Subject:In-Reply-To:To:From; b=eUTVcj1FmZ3J+n4rUTy4SG4uSorj+AJ7xz3uODWhm/xt9fozWzhy54C0qdi4DM7Br rKk09R9TIR7sLNg04j5a2iKtgSk5/I+UelSBdr8hF+A1anatnclAJ7P+IAAxVY2NY3 x4nl7LdtP/KlbtZznZWcTHGzzS6wGGd5Fik1i1x0= Received: by sas1-ffdbcd5f1d77.qloud-c.yandex.net with HTTP; Mon, 08 Feb 2021 21:32:36 +0300 From: Alexander V. Chernikov To: Marek Zarychta , mike tancsa , FreeBSD-STABLE Mailing List In-Reply-To: <8696072a-dc25-8eff-04fa-4d1db13bf5cc@plan-b.pwste.edu.pl> References: <5670cd9a-cd10-2b89-1347-97a6c817c50f@sentex.net> <8696072a-dc25-8eff-04fa-4d1db13bf5cc@plan-b.pwste.edu.pl> Subject: Re: option FIB_ALGO and dpdk_lpm4 MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 08 Feb 2021 18:32:36 +0000 Message-Id: <3588111612809020@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 4DZF4n2lhpz4dQW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=eUTVcj1F; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 5.45.198.250 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-1.61 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[5.45.198.250:from]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; FREEFALL_USER(0.00)[melifaro]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:5.45.192.0/19:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ipfw.ru]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.99)[0.993]; SPAMHAUS_ZRD(0.00)[5.45.198.250:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[ipfw.ru:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[5.45.198.250:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13238, ipnet:5.45.192.0/18, country:RU]; MAILMAN_DEST(0.00)[freebsd-stable]; RCVD_IN_DNSWL_LOW(-0.10)[5.45.198.250:from] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 18:32:42 -0000 08.02.2021, 14:33, "Marek Zarychta" : > W dniu 08.02.2021 o 13:10, mike tancsa pisze: >>  I have been setting up some tests to see if >> >>  option FIB_ALGO and dpdk_lpm4.ko >> >>  will help with my pkt forwarding needs and large routing tables. So far so good. But one thing I noticed, is that its very chatty to dmesg. >>  eg >>  alloc_nhgrp: new mpath group: num_nhops: 2 >>  compile_nhgrp: O: 2/2 >>  compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 >>  compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 >>  alloc_nhgrp: new mpath group: num_nhops: 2 >>  compile_nhgrp: O: 2/2 >>  compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 >>  compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 >>  alloc_nhgrp: new mpath group: num_nhops: 2 >>  compile_nhgrp: O: 2/2 >>  compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 >>  compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 >> >>  are these debugging messages that forgot to be turned off ? What do they mean ? >>  Thanks for this work! >> >>  13.0-STABLE #11 stable/13-cc1352c1f-dirty > > Thank you for sharing this Mike. Could you please reveal us how do you > feed your routing tables? Is net/bird{,2} or net/frr7 involved? Any > problems or hints to make the routing daemon working with new routing stack? Non-multipath should work as before, multipath works for quagga/frr but needs some patches for bird. > > The new routing stack looks very promising, please let me also give this > way some appreciations to melifaro@ and other people who worked on it. > > I was also trying to test it with legacy net/bird and multiple fib > tables, but I was early hit by: "KRT: Error sending route x.x.x.x/y to > kernel: Operation not supported" Any chance you could clarify what are these routes? "Operation not supported" looks a bit weird, it shouln't happen. > Setting net.add_net.add_addr_allfibs=1addr_allfibs=1 changed it a bit, > but still some blackhole /32 routes seem to get rejected. Just "blackhole" route in the bird config? /32 or all? > > -- > Marek Zarychta