From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CADD38A2A1 for ; Tue, 13 Jan 2026 10:27:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768300079; cv=none; b=i8eVaIFcMY45x74K3X3icZc8Xv9YvBLBdfncVzV9UYIFC4j059150rgTru3YMRwiyqY6eZ7TQTyXO9nA5hckCA/prJ95Jz38ZYMWtr9nQjFDMnfa8qiGExGxQmB5CSuvTw7EFxNbnqTiNO/dP3+txu1YOaw3+GzBB3i2CB7o92o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768300079; c=relaxed/simple; bh=Xs40V71NSFgBl8ux07wXA+nnPiuQ97Bp4CQVChxYDDY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HlgCFz5aLsPEO6kIjbmEe3FArckmASex19XlCvXQAoNHmLP51LpRAQmw8HyninQKTESj1NaTQdsSKoIEYxWhQ1DXPgFEKBiO5wn2eDuW4k43kPVGeFm48ksMNqOcrsOLlnfGsqSWCvU+MTLsHpGs7Q4rvRS3c/Iv1MIeY7vKLYE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Xc1g8CqM; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=l7rblCDK; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Xc1g8CqM"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="l7rblCDK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768300077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WZv6AyyuLVVLAZ1eQ6zjrtIwS0o/q5F3gCFQ/xz3D2k=; b=Xc1g8CqMKwrV5Wj6cUYh5x/oF8UVQ1mKyNQn2KWpG+4DmDvfgSBSl3e96BHFfNjQYQDAHx 4h/bLWnca82GfiIZajQWJE4DT5VLQ9nBZhBWNlcF3Cg314A1QI3XKKCTsTWNpG7H2htaof sT3gAFllLCZAh8dS7+YEF4VqVrn9iuA= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-206-VZAorspjMwyetJZN5rUqLw-1; Tue, 13 Jan 2026 05:27:54 -0500 X-MC-Unique: VZAorspjMwyetJZN5rUqLw-1 X-Mimecast-MFC-AGG-ID: VZAorspjMwyetJZN5rUqLw_1768300072 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-43065ad16a8so4126457f8f.1 for ; Tue, 13 Jan 2026 02:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768300072; x=1768904872; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WZv6AyyuLVVLAZ1eQ6zjrtIwS0o/q5F3gCFQ/xz3D2k=; b=l7rblCDKgRS2I8oTRrwQ581FzINuB670SWOuseGwHOQbWyBC9dTt+/5RgCIcU/9EE3 XD+IsZvDDq8b60X5k3xH3B7rawc5Q/fSX8JH2v/YDk1hwJUCm4BcV/Alz9PK66UotQaj gZcHrNG8OALEVy2ggRJTjuUOx5FIlJ49Z5OXAUSuRx8rLxpMyX1pME0x0488fM48QgJT CW/durgdG8PRaW+3XLBL4lQxoIRpUG8vU6Q8ZbgAITczA+8hnfDGF1d22IrrZ3E5G52Q KotZHPmbkOc6rxF6ydk15WebD6IDQd52YzwP3VMoCFuyMMHlmen3U5EcrQTrPMPhGLUB hnfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768300072; x=1768904872; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WZv6AyyuLVVLAZ1eQ6zjrtIwS0o/q5F3gCFQ/xz3D2k=; b=I3J8tyzYhBMZLyNXHxV0DGPlND9bMepJc3+hRB9SQ0SMeoWkn03Wmmh3kMjZ2MdrYO Em54dF2mRCiqfhyy3pRDiIG24bZ5udQ/FERQaJdVeWmn1yXurNZrpTQHFLLm85YgZYtd CNSNOf5R8Zxsvu7DTPn7jgPMuOXX3k0yn4OLlhfyRiccgDXuLFBLo39IC4JHlZO7RbWV n+kWfRWyV4TOY+9vzLKILh+3UUUGJyOVb8j/W0Kc9hEEoCcqlUKg4RtZrtdu7zp21JuJ XxJsS1R9dMM8la5IuudLUuy4gI66Fne2av+ybnays9zZcre/rnFiUTQm8zwmIuMm+yep WOYQ== X-Forwarded-Encrypted: i=1; AJvYcCXT0IKFitQSYQ72Gq1TYkhDtStgmRl6p0kkiNjmWr6A0zj/NTYxodXtksPNlLrDJfQmE1BPV6nOB4LG6Is=@vger.kernel.org X-Gm-Message-State: AOJu0YwRaXODZvfdX/2EziLeqKLOwUgqBWuNIba7J0FsxuA/gahzoprV AfBYXqeFaIE9ECgMwDpDZMxSG7ZiqB9RL/yPeUx7DhdykZ4Hu/NcxQEUm5HDorkjKl+CPsPciot QJ9OyE1zb3RTvllmh2m2+WJSOw1DECfLi8Sqkiepw5iSm1z2OJdilR/UoeCCMwH1kfQ== X-Gm-Gg: AY/fxX4sT4sTfOc8DqA/rxuJKfyGd37a5CLXI/qd9tdLFh/E4H1nqJHUSKk6S8ELmil Isr+LAO8+VwvcPwGF8bnk2YNxSTbrbjr7pMR7eVtjWIUMpu9PDdIdkUy+lfbUHZb9lKn3c8salV 0MQmymyiYPsq2rCnt5ZZbQlvkik64foUL+ZiMSJEJpxuHxTmCj82SXCch0SHPuiwBdZ51/vFsGC BGStF+IYIw48+BdeTloqDf9UvlAyrn/vl8t8kzJHWu+j77WEHrNZQ3aPu7gfQ0xSNPNVfIhihTO KP9/SUrnKOa6KGhIAigZystHa5TZEKcIt2phXWfnutu9Axtm+6W8sUv3/Z9L1vvlrKVS9bThWAf jINS6OHurks6i X-Received: by 2002:a05:600c:c10f:b0:47e:d6ee:7dd1 with SMTP id 5b1f17b1804b1-47ed6ee7dfbmr30480725e9.2.1768300071582; Tue, 13 Jan 2026 02:27:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IFBi8qAsCyoUj8yK3DWWfIteg/UVGEMMZ3DTwKr3HpHFkur4u7m4Xtrpa9L15tB9tU9SsSBiA== X-Received: by 2002:a05:600c:c10f:b0:47e:d6ee:7dd1 with SMTP id 5b1f17b1804b1-47ed6ee7dfbmr30480125e9.2.1768300071047; Tue, 13 Jan 2026 02:27:51 -0800 (PST) Received: from [192.168.88.32] ([212.105.155.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f695956sm408197555e9.6.2026.01.13.02.27.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 02:27:50 -0800 (PST) Message-ID: <4db44c27-4654-46f9-be41-93bcf06302b2@redhat.com> Date: Tue, 13 Jan 2026 11:27:47 +0100 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: [PATCH net-next v8 6/9] eth: bnxt: adjust the fill level of agg queues with larger buffers To: Pavel Begunkov , netdev@vger.kernel.org Cc: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Jonathan Corbet , Michael Chan , Pavan Chebbi , Andrew Lunn , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Joshua Washington , Harshitha Ramamurthy , Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Alexander Duyck , Ilias Apalodimas , Shuah Khan , Willem de Bruijn , Ankit Garg , Tim Hostetler , Alok Tiwari , Ziwei Xiao , John Fraker , Praveen Kaligineedi , Mohsin Bashir , Joe Damato , Mina Almasry , Dimitri Daskalakis , Stanislav Fomichev , Kuniyuki Iwashima , Samiullah Khawaja , Ahmed Zaki , Alexander Lobakin , David Wei , Yue Haibing , Haiyue Wang , Jens Axboe , Simon Horman , Vishwanath Seshagiri , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kselftest@vger.kernel.org, dtatulea@nvidia.com, io-uring@vger.kernel.org References: <8b6486d8a498875c4157f28171b5b0d26593c3d8.1767819709.git.asml.silence@gmail.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <8b6486d8a498875c4157f28171b5b0d26593c3d8.1767819709.git.asml.silence@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/9/26 12:28 PM, Pavel Begunkov wrote: > From: Jakub Kicinski > > The driver tries to provision more agg buffers than header buffers > since multiple agg segments can reuse the same header. The calculation > / heuristic tries to provide enough pages for 65k of data for each header > (or 4 frags per header if the result is too big). This calculation is > currently global to the adapter. If we increase the buffer sizes 8x > we don't want 8x the amount of memory sitting on the rings. > Luckily we don't have to fill the rings completely, adjust > the fill level dynamically in case particular queue has buffers > larger than the global size. > > Signed-off-by: Jakub Kicinski > [pavel: rebase on top of agg_size_fac, assert agg_size_fac] > Signed-off-by: Pavel Begunkov > --- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 28 +++++++++++++++++++---- > 1 file changed, 24 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > index 8f42885a7c86..137e348d2b9c 100644 > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > @@ -3816,16 +3816,34 @@ static void bnxt_free_rx_rings(struct bnxt *bp) > } > } > > +static int bnxt_rx_agg_ring_fill_level(struct bnxt *bp, > + struct bnxt_rx_ring_info *rxr) > +{ > + /* User may have chosen larger than default rx_page_size, > + * we keep the ring sizes uniform and also want uniform amount > + * of bytes consumed per ring, so cap how much of the rings we fill. > + */ > + int fill_level = bp->rx_agg_ring_size; > + > + if (rxr->rx_page_size > BNXT_RX_PAGE_SIZE) > + fill_level /= rxr->rx_page_size / BNXT_RX_PAGE_SIZE; According to the check in bnxt_alloc_rx_page_pool() it's theoretically possible for `rxr->rx_page_size / BNXT_RX_PAGE_SIZE` being zero. If so the above would crash. Side note: this looks like something AI review could/should catch. The fact it didn't makes me think I'm missing something... /P