From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0062.outbound.protection.outlook.com [104.47.0.62]) by dpdk.org (Postfix) with ESMTP id 538961DA4 for ; Fri, 25 May 2018 03:58:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4dGkceuxOmlTfbNcUjz4+yP7wwnze+vyh3cjAWcjwnA=; b=XmuDWTIPL/41Z0XzxrOrjkffQ+VJcoG1x+ISHr4odYSDyCBpXIVn09O9bJcFud4hEfWhVg1pbsHw0LSy1o1eFBzlzfpI8ipZcpXN67Lw6dl0YBpWlYIdzm0omn8eyj4xwunvXYEiCRCyTNMB9F4AcZ2JijGMujNKuf3wrSdITOM= Received: from HE1PR0801MB1930.eurprd08.prod.outlook.com (10.168.94.136) by HE1PR0801MB2713.eurprd08.prod.outlook.com (10.166.196.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.797.11; Fri, 25 May 2018 01:58:27 +0000 Received: from HE1PR0801MB1930.eurprd08.prod.outlook.com ([fe80::9ef:63b3:b930:cf5f]) by HE1PR0801MB1930.eurprd08.prod.outlook.com ([fe80::9ef:63b3:b930:cf5f%14]) with mapi id 15.20.0776.015; Fri, 25 May 2018 01:58:27 +0000 From: Honnappa Nagarahalli To: "Guvva, Vijaya" , "Wang, Yipeng1" , "De Lara Guarch, Pablo" , "Richardson, Bruce" CC: "dev@dpdk.org" , nd Thread-Topic: [dpdk-dev] [PATCH V2] librte_hash: new hash del abi to return stored value Thread-Index: AdPzjgIUsMpKc/tsS8SUqPgFtOAbOQACiD5A Date: Fri, 25 May 2018 01:58:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.111.135] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0801MB2713; 7:iUF9RRaQiEAXj5V3Jp5svej1APRr0AXpVOzvRzXwtUhR+N2C55WKNPxKIy1P/kvUTM46K4nXoKv1Gb+pLf+RPW8zbY2bnAVUczDUscxNEl2I0AmkwzeRR1slhOtGisUxVohJ6hZhZJiirCd1SGexEUC2x5uhQvc4hz1MSRWbNbxAjcQcKI9u79Uvu8ogFee2HacGIoD8sRjLRAC57JNPSEUMN2l6M6tpL+CDxYsnhDhZI8/oFI+T8zicAepsBg33 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0801MB2713; x-ms-traffictypediagnostic: HE1PR0801MB2713: nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:HE1PR0801MB2713; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0801MB2713; x-forefront-prvs: 06833C6A67 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39380400002)(39860400002)(376002)(396003)(189003)(199004)(54534003)(13464003)(26005)(7696005)(486006)(68736007)(59450400001)(5250100002)(74316002)(4326008)(6246003)(105586002)(102836004)(6116002)(3846002)(99286004)(11346002)(186003)(476003)(478600001)(106356001)(6506007)(6436002)(5660300001)(76176011)(86362001)(25786009)(53546011)(72206003)(81156014)(81166006)(110136005)(229853002)(446003)(2900100001)(3660700001)(33656002)(305945005)(7736002)(14454004)(54906003)(55016002)(3280700002)(9686003)(2906002)(53936002)(97736004)(66066001)(316002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0801MB2713; H:HE1PR0801MB1930.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Nqv2RX33JOax5nYFGGgh5SI2AM888D15i+CtXulBSh6HopHt7ay4FoGuArJWN9unsEIx0oes+/emCm4Zjc7u8e3Uct4LY0+S/g/nDMJ15LrqOQZ5oytE9JrBflS5fT9OcUbTlPuAK/eO1MFNrcqJNdTfkxM1AQUCjEnE40TVCcF4R7L5JbCYiexeEkDb1GTQ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 69e2a62b-49a9-4ba0-4078-08d5c1e301d9 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69e2a62b-49a9-4ba0-4078-08d5c1e301d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2018 01:58:27.4138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB2713 Subject: Re: [dpdk-dev] [PATCH V2] librte_hash: new hash del abi to return stored value 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, 25 May 2018 01:58:31 -0000 Hi Yipeng, Can you please elaborate on the read-write concurrency changes you are mak= ing? I am looking at few changes myself, want to see how we can align. Issues that I am looking at are: 1) The delete APIs are not multithread safe - from writers perspective 2) Memory ordering between writer and reader while adding the keys 3) Additional APIs to support RCU while deleting the entries Thank you, Honnappa -----Original Message----- From: dev On Behalf Of Guvva, Vijaya Sent: Thursday, May 24, 2018 1:35 PM To: Wang, Yipeng1 ; De Lara Guarch, Pablo ; Richardson, Bruce Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH V2] librte_hash: new hash del abi to return = stored value Hi Yipeng, Sure, It will be great help if you can include these changes in the patches= you are proposing with the necessary locks. Thanks, Vijay=20 -----Original Message----- From: Wang, Yipeng1 Sent: Thursday, May 24, 2018 10:47 AM To: De Lara Guarch, Pablo ; Guvva, Vijaya <= Vijaya.Guvva@cavium.com>; Richardson, Bruce Cc: dev@dpdk.org Subject: RE: [dpdk-dev] [PATCH V2] librte_hash: new hash del abi to return = stored value Hi, Vijaya,=20 Thanks for contributing the new API. We actually have a patch to support read-write concurrency for rte_hash com= ing in a couple of weeks. The new del function you proposed may need to be= protected under the new concurrency scheme as well. If you like, we could = collaborate together to fit your del function under the new concurrency sup= port.=20 Thanks Yipeng >-----Original Message----- >From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of De Lara Guarch,=20 >Pablo >Sent: Thursday, May 17, 2018 1:06 AM >To: Vijaya Mohan Guvva ; Richardson, Bruce=20 > >Cc: dev@dpdk.org >Subject: Re: [dpdk-dev] [PATCH V2] librte_hash: new hash del abi to=20 >return stored value > >Hi Vijaya, > >> -----Original Message----- >> From: Vijaya Mohan Guvva [mailto:vguvva@caviumnetworks.com] >> Sent: Thursday, May 17, 2018 2:27 AM >> To: Richardson, Bruce ; De Lara Guarch,=20 >> Pablo >> Cc: dev@dpdk.org; Vijaya Mohan Guvva >> Subject: [PATCH V2] librte_hash: new hash del abi to return stored=20 >> value >> > >You are actually adding new API, not ABI, so I would reword the commit mes= sage. > >"hash: add API to return stored value at deletion" maybe? > >I would add some information in the commit message and move the=20 >changelog (V1, V2 notes) after the three dashes. > >> V2: >> Adding another new interface rte_hash_del_key_data to delete key from=20 >> hash table and return stored data. >> >> V1: >> Add a new key delete interface rte_hash_del_key_with_hash_data to=20 >> delete the key from hash and return the value stored. This is useful=20 >> for hash users to free the data stored in the table after key delete=20 >> and to avoid maintaining a user data array in the dpdk application. >> >> Signed-off-by: Vijaya Mohan Guvva >> --- >> lib/librte_hash/rte_cuckoo_hash.c | 30 +++++++++++++++++++++++--- >> lib/librte_hash/rte_hash.h | 45 >> +++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 72 insertions(+), 3 deletions(-) > >... > >> +int32_t >> +rte_hash_del_key_with_hash_data(const struct rte_hash *h, const void *k= ey, >> + hash_sig_t sig, void **data); >> + >> +/** >> * Remove a key from an existing hash table. >> * This operation is not multi-thread safe >> * and should only be called from one thread. >> -- >> 1.8.3.1 > >You need to update the version.map file to add the two new functions=20 >(you might need to wait until 18.05 is released, so you can use the 18.08 = tag).