From owner-freebsd-net@freebsd.org Wed Jul 15 08:47:55 2020 Return-Path: Delivered-To: freebsd-net@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 242A035E297 for ; Wed, 15 Jul 2020 08:47:55 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender4-of-o58.zoho.com (sender4-of-o58.zoho.com [136.143.188.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B69y12xMXz3Zdk; Wed, 15 Jul 2020 08:47:52 +0000 (UTC) (envelope-from patfbsd@davenulle.org) ARC-Seal: i=1; a=rsa-sha256; t=1594802869; cv=none; d=zohomail.com; s=zohoarc; b=Ghn05QI2oRyQnetKmTUw2u2o9mBFEzWAVDYnMJOqVOSyFYKm46EHjxOu6Osl35trpsuqnbMADQsmFBxGSI/Nit8ay0DrUcnIZRH9rX1OWMgLLHErmnfVPzuOk6BwMAXXZWd66HChPUM5SxCg6m6FfJdkuYxTPGD5i2a5T5DqFNU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1594802869; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=PowwxHGJejUTleh2BophB4r69NOj4CsrgE0By+4hW4E=; b=Aq/G32sxk9Ms8OUIq9U+zO8sTkqHOn1dvRvHMGOt41C37T1hJOCxSC8MgCsOFZl1jmixzaHacMS3r6RKMLoEIbIgjgD898H+pWHIHbVJoU0euzc5k0YHoW4L1uiIS5zzdxlny8McX3zC+RoL49MeH/vrWTYNANBbe9R9ACBcV3k= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=patfbsd@davenulle.org; dmarc=pass header.from= header.from= Received: from mr185033.univ-rennes1.fr (mr185033.univ-rennes1.fr [129.20.185.33]) by mx.zohomail.com with SMTPS id 1594802866617924.7628233558402; Wed, 15 Jul 2020 01:47:46 -0700 (PDT) Date: Wed, 15 Jul 2020 10:47:37 +0200 From: Patrick Lamaiziere To: Olivier =?UTF-8?B?Q29jaGFyZC1MYWJiw6k=?= Cc: freebsd-net@freebsd.org Subject: Re: poor performance with Intel X520 card Message-ID: <20200715104737.1a0bbe00@mr185033.univ-rennes1.fr> In-Reply-To: References: <20200710084530.777ce321@mr185033.univ-rennes1.fr> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Rspamd-Queue-Id: 4B69y12xMXz3Zdk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of patfbsd@davenulle.org has no SPF policy when checking 136.143.188.58) smtp.mailfrom=patfbsd@davenulle.org X-Spamd-Result: default: False [-3.78 / 15.00]; NEURAL_HAM_MEDIUM(-0.95)[-0.950]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[davenulle.org]; RWL_MAILSPIKE_GOOD(0.00)[136.143.188.58:from]; NEURAL_HAM_SHORT(-0.73)[-0.731]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.58:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 08:47:55 -0000 On Fri, 10 Jul 2020 18:21:11 +0200 Olivier Cochard-Labb=C3=A9 wrote: Hi Olivier, > > That is mostly for the record but it looks like the intel X520 is > > not very good and generates a high level of interrupts. > > > > On a router / firewall with 500 Kpps in input (dropped by pf) is > > enough to put the CPUs at > > 100% busy. >=20 > yes 500 Kpps is quite low: Do you have a very complex long pf rule > set? Around 1450 rules in all but only 760 for ix0 in input (quick rules only). PF ruleset-optimization is set to 'basic' (the default) It's hard to see if PF is the bottleneck but we graph all PF statistics each 10 seconds (pfctl -vsi). input 500 Kpps, traffic dropped 200 Kpps, pfctl matches rules (counter match) is high with around 270 K matches/s (normally is around 12 K matches/s), pfctl states searches around 300 K/s (normally 200 K/s) So there is a large number of ruleset evaluations (time costly). PF congestion counter is always =3D 0, I'm not sure if this counter works on FreeBSD - I'm sure it works on OpenBSD :) On FreeBSD does PF congestion increase if PF is not able to handle the load? (On OpenBSD when congestion occurs, PF stops to evaluate the ruleset for a litle time and only evaluates states matches). Thanks, I guess I have to find a packets generator to make tests.