Received-SPF: pass (google.com: domain of linux-kernel+bounces-42920-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <c3e314f4-f145-472f-8321-b696e367fb08@intel.com>
Date: Mon, 29 Jan 2024 15:34:26 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net-next 2/7] dma: avoid expensive redundant calls for
 sync operations
Content-Language: en-US
To: Robin Murphy <robin.murphy@arm.com>
CC: "David S. Miller" <davem@davemloft.net>, Eric Dumazet
	<edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni
	<pabeni@redhat.com>, Christoph Hellwig <hch@lst.de>, Marek Szyprowski
	<m.szyprowski@samsung.com>, Joerg Roedel <joro@8bytes.org>, Will Deacon
	<will@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael
 J. Wysocki" <rafael@kernel.org>, Magnus Karlsson <magnus.karlsson@intel.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>, Alexander Duyck
	<alexanderduyck@fb.com>, <bpf@vger.kernel.org>, <netdev@vger.kernel.org>,
	<iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>
References: <20240126135456.704351-1-aleksander.lobakin@intel.com>
 <20240126135456.704351-3-aleksander.lobakin@intel.com>
 <0f6f550c-3eee-46dc-8c42-baceaa237610@arm.com>
 <7ff3cf5d-b3ff-4b52-9031-30a1cb71c0c9@intel.com>
 <3d9f7f89-9d62-4916-8f3f-a4aaad85a8e2@intel.com>
 <9ab3aa81-294c-4b16-a4e3-97b4fe358be8@arm.com>
From: Alexander Lobakin <aleksander.lobakin@intel.com>
In-Reply-To: <9ab3aa81-294c-4b16-a4e3-97b4fe358be8@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?djRCRnNIZjBRTFBlOGJSZHMvR3hqUU9yZGJ1QmRMa2wxczR4NTZ5dCtGZkVz?=
 =?utf-8?B?bkZxb2Zxb29wdWpuUFVOdkxscm83Rzk5OFN1c0tTb0lqdEYwbXRHcXp4QjNJ?=
 =?utf-8?B?Q2dLcDhpajJnOTlZOExmVmwxRElodHptanRYTytQRFJtZkhFcGtVSCt1YkhV?=
 =?utf-8?B?QjUyL3RqemcvYjJNY0JMU2htZkdvNFY0M0gzdlFsWVIxWTZGQ0t1NDdjYm5t?=
 =?utf-8?B?dUh4aEZKMFpNMGgzVTNWS0dvT3IvMWRJRHhuVkhKWVpUbVdjZXRhWGpBdjBD?=
 =?utf-8?B?dmRqek9NNHEzUlB4NTFjWjNva3lKUXdMcGZ2YVBqR2lDOUF2ZDhZUSsxaUlq?=
 =?utf-8?B?U0tUS3pGM3JUQ21zOWFFWHMySVFRZC9VV1o3ck9QaDdoNkdUUVNBMnJ1OEtE?=
 =?utf-8?B?bk1HVTkxa21NT1JoNVI2Rzd3Z3NRZjFpM1VFRnIwYysrS2ZSNlA3NW5GWmg0?=
 =?utf-8?B?dWE1K1E3TjJIc25teWQ5emVnMmtmSmhLOHBRSnUyMzNDMk1acGNlS0h6RU5P?=
 =?utf-8?B?N2lQYXYxYnBTWHlRNDl1OWdRSXFxamV2dEk2T1lHZjI2S2FhN0JvQzgvRDN6?=
 =?utf-8?B?Sk9NSGJGbWRHZE9iSzE0bS82UkhWMUgycEh3dTlqbjJ3MStrUUdmT2VpYm1S?=
 =?utf-8?B?SlFTQXVBL0JxbjBvSEcvVDBMZ09WRnpyVG90Zml0aW1GUzBCZU1QU3VHOEY4?=
 =?utf-8?B?Zlk0Z25Ubk9VOVpkWWxTQzFHcjM3eHJVZlgyaHhZampJSXA2MDVCdU9tNUhC?=
 =?utf-8?B?TkxVaUozRm5TRm05WGJIaE90SU4zblNLeWViTHRVSStrVXVGWmtEWEhZOFJm?=
 =?utf-8?B?ejJNYy9VVjFrd1gxL0xPa3VwMmNMbFJyNlRpUEpnZWdzcUo5TXJzb1hwMVBk?=
 =?utf-8?B?VVpzeDVTc0IrdTFQSmdDN0MwbklkN2FVRjZlYU1pYlpRbVI5b3FXR3FLS2FB?=
 =?utf-8?B?QzZmU3NJdDUxalljN2xiTmR3SXd1c01Jdy9JWW84TkVCMjBrQndNQkk0YTVa?=
 =?utf-8?B?UFNjaC9zSmZvWlQrUDg0L09JcE41ekd0a1Q2V2dlQ0M5R1JFeUR1YVhjcGt2?=
 =?utf-8?B?V1FoNkszM2RXVWdkdzlONVBqYmVkL2c5blhwRkhsSEhnbVFvT1Uvak9kbk9E?=
 =?utf-8?B?K2VKc2Z1Nkp6KzdzbXRZZ1VmT2ZvYW45VVF6bGVFRXhBdE1pZG5BSE4vSHN6?=
 =?utf-8?B?Z2JXeVhwZ01UVnh2YzYwNjFmNmRRNFhrRk1zVTlaeEdYK1VqOENtTHdSaFA3?=
 =?utf-8?B?Q1VXU0cvWUdsSGFvRUw0V1VBcXhFKzQ3blFMLzBDdHlSdU15ODhUa2txVmk3?=
 =?utf-8?B?TnBqSFIyMHp4TkZjcW1tWjhyRkU1cUdGWDZaZUdJdFF3N28zR011Y1RaaVpl?=
 =?utf-8?B?MlprRStPNUs1S01nY3diRnRyUzh4Z1lrOWNFbmZmNTZrNzRKN3VIMjBhSXFK?=
 =?utf-8?B?aU1ydzJNdWpEalNRMnhTM01kempnNFVJUFI2WEpBUy9Nc0svMjI3ZmFCbXZy?=
 =?utf-8?B?QkcycXhXSlZScnlxWVRUWm5LRnZ6UmJEdzRXbUkxTSs2cVdnVmJ4alZFSVV1?=
 =?utf-8?B?RkJWcTJRQ3NXcFYvcVJwYVVFMXlseld6OXg1KzNLa3pKMlROKzY2K0hxK2hi?=
 =?utf-8?B?elB6d0VYZmFUQUFlS0NTeTJMVzJQVm9IcjVpZ0lUM081M2ZyOEVXVWtkQWFy?=
 =?utf-8?B?TVlXN2UvZ1E3KytQVDdDWXZpUEhkMktZR3JMOWQzWm1HSnMvUTI4MUZ0WWtN?=
 =?utf-8?B?V09KSnlkNGNyZ3lBTGdaSnZUdkFqYXpVY2dMQ043NW15cGlXQ2hCTnZjdVY3?=
 =?utf-8?B?Zzg0cE9TWXNaMFQ5Y1pKRkNSVUJscEZvWUllb1JPVlhqUlM3Nm8zaCtaRmRD?=
 =?utf-8?B?b2FJS1llTnRhZ2RpZWpwVkl4cytaMFBJZENwRUpmQ2xnakJCQzNaNDRkMHRP?=
 =?utf-8?B?aHlNK0NwL05ldmR4eFU1enJheHVyQXovTWxOMi9KQjZBQnFnRkhsL2xubGxY?=
 =?utf-8?B?bjVWUjRWSmVqNjVDc2ZyRW1aV3phbTJFWFFyRDNIQzJJZ05pVmJmNkI3T3lF?=
 =?utf-8?B?eFZtTUZGN2N2Q1VXcXcyK21QNkJWdFQvOWFWTmdoTWs3amwzYWZQRUN0a05j?=
 =?utf-8?B?NnJxRm5ERVR6dFFLK0VXakdwZzR0UDFyUE45WFRVWFZScjFHdTZiSTh2OWFQ?=
 =?utf-8?B?VFE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 47dd3d3f-4f21-4e0f-9640-08dc20d77788
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB8718.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2024 14:34:57.6406
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: BtNKmm5XS0NtsYl0o7AcsSShSviygxmt+OEJo+MKsT9BicYlBUhSC74mPuxPIKZ/RuR5td17NIGd3zsJBRzLCIuADntGLYWClNtFmSgdbnc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8521
X-OriginatorOrg: intel.com

