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 D8537440FA; Tue, 28 May 2024 23:34:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1D4BF40697; Tue, 28 May 2024 23:34:35 +0200 (CEST) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by mails.dpdk.org (Postfix) with ESMTP id DEDDB4064E for ; Tue, 28 May 2024 23:34:31 +0200 (CEST) Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-354b722fe81so1072241f8f.3 for ; Tue, 28 May 2024 14:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716932071; x=1717536871; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9CCQKbQtwp9Q5VwxypnfH6nb0BYHroZGqXWufPGZTso=; b=OUxhgwJ/v4ZxpK28GhpPPGfbFZN9nphKw+3Tv7p/LShJ7gxtovxt/z6TcMBJEOdOYl aR2GwSURm+10sNj8Y5CIdIQu0ADp5czQjNAn6l+WQDctKPgSOTRzxYptYKdshg0KKTHY sJznt+fU4lVzuMqN5SrDDVJaAQ9bPEwUE4sTnj0I5FDcMwurm3+904i9MM78KklO4phD rsrQcD1CW2qLQKhZYZjpLRUXW2u/VgZe0Q7oE4jEn2vEm770gcD+/n7nnvlEbNPX1cIT VVEqQC+Ellnf8GPJpGKV/SkMrGNJ3hoqTLptTTD4o+w1Xkk509CclXcNbtxHSfVGLsya jNCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716932071; x=1717536871; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9CCQKbQtwp9Q5VwxypnfH6nb0BYHroZGqXWufPGZTso=; b=nU0kmO+iJFRZY8nYb0tIbWLoSk/SLRTzSQR3OAGULqARN8bqN4jq16QKWrdoTDZoGZ RUvnsAVZqF61iafLOL3rUvdtt0qsUBLausicDfu/0KxTsDtOfDOYAQRZoAUuL1ZW9LKV yq2yLpHZmTcHVxwGYREVdx9MxDzJpWMbCkA6GhmhI9KwOMcxap0NwHhABqVB7BJNjaux w16rtCq06t911z2ED3QTjtnVDZPFgXc93sFKKLalc7PoePqqcnwI7BWklHS4NLL5MAd6 CAGAU1LoQdxNelefNPOG4+EwnWOKuqW/fx4lkN2WKjXxv6PFD9prNTXbXXWbt7mPRqZ9 Z3xw== X-Gm-Message-State: AOJu0YzT5Rxiv/hliCiVqMAELI7zAdjHbGSf1Naf+SFMU8JtvVueeUQK FfvawJPl4EcKBPIB7/6oivgYErHa9IzxAQQbzWdLN/s6zpfxIw3ejky5suieG9KQIiUM5g67/zy BIMSkc0EwrhuAt7CcDqPm3zOOjMY3DzIX X-Google-Smtp-Source: AGHT+IEMAmVPyZd8gFos4SY34rSCF8hwgtj7/bgILd6+747WMkwpVKgvzKa0ICrDHQ87+5XF87Q5FWmowU5mQqkAoOQ= X-Received: by 2002:a5d:4d42:0:b0:354:f984:3b83 with SMTP id ffacd0b85a97d-3552fdf237cmr9195857f8f.63.1716932070946; Tue, 28 May 2024 14:34:30 -0700 (PDT) MIME-Version: 1.0 From: Mohsen Meamarian Date: Tue, 28 May 2024 23:34:19 +0200 Message-ID: Subject: hash lookup in secondary process To: dev@dpdk.org Content-Type: multipart/alternative; boundary="00000000000031413206198a66b7" 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 --00000000000031413206198a66b7 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 --00000000000031413206198a66b7 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 processes running based on different com= piled 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 t= he librte_hash library from behaving properly as in a multi-process instanc= e since it uses a pointer to the hash function internally.