lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <7d484879-e256-fb06-45cd-1b61a429e6c2@intel.com> Date: Thu, 18 May 2023 15:29:34 +0200 From: Alexander Lobakin <aleksander.lobakin@...el.com> To: Yunsheng Lin <linyunsheng@...wei.com> CC: Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, "Maciej Fijalkowski" <maciej.fijalkowski@...el.com>, Magnus Karlsson <magnus.karlsson@...el.com>, Michal Kubiak <michal.kubiak@...el.com>, "Larysa Zaremba" <larysa.zaremba@...el.com>, Jesper Dangaard Brouer <hawk@...nel.org>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, "Christoph Hellwig" <hch@....de>, <netdev@...r.kernel.org>, <intel-wired-lan@...ts.osuosl.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH net-next 06/11] net: page_pool: avoid calling no-op externals when possible From: Yunsheng Lin <linyunsheng@...wei.com> Date: Thu, 18 May 2023 12:54:37 +0800 > On 2023/5/18 12:08, Jakub Kicinski wrote: >> On Tue, 16 May 2023 18:18:36 +0200 Alexander Lobakin wrote: >>> + /* Try to avoid calling no-op syncs */ >>> + pool->p.flags |= PP_FLAG_DMA_MAYBE_SYNC; >>> + pool->p.flags &= ~PP_FLAG_DMA_SYNC_DEV; >>> } >>> >>> if (PAGE_POOL_DMA_USE_PP_FRAG_COUNT && >>> @@ -323,6 +327,12 @@ static bool page_pool_dma_map(struct page_pool *pool, struct page *page) >>> >>> page_pool_set_dma_addr(page, dma); >>> >>> + if ((pool->p.flags & PP_FLAG_DMA_MAYBE_SYNC) && >>> + dma_need_sync(pool->p.dev, dma)) { >>> + pool->p.flags |= PP_FLAG_DMA_SYNC_DEV; >>> + pool->p.flags &= ~PP_FLAG_DMA_MAYBE_SYNC; >>> + } >> >> is it just me or does it feel cleaner to allocate a page at init, >> and throw it into the cache, rather than adding a condition to a >> fast(ish) path? > > Is dma_need_sync() not reliable until a dma map is called? > Is there any reason why not just clear PP_FLAG_DMA_SYNC_DEV if > dma_need_sync() is false without introducing the PP_FLAG_DMA_MAYBE_SYNC > flag? We can't just clear the flag, because some drivers don't want PP to synchronize DMA. Without a new flag, we can't distinguish those two. Example: 1) Driver doesn't set DMA_SYNC_DEV 2) We check for dma_need_sync() and it returns true 3) As a result, we set DMA_SYNC_DEV, although driver does that on its own Thanks, Olek
Powered by blists - more mailing lists