From nobody Wed Nov 23 19:40:31 2022 X-Original-To: freebsd-performance@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 4NHWh06xl4z4j81l for ; Wed, 23 Nov 2022 19:40:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NHWh00gZBz3pBR for ; Wed, 23 Nov 2022 19:40:48 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net; dmarc=none Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 2ANJeVbe073228 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 23 Nov 2022 14:40:32 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:c0b6:89d8:b838:d5de] ([IPv6:2607:f3e0:0:4:c0b6:89d8:b838:d5de]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 2ANJeVI6061279 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 23 Nov 2022 14:40:31 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: Date: Wed, 23 Nov 2022 14:40:31 -0500 List-Id: Performance/tuning List-Archive: https://lists.freebsd.org/archives/freebsd-performance List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-performance@freebsd.org X-BeenThere: freebsd-performance@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: Chelsio Forwarding performance and RELENG_13 vs RELENG_12 (solved) Content-Language: en-US From: mike tancsa To: Navdeep Parhar , Freebsd performance References: <7b86e3fe-62e4-7b3e-f4bf-30e4894db9db@sentex.net> <92cdf4b8-2209-ec44-8151-a59b9e8f1504@gmail.com> <8166abfe-a796-2cf0-ade2-de08df8eecd2@gmail.com> <39ca9375-e742-618e-5020-dda5fa24ac0a@sentex.net> <63424978-a10f-a88b-2b3e-eb80d0f29f51@sentex.net> In-Reply-To: <63424978-a10f-a88b-2b3e-eb80d0f29f51@sentex.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 64.7.153.18 X-Spamd-Result: default: False [-3.35 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.98)[-0.981]; NEURAL_HAM_LONG(-0.97)[-0.970]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-performance@freebsd.org]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[mike]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[sentex.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4NHWh00gZBz3pBR X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 11/3/2022 2:20 PM, mike tancsa wrote: > Yes, I think 4 queues are enough for 10G. >>> >> Sadly, no luck. Still about the same rate of overflows :( >> >> > FYI, I worked around the issue by using two 520-CR NICs instead of the > one 540-CR NIC and performance is solid again with no dropped packets > > Another configuration point on this. Moving to RELENG_13 has some different defaults with respect to power/performance ratios for my motherboard and CPU (SuperMicro X11SCH-F,  Xeon(R) E-2226G). On RELENG_13, the hwpstate_intel attaches by default and is used to scale up and down the CPU frequency. I am guessing due to the somewhat bursty nature of the load, the CPU scaling down to 800Hz could not scale back up fast enough to deal with a sudden burst of traffic going from say 300Mb/s to 800Mb/s and some packets would overflow the NIC's buffers.  Printing out the cpu frequency once per second, it would be constantly floating up and down from 900 to 4300.  At first, I couldnt quite get my head around the fact that the most lost packets would happen at the lowest pps periods.  Once I started to graph the cpu freq, CPU temp, pps, Mb/s, the pattern really stood out.  Sure enough, setting dev.hwpstate_intel.0.epp=0 on the cores from the default of 50 (see HWPSTATE_INTEL(4)  ) made the difference. #  sysctl -a dev.cpufreq.0.freq_driver dev.cpufreq.0.freq_driver: hwpstate_intel0 #     ---Mike