From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0068.outbound.protection.outlook.com [104.47.42.68]) by dpdk.org (Postfix) with ESMTP id A6C323798 for ; Tue, 5 Sep 2017 10:11:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v+zInFPGupRFJoLcw/KdctEDJflTgbNmeM4Tux8t7eQ=; b=kli4pek+v6QS0U4We+EECaZiUms1JAiuvwQHLzO+xv++bLqEcSXuW7YJyx5jxSHgBzSaH6QJyzi5yDFbMolQCRUnz0pBY/GniuHytAIIZX72wHJ+FzrSkoPrZaiwcsjnafGwaDDt8uGIqxlYLr00I4T6Bfi9yuBKSTu/foV8SUw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (14.140.2.178) by CO2PR07MB2520.namprd07.prod.outlook.com (10.166.201.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 5 Sep 2017 08:11:23 +0000 Date: Tue, 5 Sep 2017 13:41:03 +0530 From: Jerin Jacob To: Olivier MATZ Cc: Sergio Gonzalez Monroy , Santosh Shukla , dev@dpdk.org, thomas@monjalon.net, hemant.agrawal@nxp.com Message-ID: <20170905081101.GA20899@jerin> References: <20170720070613.18211-2-santosh.shukla@caviumnetworks.com> <20170815080717.9413-1-santosh.shukla@caviumnetworks.com> <5724dc82-952a-8ca5-2f99-f463a54ec07d@intel.com> <20170904133437.ym3cd7n3dswt4yjb@neon> <1b3482e9-7e49-5f15-afc9-56c0c098c1ab@intel.com> <20170905074724.lmo3xitraq4cxwg2@neon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170905074724.lmo3xitraq4cxwg2@neon> User-Agent: Mutt/1.9.0 (2017-09-02) X-Originating-IP: [14.140.2.178] X-ClientProxiedBy: BMXPR01CA0047.INDPRD01.PROD.OUTLOOK.COM (10.174.214.33) To CO2PR07MB2520.namprd07.prod.outlook.com (10.166.201.7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bdddd64b-de2a-44ce-1d81-08d4f435b4b4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR07MB2520; X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2520; 3:FpX9ETtsRmzjNpDruqIJbUy7gfHixvjbIFboJ/h5SbWkbyWAT6E2D2GoUAYX5RaQahjtICBHVMR0gxR9d9J8V4RZKFyDipI3YkLvORTCTQxDnKtVVHm87oIWU/3VwdLn6YO00lt86c13O1RzEViUW2v3kPuytBWuwo3ZG/QoVmY5UeSho60YhpBaklylRRhbS4BUblfgRMBtpxhzHWsX+Kdst2L8+OtSVWqqOSrotfY03kttjNx0cROhsFvvrIoY; 25:xxF0Q0EHyJA2tjN+JnB7d5iiguvFxraeKBVimS3iR4HOWk2AG4cFkirY9x1YhvpN6XbCCsgbUFbCi5O4ntCwfQYPzuecTDDExaCz7sKMUjWXV8eHKXzaccCEoZ0jllEPkw7GmzXqnVN/RFathPRA9yCdmIyF8v9odOWTi0FzFL9Ogoo9MLpf4WJNhMRZUD0EV9/wKHkQ/9E0uY8kRUEXS2ZYp4q15DshnGDuo8RcfS6LrzwcqTNTiXIcUaLtSrZS4tJx9J/etyoT5Noku6kqVNfMfBqex9KFJdRNLiodoT37dDuTEe0dxzpU1mnN2DvnldFJ38RJT0VxEX9pOp4mOA==; 31:c2Lo4Z4zRqsiG9i/MfI7y/ogYKdMlCr6KDq5y+AmS1Y/k3wAIEwKwstuIKNZo1U4Bcy2ADSh9Rd+fgsSXN6epAz46IRWzFAoqrHDo2Vv95HGeX0g9RlpRmJ/KBpDB1XMTTHd7xcvaPivvBZWph6Zf14LW0CTv1v7m46Cyu68Oc9bF3YhW+Lx9aoDA5lKoitnDmmWwq9lU7EFbd513m9IpGQDTZb7b17ExWrFvpNajB0= X-MS-TrafficTypeDiagnostic: CO2PR07MB2520: X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2520; 20:4UIIOWwwxETg/PukzPujyXtIm/LqCWyt+mNh5F/oSYn6uvq/QU4g6+wUyW8jLO6EGwpjdjUKeJ3vrkPfu58SxZHid321GLV8rIrHv5nED6a6PslD3/+qYlgIwg7d5k9KWduwAyhVojbMbAWsch8STvB31DmP5sKN0ikUP/9QuXRU+4jjOd84NJdvot6+KMmSo2HkiXD1pKosNlZrbQJklqzY2+LTcxGZM0xka+FDdAFIilBJZiKHyp5orVQq0qRSi+KJU+j31ydrntQ7C4/Ho9JG8pd5IvUfBc/08lCixePNfdqhfKMcjs6Ayh09/RHtJUavGAuOUcDLlkk8RYnLH720k5ZMrJCWDvn+IgI0So/juFF/rTCLcRI+AC8YGZennVlb07eheiRdvzhnOzdhrpD/nk7J6zo/X0nsIGvW1zq8DTc45l2e1JwOUBUEVeYuNT/IPlFaDsPyP8qO+On3Q4AvehcifYydJAe3lFbtF2UAZMafuAKeyljZ48nwHoty1bSr7duntoZfSjJtrHtCzG302mrMNENc+egjfbHqBs5x4jtqjNjv65IvvKNiD7Vk0YpgSTEEg7nbiCXqVsfD4gdz+Gddv6vDgnN7TitfW2A= X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(185117386973197)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR07MB2520; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR07MB2520; X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2520; 4:1o2I8XBkhyi6bQR+eVMa7TXdTSPDwnTwaZtj9u0iPVBcQRLdaPxe69Ybh3Lh5oYZizmhN18IIdiAQnILqhh5TgQT9VZ9y77DoecdSfBEur4Eg4e43ooEP+8LLIXx7GcJkeMiGX92zFBXRgDe6Z6EAhRDN0ccExyzGRaADby0EBjOGZWhVw1enpzg2PNr+B36IvTkrzSZspOJB42qhdHrHGV0qBDVdid2WpXGuERLbmfsCa3v2qgE+WEdCkApxg8r4CGryn/BcR20Q1ynuj2DjsjyNDZxYsatcFvGsBsBYPaP9vgdzQyNlJsoIpRN5LdM4b/ExJepPYmd+oxfF0dNvH4+YT06EJ12bGkalU/MDm8zBZH3tfudxz1yZxnHaAl1 X-Forefront-PRVS: 0421BF7135 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(13464003)(24454002)(51444003)(189002)(93886005)(33716001)(110136004)(33656002)(5660300001)(54906002)(4326008)(4001350100001)(66066001)(6496005)(6246003)(25786009)(53936002)(97736004)(478600001)(47776003)(68736007)(83506001)(5009440100003)(229853002)(50466002)(101416001)(189998001)(54356999)(76176999)(7736002)(9686003)(6916009)(42882006)(53546010)(6666003)(42186005)(8656003)(81156014)(2950100002)(81166006)(23726003)(106356001)(6116002)(105586002)(50986999)(3846002)(8936002)(72206003)(1076002)(55016002)(2906002)(8676002)(305945005)(110426004)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR07MB2520; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR07MB2520; 23:KYxrE6rXiT7O/xBH0vEGhq3eBwfUCBD05NMA+ABnz?= =?us-ascii?Q?A1NfugJQZCYT4fRiFvTcaiXjHr9+viV39DYQ3FHjNXUGZ8HXGdFaPXFC5fCB?= =?us-ascii?Q?s1ayX+8VMFLrkC3RMLrt9iBJ7zbm8LPNE7ysZEmy/JFjOTQTv25qmC2HZplm?= =?us-ascii?Q?7qI/muvIDH5CFUIp+dORq/nq8SqqschhjR9CLWODRKWSiNK+XGkGEw5lZ5gV?= =?us-ascii?Q?/XX8pRBNTDoaJe1isa2+pO8gvZkYAztqvntHPxg3LHCOlJZMxplPEYW4HVJk?= =?us-ascii?Q?demDt1OmAjYRXOxU9ehnDJlZAytfauWNp2g9z4sNGKvsF9BLjDG51x4s3v4Z?= =?us-ascii?Q?/Qmknk13GJV4CAh1pdbsWdBlVb4GnXey7N5ZtoMp0idjtX05hg8r1zlYGP62?= =?us-ascii?Q?vHxdISFS2J2Qfmsz5uAI2JUZZYvcMN5tuW7jCABptwipvFjJNjeVVVRUKhZp?= =?us-ascii?Q?Fx0slE0X7awt8R7aCkzLZO0l3aKCMsScpzz/li4mcmcNFVDUusUm4d2BeTZ+?= =?us-ascii?Q?J0q1TmcLvK7NcAgAdsYFnByOIbcgX3pW5kvlcFfcuG2G02rIixlaxOjN+qs6?= =?us-ascii?Q?QtqtgT1nmS7noraT/5XY2TnpPGugExElZTvYz5O+sm6kst1SxQakuLch7fTm?= =?us-ascii?Q?z7051d3gcH3cm4z60sH8Z7mYToqEp6gMvStaWDe8wTyB1B2DpegQoYVeeLoR?= =?us-ascii?Q?SJFSsremS6g4MTm5dbzR6PDAXgqXC3DO2MgT8xBp4wp6MgFOGmg+dIEVeTDU?= =?us-ascii?Q?ybkkrXFYRQdeMwzFvNgk4zVXAZMyI3GXATjW8pLyNAu8PF1iHBWb/C5p6PGY?= =?us-ascii?Q?WdEwqWdBzutZB58L0TmBQlccGpACXnoYMmAExqYTat+yaqQAlzJ4HTTLMCrL?= =?us-ascii?Q?i7B5KyBKHyM9QjpAHirzArwmix6yCpginnl03FMR6jJOGL+j+sZNsBzPZig7?= =?us-ascii?Q?ZSx8LJJlJNy9rIvy1zwLUt80mqqVQrfg8OJERJyBfn1WyZv2coOfFR3LjmYA?= =?us-ascii?Q?1CkVRqjiG759YsEUs8vO3IpEOy2HqCigZqNBWRLfpOn7oq51vrz1+jYoS9wN?= =?us-ascii?Q?zG4QJtpzW/T+94qW0/S43uW63R+phaYwN0udwTMyoezZjKo1X4kyZwtaCSsz?= =?us-ascii?Q?j6qqMKN5NCcERyUpw0XB5ysIuiaCkHtBoLUH37w0R6jkE4DkyT5Y5k9YVLNi?= =?us-ascii?Q?v90ZcV7717CEd6x/KVn0yxuzZArB7oPguAagoAKnvRacdAbO52skpfDmmEFb?= =?us-ascii?Q?y65JYvvaXAvijE+mXC2yrTVFqMsGb36MD4dZ75dP9lCynG01H9RNX9aGxfrc?= =?us-ascii?Q?vUQUDTI0G+18HhLntx4y1NmLnBzCE/HRrrVnB843bVuzDjQ6XwwFkcUiupPF?= =?us-ascii?Q?KpcQw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2520; 6:7Hy5pE6rGgcrD0sO7LbACshA5aHmcGvq1hoVK0D+SBiSsr38ZLPuiOEv7voBPoLsZKMjdQEbBV7E46r0yKWwajK2InDoxwFc5OqJ7uoiE1B7xq63dt1u5kmP5jJmhgD9TKLRmCd0/M8BneA5aBwOZLmD3hdKM5F4AQ5H4xraEVII8f7GHICEbVo2kSvc417aAsDnpVaj1oq2e5MxxLpgxoqyRRgDC8I7hTVBn+6wIm7+p3+QJFv0h3R1lQXo62OyepHRYvm/jgkBaoOBu09weVe24SMvMO2gTA5tVMtqwhxl30tWxToQ2Jg30uzEwE3T5pMpV8Q38ixswPP+Ns5taA==; 5:T372JBxBRQ3FUtai0sBYl3Op0nb+CzMdyRy1hLqSvSG7ymz240kQWOABwUYZIwuL/NAqKSNfKwTD/Yp/X5tAq1E/Ha41m5naRmzPUU7n1l4XgSkkZQ5iN/HSv8dHT1SJP4YknuiQ6Kd08IdNf2JAVg==; 24:Em+j9rD4GGrniUImboZal7Gj7jV4JuPnOK5eCcgygh3fgFxgoh2+CqVnM7jVc5REqsfF6e9RxSGv4T0Nsrr1jGq6Vvs3R98tjN6PI+8Nx7k=; 7:siEfW6YnVVW5Hzd5hNt/F+2BcgQ2pFU6ZSoB1hQHF5sllu2dnQpIfYgJIMPN4SQ94DAh+oD9eTCmOGIMF8TS8JvRBxAVJm9xkiohosx9baWyV3u6GUeqVXcg/HlKwuYAOSuwwxQIqLq4N+8PzuV/4A5ukzaQg/vMAr+ezSwAlhe5DTs/2F3q7wNKQOOO07XFpTT+gDuyz7k2QWISXBmybNs0qfKGuHXh6SMkGVbiZkQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2017 08:11:23.5308 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB2520 Subject: Re: [dpdk-dev] [PATCH v3 0/2] Dynamically configure mempool handle 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: Tue, 05 Sep 2017 08:11:30 -0000 -----Original Message----- > Date: Tue, 5 Sep 2017 09:47:26 +0200 > From: Olivier MATZ > To: Sergio Gonzalez Monroy > CC: Santosh Shukla , dev@dpdk.org, > thomas@monjalon.net, jerin.jacob@caviumnetworks.com, > hemant.agrawal@nxp.com > Subject: Re: [dpdk-dev] [PATCH v3 0/2] Dynamically configure mempool handle > User-Agent: NeoMutt/20170113 (1.7.2) > > On Mon, Sep 04, 2017 at 03:24:38PM +0100, Sergio Gonzalez Monroy wrote: > > Hi Olivier, > > > > On 04/09/2017 14:34, Olivier MATZ wrote: > > > Hi Sergio, > > > > > > On Mon, Sep 04, 2017 at 10:41:56AM +0100, Sergio Gonzalez Monroy wrote: > > > > On 15/08/2017 09:07, Santosh Shukla wrote: > > > > > * Application programming sequencing would be > > > > > char pref_mempool[RTE_MEMPOOL_OPS_NAMESIZE]; > > > > > rte_eth_dev_get_preferred_pool_ops(ethdev_port_id, pref_mempool /* out */); > > > > > rte_mempool_create_empty(); > > > > > rte_mempool_set_ops_byname( , pref_memppol, ); > > > > > rte_mempool_populate_default(); > > > > What about introducing an API like: > > > > rte_pktmbuf_poll_create_with_ops (..., ops_name, config_pool); > > > > > > > > I think that API would help for the case the application wants an mbuf pool > > > > with ie. stack handler. > > > > Sure we can do the empty/set_ops/populate sequence, but the only thing we > > > > want to change from default pktmbuf_pool_create API is the pool handler. > > > > > > > > Application just needs to decide the ops handler to use, either default or > > > > one suggested by PMD? > > > > > > > > I think ideally we would have similar APIs: > > > > - rte_mempool_create_with_ops (...) > > > > - rte_memppol_xmem_create_with_ops (...) > > > Today, we may only want to change the mempool handler, but if we > > > need to change something else tomorrow, we would need to add another > > > parameter again, breaking the ABI. > > > > > > If we pass a config structure, adding a new field in it would also break the > > > ABI, except if the structure is opaque, with accessors. These accessors would be > > > functions (ex: mempool_cfg_new, mempool_cfg_set_pool_ops, ...). This is not so > > > much different than what we have now. > > > > > > The advantage I can see of working on a config structure instead of directly on > > > a mempool is that the api can be reused to build a default config. > > > > > > That said, I think it's quite orthogonal to this patch since we still require > > > the ethdev api. > > > > Fair enough. > > > > Just to double check that we are on the same page: > > - rte_mempool_create is just there for backwards compatibility and a > > sequence of create_empty -> set_ops (optional) ->init -> populate_default -> > > obj_iter (optional) is the recommended way of creating mempools. > > Yes, I think rte_mempool_create() has too many arguments. > > > - if application wants to use rte_mempool_xmem_create with different pool > > handler needs to replicate function and add set_ops step. > > Yes. And now that xen support is going to be removed, I'm wondering if > this function is still required, given the API is not that easy to > use. Calling rte_mempool_populate_phys() several times looks more > flexible. But this is also another topic. > > > Now if rte_pktmbuf_pool_create is still the preferred mechanism for > > applications to create mbuf pools, wouldn't it make sense to offer the > > option of either pass the ops_name as suggested before or for the > > application to just set a different pool handler? I understand the it is > > either breaking API or introducing a new API, but is the solution to > > basically "copy" the whole function in the application and add an optional > > step (set_ops)? > > I was quite reticent about introducing > rte_pktmbuf_pool_create_with_ops() because for the same reasons, we > would also want to introduce functions to create a mempool that use a > different pktmbuf_init() or pool_init() callback, or to create the pool > in external memory, ... and we would end up with a functions with too > many arguments. > > I like the approach of having several simple functions, because it's > easier to read (even if the code is longer), and it's easily extensible. > > Now if we feel that the mempool ops is more important than the other > parameters, we can consider to add it in rte_pktmbuf_pool_create(). Yes. I agree with Sergio here. Something we could target for v18.02.