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 0A307A0C47; Thu, 2 Sep 2021 11:50:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B7CF240041; Thu, 2 Sep 2021 11:50:51 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id 41C8D4003C for ; Thu, 2 Sep 2021 11:50:50 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10094"; a="199283218" X-IronPort-AV: E=Sophos;i="5.84,372,1620716400"; d="scan'208";a="199283218" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2021 02:50:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,372,1620716400"; d="scan'208";a="532970343" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by FMSMGA003.fm.intel.com with ESMTP; 02 Sep 2021 02:50:17 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 2 Sep 2021 02:50:17 -0700 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 2 Sep 2021 02:50:16 -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.12 via Frontend Transport; Thu, 2 Sep 2021 02:50:16 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.102) 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; Thu, 2 Sep 2021 02:50:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l3Cfl8ReliyXcqiDpvootYOSZUs2Qib6g/z1jYLUZ3kXhbAJaIqpbl11G2zEAd87CR85B1atNCRaImceYdY8oEuDOEMUojG82ufeq7AoCjY2goMjbnCQc7pKOSk6I49lq3REtxYe05Z3WeRkkyZD+b4lfKyUk0i7hFfBYg/NLUUXD6R6NKukYBn3DiteL/1yWxKUgmyzE4iIg9AHAxpfF2GYVHuiH/53qJMBIOEVbW7mIej9gPG2gqcG0gOAOd5g3sF0q5fsBLuzGq+LlaI+zxTyXswghkaMn4Bw2dKRHXIa1FMi+jVXAzpOlYhVWALfR9kTKL3TX5SzBJfMUaLN7A== 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; bh=3snjuo2f2U78b5a25sp+SJkNeTORQb6DS09q9CF7dYI=; b=Q4PQMVr8EDANmW1w5BvkKKpnhnTF6/dqkxtgb280RzTr95IWjecQF+ERCxXmkzkHbvf4baTjLu1vNWFJdDSavkRgvatu0ozvuDkQDD8dSenxpaqMX4ClQ+ZJeBxe+mfxSr2FzTkcE10cIg59fcmlt6FZB16kHdN29S0JkQyJcTrOinqLbU9lK4C7a+NYDUC+Y9qQkp5ryqHSn/SA1ZZNe2dCa3e35S92OrZf7pm3Sy7+0gajve2Dz5zmg7tpDnNXQX/bQqn6Xs00iPIXYvsDrLNp1F6I37tgxpur+3S/zcnI7Mmef9ROQ1X0FZrOvqmyvb+5IGmnzlKs2RXVYb9gxw== 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=3snjuo2f2U78b5a25sp+SJkNeTORQb6DS09q9CF7dYI=; b=WpyZ+FrraAadY00XCPRdAW4a4auYJgwNNP+X1ysmkzwBRbPaNjk0wT2N4QGN76eTJNOAFTcsDjlUzcS5zZ2DV9z/tyVBoJaYnsRSDFDBpcXln6HGJZeQNxxKyu8/iv5iiUMDI+JD6B3ncxPdIH66ceTKf3QGznBya73QXEZb+z8= Authentication-Results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB4887.namprd11.prod.outlook.com (2603:10b6:510:30::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Thu, 2 Sep 2021 09:50:10 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc%5]) with mapi id 15.20.4478.020; Thu, 2 Sep 2021 09:50:10 +0000 To: "Burakov, Anatoly" , "Ding, Xuan" , "dev@dpdk.org" , Ray Kinsella CC: "maxime.coquelin@redhat.com" , "Xia, Chenbo" , "Hu, Jiayu" , "Richardson, Bruce" , Thomas Monjalon 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: Ferruh Yigit X-User: ferruhy Message-ID: <0998ae41-2c0d-c5f6-806c-50ccbcaf2139@intel.com> Date: Thu, 2 Sep 2021 10:50:03 +0100 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB6P195CA0017.EURP195.PROD.OUTLOOK.COM (2603:10a6:4:cb::27) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB6P195CA0017.EURP195.PROD.OUTLOOK.COM (2603:10a6:4:cb::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; Thu, 2 Sep 2021 09:50:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1413bd10-4011-4492-720a-08d96df70d57 X-MS-TrafficTypeDiagnostic: PH0PR11MB4887: 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: Ev6jFdpegFJJ4L1b3UBGMKCHl+f3hZgdRIMJvrvnjpTXwaSusP5WdNk51pSHR4v7bUW8uMkEUl4PWzvgsB663tx6B0UODfrH9x3shyKL4FoiMbsBuDtPt41RXYwPAiu8n2qAxiMushUdToaIjuShI3snt94tZ0HK9Ghr/H1uLiUPsmc2TtgEVxNsPVXqX9vbEtTdmbotviOa+HCBGKt7C9Efo/DTDTlmNvTt4s8Nn0AWjmp65jWst04It2fg0Hl6/wZcC7J2x+FJTv8s9ATnsBepkCo6sVsxxTwuiWEFzUFEIYDXDWRFesa1Xksb/tNv9VincHdVQbEcau1TrkqplcKYEoilgpSim2KcITbYzEwMxaJ4jlqlxfAdXZy72K1t+YiGGs5oUHGHfyycA2V0LGGwL5SopOCPt1WFenykWavHagN8h+tg38pryVC3vqVrkhfTZVDMgGivqQ6SCLx2GeFy3YRwoO34CWJNfk4/bV49LKsXkoMKZfwKgEpEIhFMoS5shpR6VwvZzTM+3bizc0S9IBGGko2SMyk25sHZq1g684ksVPwC3AYnh0SKv1mjM468dTqcq2ulzzBYjEd7L2qxTQ+9x9jLssNxjK+G4qmYPaLaV3zhpHQ3O6gUPWRFZSB5s/tNPZPs0jAhClUn++Lw8BydpvEz8j4Tzah3Adv5GkP8MIjftvlpcF4TT1CjKPuB3mENUOGw070UdLoHkaSzJnBaItaau/V6auno3Jn653D3+FRSzbuiEa/IWb6YfSOortWczeQxPUATPd6O9SaKduVjNywijDNR/3ZzGR4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(26005)(316002)(44832011)(86362001)(186003)(6666004)(16576012)(31686004)(66946007)(508600001)(2906002)(66556008)(66476007)(4326008)(53546011)(54906003)(8676002)(5660300002)(110136005)(38100700002)(966005)(6486002)(83380400001)(2616005)(956004)(8936002)(36756003)(31696002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZmViM3k0MzZtS2hBdGlBZ3B0VDRLOFcySzV6Tnh1VitxTW5UaXBveUtOSjFJ?= =?utf-8?B?UE1YZE4vZGZhWVBwRFdscmRteGhNM0dhRHJPZmVINXY3WHVqUWF0L0Uxb3Fv?= =?utf-8?B?TkdJUE1mclpPanp3OVJ3ZWdNWmJBS0QxdE4zZ08vdnQvbmhNVEltMkxabkVJ?= =?utf-8?B?SGFGK3hmQXU4RUJzSVk2L0hBSUJEUEVCbDI1NkhTbEU0b3RYQ1JzaTRvRGlr?= =?utf-8?B?WVFJM3VyRkdhT203d1FGVjFKcThxRkdoOXczK1V6a0pyMlRtMTFUeXJWSmJB?= =?utf-8?B?MjFUL1lDZm1OZkJQUjQ1Z3ZIZDJNTnBhMStHb25mTFc2QlA3cG8yNU93dGZX?= =?utf-8?B?OWdOaXNHM1ZmaW1OTnc5M2xIdmF5WGlkRWpjbWErMHA1Y09FN0lXNjdYUFdo?= =?utf-8?B?SCtBUW9DeEg1Z2FjTzErRUd5Y28xSnppSTE1Ymt0ZUxzcXQ1UU9NaUdLcE1n?= =?utf-8?B?bVhqeTBrTjJNeW84VFg0YkxLNW1yYkZkVHFuZ3A2T0hLUmVEaUE2S0VibjlF?= =?utf-8?B?NzNZaGVvRnQ4SENoRlFobXBpelYvVnV4MFRvcmdsRkx6TThBaXJZckVvN2Fv?= =?utf-8?B?MjI4RC9tdHlaeHo3bUdTc1NWOHJFb3lBN2xEanZCV29sY3RYbE00d29TdjdW?= =?utf-8?B?aUdxc0ZxUEQwV2pPVGhJNU84UmlycHdXREhVQTBlOElVVzA0NmVhZlV6dFNC?= =?utf-8?B?WmVKNytUZEhrc2tFeFRnbTZyVHM3L1cxWUJsNVJ1N04yYjZ1aHViUXAxdndO?= =?utf-8?B?UWFZTklyem9LUEkrdDlzaTZSbUhIMnJmTDVOeTdZQlZhR0RWNG44eDhOaDJo?= =?utf-8?B?UTU3aStYZU9Od1RFOW5rZGxjRitESnhnbzk4bXRxaENWaUZhajFxL0xaVVlN?= =?utf-8?B?Z3VCNENXZ0xIK2YwWmxRNlVzZnJPNGw0R1MxT2dEc0M3NUF0ampvc2dET2Y4?= =?utf-8?B?OVR2eFdPQVRhdm5iTmlEV2s0NW9mOUVEcHVleERGdW8xNkRRQ1VNMEtEQ1o3?= =?utf-8?B?YnR6NGRnVjhOc3lYZE5OOHRVaTRaUXh0WUJTcnF3VkhjbElFVVRab1N4Tzgy?= =?utf-8?B?azhoMkpKTXBMdnlnVkk3ZThsZWRtYUU0S0F5ajNldXYyYmhjS1ZYQUMxWmVk?= =?utf-8?B?SEZPNTl2QXpxTnJqbjRRbWs1NlFUOU1XbytGZzF0SnFIMHhIVndwaU9iS2lu?= =?utf-8?B?MUhpN1JvOTU4enZqcW5ldTlUKzhQOGRJb3k5UUxPVHhFK3piY2pYYkFTZ3I1?= =?utf-8?B?ajBjYlJ5ajhWZ1JFOEphK05ZbzF2VVpPVW43SlpVR3VFNGdSSGZOdStlT2po?= =?utf-8?B?bnhXYWp1SFV2SHcwV281ZFZ3bzJyc0RoYTdRZmxUQ2tmWHF4dlgxUm9TYjUz?= =?utf-8?B?YU5CWDFqczBjNUY1M0dCSEVJYnljdS9xNUtpODdLSmNxbjBiQ3RzZEQvWTlB?= =?utf-8?B?SVFqQzl2UnphbEp6TFBVQmNLYkY1RlFCRmk0Y0pEbGVXdksxaFJQRUpsNkdI?= =?utf-8?B?aTVlci90cnFZTUZOZzRVcTF3VGo5S0Nxc2JORDlPMTc2ODR2MTV0M2Y1SWtp?= =?utf-8?B?WnFNNnBjOVliSWxtZXVYMUpZZis4MWNHcnZwWWx4MENZYk5VZnZmWXRQWlNT?= =?utf-8?B?dytueVZDZHVOSGFEUUpFZXBCenVSQUZvR0RNMk85bTRsK2w1ejA4NE9kSjdU?= =?utf-8?B?WmhaQUF4SXpPak10em1uaXlJZGlsd0xFaEZ0RVpwTjV1ZzFRVXdONHdUNmRK?= =?utf-8?Q?XhwOipQuaqBs/zQubsdfxJRwxGF8GFkXk0L5tXN?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1413bd10-4011-4492-720a-08d96df70d57 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2021 09:50:09.9253 (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: XZ9uDPdhWTMaVUPdejg9alIp6FMYadCtDFtOF6cqzsEGXTwbJjxRmNjgL3FwhPXddPegZwgtbs94lGSvwvDINg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4887 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 9/1/2021 2:25 PM, Burakov, Anatoly wrote: > 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? > Nothing wrong with symbol versioning, indeed that is preferred way if it works for you, I didn't get that symbol versioning is planned. @Ray, Since symbol versioning is planned, ABI won't break, but API will change, can this change be done in this release without deprecation notice? Later we can have a deprecation notice to remove old symbol on 22.11. Thanks, ferruh