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 870254242F; Fri, 20 Jan 2023 13:22:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2769E40150; Fri, 20 Jan 2023 13:22:34 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 5B46B400D5 for ; Fri, 20 Jan 2023 13:22:32 +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 9FB3650; Fri, 20 Jan 2023 15:22:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 9FB3650 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1674217351; bh=lr+nRWVA7QEc4KosqPmdk/MgncryRCjwEQLlVm0G2f0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JEqb+9wPhDNyif++3mD5Q6+h+0ie4pp3pdZMBEyM3ri/Os22hQnMSoxhZQwtADrmK vAnnpmig6jwDGTRxYcj9Ej3Wl6m7plK+EkEExOSywfq9aUDiHgd4NGXEPHU7Z3aVui uDkYR9wC5pZIok+K4pYlbC7X9BJ3qfcKGXcJDacg= Message-ID: <22e1d57d-37bd-2eae-4347-79147f644c27@oktetlabs.ru> Date: Fri, 20 Jan 2023 15:22:31 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [RFC] ethdev: sharing indirect actions between ports Content-Language: en-US To: Slava Ovsiienko , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Ori Kam Cc: "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh , "ivan.malov@oktetlabs.ru" , "ferruh.yigit@amd.com" References: <20221228165433.18185-1-viacheslavo@nvidia.com> <12784039.iMDcRRXYNz@thomas> <5033552.JsnAkG3lO3@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/18/23 19:37, Slava Ovsiienko wrote: > > >> -----Original Message----- >> From: Thomas Monjalon >> Sent: Wednesday, January 18, 2023 6:22 PM >> To: Slava Ovsiienko ; Ori Kam >> >> Cc: dev@dpdk.org; Matan Azrad ; Raslan Darawsheh >> ; andrew.rybchenko@oktetlabs.ru; >> ivan.malov@oktetlabs.ru; ferruh.yigit@amd.com >> Subject: Re: [RFC] ethdev: sharing indirect actions between ports >> >> 18/01/2023 16:17, Ori Kam: >>> From: Thomas Monjalon >>>> 28/12/2022 17:54, Viacheslav Ovsiienko: >>>>> The RTE Flow API implements the concept of shared objects, known >>>>> as indirect actions (RTE_FLOW_ACTION_TYPE_INDIRECT). >>>>> An application can create the indirect action of desired type and >>>>> configuration with rte_flow_action_handle_create call and then >>>>> specify the obtained action handle in multiple flows. >>>>> >>>>> The initial concept supposes the action handle has strict >>>>> attachment to the port it was created on and to be used >>>>> exclusively in the flows being installed on the port. >>>>> >>>>> Nowadays the multipath network topologies are quite common, >>>>> packets belonging to the same connection might arrive and be sent >>>>> over multiple ports, and there is the raising demand to handle >>>>> these "spread" connections. To fulfil this demand it is proposed >>>>> to extend indirect action sharing across the multiple ports. This >>>>> kind of sharing would be extremely useful for the meters and >>>>> counters, allowing to manage the single connection over the >>>>> multiple ports. >>>>> >>>>> This cross-port object sharing is hard to implement in generic way >>>>> merely with software on the upper layers, but can be provided by >>>>> the driver over the single hardware instance, where multiple >>>>> ports reside on the same physical NIC and share the same hardware >>>>> context. >>>>> >>>>> To allow this action sharing application should specify the "host >>>>> port" during flow configuring to claim the intention to share the >>>>> indirect actions. All indirect actions reside within "host port" >>>>> context and can be shared in flows being installed >>>> >>>> I don't like the word "host" because it may refer to the host CPU. >>>> Also if I understand well, the application must choose one port >>>> between all ports of the NIC and keep using the same. >>>> I guess we don't want to create a NIC id. >>>> So I would suggest to rename to nic_ref_port or something like that. >>>> >>> >>> I think that host is the correct word since this port hosts all >>> resources for other ports. (this is also why the host is used in case >>> of CPU 😊) >>> I don't think it is correct to use bad wording due to the fact that >>> some one else also uses this word. >>> in rte_flow we never talk about host CPU so I don't think this is confusing. >> >> The confusion is that we can think of a port on the host. > > In my humble opinion, "_port_id" suffix explicitly specifies what field is and does not leave > too much space for confusion. > > "root_port_id"? "base_port_id"? "container_port_id" ? "mgmnt_port_id" ? > Looks worse as for me and does not reflect the exact meaning. > As Ori mentioned this is DPDK port ID that embraces all the shared actions. > It plays a host role for them. Maybe 'owner_port_id' or 'rsrc_port_id' ?