[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ff3cf5d-b3ff-4b52-9031-30a1cb71c0c9@intel.com>
Date: Fri, 26 Jan 2024 17:45:11 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Robin Murphy <robin.murphy@....com>
CC: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Christoph Hellwig <hch@....de>, Marek Szyprowski
<m.szyprowski@...sung.com>, Joerg Roedel <joro@...tes.org>, Will Deacon
<will@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael
J. Wysocki" <rafael@...nel.org>, Magnus Karlsson <magnus.karlsson@...el.com>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>, Alexander Duyck
<alexanderduyck@...com>, <bpf@...r.kernel.org>, <netdev@...r.kernel.org>,
<iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 2/7] dma: avoid expensive redundant calls for
sync operations
From: Robin Murphy <robin.murphy@....com>
Date: Fri, 26 Jan 2024 15:48:54 +0000
> On 26/01/2024 1:54 pm, Alexander Lobakin wrote:
>> From: Eric Dumazet <edumazet@...gle.com>
>>
>> Quite often, NIC devices do not need dma_sync operations on x86_64
>> at least.
>> Indeed, when dev_is_dma_coherent(dev) is true and
>> dev_use_swiotlb(dev) is false, iommu_dma_sync_single_for_cpu()
>> and friends do nothing.
>>
>> However, indirectly calling them when CONFIG_RETPOLINE=y consumes about
>> 10% of cycles on a cpu receiving packets from softirq at ~100Gbit rate.
>> Even if/when CONFIG_RETPOLINE is not set, there is a cost of about 3%.
>>
>> Add dev->skip_dma_sync boolean which is set during the device
>> initialization depending on the setup: dev_is_dma_coherent() for direct
>> DMA, !(sync_single_for_device || sync_single_for_cpu) or positive result
>> from the new callback, dma_map_ops::can_skip_sync for non-NULL DMA ops.
>> Then later, if/when swiotlb is used for the first time, the flag
>> is turned off, from swiotlb_tbl_map_single().
>
> I think you could probably just promote the dma_uses_io_tlb flag from
> SWIOTLB_DYNAMIC to a general SWIOTLB thing to serve this purpose now.
Nice catch!
>
> Similarly I don't think a new op is necessary now that we have
> dma_map_ops.flags. A simple static flag to indicate that sync may be> skipped under the same conditions as implied for dma-direct - i.e.
> dev_is_dma_coherent(dev) && !dev->dma_use_io_tlb - seems like it ought
> to suffice.
In my initial implementation, I used a new dma_map_ops flag, but then I
realized different DMA ops may require or not require syncing under
different conditions, not only dev_is_dma_coherent().
Or am I wrong and they would always be the same?
>
> Thanks,
> Robin.
Thanks,
Olek
Powered by blists - more mailing lists