From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0065.outbound.protection.outlook.com [104.47.1.65]) by dpdk.org (Postfix) with ESMTP id CA85B7CEF for ; Fri, 2 Feb 2018 20:28:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LPar+3+faXh65OPDBY1iSaQjEC32OJmidIY9lu/0pAc=; b=rPEXmofy5E5qJPujLmWeAA1zdKFEtCbvCXTxGB5vkVsRq4mRnrbAC+m48+OZ79dafWLqHH21hyjDHkm29GFJYyoWBvmWyRJwFxF4d+r6rxYxd+SW4hCeUzrMDBjHU78jtzm1bvzG7V9wbHQ7DQzC6BNLE5VEOlOQAWb7BgC0CuM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by AM5PR0501MB2034.eurprd05.prod.outlook.com (2603:10a6:203:1a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Fri, 2 Feb 2018 19:28:45 +0000 Date: Fri, 2 Feb 2018 11:28:32 -0800 From: Yongseok Koh To: "Walker, Benjamin" Cc: "Burakov, Anatoly" , "dev@dpdk.org" , "thomas@monjalon.net" , "andras.kovacs@ericsson.com" , "Wiles, Keith" , "Richardson, Bruce" Message-ID: <20180202192832.GA42096@yongseok-MBP.local> References: <1513892309.2658.80.camel@intel.com> <1514308764.2658.93.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1514308764.2658.93.camel@intel.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: BN6PR16CA0023.namprd16.prod.outlook.com (2603:10b6:404:f5::33) To AM5PR0501MB2034.eurprd05.prod.outlook.com (2603:10a6:203:1a::20) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0f8f97a9-f1a2-4d7f-287b-08d56a732e06 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:AM5PR0501MB2034; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2034; 3:fNY/jTJllCN3MxVRzdIK1ghR/PbjPXsLrHMIVe7l6+ZcQDhRqmJc8igNa5T1uWWE480xy/chg8HTmDm/0nB4P5qwqMx+bFvZ1NfecNQw2R+qHp8aDFSjqSDZ2SPxREsNl74U0DpEAOkwWROgZZkLiMGOX4xIwF71XharNcx6FKEdteEduQdrvEFCOQUXoldCWTklZL0M8p0dpnK02PbITSM2JUVex6CAfdZyFZWeXaRLYFWg76DStpmK9+KOpUHa; 25:/qkEKPUfVQW8LUQteEO1yXOVDSpYt3Vj17rGTGb4kOxdi68LHla2v6FFtyKsW505Eod0aaiteEcBLQ/BIuxy0hiF2v7cByGK3a3E3yzyZ5rJwh4P0YKilKBnJ494uvDEx38uOWmbdwlxBaC/iHdPtWaLsWJteGwErEdYeQZFIeuOXVlAW2YKJq4iFdS3i0OxTUpbd6I+JmytYCpIrc1DyPJT1glsT1D+E1jsYIcXuCJwu/HbX3cw7zp3xrkWqYSIYqJ4lD5d8LaikBeouKNwwFjEmvn9cv1VGInqrA22TBcFFVERdtGDtBLbAEkHu1nq9d2hRfDtoaSIREvdPrvRFw==; 31:hLsV4embjLH+Pa2cNJ4VysxLMNcvw693UNpTjjPKp6uT6epLtd4jnXuMJNAjwEnJk9/2x+AwobDk7ZY2bIvR0z+zIjGcj9u4nqZDlnLrfBc00D7b71l3HEckw7WqJgM37YZ9UMxAcbUJmlmvQXfX4QphF8joivX38KME5NOJJsTiRZvFScuhJqvPwDOpgoTLkcg81Exd9qPBufvocCBCIieDxM0Zo9p0+KszM1BqEXk= X-MS-TrafficTypeDiagnostic: AM5PR0501MB2034: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2034; 20:Irle1i5AhnYq0gSLP+LraK7tBC37WZDbM5C+kWXW2jUlQccOpoFJnpoidB9ocky0XJLS5innnUxd78wFmrOMn9wrykHf7smQwiA7fZ8hvCKUL4zzWnMB9/kg4Rr600lBjDoMh1wwrFOjKz4rH6uk529ywjtkaUOrMnh2dOSvUuu3hVs6Clqld+5EfSoz5dyGqh+bLcMC+fiQ1BUjamUHPyjcZlo45zPlWWNXV3lILRvcSh3AqETOFfry1zRKDUuMVZeQfwDV9WtcNkLmMdizrr7zA1btUQPLd5CGxRnpnAYUeKKmWdHoBqMERDU4cF4elsnJfCCtB1zvSFOidmTeBAnKEaeUmyeHDO08tb1QEHr47+hOyxH3n4LeA12fZW4ElWIW+dCCLp9jMimECNOxRdIfdXwVwjI6I8Y7b0y5xsZsGwnTeN7H4mTEfwt6b1XN4X1eWPNgd3LyD0YAQOOGT2kD5viF0+5oVUD9f/QsdmSUO0vSVDSBQPS7/Ls+Pp3a; 4:20i11ctVnf5UPqnWNJBFHWbzidr+N+OczKzfbw5CXtWL0sJRuJtUyMpJRjv+8KppN7ELc9jJTgjWT7OjhwDa9MszTL2td34s9x+DGXtB5Mf689yoxEhaz8y/X2ca+MmdqyZ/Kn7aSyW3lM+kiN31C8hFq55jSf4mpJlR7buSkpsXVJAdA021n9MVUDhkCkeB7ShqTO2rPR7u5dBTxHFl8hknn2HN1cPy5kCCBpKrALKXZrd9fiE5sBEY3W5cAhBdPQ1dyj8wikyePQSWo+HupDGEC3Fwj5EQhP0hILSMQ0PtfAyW0NIlANl/lSAeIgVP X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6055026)(6041288)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:AM5PR0501MB2034; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2034; X-Forefront-PRVS: 05715BE7FD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39380400002)(396003)(39860400002)(366004)(377424004)(199004)(189003)(69234005)(9686003)(47776003)(83506002)(53936002)(106356001)(8936002)(50466002)(4001150100001)(86362001)(81156014)(81166006)(8676002)(6246003)(55016002)(2950100002)(6916009)(97736004)(6666003)(305945005)(7736002)(7696005)(52116002)(478600001)(76176011)(105586002)(68736007)(33896004)(59450400001)(53546011)(386003)(6506007)(93886005)(16526019)(186003)(4326008)(25786009)(551934003)(33656002)(316002)(98436002)(23726003)(1076002)(6116002)(58126008)(26005)(16586007)(54906003)(229853002)(2906002)(5660300001)(66066001)(3846002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2034; H:yongseok-MBP.local; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5PR0501MB2034; 23:dv25C5ev7V0cZ3IBiuI4i+5FgT5StLxkOdtJdqu?= =?us-ascii?Q?6Fnn/jsDEqjVTYIKeBJN5EGR34aIU57bXAcH5YHJ4a43zRW7HSL2L1FcCHoA?= =?us-ascii?Q?PQXQ9ESAIZVscV0jiO42QfzMIXIjU/yLNLedPgo3RUnnYFHfyz3AvR5yjsTa?= =?us-ascii?Q?jJ5zUfQGPUhSaTQg7B2A8Jw2/RohoxJhxZNYwnh03xFm2PQQqOEz+o4YrB9M?= =?us-ascii?Q?Q655uG15pNKDOdTVvQ8cKvBJbImD8sshZeQxfC6b1elCy5GYxWn3sDs+1gzi?= =?us-ascii?Q?z/A6ET5xCmewIIcMCWxMU9YtWF4esNLlhh70nyWUfSfuYWFQppAYyGSuy1VD?= =?us-ascii?Q?lk/uYdt7EXB4xHN5Nc1ut06NfEPZZWIozZeYdCqr2IjEvmv6Jt4QgLb3FZ/6?= =?us-ascii?Q?3UjHuQMUYjuIatCvAqS1f1lte4V0ll7jlYYhyJuTVPEtQ5LXpQ8Af1yTgdSu?= =?us-ascii?Q?T8nAAOQpuNLhuzwuOY/91cZrOD8H8Jf8+gMlnEJV10ILIIhMRq0plcUfNOrQ?= =?us-ascii?Q?Ttc1LZEsmbByc2KxxQmD2mAxWawhD2G4lrp1uOXMo5rXlOmx1aJmxXVqlgI+?= =?us-ascii?Q?RbQdT8yLyRHFtvqIUEwOWYFCarVMlo9SiQhqMZx4uL7TPHfNpJkhJJOpGMQg?= =?us-ascii?Q?nOA89Q11JTA44wv77HFiPzgxf0u3dgztKBjR0ZhnVm0w+nT2o4AiGJGJJ1gm?= =?us-ascii?Q?HiK0hVR5jxv7aA7V1/xHYynGI1m4qqkWDKyeM9005RTt1Vmhm8Etx9GGWckt?= =?us-ascii?Q?1Z0Qw8jraIfsJNBSronGEi+GJWwymS6081/BM0ou9LmQrGrraau3elbl9Bpo?= =?us-ascii?Q?0XBeGRIOC2RGTdUI34zBYL/d+jIwJVe1VhHmutyLfBkAXRSKlibuyEzX5WqT?= =?us-ascii?Q?HTjxwfEMHglP2WPKvoxSreW/EpUPpDiF1jPboE8EWkvWRKqKMWlQ4jDkzV9T?= =?us-ascii?Q?fk81R16XrmOfq2rlp3vU2eeQYi1BI6Up4KKa9M3BNHhmat8bOn7wpRGvRsjX?= =?us-ascii?Q?6uaJ8jgtxV3TBNAQk5HeuIsmsndqh7MqtmyKThPYxNS/M7jczXEhcVawlnFI?= =?us-ascii?Q?AtXRsVMigR6aDs0y78TMBr883D788H1eyuilCoLAt0UiIeUnqIk42myN1G0p?= =?us-ascii?Q?23k36+MZJfx0/PIThHrezTYESBfbw17JzxBU0P+DwIdHo9Ap29+x+EruOUpx?= =?us-ascii?Q?/kBh1l2e1D+DQX02U0VshsVScOsKYM9LKdzDUWSXYkC4N3r8k4O/jE0TA+pa?= =?us-ascii?Q?B4Bbq9Lr1y98X58GPJDyhmMGD7zVk6Ml32LfyGBBxJLQcyCBFiPbgbNUBJLB?= =?us-ascii?Q?guC4zigvQ58aT1PE8iJRpoyZ+XvFWWv1SVFRVnqiz0WmDK99js49OCM0b9Zz?= =?us-ascii?Q?K2hbr13zasaswVoM38EDsCkhOGpxj2dHjVequ87be+m8bunp9HFeSouWTTz/?= =?us-ascii?Q?hXL4jWI/TpoH9qZ83ccKGF9mAOfKhnjs=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0501MB2034; 6:RNKS9c5ZeP6AZJosPNXH8xol9pesV3ChPWNB26ecCThoipsPV07YHBZi8DO0HyAcImWNraynGpAoVcQRpvpLgyPZpGLxcTUGrGvyJTTSPqo+UUVmSYOWPuHMXvtwav+JFPSdOt8XXgteRWnkh9sZEUyuPnr6MYRotE/rrQ68vZVDfAazTC5gqxAd0wESs74QAbjijfZLh3znYERG4/c35OxERjTbR+0NSMS9DPYjM+RQXeiYJAWut240zpmTfK5LnGuWPuoUcjwioxpONyeq7U1iyQ+5WSq+24MGGb8y+zMctf3cewc1adzB0AbqNbtMwRIDHuBTPIGFxO7ytjYxiFJwNjVPWniSDSysCkSNaRQ=; 5:XfkUlAInk5KwAWqcv54l0RxeoQAWJJlojwwDYLkSHZVwkniqGof8rsNyXuxSbXbOfAjb+TU6XgnLYcp91ApHycFQaAuux7dO67ko3zGv6wc/kPyojyiUEwdBGyhbIxP4dcbZ3qa46SsimEKi2Xjh1HXj5+Qn8czH4a48Va5/JyI=; 24:KOWodb6Fjudd1Kz8AATEdpPOUqEKustEbLrROy/8pxNejlADE8L3//ERPzIwK6aipo+6Qr9g1vKuMF4r0mpVLi/7TCORtqEsiIpr7RJrBo0=; 7:uiAVYMbd3/wEp/0m6idJId6wGnCuZkFMGR75cbMlgbPXdd+HGYfgiOnHE7NL+t2U3OZz2mgJvrDut/tw2jNccHbpRrx8xtjHn0BeVKze04cbetmprJOD9UWJL0Wyr7GZMjYH+fi64l5v49ONW+EJwqWl6y760Z38c1yxdStlD/WddJgK6xwLfWKKM3pI+h6K7giTZ4IXFjfE5CyakeXfKa2GSu/7/iuDLUSoEBJYhNkD/LjiyBnL05lhCXt0t/ta SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2018 19:28:45.4825 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f8f97a9-f1a2-4d7f-287b-08d56a732e06 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0501MB2034 Subject: Re: [dpdk-dev] [RFC v2 00/23] Dynamic memory allocation for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 19:28:50 -0000 On Tue, Dec 26, 2017 at 05:19:25PM +0000, Walker, Benjamin wrote: > On Fri, 2017-12-22 at 09:13 +0000, Burakov, Anatoly wrote: > > On 21-Dec-17 9:38 PM, Walker, Benjamin wrote: > > > SPDK will need some way to register for a notification when pages are > > > allocated > > > or freed. For storage, the number of requests per second is (relative to > > > networking) fairly small (hundreds of thousands per second in a traditional > > > block storage stack, or a few million per second with SPDK). Given that, we > > > can > > > afford to do a dynamic lookup from va to pa/iova on each request in order to > > > greatly simplify our APIs (users can just pass pointers around instead of > > > mbufs). DPDK has a way to lookup the pa from a given va, but it does so by > > > scanning /proc/self/pagemap and is very slow. SPDK instead handles this by > > > implementing a lookup table of va to pa/iova which we populate by scanning > > > through the DPDK memory segments at start up, so the lookup in our table is > > > sufficiently fast for storage use cases. If the list of memory segments > > > changes, > > > we need to know about it in order to update our map. > > > > Hi Benjamin, > > > > So, in other words, we need callbacks on alloa/free. What information > > would SPDK need when receiving this notification? Since we can't really > > know in advance how many pages we allocate (it may be one, it may be a > > thousand) and they no longer are guaranteed to be contiguous, would a > > per-page callback be OK? Alternatively, we could have one callback per > > operation, but only provide VA and size of allocated memory, while > > leaving everything else to the user. I do add a virt2memseg() function > > which would allow you to look up segment physical addresses easier, so > > you won't have to manually scan memseg lists to get IOVA for a given VA. > > > > Thanks for your feedback and suggestions! > > Yes - callbacks on alloc/free would be perfect. Ideally for us we want one > callback per virtual memory region allocated, plus a function we can call to > find the physical addresses/page break points on that virtual region. The > function that finds the physical addresses does not have to be efficient - we'll > just call that once when the new region is allocated and store the results in a > fast lookup table. One call per virtual region is better for us than one call > per physical page because we're actually keeping multiple different types of > memory address translation tables in SPDK. One translates from va to pa/iova, so > for this one we need to break this up into physical pages and it doesn't matter > if you do one call per virtual region or one per physical page. However another > one translates from va to RDMA lkey, so it is much more efficient if we can > register large virtual regions in a single call. Another yes to callbacks. Like Benjamin mentioned about RDMA, MLX PMD has to look up LKEY per each packet DMA. Let me briefly explain about this for your understanding. For security reason, we don't allow application initiates a DMA transaction with unknown random physical addresses. Instead, va-to-pa mapping (we call it Memory Region) should be pre-registered and LKEY is the index of the translation entry registered in device. With the current static memory model, it is easy to manage because v-p mapping is unchanged over time. But if it becomes dynamic, MLX PMD should get notified with the event to register/un-regsiter Memory Region. For MLX PMD, it is also enough to get one notification per allocation/free of a virutal memory region. It shouldn't necessarily be a per-page call like Benjamin mentioned because PA of region doesn't need to be contiguous for registration. But it doesn't need to know about physical address of the region (I'm not saying it is unnecessary, but just FYI :-). Thanks, Yongseok