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 A30F4A0547; Sat, 10 Apr 2021 02:05:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7CF97140F3F; Sat, 10 Apr 2021 02:05:09 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id BC22640688 for ; Sat, 10 Apr 2021 02:05:07 +0200 (CEST) IronPort-SDR: SOKLdeRDLk/YA8w5zim38NEybibRHlY26JONvQYG0IwHyUEYjE5z7IS30lgLhKGHuC8tZzX7CV O7ozwBip4VSQ== X-IronPort-AV: E=McAfee;i="6000,8403,9949"; a="181391789" X-IronPort-AV: E=Sophos;i="5.82,210,1613462400"; d="scan'208";a="181391789" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2021 17:05:06 -0700 IronPort-SDR: Y4EyCSSllQOS0Ilrg3Lb8QyHzGocDOmEJlWVwIi5iyMUsAElAvwzHOVpLTB6jEZJrlXiOX3mLs gCSlB/OI9CMA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,210,1613462400"; d="scan'208";a="382267635" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by orsmga006.jf.intel.com with ESMTP; 09 Apr 2021 17:05:06 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 9 Apr 2021 17:05:05 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) 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.2106.2 via Frontend Transport; Fri, 9 Apr 2021 17:05:05 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.173) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Fri, 9 Apr 2021 17:05:05 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZvBh+TX2wJXCxieS4IvnaY5KwAMYtac4qKjNOA1pQOEk2QzXz84sCX49TSTlR+SxggqjxMeEVH4ZQzXDs5VNBA/lRYUcefF88X5TUpLiaBCye/V7nIY7MreFm4Ii0nx6IdM/JD/7/e2iOAtUnEKUJ+MfR/ftpKvylPFc3PZlqDTPlDwuxU6XuiJXUWOlH3eZu7GvN3rGP6pimDqDvpd6jpNqRIgjp0g3LnoVP7vKJPr8127+XPQvDFgY9r4XTM0ykMAY/T0Nhq4p9T6AurQtJec+HzirfLuTA9KtJaIP8CJrx0F719AX5cA1rzLD8Rg7PA//WV49pfTdUb8mP7BX7A== 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=uxaECbCmu5kheaPAFfp4/oF8j2lCC6TKlOkq/0fC1fc=; b=kVGgdvajTWJ1bMh2s5xDoKsYAqXm+SPrHrHOArMH5xZRTgTRiV4Mh0LPb4TzpJO9GgKgSxrAuveAcl8sitq3qKC+6+M0U3VlKnUoPN+UPvpnk6Ik+Flvb6WRT/jn6NC+TggzOpItVVrg9IKGhai3h8i/z5af6aBcKZCLqQxbZuFIfu84PWtUQHznMhkg2jV+pGh3PwGatRQub3gJSSnwpO8uq9z8Q4lGv3loMxd9FXESYqoOOryaJ1HcEiyXO64BP9txtq0KnhuY3b0tQN7NVNh7Rbv819mCAKW72LpRtaeAlY0c1Pu+t2pTHgOVTb3c2ELpj/RslkMG5XOXSuv3ng== 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=uxaECbCmu5kheaPAFfp4/oF8j2lCC6TKlOkq/0fC1fc=; b=xVe/y/kyNjaVyOTsVJ7VxAZ3zeqbBc7PIyWec4k2/x5BsUiNU/y31Bb0mfK4ArZNWGBQiVBNVjmIUlJ/urVHu7rYmkk180F8TDprbKeoTUDxWfYEe4Q3uG/U8vYczVoz/u++OX+AyITS1B8ic4tuDRadnkV2e7J2hFAv23gbQqg= Received: from BYAPR11MB3494.namprd11.prod.outlook.com (2603:10b6:a03:86::15) by SJ0PR11MB4781.namprd11.prod.outlook.com (2603:10b6:a03:2d8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Sat, 10 Apr 2021 00:05:01 +0000 Received: from BYAPR11MB3494.namprd11.prod.outlook.com ([fe80::8446:4da6:a155:5b3e]) by BYAPR11MB3494.namprd11.prod.outlook.com ([fe80::8446:4da6:a155:5b3e%7]) with mapi id 15.20.3999.032; Sat, 10 Apr 2021 00:05:01 +0000 From: "Wang, Yipeng1" To: "Medvedkin, Vladimir" , "dev@dpdk.org" CC: "Ananyev, Konstantin" , "Chilikin, Andrey" , "Kinsella, Ray" , "Gobriel, Sameh" , "Richardson, Bruce" , Stephen Hemminger Thread-Topic: [PATCH v2 1/3] hash: add predictable RSS API Thread-Index: AQHXKx4s77ZmwjTi50qSBVPvD6JTYqqs25hw Date: Sat, 10 Apr 2021 00:05:01 +0000 Message-ID: References: <1615919077-77774-1-git-send-email-vladimir.medvedkin@intel.com> <1617738643-258635-2-git-send-email-vladimir.medvedkin@intel.com> In-Reply-To: <1617738643-258635-2-git-send-email-vladimir.medvedkin@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [108.161.24.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 95ecb431-df18-471c-e06f-08d8fbb44985 x-ms-traffictypediagnostic: SJ0PR11MB4781: 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:4125; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2rSoMmIcnzn7Zj71Bhc39p3oLG7Ib0S3RRnuijb6GkdnHrc3Jtv5c4VG8oPzG5lrMQmVd5oqFJEfq8vI9BDOp6TIDSBYXqXY92egiX2KDczjpypXE8cRk4iiNzeLsKe0eS6rLCZqgbj+03e9lKK69C8t6DNkYL8HS5hahREfVF5amnl7M5X/OO8VOdx3GPGoGWntNjI3KhQfobSeBlDJ6S/65UliSq5EA90SeU5qrvKPKnAkTocmLTFgUIcWqYmSBFM/3GXGEllcux69uXOYT60G1/H7ahM4bhdrHBxz+cnIaCDtQN7hUoUUbv2l8xtibf4FFpi7osuqJvMdns9P1nehhXh/z6zBq/FaLgnvTgwfwTcR7fsXIfrwaCUaGnpGa9hlviJzTdYqv5i2SVRR3vCny7qNAArBjBN3vGHoMo+ho1ZJ5pnc8aEVPpjnOI20Fhz9HG/0k40aTeI6msVX55/anA8BexbkOV/gL/oF+ZSks+Vs2QnT3POTJ4xE6ajbPA0sRINreq+lHwFwzKaZiyyOKk8zQCDM6kVQiktfVheD1qWVpvd2kxdE0Cr08GqUXsx3tn3+5c0S8RdEBAcZlzBGf+6s00MweFErdVAiqKPrfQs7qaYJpsLrfVa/UsWpJDT/DAzAQjgn178kF/VWRN1asehAI70MPHsuU93mhFE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3494.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(376002)(396003)(39860400002)(136003)(66476007)(66946007)(66556008)(83380400001)(52536014)(4326008)(66446008)(478600001)(76116006)(86362001)(64756008)(33656002)(2906002)(9686003)(55016002)(54906003)(110136005)(316002)(53546011)(8676002)(5660300002)(26005)(8936002)(6506007)(7696005)(71200400001)(186003)(38100700001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?V8vIf06mu4hL8EtSCoyD5gTUAJGUaaE4WmcCkOYZfX9AY4QecGrLix3svyPf?= =?us-ascii?Q?kduuUeIpYIF68Rhg8WhvW2iJ6JE+kRQsh5RnxeqcBOGwm65fm7fX4q7pftBP?= =?us-ascii?Q?an067cVzvv195JJPw9rkBA/aGrOHaQUeyfFFYUqGYmMrxFAJxq113MiPbB/D?= =?us-ascii?Q?zTCl9+WKgNl3dYacK7fsrZcyr4+2fta1WBeDXA25QroFUpBYur7jCElJU+zG?= =?us-ascii?Q?r7Jdn9umlQMKtTMcMWkNSs8DgvACUi/B/4jXOi6ZVbQ/8xBU292hqELXiFUQ?= =?us-ascii?Q?ziJVQMVn47mSEzRy4Dxr3wlpTU1L8WeoJq+VVVj4fDPZXCi/8K3+MIO4LAY+?= =?us-ascii?Q?K1v4wyL/fztLHPQ+QL1RRuU/tYQgYBpoF9d92YuDTtHyQCXvS3iEfP2iadOi?= =?us-ascii?Q?6od44JKjayQ8Jvet8HUHbA759P1SRh/OlOSOGd6boekbeOwZzNCe17zFGl1A?= =?us-ascii?Q?I0yy0TCB9C5fo9p6rWOz5MXZlepQpBabd7VfJRFZITaf4W3PKr4uMKI2RBVt?= =?us-ascii?Q?+xipAZECX2ZUJRNaISPxL/8Su0pHZk24bQ0NZFxz0Eazy/SrCkyIINJc5ZcH?= =?us-ascii?Q?RImmCIVvllkOu0vQ3bDqUUKhFDelOcliYp5tInthaWYoUZsHIhF8XCnTUJI7?= =?us-ascii?Q?8v4fys6sq+kb4r830DqGm7CsVrqAoDH1Pqg7XNJFGf2I0yAiUEv5KCoXyYzm?= =?us-ascii?Q?WglDMXH3mGH7dA6C0FfG6qSQuObWVUPakJ1c50sPEAfuSN7GGpJzI44vKgq4?= =?us-ascii?Q?h4b99ijyP5CnD9X201Dw3+ai8g2gfsIoZhO4X6+W19w7QBdbQ7H3I+3nmc6A?= =?us-ascii?Q?WVT6y2Lq6Aj4AvO0zoElzS0jaKAwNLvAIwJ3qx8qV2mb9nzsQB/tg0Xcpgeb?= =?us-ascii?Q?OUfgYox2GI5TYct+ZHwNNHwkKvwk++/0f6ONpGhC4by9lNvphQdSaBw2JKMg?= =?us-ascii?Q?XfF/pAbxu9bc1x8divQHgZrX10q/89v2TVyXDJQ31OQeVTJRpZy1a/SGNbFO?= =?us-ascii?Q?zFXPKW7VBvkxZx+KgkdzzEzZjiLppd7AIp9AUZ515fuUwrg0pbEyAI0MYqeG?= =?us-ascii?Q?Bs4hblUn5OaCNc9VcclEKwDJt0ikmkhgXj5L3i/p0zcys9KL6sc7ezKlYm6J?= =?us-ascii?Q?QAa1LxuHyAxeuW7I+dRaqzHsugWFmCNqu3I+Rfj+p6pPUBVyUlQ7lTIi8uNe?= =?us-ascii?Q?KsZu5FPh0yYfxPq9cMSwumiHSKeWYdlhjsmuq0+Kn95rxZCh75D72tpe7nTp?= =?us-ascii?Q?+TwP3/95VL8iOTBmCn2qsSf4VjQtWWQmm5rLrTFaxgr+wwbGwDf8mK794w09?= =?us-ascii?Q?5OeIYlvHBC+1TKdsLn+dyb/B?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3494.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95ecb431-df18-471c-e06f-08d8fbb44985 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2021 00:05:01.7081 (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: xj5OPsIeJNGYRIjQqu3jLTRWFjM4nHn/DmY+v4Rmip/ezyeGUrqnXsxslRh1I3JdSD3VpyDiPnYyk7lDBz6mRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4781 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2 1/3] hash: add predictable RSS API 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" > -----Original Message----- > From: Medvedkin, Vladimir > Sent: Tuesday, April 6, 2021 12:51 PM > To: dev@dpdk.org > Cc: Ananyev, Konstantin ; Chilikin, Andrey > ; Kinsella, Ray ; Wang= , > Yipeng1 ; Gobriel, Sameh > ; Richardson, Bruce > > Subject: [PATCH v2 1/3] hash: add predictable RSS API >=20 > This patch adds predictable RSS API. > It is based on the idea of searching partial Toeplitz hash collisions. >=20 > Signed-off-by: Vladimir Medvedkin > --- > lib/librte_hash/meson.build | 3 +- > lib/librte_hash/rte_thash.c | 96 ++++++++++++++++++++++++++++++ > lib/librte_hash/rte_thash.h | 138 > ++++++++++++++++++++++++++++++++++++++++++++ > lib/librte_hash/version.map | 7 +++ > 4 files changed, 243 insertions(+), 1 deletion(-) create mode 100644 > lib/librte_hash/rte_thash.c >=20 > diff --git a/lib/librte_hash/meson.build b/lib/librte_hash/meson.build in= dex > 242859f..3546014 100644 > --- a/lib/librte_hash/meson.build > +++ b/lib/librte_hash/meson.build > @@ -8,6 +8,7 @@ headers =3D files('rte_fbk_hash.h', > 'rte_thash.h') > indirect_headers +=3D files('rte_crc_arm64.h') >=20 > -sources =3D files('rte_cuckoo_hash.c', 'rte_fbk_hash.c') > +sources =3D files('rte_cuckoo_hash.c', 'rte_fbk_hash.c', 'rte_thash.c') > +deps +=3D ['net'] > deps +=3D ['ring'] > deps +=3D ['rcu'] > diff --git a/lib/librte_hash/rte_thash.c b/lib/librte_hash/rte_thash.c ne= w file > mode 100644 index 0000000..79e8724 > --- /dev/null > +++ b/lib/librte_hash/rte_thash.c > @@ -0,0 +1,96 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2021 Intel Corporation > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define THASH_NAME_LEN 64 > + > +struct thash_lfsr { > + uint32_t ref_cnt; > + uint32_t poly; > + /**< polynomial associated with the lfsr */ > + uint32_t rev_poly; > + /**< polynomial to generate the sequence in reverse direction */ > + uint32_t state; > + /**< current state of the lfsr */ > + uint32_t rev_state; > + /**< current state of the lfsr for reverse direction */ > + uint32_t deg; /**< polynomial degree*/ > + uint32_t bits_cnt; /**< number of bits generated by lfsr*/ > +}; > + > +struct rte_thash_subtuple_helper { > + char name[THASH_NAME_LEN]; /** < Name of subtuple > configuration */ > + LIST_ENTRY(rte_thash_subtuple_helper) next; > + struct thash_lfsr *lfsr; > + uint32_t offset; /** < Offset in bits of the subtuple */ > + uint32_t len; /** < Length in bits of the subtuple > */ > + uint32_t lsb_msk; /** < (1 << reta_sz_log) - 1 */ > + __extension__ uint32_t compl_table[0] __rte_cache_aligned; > + /** < Complimentary table */ > +}; > + > +struct rte_thash_ctx { > + char name[THASH_NAME_LEN]; > + LIST_HEAD(, rte_thash_subtuple_helper) head; > + uint32_t key_len; /** < Length of the NIC RSS hash key > */ > + uint32_t reta_sz_log; /** < size of the RSS ReTa in bits */ > + uint32_t subtuples_nb; /** < number of subtuples */ > + uint32_t flags; > + uint8_t hash_key[0]; > +}; > + > +struct rte_thash_ctx * > +rte_thash_init_ctx(const char *name __rte_unused, > + uint32_t key_len __rte_unused, uint32_t reta_sz __rte_unused, > + uint8_t *key __rte_unused, uint32_t flags __rte_unused) { > + return NULL; > +} > + > +struct rte_thash_ctx * > +rte_thash_find_existing(const char *name __rte_unused) { > + return NULL; > +} > + > +void > +rte_thash_free_ctx(struct rte_thash_ctx *ctx __rte_unused) { } > + > +int > +rte_thash_add_helper(struct rte_thash_ctx *ctx __rte_unused, > + const char *name __rte_unused, uint32_t len __rte_unused, > + uint32_t offset __rte_unused) > +{ > + return 0; > +} > + > +struct rte_thash_subtuple_helper * > +rte_thash_get_helper(struct rte_thash_ctx *ctx __rte_unused, > + const char *name __rte_unused) > +{ > + return NULL; > +} > + > +uint32_t > +rte_thash_get_compliment(struct rte_thash_subtuple_helper *h > __rte_unused, > + uint32_t hash __rte_unused, uint32_t desired_hash __rte_unused) { > + return 0; > +} > + > +const uint8_t * > +rte_thash_get_key(struct rte_thash_ctx *ctx __rte_unused) { > + return NULL; > +} > diff --git a/lib/librte_hash/rte_thash.h b/lib/librte_hash/rte_thash.h in= dex > 061efa2..38a641b 100644 > --- a/lib/librte_hash/rte_thash.h > +++ b/lib/librte_hash/rte_thash.h > @@ -1,5 +1,6 @@ > /* SPDX-License-Identifier: BSD-3-Clause > * Copyright(c) 2015-2019 Vladimir Medvedkin > + * Copyright(c) 2021 Intel Corporation > */ >=20 > #ifndef _RTE_THASH_H > @@ -222,6 +223,143 @@ rte_softrss_be(uint32_t *input_tuple, uint32_t > input_len, > return ret; > } >=20 > +/** > + * LFSR will ignore if generated m-sequence has more than 2^n -1 bits > +*/ [Wang, Yipeng]=20 I haven't fully got the significance/reasons behind the two flags. For the comment above, 2^n is the reta_size right? If so, it is better than commenting 2^n. For the first flag: What would be the issue for overflow? I understand that multiple helpers ma= y overlap on the m-sequence, but since they are for different tuples, what would be t= he issue? For the second flag: is it always good to keep it minimum for each helper? The goal is to have the best default values for user who do not understand = the algorithm details. Less flags is usually better. > +#define RTE_THASH_IGNORE_PERIOD_OVERFLOW 0x1 > +/** > + * Generate minimal required bit (equal to ReTa LSB) sequence into > + * the hash_key > + */ > +#define RTE_THASH_MINIMAL_SEQ 0x2 > + > +/** @internal thash context structure. */ struct rte_thash_ctx; > +/** @internal thash helper structure. */ struct > +rte_thash_subtuple_helper; > + > +/** > + * Create a new thash context. > + * > + * @param name > + * context name > + * @param key_len > + * length of the toeplitz hash key > + * @param reta_sz > + * logarithm of the NIC's Redirection Table (ReTa) size, > + * i.e. number of the LSBs if the hash used to determine > + * the reta entry. > + * @param key [Wang, Yipeng] Key will be modified by helper anyway. What is the reason of= having the users to specify the key here? > + * pointer to the key used to init an internal key state. > + * Could be NULL, in this case internal key will be inited with random. > + * @param flags > + * supported flags are: > + * RTE_THASH_IGNORE_PERIOD_OVERFLOW > + * RTE_THASH_MINIMAL_SEQ > + * @return > + * A pointer to the created context on success > + * NULL otherwise > + */ > +__rte_experimental > +struct rte_thash_ctx * > +rte_thash_init_ctx(const char *name, uint32_t key_len, uint32_t reta_sz, > + uint8_t *key, uint32_t flags); > + > +/** > + * Find an existing thash context and return a pointer to it. > + * > + * @param name > + * Name of the thash context > + * @return > + * Pointer to the thash context or NULL if it was not found with > +rte_errno > + * set appropriately. Possible rte_errno values include: > + * - ENOENT - required entry not available to return. > + */ > +__rte_experimental > +struct rte_thash_ctx * > +rte_thash_find_existing(const char *name); > + > +/** > + * Free a thash context object > + * > + * @param ctx > + * thash context > + * @return > + * None > + */ > +__rte_experimental > +void > +rte_thash_free_ctx(struct rte_thash_ctx *ctx); > + > +/** > + * Add a special properties to the toeplitz hash key inside a thash cont= ext. > + * Creates an internal helper struct which has a complimentary table > + * to calculate toeplitz hash collisions. > + * > + * @param ctx > + * thash context > + * @param name > + * name of the helper > + * @param len [Wang, Yipeng]=20 Add requirement here so user know the expectation. e.g. Len should be no shorter than log(reta_size). > + * length in bits of the target subtuple > + * @param offset > + * offset in bits of the subtuple > + * @return > + * 0 on success > + * negative on error > + */ [Wang, Yipeng] thread-safety for the APIs? Better to add thread-safety info in the comments. > +__rte_experimental > +int > +rte_thash_add_helper(struct rte_thash_ctx *ctx, const char *name, > uint32_t len, > + uint32_t offset); > + > +/** > + * Find a helper in the context by the given name > + * > + * @param ctx > + * thash context > + * @param name > + * name of the helper > + * @return > + * Pointer to the thash helper or NULL if it was not found. > + */ > +__rte_experimental > +struct rte_thash_subtuple_helper * > +rte_thash_get_helper(struct rte_thash_ctx *ctx, const char *name); > + > +/** > + * Get a complimentary value for the subtuple to produce a [Wang, Yipeng]=20 Should it be complimentary->complementary? compliment -> complement? > + * partial toeplitz hash collision. It muxt be XOR'ed with the [Wang, Yipeng] typo *must be > + * subtuple to produce the hash value with the desired hash LSB's > + * > + * @param h > + * Pointer to the helper struct > + * @param hash > + * toeplitz hash value calculated for the given tuple > + * @param desired_hash > + * desired hash value to find a collision for > + * @return > + * A complimentary value which must be xored with the corresponding > +subtuple */ __rte_experimental uint32_t > +rte_thash_get_compliment(struct rte_thash_subtuple_helper *h, > + uint32_t hash, uint32_t desired_hash); > + > +/** > + * Get a pointer to the toeplitz hash contained in the context. > + * It changes after each addition of a helper. It should be installed > +to > + * the NIC. > + * > + * @param ctx > + * thash context > + * @return > + * A pointer to the toeplitz hash key > + */ > +__rte_experimental > +const uint8_t * > +rte_thash_get_key(struct rte_thash_ctx *ctx); > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/librte_hash/version.map b/lib/librte_hash/version.map in= dex > c6d7308..93cb230 100644 > --- a/lib/librte_hash/version.map > +++ b/lib/librte_hash/version.map > @@ -37,4 +37,11 @@ EXPERIMENTAL { > rte_hash_lookup_with_hash_bulk_data; > rte_hash_max_key_id; > rte_hash_rcu_qsbr_add; > + rte_thash_add_helper; > + rte_thash_find_existing; > + rte_thash_free_ctx; > + rte_thash_get_compliment; > + rte_thash_get_helper; > + rte_thash_get_key; > + rte_thash_init_ctx; > }; > -- > 2.7.4