From: Robin Murphy <robin.murphy@arm.com>
Date: Mon, 29 Jan 2024 14:29:43 +0000

> On 2024-01-29 2:07 pm, Alexander Lobakin wrote:
>> From: Alexander Lobakin <aleksander.lobakin@intel.com>
>> Date: Fri, 26 Jan 2024 17:45:11 +0100
>>
>>> From: Robin Murphy <robin.murphy@arm.com>
>>> Date: Fri, 26 Jan 2024 15:48:54 +0000
>>>
>>>> On 26/01/2024 1:54 pm, Alexander Lobakin wrote:
>>>>> From: Eric Dumazet <edumazet@google.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!
>>
>> BTW, this implies such hotpath check:
>>
>>     if (dev->dma_skip_sync && !READ_ONCE(dev->dma_uses_io_tlb))
>>         // ...
>>
>> This seems less effective than just resetting dma_skip_sync on first
>> allocation.
> 
> Well, my point is not to have a dma_skip_sync at all; I'm suggesting the
> check would be:
> 
>     if (dev_is_dma_coherent(dev) && dev_uses_io_tlb(dev))
>         ...

Aaah, okay, but what about dma_map_ops?
It would then become:

	if ((!dev->dma_ops ||
	     (!dev->dma_ops->sync_single_for_device &&
	      !dev->dma_ops->sync_single_for_cpu)) ||
	     (dev->dma_ops->flags & DMA_F_SKIP_SYNC)) &&
	    dev_is_dma_coherent(dev) && !dev_uses_io_tlb(dev))
		dma_sync_ ...

Quite a lot and everything except dev_uses_io_tlb() is known at device
probing time, that's why I decided to cache the result into a new flag...

> 
> where on the platform which cares about this most, that first condition
> is a compile-time constant (and as implied, the second would want to be
> similarly wrapped for !SWIOTLB configs).
> 
> Thanks,
> Robin.

Thanks,
Olek