From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 593DDA04C0; Thu, 17 Sep 2020 17:16:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E820B1C19F; Thu, 17 Sep 2020 17:16:17 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id DBCF91BFCF for ; Thu, 17 Sep 2020 17:16:16 +0200 (CEST) Received: from mx1-us1.ppe-hosted.com (unknown [10.7.65.62]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 5966F60151; Thu, 17 Sep 2020 15:16:16 +0000 (UTC) Received: from us4-mdac16-63.ut7.mdlocal (unknown [10.7.66.62]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 561A7800A3; Thu, 17 Sep 2020 15:16:16 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.7.65.197]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id B3D08280089; Thu, 17 Sep 2020 15:16:15 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 2AB36A4007A; Thu, 17 Sep 2020 15:16:14 +0000 (UTC) Received: from [127.0.0.27] (10.17.10.39) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Sep 2020 16:16:01 +0100 To: Ori Kam , Gregory Etelson , "Ajit Khaparde" CC: dpdk-dev , Matan Azrad , Raslan Darawsheh , Ori Kam , "NBU-Contact-Thomas Monjalon" , Ferruh Yigit References: <20200625160348.26220-1-getelson@mellanox.com> <20200908201552.14423-1-getelson@nvidia.com> <20200908201552.14423-2-getelson@nvidia.com> <599184f9-72ce-d0f1-a586-d0182888497e@solarflare.com> From: Andrew Rybchenko Message-ID: <0b6d50d9-1c81-fc28-f340-f9621b835ba8@solarflare.com> Date: Thu, 17 Sep 2020 18:15:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.10.39] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.6.1012-25670.006 X-TM-AS-Result: No-14.840000-8.000000-10 X-TMASE-MatchedRID: 8HTFlOrbAtHmLzc6AOD8DfHkpkyUphL9Ud7Bjfo+5jR9MM0d1GPM58br Fd3sG7v6wPb5NDq94CA5ZtwAbvsNRTM9BBRuZZ1vjoyKzEmtrEfSZJzVjNsLneJiUqjHevI0fz3 n21Fh9R/a1ww6r03aTV+UpxY637L1y1tmOynPkIiJkf5qQgIh3Wz/G1X22faHy5JfHvVu9ItLHO UwQSaLE3At2JJPW5ClFSBu+tQQ73hsU/Z4e9ZwwPChiQolft/yyWxPa/RwSU9XJ/NTgaKQpn1VA AVhzJtLUps8ygWfsedfDhUfOPIAnZUdE3qKOvgFNDrSVZCgbSvFi3oiVvGfqZl8NETW6pKCqtFs 7h44NpQoOpobt07Johr6ZG7/Nft3gp82HbRpnMyPR2u912hYRAKflB9+9kWVWkvncDztoltNc6P VcEC7cDXQ1fUdLRYOc6pDUDt9WXmuQJJrm28HTZSqu+juUUMT0joXc9rEANEtg96xGBa1q6s7H9 ycK/bo9umfp9Nob1Hf0drLux5thIxx6d6X8tJ6SyH6bNPVSdtRwfT2oEaYdCNGK7UC7ElMTG1Bc O0WTnVYwtyyEZ1GpjW7brlByCWY97rw/tQZJe1n3ejPjd19cfXuWpt5ue19IwI6xJuH+sxVRdCO +dIPYDgDB3oCFI9vmYPgMH8ydf4oGsCID/XH5QXGi/7cli9jD+jls0cSwJMy2ckJNvUX+BOvqWE 4CGBU1IOu1gdN7qpkKS4UVybo84VVY0f2VRT154eqweLWaL5uwUsg2ZgJ8QCOLD+ckgKHoSnPJt mDAFI3eU2K7p2m/FwEwHQwCoCl1UgtfzQ9KzGeAiCmPx4NwLTrdaH1ZWqC1B0Hk1Q1KyLUZxEAl FPo846HM5rqDwqtk3+yocxm9LNG2z9zz9NMgljuPotOazGH589OPscsYpdL4oVGbn8vsA== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.840000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.6.1012-25670.006 X-MDID: 1600355776-PyN-p1lDpV9d Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: allow negative values in flow rule types X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Ori, On 9/17/20 10:47 AM, Ori Kam wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Thursday, September 17, 2020 9:50 AM >> >> On 9/16/20 8:21 PM, Gregory Etelson wrote: >>> From: Gregory Etelson >>> Sent: Tuesday, September 15, 2020 13:27 >>> To: Andrew Rybchenko ; Ajit Khaparde >> >>> Cc: dpdk-dev ; Matan Azrad ; Raslan >> Darawsheh ; Ori Kam ; Gregory >> Etelson ; Ori Kam ; NBU- >> Contact-Thomas Monjalon ; Ferruh Yigit >> >>> Subject: RE: [dpdk-dev] [PATCH v2 1/4] ethdev: allow negative values in flow >> rule types >>> >>> Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: allow negative values in flow >> rule types >>> On 9/15/20 7:36 AM, Ajit Khaparde wrote: >>> On Tue, Sep 8, 2020 at 1:16 PM Gregory Etelson >> wrote: >>> From: Gregory Etelson >>> >>> RTE flow items & actions use positive values in item & action type. >>> Negative values are reserved for PMD private types. PMD >>> items & actions usually are not exposed to application and are not >>> used to create RTE flows. >>> >>> The patch allows applications with access to PMD flow >>> items & actions ability to integrate RTE and PMD items & actions >>> and use them to create flow rule. >>> While we are reviewing this, some quick comment/questions.. >>> >>> Doesn't this go against the above "PMD >>> items & actions usually are not exposed to application and are not >>> used to create RTE flows."? >>> Why would an application try to use PMD specific private types? >>> Isn't this contrary to having a standard API? >>> >>> +1 >>> >>> I would like to clarify the purpose and use of private elements patch. >>> That patch is prerequisite for [PATCH v2 2/4] ethdev: tunnel offload model >> patch. >>> The tunnel offload API provides unified hardware independent model to >> offload tunneled packets, >>> match on packet headers in hardware and to restore outer headers of >> partially offloaded packets. >>> The model implementation depends on hardware capabilities. For example, >> if hardware supports inner nat, >>> it can do nat first and postpone decap to the end, while other hardware that >> cannot do inner nat must decap first >>> and run nat actions afterwards. Such hardware has to save outer header in >> some hardware context, >>> register or memory, for application to restore a packet later, if needed. Also, >> in this case the exact solution >>> depends on PMD because of limited number of hardware contexts. >>> Although application working with DKDK can implement all these >> requirements with existing flow rules API, >>> it will have to address each hardware specifications separately. >>> To solve this limitation we selected design where application quires PMD for >> actions, or items, >>> that are optimal for a hardware that PMD represents. Result can be a >> mixture of RTE and PMD private elements - >>> it's up to PMD implementation. Application passes these elements back to >> PMD as a flow rule recipe >>> that's already optimal for underlying hardware. >>> If PMD has private elements in such rule items or actions, these private >> elements must not be rejected by RTE layer. >>> >>> I hope it helps to understand what this model is trying to achieve. >>> Did that clarify your concerns ? >> >> There is a very simple question which I can't answer after >> reading it. >> Why these PMD specific actions and items do not bind >> application to a specific vendor. If it binds, it should >> be clearly stated in the description. If no, I'd like to >> understand why since opaque actions/items are not really >> well defined and hardly portable across vendors. > > You are correct, when looking at this patch as a stand a lone > patch using such action / items does bind the application to specific PMD. > first sometimes it is required, for example one vendor may introduce private action > to support some key costumer, or enable feature that is not supported using standard rte flow API. Good. So I understand it correctly. > The main reason for this patch is the tunnel API[1] as stated in the reply > from Gregory, the tunnel API exposes a public function that returns a list of > actions / items. The list is generated by the PMD, so using the API is not binding > since it is generic, but the action / items returned are private but the application is not aware of those actions / items, from it's point of view it called a generic function > and got actions that are configured to do the requested job. All the application needs to do is send the actions / item as actions / item when calling flow create. > > Does this answer your question? Yes, many thanks. I'm still trying to put the feature design in my head and your explanations helped a lot. May be it is just the same words as before, but in a bit different order and highlights. > [1] https://patches.dpdk.org/patch/76931/ >