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 969DC331237 for ; Tue, 13 Jan 2026 10:41:35 +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=1768300898; cv=none; b=QyjZnlmytXn197C5npBKk4ZmdP5YENr1IB+w8gHQbDFYYvYv02Ni811vdUuDm7eX/S0ZC1m0Wta/e5/HBQWOUpSJGR1pij1YP8CjlaZdJcKi5fQnXaixHGhgU7prTDv6UvQT6Q7ISWUJFG1oPEogb2463yAe5pQ7z58N4rTTpiU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768300898; c=relaxed/simple; bh=6rphP0XeUY1TRejd2aNPhK+QTTqnj0/IWJtxgLJQFlY=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=ea4p6wgtSnVQ8CLPTl+aOOYlLCUVDN2Qtr7V2gCr/+JP3jwGxUBCqKnYvT44CaWnKZCh3eyIbRwgkLEOyy0atTW3PhZKCyQpm7jXRwSvACZXZXIEwsW5Cgow02DB1dmrr9bfsSirzYvetzyEf0e8IYwu50/MI3j9So+QhYhk+Pg= 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=TwDx6rus; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=MXjzljLa; 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="TwDx6rus"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="MXjzljLa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768300894; 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=S0UJyxAD7OV1Vlm9xAqwyNi0f+c77Epf12aV/zNPFd8=; b=TwDx6ruslPmtpXkYyaxcLnjjHcqVMMNt4DoYRRyWpPrbV363SIZ/wCBq1vwtHGQNCP0edm K0uf3uRU6dwnfsjRFfB+7jQRbyPiwFyxZu6JpwSTSQddH6uTr+SM0Esjy38s3kfh2/O8sm 765g5MI9SRvLISqktI0Xo6sk+KA7ebk= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-rfx43Sl2N06xgZmBPZkg0w-1; Tue, 13 Jan 2026 05:41:33 -0500 X-MC-Unique: rfx43Sl2N06xgZmBPZkg0w-1 X-Mimecast-MFC-AGG-ID: rfx43Sl2N06xgZmBPZkg0w_1768300892 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4775f51ce36so67851715e9.1 for ; Tue, 13 Jan 2026 02:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768300892; x=1768905692; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=S0UJyxAD7OV1Vlm9xAqwyNi0f+c77Epf12aV/zNPFd8=; b=MXjzljLa7elUnoRzn0CoAuENKKL7+rkFSYz3pNVLDoVAhVOvcjNiZtPElWhwD7kXbq qqw1wK7DLG3xP+IHUEoeKSvBbXw/xjF1X5a7bsQ3+FaJBe7nrHprzbxWKsEJEVKo6q6/ QasZpeKDDAsO2NzG21ebv3pCuprozp1/3E0UNsnhdDgRPAp68yooZ9OudB3vHOydBY26 Y8rHifgm7wMMhLVXDZ/srSFr6Djv6D81wpNO0ZVk6qOwWwyQQa8WK7HMuDb24yfQyIcO WFpxnnQNPAuZ0vfEbhdoBGgiEDEhXueJsHEembd3aqyOkXcAJ6iHvBvNooKN81HAQlN8 pyGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768300892; x=1768905692; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from: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=S0UJyxAD7OV1Vlm9xAqwyNi0f+c77Epf12aV/zNPFd8=; b=qHDfZBiP5eicvSxMqE4fhNjQTBKd8O56zkrF7KmrCP0T3pjRLOw3CwoNid5QatMfUi bMhqcrUHlFuvAJydhlR2wDN0iLy+m9Lqvh3W4VOWDS7LWeCJ6JeUTdgeXVW5+rPkmI2G 11w0nnU895dR23oPiF5fi4UeWqDyCI1F7vzgLWL2q0iRHw3w61GPjItapMEfheoOdpuy o0kPLjiaCzu7fGoS3m4hb+b1AoJCwYqNbwXuw75U7vLwEHsJvkdJEI9h5AvWgkmnAkJL zDXhy/ydYMpLG9V5Zpf+uc+ak1rGRaIdBdFVO4qWi+K51P3YWpTvllr1FC7NavsyP2/X QsIg== X-Forwarded-Encrypted: i=1; AJvYcCXY4/qFXT8Kq9Z3dW0JET8qcyBq5gW8xWb8e3nXq6SkpkEZ7gSF0XGIK4i/WTiqR+VjbJC1pjP4BVTJw4s=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9/AAjk4IG6g1/VkkXZiowgt+vf/alUIHThFds9LQ8X+57JEHx v8Enay1lFMPr6Ki2hoaltZcVRU5DQ8aECjg4qb8daEC2Wn3zOQxksysLVQELKKfaB4BbKWi5EUZ eNJsdpG9ITJrC+zstQ1jAfDdtCrfDcWRiCVPwHpjig10EEEAsNloVOL5qhfaSodkaOQ== X-Gm-Gg: AY/fxX6s483L7Mcj21J3GtQREY5RQMhSkeo+wmlx+Cw/2e1OF5PhIuvFH5/l30EzzGE Jp+2yEAcsbh8+D8b1PBfZWdE3+Qg7DTjwqLo4CjGWADi2gNqniSk+xA8PxEhNCTuMW+L/aVex5R kU19PVknZaxMHVrBw02MbejvWdW3TjgQaYH8iX2S/vVJHNJq1abv7owKFe+zLzbMmJj5lP8klCp mEZu9PJMZpb4AywgEdP5fBXlQstHDTItOUDdxvrTNH3we+iSBv2xcGHaZnQ4wEXjtEJyL6TnPaO JrNJaxQ7jpbV4BWGUN30MvT0pHVHz/QzmGx+0b479p++xspUciXVWtGjZBC6Ey81ftlNUfNzUkW Og/TKKDkTTtk4 X-Received: by 2002:a05:600c:a16:b0:47b:de05:aa28 with SMTP id 5b1f17b1804b1-47d84b0aadcmr200306765e9.2.1768300892148; Tue, 13 Jan 2026 02:41:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IHyA6GIRnSDRUL9ab020nIrIsOT+mtQP2pIuI9imx0C1in3fLtYCcDSBcqt+RulymIY1xRsYA== X-Received: by 2002:a05:600c:a16:b0:47b:de05:aa28 with SMTP id 5b1f17b1804b1-47d84b0aadcmr200306215e9.2.1768300891731; Tue, 13 Jan 2026 02:41:31 -0800 (PST) Received: from [192.168.88.32] ([212.105.155.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47edfd5cfd5sm4882345e9.8.2026.01.13.02.41.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 02:41:31 -0800 (PST) Message-ID: <0eab9112-eedf-4425-9ce9-be0a59191d8d@redhat.com> Date: Tue, 13 Jan 2026 11:41:27 +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 From: Paolo Abeni 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> <4db44c27-4654-46f9-be41-93bcf06302b2@redhat.com> Content-Language: en-US In-Reply-To: <4db44c27-4654-46f9-be41-93bcf06302b2@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/13/26 11:27 AM, Paolo Abeni wrote: > 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... I see the next patch rejects too small `rx_page_size` values; so possibly the better option is to drop the confusing check in bnxt_alloc_rx_page_pool(). /P