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 406C641BAB; Thu, 2 Feb 2023 10:28:47 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C127406A2; Thu, 2 Feb 2023 10:28:47 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 6C3AE40689 for ; Thu, 2 Feb 2023 10:28:45 +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 D405250; Thu, 2 Feb 2023 12:28:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D405250 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1675330124; bh=rQCkcy6C2ol23qsgPWmQNqDrJeW/6qRCVnmGAbKlRck=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VCTCW716jivrXG88sGwh9XnkRbPJU7vjDemz6t/HVLyG8MuFH4sKbBEK+q3WhKdSl C4cNG/Q9qk+8YyV8tjW3vTEzXO452zfzyxp7I1sXugNxE/GOsNA6ctwwUfn8x/1dm5 VKfEi1hGD5LuSU/pyN9Y6+/vPg8KO6SVdTOzxOAU= Message-ID: Date: Thu, 2 Feb 2023 12:28:44 +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(Jonny) Wang" , Slava Ovsiienko , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Aman Singh , Yuying Zhang , Ferruh Yigit Cc: "dev@dpdk.org" , Raslan Darawsheh References: <20230130170041.1360-1-jiaweiw@nvidia.com> <20230130170041.1360-3-jiaweiw@nvidia.com> <53ac9185-1f93-d3b3-010f-38c04d04a806@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: 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 2/1/23 18:50, Jiawei(Jonny) Wang wrote: >> -----Original Message----- >> From: Andrew Rybchenko >> Subject: Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue >> API >> >> On 1/30/23 20:00, Jiawei Wang wrote: >>> 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. >> > > OK, the phy affinity is not part of packet information(like timestamp). Why? port_id is a packet information. Why phy_subport_id is not a packet information. > And second, the phy affinity is Queue layer, that is, the phy affinity value > should keep the same behavior per Queue. > After the TxQ was created, the packets should be sent the same physical port > If using the same TxQ index. Why are these queues should be visible to DPDK application? Nobody denies you to create many HW queues behind one ethdev queue. Of course, there questions related to descriptor status API in this case, but IMHO it would be better than exposing these details to an application level. > >> 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. >> > > See above, I think phy affinity is Queue level not for each packet. > >> 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. >> > > Thanks for agreement. > >> 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. >> > > OK. > >>> >>> Signed-off-by: Jiawei Wang >> >> [snip] >