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 5FC44A04DB; Wed, 14 Oct 2020 19:24:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D98241DAC0; Wed, 14 Oct 2020 19:23:58 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7D6E61B708 for ; Wed, 14 Oct 2020 19:23:56 +0200 (CEST) IronPort-SDR: I5a4mlhYQizj2fyoeldYKjsim9yXMopJG2Z1fmSHZQg6tb75LqJQVZ1sdUIrihChJOJxppUCfb 2u+IGAwlyvcg== X-IronPort-AV: E=McAfee;i="6000,8403,9774"; a="165365204" X-IronPort-AV: E=Sophos;i="5.77,375,1596524400"; d="scan'208";a="165365204" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2020 10:23:54 -0700 IronPort-SDR: M7RMFVwEGuAGL/RRHJJlEuqfO6KHXGs2K6Hgbp2u0bRWayyKne7KZz/cgAiEGFM5vz4hfhf+ub MUBcUjSGBmKw== X-IronPort-AV: E=Sophos;i="5.77,375,1596524400"; d="scan'208";a="463959801" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.212.224]) ([10.213.212.224]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2020 10:23:53 -0700 To: Gregory Etelson , Sriharsha Basavapatna , "dev@dpdk.org" Cc: Eli Britstein , Oz Shlomo , Ori Kam References: <20200625160348.26220-1-getelson@mellanox.com> <20201004135040.10307-1-getelson@nvidia.com> <20201004135040.10307-3-getelson@nvidia.com> From: Ferruh Yigit Message-ID: Date: Wed, 14 Oct 2020 18:23:49 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 2/4] ethdev: tunnel offload model 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" On 10/7/2020 1:36 PM, Gregory Etelson wrote: > Hello Harsha, > >> -----Original Message----- > > [snip] >> >> Tunnel vport is an internal construct used by one specific >> application: OVS. So, shouldn't the rte APIs also be application >> agnostic apart from being vendor agnostic ? For OVS, the match fields >> in the existing datapath flow rules contain enough information to >> identify the tunnel type. > > Tunnel offload model was inspired by OVS vport, but it is not part of the existing API. > It looks like the API documentation should not use that term to avoid confusion. > > [snip] > > [snip] >> >> Wouldn't it be better if the APIs do not refer to vports and avoid >> percolating it down to the PMD ? My point here is to avoid bringing in >> the knowledge of an application specific virtual object (vport) to the >> PMD. >> > > As I have mentioned above, the API description should not mention vport. > I'll post updated documents. > >> Here's some other issues that I see with the helper APIs and >> vendor-specific variable actions. >> 1) The application needs some kind of validation (or understanding) of >> the actions returned by the PMD. The application can't just blindly >> use the actions specified by the PMD. That is, the decision to pick >> the set of actions can't be left entirely to the PMD. >> 2) The application needs to learn a PMD-specific way of action >> processing for each vendor. For example, how should the application >> handle flow-miss, given a different set of actions between two vendors >> (if one vendor has already popped the tunnel header while the other >> one hasn't). >> 3) The end-users/customers won't have a common interface (as in, >> consistent actions) to perform tunnel decap action. This becomes a >> manageability/maintenance issue for the application while working with >> different vendors. >> >> IMO, the API shouldn't expect the PMD to understand the notion of >> vport. The goal here is to offload a flow rule to decap the tunnel >> header and forward the packet to a HW endpoint. The problem is that >> we don't have a way to express the "tnl_pop" datapath action to the HW >> (decap flow #1, in the context of br-phy in OVS-DPDK) and also we may >> not want the HW to really pop the tunnel header at that stage. If this >> cannot be expressed with existing rte action types, maybe we should >> introduce a new action that clearly defines what is expected to the >> PMD. > > Tunnel Offload API provides a common interface for all HW vendors: > Rule #1: define a tunneled traffic and steer / group traffic related to > that tunnel > Rule #2: within the tunnel selection, run matchers on all packet headers, > outer and inner, and perform actions on inner headers in case of a match. > For the rule #1 application provides tunnel matchers and traffic selection actions > and for rule #2 application provides full header matchers and actions for inner parts. > The rest is supplied by PMD according to HW and rule type. Application does not > need to understand exact PMD elements implementation. > Helper return value notifies application whether it received requested PMD elements or not. > If helper completed successfully, it means that application received required elements > and can complete flow rule compilation. > As the result, a packet will be fully offloaded or returned to application with enough > information to continue processing in SW. > > [snip] > > [snip] > >>> Miss handling >>> ------------- >>> Packets going through multiple rte_flow groups are exposed to hw >>> misses due to partial packet processing. In such cases, the software >>> should continue the packet's processing from the point where the >>> hardware missed. >> >> Whether the packet goes through multiple groups or not for tunnel >> decap processing, should be left to the PMD/HW. These assumptions >> shouldn't be built into the APIs. The encapsulated packet (i,e with >> outer headers) should be provided to the application, rather than >> making SW understand that there was a miss in stage-1, or stage-n in >> HW. That is, HW either processes it entirely, or punts the whole >> packet to SW if there's a miss. And the packet should take the normal >> processing path in SW (no action offload). >> >> Thanks, >> -Harsha > > The packet is provided to the application via the standard rte_eth_rx_burst API. > Additional information about the HW packet processing state is provided to > the application by the suggested rte_flow_get_restore_info API. It is up to the > application if to use such provided info, or even if to call this API at all. > > [snip] > > Regards, > Gregory > Hi Gregory, Sriharsha, Is there any output of the discussion?