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 37EB241B9D; Wed, 1 Feb 2023 10:05:57 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2DB4942D49; Wed, 1 Feb 2023 10:05:40 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id C4F8442D53 for ; Wed, 1 Feb 2023 10:05:38 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id BC9775A; Wed, 1 Feb 2023 12:05:35 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru BC9775A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1675242335; bh=7sYpNzqw8n0qlu4mVvp/p+npf00REqRaivjTXtAvxL0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=kJ4PXq3J4JsfZJPa+vpsd9LowXAB6ZhNealaEzZoontDr/QT0IXImizM8zvs8hB+p vzHG1eeHU82naUDgi/ECnL2WsHqDnucc3o9LvD0v3sLn7HpMfieYb7gv4SSom5RYYS 6OhY4tBfzl9HQaSBi30hmbCPEEYGggO2RjnfkvSs= Message-ID: <53ac9185-1f93-d3b3-010f-38c04d04a806@oktetlabs.ru> Date: Wed, 1 Feb 2023 12:05:35 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API Content-Language: en-US To: Jiawei Wang , viacheslavo@nvidia.com, orika@nvidia.com, thomas@monjalon.net, Aman Singh , Yuying Zhang , Ferruh Yigit Cc: dev@dpdk.org, rasland@nvidia.com References: <20230130170041.1360-1-jiaweiw@nvidia.com> <20230130170041.1360-3-jiaweiw@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <20230130170041.1360-3-jiaweiw@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 1/30/23 20:00, Jiawei Wang wrote: > For the multiple hardware ports connect to a single DPDK port (mhpsdp), > the previous patch introduces the new rte flow item to match the > phy affinity of the received packets. > > This patch adds the tx_phy_affinity setting in Tx queue API, the affinity "This patch adds" -> "Add ..." > value reflects packets be sent to which hardware port. > Value 0 is no affinity and traffic will be routed between different > physical ports, Who will it be routed? > if 0 is disabled then try to match on phy_affinity 0 > will result in an error. Why are you talking about matching here? > > Adds the new tx_phy_affinity field into the padding hole of rte_eth_txconf > structure, the size of rte_eth_txconf keeps the same. Adds a suppress > type for structure change in the ABI check file. > > This patch adds the testpmd command line: > testpmd> port config (port_id) txq (queue_id) phy_affinity (value) > > For example, there're two hardware ports 0 and 1 connected to > a single DPDK port (port id 0), and phy_affinity 1 stood for > hardware port 0 and phy_affinity 2 stood for hardware port 1, > used the below command to config tx phy affinity for per Tx Queue: > port config 0 txq 0 phy_affinity 1 > port config 0 txq 1 phy_affinity 1 > port config 0 txq 2 phy_affinity 2 > port config 0 txq 3 phy_affinity 2 > > These commands config the TxQ index 0 and TxQ index 1 with phy affinity 1, > uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the > hardware port 0, and similar with hardware port 1 if sending packets > with TxQ 2 or TxQ 3. Frankly speaking I dislike it. Why do we need to expose it on generic ethdev layer? IMHO dynamic mbuf field would be a better solution to control Tx routing to a specific PHY port. IMHO, we definitely need dev_info information about a number of physical ports behind. Advertising value greater than 0 should mean that PMD supports corresponding mbuf dynamic field to contol ongoing physical port on Tx (or should just reject packets on prepare which try to specify outgoing phy port otherwise). In the same way the information may be provided on Rx. I'm OK to have 0 as no phy affinity value and greater than zero as specified phy affinity. I.e. no dynamic flag is required. Also I think that order of patches should be different. We should start from a patch which provides dev_info and flow API matching and action should be in later patch. > > Signed-off-by: Jiawei Wang [snip]