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 6A506A00BE for ; Mon, 20 Dec 2021 19:22:59 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0321840040; Mon, 20 Dec 2021 19:22:59 +0100 (CET) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by mails.dpdk.org (Postfix) with ESMTP id A88D14003C for ; Mon, 20 Dec 2021 19:22:57 +0100 (CET) Received: by mail-wr1-f50.google.com with SMTP id r17so21508296wrc.3 for ; Mon, 20 Dec 2021 10:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=l1p8DT13oswLtaV8QtBNd4GP8JryVwp+7v86QzYW7mA=; b=jP59Fuyb7HEk8tOwhiIvI9p6YLbYt2vkgrxlorcNJ5Ssmp5D9pm2pkCsgr44NBQk4v 6tbuPLOjoNMa3LR/ggnu2wosZKG+SIiXYfuafyPqvFzF0VxN8tL5y1i5S/sQBtYC3BIS 7RAe057FFq+vRz9YCmoptdQkt1dB9EHqxy7Wpe6Sb5BlJUsTUIE2HTHsx14PhB3qfOs1 5iWKNMcBX2BFx9nnMstzMGNrv1lrKDCm3MW6+RSokQQ90XTIP5wSvTBKG6yxUGqD+2Q9 0kox5/WUqfR1M+RBd1FUl4+6bOct5gp5Fq43G4nyXtmB0AtNQdCqip2BZlHlUSqtgSd8 JwXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l1p8DT13oswLtaV8QtBNd4GP8JryVwp+7v86QzYW7mA=; b=pU4EpFIGvB+mx6XCsnu32dmzIlWaEVn2zECAa7ReJIVXjUygjKPdYkWZOwwu95jDXQ KGLjSBaSHdjYpu7291YjpFhIMIUMGvlZyXXkdhcXzOT5WzaaGarIRvriTapMaa4NhujS 2p0wcWDihxE/H4ze+RNheUYRuikqLRNJkLzuAgYZHONLXIkIymJYT/m+naZcBGPdZCkr 76CPtArtNe2HVRiOS6Dv5xjuJh+CBOhjtzoRT45xWBAgbdi4w/17gSDvVClOyTB4rmvh t/t2TPJsV5XezcZH0NBZWg18As7ffQ0p4Ch74151K2W+Cd0eiR6CyAWNG/6gTTYkMOKF xeYQ== X-Gm-Message-State: AOAM530ki70Gp4G/JARJnlXmdZqbzf3GbniixQK00rMdFdGUjrupFEE+ qvCugfEQeWDKccqjGRwc7Iz9Rm/LHJJ+t4TcNFUTh45iI4A= X-Google-Smtp-Source: ABdhPJwzOzkkNiNj2769bMgEFuISCRhYSSjy2S+xlIflGu84LytYd1LokuQcwJVaKlxsenY2dXIahIyTbJ85y1LeruI= X-Received: by 2002:a5d:4ccb:: with SMTP id c11mr13110976wrt.689.1640024577124; Mon, 20 Dec 2021 10:22:57 -0800 (PST) MIME-Version: 1.0 From: fwefew 4t4tg <7532yahoo@gmail.com> Date: Mon, 20 Dec 2021 13:22:46 -0500 Message-ID: Subject: Concept clarification on NICS with multiple queues To: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000057ad7b05d397faa4" 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 --00000000000057ad7b05d397faa4 Content-Type: text/plain; charset="UTF-8" My NIC has 32 RX and 32 TX queues. Now given this API, static uint16_t rte_eth_tx_burst ( uint16_t port_id, uint16_t queue_id, struct rte_mbuf ** tx_pkts, uint16_t nb_pkts ) I gather the most natural approach for efficient packet transmissions is, - assign one core to TX on a given port, queue since I/O through different queues is essentially independent - arrange packets in memory buffers so packets for the same queue are in the same buffer The RX side is much the same: static uint16_t rte_eth_rx_burst ( uint16_t port_id, uint16_t queue_id, struct rte_mbuf ** rx_pkts, const uint16_t nb_pkts ) - assign one core to RX on a given port, queue since I/O through different queues is essentially independent of other queues Is this pretty much the starting place? Now, my NIC also has RSS (elided): ethtool -x eth0 RSS hash key: e8:27:27:e4:d9:fa:e4:1e:c6:89:67:95:52:4b:7a:41:3a:a6:68:5f:12:ec:4c:2f:51:18:a0:9b:bb:e1:7a:fb:a7:fb:7f:68:39:47:c2:83 RSS hash function: toeplitz: on xor: off crc32: off But doesn't specifying the queue_id on RX/TX burst functions undercut RSS? That is, nowhere is there an opportunity for the NIC to determine which queue TX or RX go to since it was told at the outset? --00000000000057ad7b05d397faa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My NIC has 32 RX and 32 TX queues.

Now given this A= PI,

<= td class=3D"gmail-paramkey" style=3D"text-align:right;vertical-align:bottom= ">nb_pkts=C2=A0
I gather the most natural approach for efficient packet transmissi= ons is,

- assign one core to TX on a given port, queue since I/O thr= ough different queues is essentially independent
- arrange packets in me= mory buffers so packets for the same queue are in the same buffer

Th= e RX side is much the same:

static uint16_t = rte_eth_tx_burst(uint16= _t=C2=A0port_id,
uint16_t=C2=A0queue_id,
struct=C2=A0rte_m= buf=C2=A0**=C2=A0tx_pkts,
uint16_t=C2=A0
)
<= td class=3D"gmail-paramtype" style=3D"white-space:nowrap;vertical-align:bot= tom">const uint16_t=C2=A0<= /tr>
- assign one core to = RX on a given port, queue since I/O through different queues is essentially= independent of other queues

Is this pretty mu= ch the starting place?

Now, my NIC also has RSS (elided):

eth= tool -x eth0

RSS hash key:

e8:27:27:e4:d9:fa:e4:1e:c6:89:67:95:52:4= b:7a:41:3a:a6:68:5f:12:ec:4c:2f:51:18:a0:9b:bb:e1:7a:fb:a7:fb:7f:68:39:47:c= 2:83

RSS hash function:

=C2=A0 =C2=A0 toeplitz: on

=C2=A0 =C2=A0 xor: off

=C2=A0 =C2=A0 crc32: off


But doesn't specifying the queue_id on RX/TX = burst functions undercut RSS? That is, nowhere is there an opportunity for = the NIC to determine which queue TX or RX go to since it was told at the ou= tset?
--00000000000057ad7b05d397faa4--
static uint16_t rte_eth_rx_burst(uint16_t=C2=A0port_id,
uint16_t= =C2=A0queue_id,
struct=C2=A0rte_mbuf=C2=A0**=C2=A0rx_pkts,
nb_pkts=C2=A0
)