From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <users-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 815E5A034E for <public@inbox.dpdk.org>; Wed, 22 Dec 2021 17:53:30 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A8EA40040; Wed, 22 Dec 2021 17:53:30 +0100 (CET) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by mails.dpdk.org (Postfix) with ESMTP id 7751F4003C for <users@dpdk.org>; Wed, 22 Dec 2021 17:53:27 +0100 (CET) Received: by mail-pj1-f45.google.com with SMTP id v16so2798952pjn.1 for <users@dpdk.org>; Wed, 22 Dec 2021 08:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KaZRRuySI5Pm2IqOhCBtHXRNGhtA/C08aKJ09K/VOUY=; b=TZA5ktTi+dFq8Y0uJI2WBbybv/hO6khU0BHwuzJJU9UUGXv8A1shn6t1+//2uKuK+O rmHioIXdMuj1/Bcs/fxnEpL+cVoZjF51UNit8O3AnPdDJR8G46wPZb1VN8sZ9hzTR/aR 96tgG1jx9dxAP5ahUXpsvYpBLNq6Fc5oUvkpyQDoBxF6OrE7jmQlFefRuQrhQ6Z+AohG lqDRbYVKWUVisESa0siHSutH7mfpuoDJsrUIKPOmZ66E2MGRcW28nbK97P4pllJxeSGW wu/k+brw2/KXe9qlE93nrcaag9hMRk4rFkBmswzmXrWrmCCmDNdmlYNRZhDzyoCZlM89 YC5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KaZRRuySI5Pm2IqOhCBtHXRNGhtA/C08aKJ09K/VOUY=; b=KvwQohjLYAem7cHzJvLqcPqg33fKv5X/Zv9C6NXHvply12/hODX1kystyvTr4KNtPQ KRRAIPzCWUFHWepr6mdq6ef3ZB6fqIzwQtnKtpQ0Wym4TPmhhaimgyLq1Dw9tDPEKXbJ beyVZovpdcFa/TKnxJlRMDE5k72l0F3bzvDvT633wUrnFInKBYB+dCELJPyrf3Tela6h I7I1DimiY048jZhJ40sVOuCXQxBVsolcFGuexwXDp+tei0fXvR2O1Cc9uPZcScE5oKUS 4Wp9y/gxTRAYS0N+YuUi6A5LfX32obLQgFhdFigtJDasKvxdXYuymp1knR1+YhEgObP5 YOhA== X-Gm-Message-State: AOAM530WRF94u0PNuO89tCsglaR9YVoBWkfSp3aWj362ht8mx5RIlagb V9XXeqzM4syioLuZFJpkTk26zQek2/7skg== X-Google-Smtp-Source: ABdhPJyfnt3WoWbrnyilWns3cCFjEtQgcttTMPjDdiSAh3s0h3u5nEhZkAy88xcD8QJMagzmtinwPw== X-Received: by 2002:a17:902:a404:b0:148:b897:c658 with SMTP id p4-20020a170902a40400b00148b897c658mr3468207plq.71.1640192006565; Wed, 22 Dec 2021 08:53:26 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id l15sm2782877pjq.2.2021.12.22.08.53.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 08:53:26 -0800 (PST) Date: Wed, 22 Dec 2021 08:53:23 -0800 From: Stephen Hemminger <stephen@networkplumber.org> To: fwefew 4t4tg <7532yahoo@gmail.com> Cc: users@dpdk.org Subject: Re: Concept clarification on NICS with multiple queues Message-ID: <20211222085323.4b9d894e@hermes.local> In-Reply-To: <CA+Tq66X1zo3M63mkieztDa6fvhQ4ROhQo_OF3_KJTQKCysq7QA@mail.gmail.com> References: <CA+Tq66X1zo3M63mkieztDa6fvhQ4ROhQo_OF3_KJTQKCysq7QA@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions <users.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> Errors-To: users-bounces@dpdk.org On Mon, 20 Dec 2021 13:22:46 -0500 fwefew 4t4tg <7532yahoo@gmail.com> wrote: > 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 <https://doc.dpdk.org/api/structrte__mbuf.html> ** 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 <https://doc.dpdk.org/api/structrte__mbuf.html> ** 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? RSS is Receive Side Scaling. It applies only to which queue will receive a packet. For transmit, RSS is not relevant. Queues are not thread safe. You can only have a single core using a queue at a time. A typical architecture is to assign one transmit queue per core. And have receive queues associated with a single core. See the DPDK examples code. Application chooses the TX queue, NIC determines the RX queue based on configuration. See rte_flow for how more complex Rx queue management can be done.