From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3ED63A0C45; Wed, 1 Sep 2021 15:26:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C406C4013F; Wed, 1 Sep 2021 15:26:15 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 6436640041 for ; Wed, 1 Sep 2021 15:26:13 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10093"; a="205874848" X-IronPort-AV: E=Sophos;i="5.84,369,1620716400"; d="scan'208";a="205874848" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2021 06:26:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,369,1620716400"; d="scan'208";a="446571960" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga002.jf.intel.com with ESMTP; 01 Sep 2021 06:26:11 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 1 Sep 2021 06:26:10 -0700 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 1 Sep 2021 06:26:10 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 1 Sep 2021 06:26:10 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.176) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Wed, 1 Sep 2021 06:26:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hW3Vm+J1ErEUjF8MhY+prbFoIyOo8gkIvZEI4eusFby5oPlvQeq8z9BPfiqmpvfiJYjZy1dIy4/QZeUL70NdnzUyEEzp2RdSj8TVHyes/eAHPHuQxlgOOtnZ43/pdfnJFpNw7Kj81rqh/u7osKPt0+x7fIpojM3rTxQU2INqIi0opDfaKH2zmMzmRPUdDt5c1CHe+X9TtRFIo/dCjQexT0BIYiCviLwjwqMfB4Joy8jyDiep+DouyHQFLJi2m0sAvXYA95baYRxxixzF/hHRxfZ7vD+VBNcV7KTn7u9B4CbH+1zWCbsbM/xFK4VV7L/eA9niQ+kwUXEr8u6IwHJStQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=62BSyN4CqrxouxZWueWuVfjTj5wsNyn3XQG6oBaCf0g=; b=gvuN2X9QqZGLOyaEm5yt6vLFVrxqeuVfX4Ex6zbw26juOd87dzz8b2dScRqrKIG3G6YPpxW3SikAPn4/rbojsWYgzy6jyOu0EQvmSAgjpfCZ7jSwuT+UaGhJ58EaVZgP1Wu3yGrQdno7KvFIBdCQ1/BgyWkt4VyfnkU5GJdCnCZ7w1uPaVlIcixG6ey44gZo8kgTd2z8CVHbD5REDhyAR21jFam41oIFnWNB9r7JC4akNEDZ95NxO2tmNelfOg0g7zOlxdq4Hjh3lC8HIhPvOXHkzIyaQBkorPiBCV2kGxTG5G7x8e8wlMYUlYQCIBfFDuUbz3mGUnShd9FnyCIN6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=62BSyN4CqrxouxZWueWuVfjTj5wsNyn3XQG6oBaCf0g=; b=XYLvtG5cmoQ560QDZMVcgT4d5vJSieIrHU6oXeoBA0Rpt1mUAfhLqDPzH6/VyUw+XpdljJ6ttzuCx1zGwGz9Lm+vo8cy7oXR2oSjm/CLRhhEH2iDIcWJ1PFnFGJp8aPXK7lXf3hctVGsdHtI+gx+KZLpBqDun/vnwYgAYTnBQlI= Authentication-Results: ashroe.eu; dkim=none (message not signed) header.d=none;ashroe.eu; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) by PH0PR11MB4984.namprd11.prod.outlook.com (2603:10b6:510:34::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.24; Wed, 1 Sep 2021 13:26:00 +0000 Received: from PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::d145:710a:1bac:7e91]) by PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::d145:710a:1bac:7e91%8]) with mapi id 15.20.4478.020; Wed, 1 Sep 2021 13:26:00 +0000 To: Ferruh Yigit , "Ding, Xuan" , "dev@dpdk.org" CC: "maxime.coquelin@redhat.com" , "Xia, Chenbo" , "Hu, Jiayu" , "Richardson, Bruce" , Thomas Monjalon , "Ray Kinsella" References: <20210831131039.29964-1-xuan.ding@intel.com> <2c9fc397-df61-2ef6-0cce-db5dbbb1c952@intel.com> <926d7065-481f-b84e-1d05-bdeebd31d6ea@intel.com> <032e666a-9ada-f4c0-36bc-ad9b5fac4359@intel.com> <8779d165-6e98-a294-9f4b-a6ce76d9c77a@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Wed, 1 Sep 2021 14:25:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.13.0 In-Reply-To: <8779d165-6e98-a294-9f4b-a6ce76d9c77a@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB6PR0402CA0017.eurprd04.prod.outlook.com (2603:10a6:4:91::27) To PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) MIME-Version: 1.0 Received: from [192.168.1.12] (212.17.34.161) by DB6PR0402CA0017.eurprd04.prod.outlook.com (2603:10a6:4:91::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Wed, 1 Sep 2021 13:25:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bb4c68ac-f83b-43a7-f622-08d96d4c0a23 X-MS-TrafficTypeDiagnostic: PH0PR11MB4984: X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5236; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Jut0ycp092e6abzD9kSCs/pdh7RMH1zWubY74z2hL/NI5BGBU4bzZOqwc0vsIe+Q4r1CzzK5cPw8gU7Uw8q/+bXuIDs7XMtiI+eIQZoVA1HNqz/vjLmehVBDi6tt5CdR6WceXdISc6h5N7sd7gi8D5wDu0JN0xWE89xhNMhHCNZXt5Zc483SHSVN6zTzphlblWBQTR6hZ+JT+G1gK3PmoXBvsbg+Igro5VmwRFo+ho3LwIIiANcX800UP89HoPROLBzUt7yR9oRYOIEm4vxNdhVPew+1WOj7HcZ215V4h+p1dIIOHUDCIyDSDpiwHDjtcZTJVA0BIIoyLI0eOzx2MNPnQ55iHGxQfO+oKaqDhtC+fESGgYFtMzsWRdNFJGYftk4ieo2H3px/dxbVv0iwwn0CNFn+AnZI1Ir/rTt2W2zFWxF0NAKyOvnBqVDrHrZJWIovW4T2v+vWZRtIq8GZKtvQ29Xdb5YZ4gmlb9aTaTnBwtboVlQDp8KAeBmSjm694lPKb3jdEkzBNhbrY18eNlRswPqxom5/sb5H0WPcgdEmKsig6yPx70kCOTbmL8y36sbJqAoUmkckLBzKImHtF9IFBYN0MFXaZXQFWrzdf5kOkIAVrSuQNC4T/caAc+2Hd9ghtYmm5Uhop3Sub+JKT502tq1/ACKV+Hygr6jd3BsobyIG/AqG76LsOjhOEhkd5wCxjMXpLKrLVd0NcqSsd3scrJNr16YZtL2Lnr9Abse+IV3+TAAllYdJod/dRj1bq+sCipO/RIRztWxaPNPzWUctGWV7M+uYrK4tO+nhUxHTp7mJwEpE8cRHX33tKGEA X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5093.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(39860400002)(396003)(136003)(376002)(26005)(38100700002)(2616005)(86362001)(53546011)(478600001)(36756003)(8676002)(31686004)(956004)(186003)(966005)(8936002)(110136005)(2906002)(316002)(31696002)(6666004)(54906003)(66556008)(4326008)(5660300002)(6486002)(66946007)(83380400001)(66476007)(16576012)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OGhPR0JPS2phYlNBWUFYd1NRREcrY1BCTC8yNmV3Yk5MR04yK20zckpwMks3?= =?utf-8?B?OFI5c2lNQk15MktUc2orVThZMzlDc2JqalZWdUFkcmVYamh3MTJsNDRQSGtn?= =?utf-8?B?NVpOSlhYWEpwRjJTbUNZODFqdGl6L3QzTkZqQjNNOGN3SytZamhCQmVCbWNl?= =?utf-8?B?YWpkZ1RadllROXRSQ1grNVNvbXRKMFVUemFZc1d2NWNraFI3UVg3MzBHYU5j?= =?utf-8?B?bzVuZzdrREo3bVMxY2VzZHBkblRQTUVOdW0ycDlPWnlYS0V6c0xIVlZZbVhs?= =?utf-8?B?NXAwT2JrSGtYa0w4M1g2eDM2b29STXhiUE52akwxV2RLTFRqMzZINTY2cWRC?= =?utf-8?B?U0NoMWk1VWpjM2lTTEVQVWxVb1E5dWs5NlJsOEt1dzZzTUJJS3RINmNpNWdU?= =?utf-8?B?bXRPUW9PSFJuR3l2OWFFdHNYYTlqNGRMbjJid0pwVzF2Y04xdkRXNDJsMTRX?= =?utf-8?B?cVFQSk4wV1VuWGsyTDFVcTBFRE5lSllTQVZXL1dkYk5OaUtrNFovVkRIMkpu?= =?utf-8?B?Mi9kZEJwUFd0bU15MEpIK1hmMVFyMTArMG9sd0luNFpjMU9MbzVuUkJtZ0Ex?= =?utf-8?B?K1lnUGw0SVV6WTh0dUZuOStSdUdSQ1BEeU9lcTZGVDg3cXZPREVJWGtCaXFr?= =?utf-8?B?ZldUWTVTd0owL2FhOU9NOHk3STNPblQ0a1FweC9TZ3FnaXBNRVFkV1dIbjdH?= =?utf-8?B?MGlEYktXaTlFbVRBT1BTOEovS1FVOFVaTi9EbVBvRUJ0bFZsRjVDOG1yQlRG?= =?utf-8?B?WnBPZGNZU2thdjBXSkJCWTVhVE9KVkFPNElYV2dkcENIWktwT1VNMXd1Q1pH?= =?utf-8?B?aU0yUUZxMGdWVENkb1hISVY0N083MmwyaUxUVjBwbDRXeVJXSm9FTVN0VXAv?= =?utf-8?B?bk9PYW4zN3dKSE95WUxlWk81QWVwZmVIaExMOXpzRGtUNURYMWF4MzlIbWwv?= =?utf-8?B?ZkZpblBrUTZJL2kvWTB1cmZ3SmoxVktRaklPUnVzRWpZZGhCUGtSejZlS0Fu?= =?utf-8?B?SkR1c3Y3RDN0TnU1VlI1b0N2UXJZUUo3ZkJXYjRndHNFK3Zobmpid2F6b1Vx?= =?utf-8?B?Nmc3OFIrT0t1OUFwMzV6N2xYUVE1N3BnYzV1TnE2b3dGOXZLc2dMSDQzMlh6?= =?utf-8?B?aWhWSjNNZlNweGZqelBOS2RQZjhveXZkWHY1RUNIMWxSUUhlRm1NZFJtL3kz?= =?utf-8?B?TWhWTFp3dVZlQ1pEWHlWMWoyaHA0ZGhDdVQwREUzNzV4WDExOE9YNkVzUFl4?= =?utf-8?B?bEp2Wi9FTFUwdjA3bHpMdlVlTzVzQVBZYnp6eWNaR0ZGYmRROCt0K0RMOWRF?= =?utf-8?B?aVowOVdoWnhxRjRaditYaEtLMGlYbHB2eWZZUkpVcExZRk9vdWxuSVQ5U0Js?= =?utf-8?B?K1hOY1lSdXgvaWpRNXVRZjQvTDhjS1FzcEN0REhuR2dEKzFrRldLRmllZ3Ru?= =?utf-8?B?ZC8rNThRQTEzakNZSVNnYThKZnNZMkFkdkd0YnhMbkFsR3c1TUY0cEhuajlV?= =?utf-8?B?WW1jUlBaM1lGd2ljNHhaZGVWRUJpcW0zcEFaWEFpbXJpS1ZVMVk1N0RTOEY1?= =?utf-8?B?WVVVSnB0OHJQNXpMdzFqTTVITkVlRXdxQUVEUlhMRjJtaThsL1JhMkRlWEl3?= =?utf-8?B?Z1NzbEUrdXgwZ0U4cm5od3oxT1VlNmRZWktIdlZVbTNOb1FPY0FsVzA1VXN0?= =?utf-8?B?bnphZUhYbStXS0UwSjVTYkNzMWlNMXBSVkxLZGxLaVZlbzF5TlFFR2F3aHpG?= =?utf-8?Q?elfZ0eII5bsxpIwzrVc8EEgTbFwKdNMRbWU77PC?= X-MS-Exchange-CrossTenant-Network-Message-Id: bb4c68ac-f83b-43a7-f622-08d96d4c0a23 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5093.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2021 13:26:00.6200 (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: p2yvAWuP8MfkL/FWwW092lckzIza8NW0VwJ6FqTi29TC/g5vRet1/hOTQNMc33SNZxoiWZApiu3MHTJnw9oP65yPxTopZ9qqnCyHptNRQ/I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4984 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] doc: announce change in vfio dma mapping X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 01-Sep-21 12:42 PM, Ferruh Yigit wrote: > On 9/1/2021 12:01 PM, Burakov, Anatoly wrote: >> On 01-Sep-21 10:56 AM, Ferruh Yigit wrote: >>> On 9/1/2021 2:41 AM, Ding, Xuan wrote: >>>> Hi Ferruh, >>>> >>>>> -----Original Message----- >>>>> From: Yigit, Ferruh >>>>> Sent: Wednesday, September 1, 2021 12:01 AM >>>>> To: Ding, Xuan ; dev@dpdk.org; Burakov, Anatoly >>>>> >>>>> Cc: maxime.coquelin@redhat.com; Xia, Chenbo ; Hu, >>>>> Jiayu ; Richardson, Bruce >>>>> Subject: Re: [PATCH] doc: announce change in vfio dma mapping >>>>> >>>>> On 8/31/2021 2:10 PM, Xuan Ding wrote: >>>>>> Currently, the VFIO subsystem will compact adjacent DMA regions for the >>>>>> purposes of saving space in the internal list of mappings. This has a >>>>>> side effect of compacting two separate mappings that just happen to be >>>>>> adjacent in memory. Since VFIO implementation on IA platforms also does >>>>>> not allow partial unmapping of memory mapped for DMA, the current >>>>> DPDK >>>>>> VFIO implementation will prevent unmapping of accidentally adjacent >>>>>> maps even though it could have been unmapped [1]. >>>>>> >>>>>> The proper fix for this issue is to change the VFIO DMA mapping API to >>>>>> also include page size, and always map memory page-by-page. >>>>>> >>>>>> [1] https://mails.dpdk.org/archives/dev/2021-July/213493.html >>>>>> >>>>>> Signed-off-by: Xuan Ding >>>>>> --- >>>>>>   doc/guides/rel_notes/deprecation.rst | 3 +++ >>>>>>   1 file changed, 3 insertions(+) >>>>>> >>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst >>>>> b/doc/guides/rel_notes/deprecation.rst >>>>>> index 76a4abfd6b..1234420caf 100644 >>>>>> --- a/doc/guides/rel_notes/deprecation.rst >>>>>> +++ b/doc/guides/rel_notes/deprecation.rst >>>>>> @@ -287,3 +287,6 @@ Deprecation Notices >>>>>>     reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and >>>>> other >>>>>>     information from the crypto/security operation. This field will be used to >>>>>>     communicate events such as soft expiry with IPsec in lookaside mode. >>>>>> + >>>>>> +* vfio: the functions `rte_vfio_container_dma_map` will be amended to >>>>>> +  include page size. This change is targeted for DPDK 22.02. >>>>>> >>>>> >>>>> Is this means adding a new parameter to API? >>>>> If so this is an ABI/API break and we can't do this change in the 22.02. >>>> >>>> Our original plan is add a new parameter in order not to use a new function >>>> name, so you mean, any changes to the API can only be done in the LTS version? >>>> If so, we can only add a new API and retire the old one in 22.11. >>>> >>> >>> We can add a new API anytime. Adding new parameter to an existing API can be >>> done on the ABI break release. >> >> So, 22.11 then? >> > > Yes. > >>> >>> You can add the new API in this release, and start using it. >>> And mark the old API as deprecated in this release. This lets existing binaries >>> to keep using it, but app needs to switch to new API for compilation. >>> Old API can be removed on 22.11, and you will need a deprecation notice before >>> 22.11 for it. >>> >>> Is above plan works for you? >>> >> >> We have slightly rethought our approach, and the functionality that Xuan >> requires does not rely on this API. They can, for all intents and purposes, be >> considered unrelated issues. >> >> I still think it's a good idea to update the API that way, so I would like to do >> that, and if we have to wait until 22.11 to fix it, I'm OK with that. Since >> there no longer is any urgency here, it's acceptable to wait for the next LTS to >> break it. >> > > Got it. > > As far as I understand, main motivation in techboard decision was to prevent the > ABI break as much as possible (main reason of decision wasn't deprecation notice > being late). But if the correct thing to do is to rename the API (and break the > ABI), I don't see the benefit to wait one more year, it is just delaying the > impact and adding overhead to us. > I am for being pragmatic and doing the change in this release if API rename is > better option, perhaps we can visit the issue again in techboard. > > Can you please describe why renaming API is better option, comparing to adding > new API with new parameter? I take it you meant "why renaming API *isn't* a better option". The problem we're solving is that the API in question does not know about page sizes and thus can't map segments page-by-page. I mean I /guess/ we could have two API's (one paged, one not paged), but then we get into all kinds of hairy things about the API leaking the details of underlying platform. Bottom line: i like current API function name. It's concise, it's descriptive. It's only missing a parameter, which i would like to add. A rename has been suggested (deprecate old API, add new API with a different name, and with added parameter), but honestly, I don't see why we have to do that because this is predicated upon the assumption that we *can't* break ABI at all, under any circumstances. Can you please explain to me what is wrong with keeping a versioned symbol? Like, keep the old function around to keep ABI compatibility, but break the API compatibility for those who target 22.02 or later? That's what symbol versioning is *for*, is it not? -- Thanks, Anatoly