From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 8AF504F93 for ; Wed, 21 Mar 2018 04:13:20 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id h21so7052493wmd.1 for ; Tue, 20 Mar 2018 20:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XOP/t9VtE3w/JEeF8H79COHdu2JBEHa3cOFJXmzEApw=; b=CzrxOnYKSNR4fVenD98AHIvIRyOzKmDAnXv289yJX6DXcd+xEhnO6kith6FHP6rc87 9143eaaACEMqYQMLY5Sb2+Af6ZqEGaTpbTO2sxVKSbenh6ajFgUV0p3HX3WlDj0qrUAc TjZfNAyiLMFPdylVVRluLd693ZjEvFQ7D/lm+p0WBETwUAMDIy6C31XmnVpJ7hy82YzZ SIQao6Ce2Jw2mOA7IW1z7EyHifhIjxRNGvcdVNd4ZzwL/1cORis2ZrSKccG/V68FNKKI GLZEiob9/3/hCPdMfaQYF9V3ASHiIMH9QM914kFK85AkZFSQvkndgtc3Wc6pnAwPHuvq fyHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XOP/t9VtE3w/JEeF8H79COHdu2JBEHa3cOFJXmzEApw=; b=dKwNmMHh6jAXOnwch0k0nHg28/nJ5REqNpoOsGjTVcLqa7nMmGDtbZ+0tEtsNM1BLq MJyYV+C7piB3Q3+lCxSwIPonvZsIXdhBMxuLAU3riwFlkHRTdakRY+ARVBqeaH/f9hUY m+BGFQWMS3p/5bVzLTxaaN3+6pdA6HiC5n5oWjcNI8P4tTm+wdu9Z6mgOAm0yPauRGzT hfFdynpuu1P86O1Leqr2eJYpHPO9pzi7h2JdapvmO9zBCJDsyaIjklTKYl27rWjc7lR6 3K+AsQDX16hRLqBHRutHHZhk+i0M/AFOHrEz1s+lqkREXSl6b+zIjLKWAWo2QoZ7fDZY DD1A== X-Gm-Message-State: AElRT7FB6iNt7a6Rqfjw5Uh1aSn1lXOyVB+BENVOM9CLRhXDLZO7pbCu SkWn9sKkIJwKzvjpl+6TdnoxI21DZY3K7p0u/0XWo57G X-Google-Smtp-Source: AG47ELsDFn7uF7qkEMzmMyF6XJLFJ4S4s1mvEfXwHvoT1XfA/Jc7foIGjAnruI0In88avgVyRQlJI629GeGXnyIrsvg= X-Received: by 10.80.141.1 with SMTP id s1mr15978764eds.234.1521602000120; Tue, 20 Mar 2018 20:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.165.45 with HTTP; Tue, 20 Mar 2018 20:13:19 -0700 (PDT) From: shengxiao qian Date: Wed, 21 Mar 2018 11:13:19 +0800 Message-ID: To: users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-users] wrong core receive the package X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 03:13:20 -0000 Hi there; Our machine has 2 cpus=EF=BC=88Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GH= z=EF=BC=89with 40 cores. If the core num is less than or equal to 16. the application with dpdk works fine.But if the core num more than 16.there is something wrong with it. In our test scenario(more then 16 cores), server a is a tcp client and server b is a tcp server. Server a sends a syn packet to server B with core1, and server B returns a syn ack message to server a.Although the hash value of these two packets is the same, syn ack packets are distributed to server a other core(not the send core),Can anyone give some help? NIC info=EF=BC=9A Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection(recv 01) I reconnect the nic to Linux and examine it with ethtool: RX flow hash indirection table for enp4s0f1 with 40 RX ring(s): 0: 0 1 2 3 4 5 6 7 8: 8 9 10 11 12 13 14 15 16: 0 1 2 3 4 5 6 7 24: 8 9 10 11 12 13 14 15 32: 0 1 2 3 4 5 6 7 40: 8 9 10 11 12 13 14 15 48: 0 1 2 3 4 5 6 7 56: 8 9 10 11 12 13 14 15 64: 0 1 2 3 4 5 6 7 72: 8 9 10 11 12 13 14 15 80: 0 1 2 3 4 5 6 7 88: 8 9 10 11 12 13 14 15 96: 0 1 2 3 4 5 6 7 104: 8 9 10 11 12 13 14 15 112: 0 1 2 3 4 5 6 7 120: 8 9 10 11 12 13 14 15 RSS hash key: 64:8e:94:4d:41:6e:5b:84:47:49:df:34:e0:f2:6c:4f:cf:1e:c7:ec:f2:ff:e5:dc:a1:= 10:85:58:4e:af:f4:a7:98:f4:77:94:5b:d3:27:49 RSS hash function: toeplitz: on xor: off RSS related configuration and code =EF=BC=9A 1=EF=BC=9Arxmode_mq_mode =3D ETH_MQ_RX_RSS 2=EF=BC=9Arx_adv_conf.rss_conf.rss_hf =3D ETH_RSS_PROTO_MASK 3=EF=BC=9A void dpdk_device::set_rss_table() { if (_dev_info.reta_size =3D=3D 0) return; int reta_conf_size =3Dstd::max(1, _dev_info.reta_size / RTE_RETA_GROUP_SIZE); rte_eth_rss_reta_entry64 reta_conf[reta_conf_size];//reta_conf_size=3D2 // Configure the HW indirection table unsigned i =3D 0; for (auto& x : reta_conf) { x.mask =3D ~0ULL; for (auto& r: x.reta) { r =3D i++ % _num_queues;//_num_queues =3D 40 } } if (rte_eth_dev_rss_reta_update(_port_idx, reta_conf, _dev_info.reta_size)) { rte_exit(EXIT_FAILURE, "Port %d: Failed to update an RSS indirection table", _port_idx); } } is there anything wrong with the congigure?