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 EA6F2440FA for ; Tue, 28 May 2024 23:39:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B3BB7402EF; Tue, 28 May 2024 23:39:28 +0200 (CEST) Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by mails.dpdk.org (Postfix) with ESMTP id 089D7402BA for ; Tue, 28 May 2024 23:39:28 +0200 (CEST) Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a6265d47c61so139848666b.0 for ; Tue, 28 May 2024 14:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716932367; x=1717537167; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=x8SUPu94xFLGZk7do2NEI9sbwHEUvVwaPl0LvurC7RY=; b=PBEVVBi5N0Of4xMTNMMTNx20mhvx3+cU+1vlArGykz3NkaILKMNTxNMjSCKVR4E+4R PEjltAxqV0i6VBvKIEGYQFyqPvu7Q2QniK3//vQdF2Fnk5Vuy76BTZednRGAjH2SXLSh Jziw9vsohbb97Dc9OuLX7zldCNijYTiFaUvdJDzpDbn7kL4Pjr0f+C3l4buS9Aa22cr5 D0deI/R4bKS53wMPuH8paw2LqE+R/O+5WYFX3eGa7oCXBcvSyjP+nuVYsZhx05QKMBax 0oyM3edsP0Zx8NR0xwt0XmtPVsIBtHq6lY6w8NH3FNl5cUQuTQLtDh/ddk1/v4SVydVL Z9cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716932367; x=1717537167; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=x8SUPu94xFLGZk7do2NEI9sbwHEUvVwaPl0LvurC7RY=; b=rk9W00vdlKgJWY8G8juGnfCRwJAk/Ng0v1/nqbWxQyb2hAy+RPTv2+/34F2f84KYJK YWQpG0QAg6O2sqt7fQ6FhxtjxOH7IcE82yX+Ya43hrMYbHZLgFcOUx28pWUA/q3nKfjr CwzuHCMzm2mTvyGTYgw3kOejTOS2/wf8OIc0I+2YvDg3NqLXTkT7/OFCuWvBZ3LUfdD7 UqwfGna3TxZOdRdooDS6U9LZOm3PBjvzIDNgL7vBCgClT9DeKEtNYTglwQKMerJbQCF1 HZuN4XCGXcnntKmugvdRPyW1KEF1ODKc7V+IG/lSL1xIcFvBlD54/0r8tJjaUOLaQdiy R9hg== X-Gm-Message-State: AOJu0YwlPnJFUjCo1J50ENG3QjdUj2TVOAUaiY7Y61xVOFs/JkGbaEu2 MI179R5ZrXmb8BrOzd0RICYSQhjnlWsCr9VDYV3BNV0HS2kAgYWuWY5VXOF3es07jzAA2vs+rRQ 7q/8B+G16kXY2CY6MpeQrAqeq+B0vd76f X-Google-Smtp-Source: AGHT+IF4GMagSctXmkkh5qUpKvkIFGc+1ySBrJR2CAONH2QGtJFOof6nlAg7nv8zIl4cG9Y7FCi+zk3R67Kyn0Vu6YY= X-Received: by 2002:a17:906:d9d1:b0:a5a:34ae:10ea with SMTP id a640c23a62f3a-a62651187d1mr953096266b.76.1716932367220; Tue, 28 May 2024 14:39:27 -0700 (PDT) MIME-Version: 1.0 From: Mohsen Meamarian Date: Tue, 28 May 2024 23:39:16 +0200 Message-ID: Subject: hash lookup in secondary process To: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000da0a6806198a77ea" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000da0a6806198a77ea Content-Type: text/plain; charset="UTF-8" Hi all, I have two dpdk app, one primary and one secondary. I create a hash table in the primary dpdk app like this: static struct rte_hash_parameters ut_params = { .name = "BufferTable2", .entries = 1024*256, .key_len = sizeof(uint64_t), .hash_func = rte_jhash, //.extra_flag=RTE_HASH_EXTRA_FLAGS_EXT_TABLE, //.extra_flag=RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY, }; buffer_table = rte_hash_create(&ut_params); if (buffer_table == NULL) { printf("UNABLE TO CREATE HASHTABLE\n"); rte_exit(EXIT_FAILURE, "UNABLE TO CREATE HASHTABLE\n"); } and in secondary I use : h=rte_hash_find_existing("BufferTable1"); if (!h) { fprintf(stderr, "Failed to find existing hash table\n"); return -1; } int ret = rte_hash_lookup_data(buffer_table, &teid, (void**)&packet_in_bucket); I can find the table pointer, but it gives a segmentation fault when I want to look up something or add some key value. I cannot add a key value in the primary app, so it should be in the secondary app. I checked rte_hash_lookup_with_hash_data and rte_hash_add_key_with_hash. these get a hash signature along with a key/value. but it also gives segfault. in this way, the hash sig should be calculated manually. I saw this too in dpdk doc: The use of function pointers between multiple processes running based on different compiled binaries is not supported, since the location of a given function in one process may be different from its location in a second. This prevents the librte_hash library from behaving properly as in a multi-process instance since it uses a pointer to the hash function internally. https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html can you explain what I should do? dpdk version 24.03 Best, Mohsen --000000000000da0a6806198a77ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have two dpdk app, one primar= y and one secondary. I create a hash table in the primary dpdk app like thi= s:

