From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1EA1CC02198 for ; Thu, 6 Feb 2025 15:16:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JzgXDfs7zolLM+ECMRMomq4NQK9sGoV7mYHLd1cpZVo=; b=LGYyshKX/zcB/SBVl1vZKwSboT b+OwOrvk0+1uLECKtuT8iNT5Xuq/qaV+4z4vQhVymY/ji36gEjdK8cec7ODM/o2WVTEisqPFyFWC0 hyV/uzpsSmeYPz2XElMzPi6EsEWZe1k8TvEqn0ypoym2q/ngPaKrwhe1tF0ocwfU880YhG3jCdMKC CxJaY03ZPNM9PayPniRV+ydGNbZy6JF8BYYkOYOjsr338g7EaAtNpThoyxoMle4L+kO/H8BiRRaXb 64hncMDw9Npmc6S6J7eAOqEDUVQB/Q0AKzxSvIQAhVxErr5wr4YrEbCXvRIBZ7H90hJ/swuvXxb3G NBdVSOCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tg3c4-00000006ghE-31bk; Thu, 06 Feb 2025 15:16:20 +0000 Received: from lelvem-ot01.ext.ti.com ([198.47.23.234]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tg2Rv-00000006Vn7-2XeX for linux-arm-kernel@lists.infradead.org; Thu, 06 Feb 2025 14:01:48 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelvem-ot01.ext.ti.com (8.15.2/8.15.2) with ESMTPS id 516E1Chb3635411 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Feb 2025 08:01:12 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1738850472; bh=JzgXDfs7zolLM+ECMRMomq4NQK9sGoV7mYHLd1cpZVo=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=VWyBHEcG11Mm9E81MM4ZcZVa8kxViqwaJRsrM5RFvCmQwgzNjEx6LADeoBb6YmeiH SDfLHGu8sgOq6g1h2Lp2byT6n5codLVs7aXewmoNKbUrONPJsgE7/aVyRw7BLkJVLN 2nDpP/BrcLvOI8GsO2v5E51nyGo6J7X/ywvicuJw= Received: from DLEE108.ent.ti.com (dlee108.ent.ti.com [157.170.170.38]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTP id 516E1Cdt015489; Thu, 6 Feb 2025 08:01:12 -0600 Received: from DLEE101.ent.ti.com (157.170.170.31) by DLEE108.ent.ti.com (157.170.170.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Thu, 6 Feb 2025 08:01:11 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Thu, 6 Feb 2025 08:01:12 -0600 Received: from [172.24.23.168] (lt9560gk3.dhcp.ti.com [172.24.23.168]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 516E142U027248; Thu, 6 Feb 2025 08:01:04 -0600 Message-ID: <631429d8-9da6-4333-80ce-6ff59e5ecdf6@ti.com> Date: Thu, 6 Feb 2025 19:31:03 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [EXTERNAL] Re: [PATCH net 1/3] net: ti: icssg-prueth: Use page_pool API for RX buffer allocation To: Ido Schimmel CC: , , , , , , , , , , , , , , , , , , , , , , , Vignesh Raghavendra References: <20250122124951.3072410-1-m-malladi@ti.com> <20250122124951.3072410-2-m-malladi@ti.com> <9287a623-5663-4705-b61a-3ab5f5cb2424@ti.com> Content-Language: en-US From: "Malladi, Meghana" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250206_060147_729416_7D1DF2D0 X-CRM114-Status: GOOD ( 24.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/5/2025 11:11 PM, Ido Schimmel wrote: > On Tue, Feb 04, 2025 at 11: 25: 02PM +0530, Malladi, Meghana wrote: > > Seems like none of the pages which have been allocated aren't getting > > recycled in the rx path after being used unless its some error case. > Will > try to fix this.  > ZjQcmQRYFpfptBannerStart > This message was sent from outside of Texas Instruments. > Do not click links or open attachments unless you recognize the source > of this email and know the content is safe. > Report Suspicious > v9dnXdhkXiNQgIoLtH6jcbhWBIydfvayMZ6bf68taZCHXfcLg8XIOscUa_XNxqzQWA$> > ZjQcmQRYFpfptBannerEnd > > On Tue, Feb 04, 2025 at 11:25:02PM +0530, Malladi, Meghana wrote: >> Seems like none of the pages which have been allocated aren't getting >> recycled in the rx path after being used unless its some error case. Will >> try to fix this. > > skb_mark_for_recycle() should help with page recycling when an skb that > uses them is freed. > > Anyway, I believe that I don't see put call when tearing down the Rx > ring because prueth_rx_cleanup() is using page_pool_recycle_direct() > when it shouldn't. AFAICT, prueth_rx_cleanup() is only called from the > control path (upon ndo_stop()) and not in NAPI context. > Ok I will use skb_mark_for_recycle()/page_pool_recycle_direct() accordingly to recycle the pages. >> Also I have noticed, in prueth_prepare_rx_chan() pages are allocated per >> number of descriptors for a channel, but they are not being used when a >> packet is being recieved (in emac_rx_packet()) and rather new page is >> allocated for the next upcoming packet. Is this a valid design, what are >> your thoughts on this ? > > The new page is possibly a page that was recycled into the pool when a > previous packet was freed / dropped. > > [...] > >> Yes I will add PP_FLAG_DMA_SYNC_DEV as well. >> I believe page_pool_dma_sync_for_cpu() needs to be called sync Rx page for >> CPU, am I right ? If so can you tell me, in what all cases should I call >> this function. > > Before accessing the packet data. > Ok, thanks. >> https://urldefense.com/v3/__https://lkml.iu.edu/hypermail/linux/ > kernel/2312.1/06353.html__;!!G3vK!R- > autrVAgf5rAbl3CYoqlN5gRE_NqPqYRg1NHkJ405Q33b6uKiHFI73PeRky46dBYBWQpmFThUyD$ >> In the above link it is quoted - "Note that this version performs DMA sync >> unconditionally, even if the associated PP doesn't perform sync-for-device" >> for the page_pool_dma_sync_for_cpu() function. So does that mean if I am >> using this function I don't need explicily sync for device call? > > It's explained in the page pool documentation: > > "Driver is always responsible for syncing the pages for the CPU. Drivers > may choose to take care of syncing for the device as well or set the > PP_FLAG_DMA_SYNC_DEV flag to request that pages allocated from the page > pool are already synced for the device." > > https://urldefense.com/v3/__https://docs.kernel.org/networking/ > page_pool.html*dma-sync__;Iw!!G3vK!R- > autrVAgf5rAbl3CYoqlN5gRE_NqPqYRg1NHkJ405Q33b6uKiHFI73PeRky46dBYBWQphNIm6Qm$ >