From nobody Mon Jan 20 20:38:46 2025 X-Original-To: freebsd-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 4YcMcy1v8hz5kv8N for ; Mon, 20 Jan 2025 20:38:58 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward501a.mail.yandex.net (forward501a.mail.yandex.net [178.154.239.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YcMcx0nqyz42j0 for ; Mon, 20 Jan 2025 20:38:57 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=pk+fk5Jq; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 178.154.239.81 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru; dmarc=pass (policy=none) header.from=yandex.ru Received: from mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1d:3d20:0:640:8692:0]) by forward501a.mail.yandex.net (Yandex) with ESMTPS id E29DB612E5; Mon, 20 Jan 2025 23:38:53 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id kccsNlgOmGk0-JGJ5UsZU; Mon, 20 Jan 2025 23:38:53 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1737405533; bh=5I9JnlLJ6ud8R/soONPcmeeIQpTHJNppPX50D6IAEFw=; h=In-Reply-To:To:From:Date:References:Subject:Message-ID; b=pk+fk5JqjGbKJLSf/8xdAJq/L5O5xhdej+9KkVw09pLulyXWDRrFuh5DhfzHJLctS K+IRmMZPQPsbVl+Nzb1458P1ItdrpHnEpZEm1U07JJwtBTJKR4bBpEhDOymZq76BRP mYYO5vpO5aqCQ/4qX+4TwsrH2kdsVj0MtAAZ7Lkk= Message-ID: <45cf3276-e3bc-426b-9c71-5e2480733c13@yandex.ru> Date: Mon, 20 Jan 2025 23:38:46 +0300 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: FreeBSD 13: IPSec netisr overload causes unrelated packet loss To: Timothy Pearson , freebsd-net References: <2079636793.6405429.1737238589082.JavaMail.zimbra@raptorengineeringinc.com> <1820780643.6432954.1737249897808.JavaMail.zimbra@raptorengineeringinc.com> <715443646.6436953.1737251207686.JavaMail.zimbra@raptorengineeringinc.com> Content-Language: ru, en-US From: "Andrey V. Elsukov" Autocrypt: addr=bu7cher@yandex.ru; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNJUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT7CwHgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAzOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i In-Reply-To: <715443646.6436953.1737251207686.JavaMail.zimbra@raptorengineeringinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; RBL_SENDERSCORE_REPUT_9(-1.00)[178.154.239.81:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_SPF_ALLOW(-0.20)[+ip4:178.154.239.80/28]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:200350, ipnet:178.154.224.0/19, country:RU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; FREEMAIL_FROM(0.00)[yandex.ru]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@FreeBSD.org]; DKIM_TRACE(0.00)[yandex.ru:+] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4YcMcx0nqyz42j0 On 19.01.2025 04:46, Timothy Pearson wrote: > Forcibly disabling RSS with the IPSec deferred patch seems to have > fixed the issue. Given the wide ranging deleterious effects with RSS > on vs. a bit of IPsec theoretical maximum bandwidth loss with it off, > we'll take the bandwidth hit at the moment. ;) How did you disable RSS? Usually when you have one of netisr threads overloaded, this means that you got received a lot of packets that are handled by one CPU core. This can be NIC that dispatches them via RSS or there is something that forces to handle them on single core, i.e. firewall, dummynet. > Are there any significant concerns with running the patch for > deferred IPSec input? From my analysis of the code, I think the > absolute worst case might be a reordered packet or two, but that's > always possible with IPSec over UDP transport AFAIK. The mentioned patch seems does direct processing in your case, not deferred, since you had configured net.isr.dispatch=direct. -- WBR, Andrey V. Elsukov