static struct rte_hash_parameters ut_params =3D= {
=C2=A0 =C2=A0 .name =3D "BufferTable2",
=C2=A0 =C2=A0 .e= ntries =3D 1024*256,
=C2=A0 =C2=A0 .key_len =3D sizeof(uint64_t),
=C2= =A0 =C2=A0 .hash_func =3D rte_jhash,
=C2=A0 =C2=A0 //.extra_flag=3DRTE_H= ASH_EXTRA_FLAGS_EXT_TABLE,
=C2=A0 =C2=A0 //.extra_flag=3DRTE_HASH_EXTRA_= FLAGS_RW_CONCURRENCY,
};

=C2=A0 =C2=A0 buf= fer_table =3D rte_hash_create(&ut_params);
=C2=A0 =C2=A0 = if (buffer_table =3D=3D NULL) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 printf("= ;UNABLE TO CREATE HASHTABLE\n");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rte_ex= it(EXIT_FAILURE, "UNABLE TO CREATE HASHTABLE\n");
=C2=A0 =C2= =A0 }


and in secondary I use = :

=C2=A0 =C2=A0 h=3Drte_hash_find_existing(&q= uot;BufferTable1");
=C2=A0 =C2=A0 if (!h) {
=C2=A0 =C2=A0 =C2=A0= =C2=A0 fprintf(stderr, "Failed to find existing hash table\n");<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
=C2=A0 =C2=A0 }
=
int ret =3D rte_hash_lookup_data(buffer_table, &teid, (v= oid**)&packet_in_bucket);

I can find the= table pointer, but it gives a segmentation fault when I want to look up so= mething or add some key value.
I cannot add a key value in the pr= imary app, so it should be in the secondary app.

<= div>I checked=C2=A0rte_hash_lookup_with_hash_data and=C2=A0rte_hash_add_key= _with_hash. these get a hash signature along with a key/value. but it also = gives segfault. in this way, the hash=C2=A0sig should be calculated manuall= y.=C2=A0


I saw this too in dpdk doc:

The use of function pointers between multiple process= es running based on different compiled binaries is not supported, since the= location of a given function in one process may be different from its loca= tion in a second. This prevents the librte_hash library from behaving prope= rly as in a multi-process instance since it uses a pointer to the hash func= tion internally.

can you e= xplain what I should=C2=A0do?
dpdk version 24.03



Best,
Mohsen
--000000000000da0a6806198a77ea--