Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 22 Nov 2022 14:17:58 -0500
From:   Michal Kubiak <michal.kubiak@intel.com>
To:     Eric Dumazet <edumazet@google.com>
CC:     Joerg Roedel <joro@8bytes.org>,
        Robin Murphy <robin.murphy@arm.com>,
        "Will Deacon" <will@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        <netdev@vger.kernel.org>, Eric Dumazet <eric.dumazet@gmail.com>,
        <iommu@lists.linux.dev>, <maciej.fijalkowski@intel.com>,
        <magnus.karlsson@intel.com>
Subject: Re: [PATCH -next] iommu/dma: avoid expensive indirect calls for sync
 operations
Message-ID: <Y30gZm0mO4YNO85d@localhost.localdomain>
References: <20221112040452.644234-1-edumazet@google.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20221112040452.644234-1-edumazet@google.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Rz6+KCnr4p9kAK/H//UBnTCP0P9+Vi8P+cSOIu7rNqR3i2+8/5S7jlQC+xay?=
 =?us-ascii?Q?YHcJGoCoEU8Lt3xiMOEBprXcdJ/i9NNT3CqNm6CNP3g3nl2ZMRva2rGnssK/?=
 =?us-ascii?Q?LhLphup8b1MLWl1yfvcpw/NM0ZxH/VE1dgG/ypGwsqrQrpdnewi7T432ADDm?=
 =?us-ascii?Q?ylj5sRAiMKNDdy3EMeTbJVhBaSR+hZhQiI27Kfjj/gm2mVXyZ0eQ5VjAanOY?=
 =?us-ascii?Q?06Fq1RpnttT5bokUnGZt/1CUIxewtqWj2MI268Tgmzm94o6SNHX0ZjmwTJNm?=
 =?us-ascii?Q?PIPU/yqHGYGd86C/hmAA0E2/n4wu9ESCp96POhTkb1GnHjD7GnkV2/8mSqIB?=
 =?us-ascii?Q?1PdUE79ixgIhvH/Ow7VQre/YlGcLxnGfccTqoBpl4heb+yrMlm8ALS1+k676?=
 =?us-ascii?Q?G/zacgWGbOGmF76bkU2Bcy96x/8otIPtxtCS12n/ZxMZrB1NVwDr0YONq8pK?=
 =?us-ascii?Q?6aHkFQ7WeL3Ody7n1gro2B1Yr7dUQoJ7MO3JyHcAV1sHZjH/UrNZ9RTehNdq?=
 =?us-ascii?Q?Gzk1qs1O/tG6jvtEHZ3ISfEfq6Z0NA7zfBdy10AfpdxzOGyEB7fgAZxCiern?=
 =?us-ascii?Q?c0LS2qeEqgyKHrxiB/pMWtIvZfbWCP7Jo4iet9UeilcZGCQOCZSlT2uCWGJH?=
 =?us-ascii?Q?maUiyPAdG7bpHwzu+2J994ymxtipLHQtoUqKKNfiBdDWfj0qXleJAS5Zk47Z?=
 =?us-ascii?Q?Lo42gcvJXr57je1FPtrc+aQ2NtUjcINVcdWVnvUi9A+wvEQHx40YGC8fHM04?=
 =?us-ascii?Q?TtBBqy79UE1Osv8hmc7Z45TNwmrTkhA4zfFv6gN+lg7kLJwdshnk33ZmTz9N?=
 =?us-ascii?Q?V5DffKgV4733ZVvvCZL/xeyC5cdtcA7glSnMMjflyh6vhiKToJqaQuWr8zvE?=
 =?us-ascii?Q?no4LogJaKRiyIb7CjEEH2os5D7X4s1pSYBGZCEPAdbBD4lRa41ld2xG7Cct3?=
 =?us-ascii?Q?WAJFXwM4S8mj6Qi6eKKU7FxD2trPNZwI/7njW4LDXtLOne5ZFqKZyP7wNfdW?=
 =?us-ascii?Q?UqjSBQGzoQvRyQoug+k26VmWpkkl1oz/CHjfduf6DhKavVokEQdgmRDtpeM9?=
 =?us-ascii?Q?oX6qqtFHMQ/du+5XwTvF7xnEQVNDOaKhujAvN0tM944qIYIOA5RT3n0FyF8y?=
 =?us-ascii?Q?/Zf75n6XmlBci/UaFeYRLX+ltc6pBN4I3aKowzZTEZMRS40ikyb8uvYRBnCL?=
 =?us-ascii?Q?AzPymPYOaoGdE6RouZOHkcrkKU3Ox0L/vP80vZdCkWd61firM3ZhSt5o4Mo3?=
 =?us-ascii?Q?stubHNSOvQCWr9a8pkp3WPQPlEfxcoQtajWnZ1hAvstHDFeSV1FHHuejV3dQ?=
 =?us-ascii?Q?tMVhNZ/pr6qf0zeUhKnMF1qYusfNweO0cTA8+SH8Le1RGiTc6sKwBEvDBdqE?=
 =?us-ascii?Q?dyZJg5letxtESXjmYNdR1kA4DIlUPpblypCsoCqYl78mEd9Y3NJjQuaCmDJr?=
 =?us-ascii?Q?dYxy98b8M8K+kij61EJOfw+WHDiWpUB35NW+I3khDDJ5N06FLpAawg2+JiuH?=
 =?us-ascii?Q?ZImkEyh3e5Ji59Yl45HVsBZTSSvzvYJEAfPTO4eJ+YtAvPrLxJG0sQPC/dAd?=
 =?us-ascii?Q?aB2fH3T29lDKQ+Y3dH69nmd9v6PUVT2/0Esd1LysiiLfJdzsPMFiqMFJtx5/?=
 =?us-ascii?Q?CA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 4dfc55cb-f42c-4e28-ff0f-08daccbe4f45
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2937.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2022 19:18:17.3280
 (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: 7FxVjr3myvWHnTJrzMU5ZEwrdhem7ciCfFHkmGBo4pkgw6hKCp8KuHVzzgL083EOpVyExfOB+gttag4wN8YdWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4607
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Nov 12, 2022 at 04:04:52AM +0000, Eric Dumazet wrote:
> 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, as shown in [1]
> 
> Even if/when CONFIG_RETPOLINE is not set, there
> is a cost of about 3%.
> 
> This patch adds a copy of iommu_dma_ops structure,
> where sync_single_for_cpu, sync_single_for_device,
> sync_sg_for_cpu and sync_sg_for_device are unset.


Larysa from our team has found out this patch introduces also a
functional improvement for batch allocation in AF_XDP while iommmu is
turned on.
In 'xp_alloc_batch()' function there is a check if DMA needs a
synchronization. If so, batch allocation is not supported and we can
allocate only one buffer at a time.

The flag 'dma_need_sync' is being set according to the value returned by
the function 'dma_need_sync()' (from '/kernel/dma/mapping.c').
That function only checks if at least one of two DMA ops is defined:
'ops->sync_single_for_cpu' or 'ops->sync_single_for_device'.

> +static const struct dma_map_ops iommu_nosync_dma_ops = {
> +	iommu_dma_ops_common_fields
> +
> +	.sync_single_for_cpu	= NULL,
> +	.sync_single_for_device	= NULL,
> +	.sync_sg_for_cpu	= NULL,
> +	.sync_sg_for_device	= NULL,
> +};
> +#undef iommu_dma_ops_common_fields
> +
>  /*
>   * The IOMMU core code allocates the default DMA domain, which the underlying
>   * IOMMU driver needs to support via the dma-iommu layer.
> @@ -1586,7 +1612,8 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
>  	if (iommu_is_dma_domain(domain)) {
>  		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
>  			goto out_err;
> -		dev->dma_ops = &iommu_dma_ops;
> +		dev->dma_ops = dev_is_dma_sync_needed(dev) ?
> +				&iommu_dma_ops : &iommu_nosync_dma_ops;
>  	}
>  
>  	return;

 This code removes defining 'sync_*' DMA ops if they are not actually
 used. Thanks to that improvement the function 'dma_need_sync()' will
 always return more meaningful information if any DMA synchronization is
 actually needed for iommu.

 Together with Larysa we have applied that patch and we can confirm it
 helps for batch buffer allocation in AF_XDP ('xsk_buff_alloc_batch()'
 call) when iommu is enabled.