Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752833AbdHQPWX (ORCPT ); Thu, 17 Aug 2017 11:22:23 -0400 Received: from 8bytes.org ([81.169.241.247]:44782 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751620AbdHQPWW (ORCPT ); Thu, 17 Aug 2017 11:22:22 -0400 Date: Thu, 17 Aug 2017 17:22:20 +0200 From: Joerg Roedel To: Alex Williamson Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Suravee Suthikulpanit Subject: Re: [PATCH 00/13] Introduce IOMMU-API TLB Flushing Interface Message-ID: <20170817152220.GK16908@8bytes.org> References: <1502974596-23835-1-git-send-email-joro@8bytes.org> <20170817083520.3329c0ff@w520.home> <20170817144308.GI16908@8bytes.org> <20170817085407.3de4e755@w520.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170817085407.3de4e755@w520.home> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1463 Lines: 31 On Thu, Aug 17, 2017 at 08:54:07AM -0600, Alex Williamson wrote: > So _sync() does imply that they're slower, but iommu_map() does not > imply that a _flush() is required. One is a performance issue, the > other is an API usability issue. If the sync version is used > sub-optimally, it's a performance issue, not a correctness issue. If > the async version is used without an explicit flush, it's a correctness > issue. Therefore, I would lean towards making the asynchronous mode > explicit and providing good documentation and comments to steer > developers to the async version. I think it makes the API harder to > use incorrectly. I agree that it makes the API a bit more complicated to use. But that can be solved by documenting it and by converting the main users (for me that is VFIO and dma-iommu.c) of it to the unsynchronized interface, because people will look at existing users and just do what they do. Introducing _sync functions instead of _async ones also has the side-effect that it puts pressure on the maintainers of the code to convert it to the async interface, because they now see explicitly that they use the slow version and start looking for ways to make things faster. What I absolutly don't want is that the whole explicit TLB flushing of the IOMMU-API (as introduced in this patch-set) is considered some optional part of the API, as it would be when I just introduce _async versions of map/unmap/map_sg. Regards, Joerg