From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75BE61FF5E3 for ; Wed, 8 Jan 2025 16:53:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736355201; cv=none; b=S6aa8XdBruyAfNdIGu7ycuAPrAqhvTddUbsOPTqQAoWveLAOs7S1BKhD2dE6SQYKsi3Mxt9ZoVsoFqSlJ89CcXqfkzieP9AynNPZvQphWXZlcnv//q7+YDQBZMgZED3q2RtIp6zaV/luRngkafoHVAlGmo9hr8EFsMPpxS/doeg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736355201; c=relaxed/simple; bh=FhUGOusxWjfKCfdzL0fNtn26lbs1GM0d0bT6iYlv+vI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hFhTRxJ/jhOVIXDSAXkm/feZEB1e5KbvwLghFlR+Kw2uVMqu62vbUitTa/JHfibfiEOK0l6NPQ7JeNY5Y1JJ6dR2F5fR7y/RQZzElYD3LdfyiYx377lhdh3xlTJWxsW3kpKNCATr3j6zKLjSX4mAIkpVpygaRjsESc3PAuakx/4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=JojYbeQX; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="JojYbeQX" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2166651f752so63043795ad.3 for ; Wed, 08 Jan 2025 08:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1736355198; x=1736959998; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=gaB+29whKD9tF6NdRjAt8cwfbffpIlou0M2p2EY/0AM=; b=JojYbeQXbZYvLiElGqK4iw4n659GGHB+s5BaILVR7op2Q+gKPwtFxS41u2XVW2aCyJ m7XmQJCjDseSRapK0RdaIssGs0qr54F7eAc1NIWIDfcUpMti9qfR2GgJss20YThyUA4/ 40T/DpM7i6OF7AZPV8IOyVWrDp5uo06JFCbAc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736355198; x=1736959998; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gaB+29whKD9tF6NdRjAt8cwfbffpIlou0M2p2EY/0AM=; b=RYGT9Vn6Zl+0kFWmFl21kQQ3SHpIaHk2r5imkh+/F34N1TnDhvaiL0QXxiHcXF4zd5 TEDKo3/77DirKzAZN+ZtJnC1bae7KyQSmDd1FCqMdZsJppHj9yHzJiLGxtAFl9zWrtM3 cWeE/g0sm4tlTx2k6x1j0BW+CE/Bs4bMyiSZ1YBWxY4hINURwjmcXKctzvHA6nRHiATp mMNCjjkQcmBcFqA6PA+Mo8AV372zFgepStbK34rRzUtCedXVvZlPJ6LpBAqNR20/tUY6 E1SSYjTG8dIgqoCLfBn8W9xw/EVrsX7HNqn7balLsFKYNgOKiwdYtFFvPEifZ4SoLxq5 GFeg== X-Forwarded-Encrypted: i=1; AJvYcCXWpp620iWrjgmyUb94AkeT8wuwmvUBcDZg/+HHJP1aD3dXQ54XJaKlcxQSw2So/IxMVWr+imZF3beh6WQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxhU36OzcILdl+szKs3S7ERu0amshgQUhXyXsCuGxW0tFMv3c1g 6K7QRNd1rqvuDgyAUhgt+95QfqGd4cgA/gOz39yiPjzF800VgEe1dQa0nR8uj+N4jBjrDv8TctQ = X-Gm-Gg: ASbGncthpvtkcK2DXexuRnNnZVWO64lxsoeXilgoip6JMY2mlzj06AZwKl/q8qlWB6I kMXDz6DrkFB01Pbk0o3AopNBdksH6ZOmKJnp77Kk9McLrV1lxBgvsYQG7oFmnLit6Xvg9q/dyEK yOkef6Ez5Q8ttHi6Wy3ePP6HIKMjhmlSlygHNlQ/coG+qEF5Bp2+34SFAoz9DhZKIvIp4sBujyi 0MKUsrVkNc4F96dtlCqdlVRr9lnjyAEU8hMkPDRHeY2ODQ1b7tiHQUSir5z2VUkOcP0wefMjOrO +cRMhTibJO7Tx3ZIAlw0 X-Google-Smtp-Source: AGHT+IF+IBId4vqdaKN3CVtCTfPYH93J7zs6SP0NYTjmkBCo78OU4vPMoKyHYD+lpaUfmXpO/83Z0g== X-Received: by 2002:a05:6a20:3d86:b0:1e0:c5d2:f215 with SMTP id adf61e73a8af0-1e88d18b423mr5852868637.12.1736355197755; Wed, 08 Jan 2025 08:53:17 -0800 (PST) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad8fb88asm35415132b3a.135.2025.01.08.08.53.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2025 08:53:16 -0800 (PST) Message-ID: <0a633091-4ae0-4a89-9fe7-99336656009c@broadcom.com> Date: Wed, 8 Jan 2025 08:53:15 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/1] vmxnet3: Adjust maximum Rx ring buffer size To: Jakub Kicinski , Florian Fainelli Cc: Aaron Tomlin , ronak.doshi@broadcom.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, bcm-kernel-feedback-list@broadcom.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20250105213036.288356-1-atomlin@atomlin.com> <20250106154741.23902c1a@kernel.org> <031eafb1-4fa6-4008-92c3-0f6ecec7ce63@broadcom.com> <20250106165732.3310033e@kernel.org> Content-Language: en-US From: Florian Fainelli Autocrypt: addr=florian.fainelli@broadcom.com; keydata= xsBNBFPAG8ABCAC3EO02urEwipgbUNJ1r6oI2Vr/+uE389lSEShN2PmL3MVnzhViSAtrYxeT M0Txqn1tOWoIc4QUl6Ggqf5KP6FoRkCrgMMTnUAINsINYXK+3OLe7HjP10h2jDRX4Ajs4Ghs JrZOBru6rH0YrgAhr6O5gG7NE1jhly+EsOa2MpwOiXO4DE/YKZGuVe6Bh87WqmILs9KvnNrQ PcycQnYKTVpqE95d4M824M5cuRB6D1GrYovCsjA9uxo22kPdOoQRAu5gBBn3AdtALFyQj9DQ KQuc39/i/Kt6XLZ/RsBc6qLs+p+JnEuPJngTSfWvzGjpx0nkwCMi4yBb+xk7Hki4kEslABEB AAHNMEZsb3JpYW4gRmFpbmVsbGkgPGZsb3JpYW4uZmFpbmVsbGlAYnJvYWRjb20uY29tPsLB IQQQAQgAywUCZWl41AUJI+Jo+hcKAAG/SMv+fS3xUQWa0NryPuoRGjsA3SAUAAAAAAAWAAFr ZXktdXNhZ2UtbWFza0BwZ3AuY29tjDAUgAAAAAAgAAdwcmVmZXJyZWQtZW1haWwtZW5jb2Rp bmdAcGdwLmNvbXBncG1pbWUICwkIBwMCAQoFF4AAAAAZGGxkYXA6Ly9rZXlzLmJyb2FkY29t Lm5ldAUbAwAAAAMWAgEFHgEAAAAEFQgJChYhBNXZKpfnkVze1+R8aIExtcQpvGagAAoJEIEx tcQpvGagWPEH/2l0DNr9QkTwJUxOoP9wgHfmVhqc0ZlDsBFv91I3BbhGKI5UATbipKNqG13Z TsBrJHcrnCqnTRS+8n9/myOF0ng2A4YT0EJnayzHugXm+hrkO5O9UEPJ8a+0553VqyoFhHqA zjxj8fUu1px5cbb4R9G4UAySqyeLLeqnYLCKb4+GklGSBGsLMYvLmIDNYlkhMdnnzsSUAS61 WJYW6jjnzMwuKJ0ZHv7xZvSHyhIsFRiYiEs44kiYjbUUMcXor/uLEuTIazGrE3MahuGdjpT2 IOjoMiTsbMc0yfhHp6G/2E769oDXMVxCCbMVpA+LUtVIQEA+8Zr6mX0Yk4nDS7OiBlvOwE0E U8AbwQEIAKxr71oqe+0+MYCc7WafWEcpQHFUwvYLcdBoOnmJPxDwDRpvU5LhqSPvk/yJdh9k 4xUDQu3rm1qIW2I9Puk5n/Jz/lZsqGw8T13DKyu8eMcvaA/irm9lX9El27DPHy/0qsxmxVmU pu9y9S+BmaMb2CM9IuyxMWEl9ruWFS2jAWh/R8CrdnL6+zLk60R7XGzmSJqF09vYNlJ6Bdbs MWDXkYWWP5Ub1ZJGNJQ4qT7g8IN0qXxzLQsmz6tbgLMEHYBGx80bBF8AkdThd6SLhreCN7Uh IR/5NXGqotAZao2xlDpJLuOMQtoH9WVNuuxQQZHVd8if+yp6yRJ5DAmIUt5CCPcAEQEAAcLB gQQYAQIBKwUCU8AbwgUbDAAAAMBdIAQZAQgABgUCU8AbwQAKCRCTYAaomC8PVQ0VCACWk3n+ obFABEp5Rg6Qvspi9kWXcwCcfZV41OIYWhXMoc57ssjCand5noZi8bKg0bxw4qsg+9cNgZ3P N/DFWcNKcAT3Z2/4fTnJqdJS//YcEhlr8uGs+ZWFcqAPbteFCM4dGDRruo69IrHfyyQGx16s CcFlrN8vD066RKevFepb/ml7eYEdN5SRALyEdQMKeCSf3mectdoECEqdF/MWpfWIYQ1hEfdm C2Kztm+h3Nkt9ZQLqc3wsPJZmbD9T0c9Rphfypgw/SfTf2/CHoYVkKqwUIzI59itl5Lze+R5 wDByhWHx2Ud2R7SudmT9XK1e0x7W7a5z11Q6vrzuED5nQvkhAAoJEIExtcQpvGagugcIAJd5 EYe6KM6Y6RvI6TvHp+QgbU5dxvjqSiSvam0Ms3QrLidCtantcGT2Wz/2PlbZqkoJxMQc40rb fXa4xQSvJYj0GWpadrDJUvUu3LEsunDCxdWrmbmwGRKqZraV2oG7YEddmDqOe0Xm/NxeSobc MIlnaE6V0U8f5zNHB7Y46yJjjYT/Ds1TJo3pvwevDWPvv6rdBeV07D9s43frUS6xYd1uFxHC 7dZYWJjZmyUf5evr1W1gCgwLXG0PEi9n3qmz1lelQ8lSocmvxBKtMbX/OKhAfuP/iIwnTsww 95A2SaPiQZA51NywV8OFgsN0ITl2PlZ4Tp9hHERDe6nQCsNI/Us= In-Reply-To: <20250106165732.3310033e@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/6/25 16:57, Jakub Kicinski wrote: > On Mon, 6 Jan 2025 15:51:10 -0800 Florian Fainelli wrote: >> On 1/6/25 15:47, 'Jakub Kicinski' via BCM-KERNEL-FEEDBACK-LIST,PDL wrote: >>> On Sun, 5 Jan 2025 21:30:35 +0000 Aaron Tomlin wrote: >>>> I managed to trigger the MAX_PAGE_ORDER warning in the context of function >>>> __alloc_pages_noprof() with /usr/sbin/ethtool --set-ring rx 4096 rx-mini >>>> 2048 [devname]' using the maximum supported Ring 0 and Rx ring buffer size. >>>> Admittedly this was under the stock Linux kernel-4.18.0-477.27.1.el8_8 >>>> whereby CONFIG_CMA is not enabled. I think it does not make sense to >>>> attempt a large memory allocation request for physically contiguous memory, >>>> to hold the Rx Data ring that could exceed the maximum page-order supported >>>> by the system. >>> >>> I think CMA should be a bit orthogonal to the warning. >>> >>> Off the top of my head the usual way to solve the warning is to add >>> __GFP_NOWARN to the allocations which trigger it. And then handle >>> the error gracefully. >> >> That IMHO should really be the default for any driver that calls >> __netdev_alloc_skb() under the hood, we should not really have to >> specify __GFP_NOWARN, rather if people want it, they should specify it. > > True, although TBH I don't fully understand why this flag exists > in the first place. Is it just supposed to be catching programming > errors, or is it due to potential DoS implications of users triggering > large allocations? > There is some value IMHO in printing when allocations fail, where they came from, their gfp_t flags and page order so you can track high order offenders in hot paths (one of our Wi-Fi driver was notorious for doing that and having verbose out of memory dumps by default definitively helped). Once you fix those however, hogging the system while dumping lines and lines of information onto a slow console tends to be worse than the recovery from out of memory itself. One could argue that triggering an OOM plus dumping information can result in a DoS, so that should be frowned upon... -- Florian