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 84621A0540; Mon, 13 Jul 2020 17:13:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 61E401D618; Mon, 13 Jul 2020 17:13:01 +0200 (CEST) Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by dpdk.org (Postfix) with ESMTP id 14E201D615 for ; Mon, 13 Jul 2020 17:13:00 +0200 (CEST) Received: by mail-qv1-f52.google.com with SMTP id di5so5894932qvb.11 for ; Mon, 13 Jul 2020 08:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZmsFLVJgkW2jwVCzfj8/q0JLl07f8/PyibliPGuPXc8=; b=jlIWMu8/nZYYMKrSeqsLO3O+oyab+QqSCd5eQkSg/YwVAlT1m6KFd3gu23pPa6QjiO Lr5ThCKg1qQLDwxp3BDJrMP9S64PCSKWI+5LBzgCstk9LWrn8mg/gIhMT6CGYWWzqS9y QklShU99ZaAfVM/M1SQIys3qFgZizl03etkDvU9oJED9+sw2EN7iZinwO+GvwT80sIbA /8VsucKFnvsbQhGl0BF4m2IQpDtcbfI0C28jWur6tMJK+Qz5QvsUAPEi0E9PAKS+cSfl diHKqfnN4R6O9Evm81BmWP7DgN6PjYGEXLoVeQV50iYg7VJkE4B4PJF8SJQG6ANKnIn5 FQpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZmsFLVJgkW2jwVCzfj8/q0JLl07f8/PyibliPGuPXc8=; b=fq3IxaNd5h4ZauMD9AV4Q6FnDcqnq5BcYQ47P42hAOFNtYFbnPnM6+JgQmKm5W9MOC 4KISjQcZtxAZYykpr/27CTUpD1hFpS16QlevygRb+6hYwovkBUyYg8ig+cxnDgoGexbd /tEayNR03jIcbKmDuotvpJ7rxjDAhMgdBWZzPtu99LSkE+bZs7ambOGR+FCHvZFv7Itr TPFF735LbAJ3PTJnDk+sXJ4IyyzCfErycQ183npDvB1YBew1YwNzIecCOqXHYFIXOn7g TlDaa5KmRXePgq67P+pZzIr28cUR+MPnvNL8lGJTqTiBYS1NRXI0UULkwN6Fqtir98DZ 1JRg== X-Gm-Message-State: AOAM5301grvS/ePoqnF4wrm40MO2yzdb6+hM7b+OYvxu/T6N47LOyS4H m795oIeukC8CJL1cKmNIMzZZ6h1nQ7bg6aMHFck= X-Google-Smtp-Source: ABdhPJyLW2i4+JBT6KJdoJEawtiVLUzqyoXF24sqQJkT3FmNoVje9ymzptLN5lVkmKqUFmkZDWXDpchsauUMoBIyKY8= X-Received: by 2002:a05:6214:13c6:: with SMTP id cg6mr81697358qvb.160.1594653179352; Mon, 13 Jul 2020 08:12:59 -0700 (PDT) MIME-Version: 1.0 References: <5862610e-76cc-7783-7d66-2b2173eeb974@mellanox.com> <395d4c2d-198f-67e3-a6b2-f40773a0e196@mellanox.com> In-Reply-To: <395d4c2d-198f-67e3-a6b2-f40773a0e196@mellanox.com> From: William Tu Date: Mon, 13 Jul 2020 08:12:22 -0700 Message-ID: To: Oz Shlomo Cc: dev@dpdk.org, Thomas Monjalon , Ori Kam , Eli Britstein , Sriharsha Basavapatna , Hemal Shah Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC] - Offloading tunnel ports 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 Sun, Jul 12, 2020 at 9:52 PM Oz Shlomo wrote: > > Hi William, > > On 7/12/2020 7:34 PM, William Tu wrote: > > Hi Oz, > > snip > >> > >> Openvswitch, for example, uses two flows: > >> 1. classification flow - setting the virtual port representing the tun= nel type > >> For example: match on udp port 4789 actions=3Dtnl_pop(vxlan_vport) > >> 2. steering flow according to outer and inner header matches > >> match on in_port=3Dvxlan_vport and outer/inner header matches actions= =3Dforward to port X > >> The benefits of multi-flow tables are described in [1]. > >> > >> Offloading tunnel ports > >> ----------------------- > >> Tunnel ports introduce a new stateless field that can be matched on. > >> Currently the rte_flow library provides an API to encap, decap and mat= ch > >> on tunnel headers. However, there is no rte_flow primitive to set and > >> match tunnel virtual ports. > >> > >> There are several possible hardware models for offloading virtual tunn= el port > >> flows including, but not limited to, the following: > >> 1. Setting the virtual port on a hw register using the rte_flow_action= _mark/ > >> rte_flow_action_tag/rte_flow_set_meta objects. > >> 2. Mapping a virtual port to an rte_flow group > >> 3. Avoiding the need to match on transient objects by merging multi-ta= ble > >> flows to a single rte_flow rule. > >> > >> Every approach has its pros and cons. > >> The preferred approach should take into account the entire system arch= itecture > >> and is very often vendor specific. > > > > Are these three solutions mutually exclusive? > > And IIUC, based on the description below, you're proposing solution 1, = right? > > and the patch on OVS is using solution 2? > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpat= chwork.ozlabs.org%2Fproject%2Fopenvswitch%2Fcover%2F20200120150830.16262-1-= elibr%40mellanox.com%2F&data=3D02%7C01%7Cozsh%40mellanox.com%7C4ece31d7= 45d246e30f9308d8268185cb%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63730= 1685025981024&sdata=3DmPCFG468xYkHRX3HJRkrrDix4hfDLstAZtlILQfGxr8%3D&am= p;reserved=3D0 > > > > From the OVS patchset we learned that it might be better to provide each= vendor > with the flexibility to implement its optimal hardware model. > We propose this design as an alternative to the submitted OVS patchset. > > This patch is designed to provide an abstract API. > As such, any of the solutions listed above, or others, are possible. > The Mellanox PMD is planned to implemented solution 2. > > > >> > >> The proposed rte_flow_tunnel_port_set helper function (drafted below) = is designed > >> to provide a common, vendor agnostic, API for setting the virtual port= value. > >> The helper API enables PMD implementations to return vendor specific c= ombination of > >> rte_flow actions realizing the vendor's hardware model for setting a t= unnel port. > >> Applications may append the list of actions returned from the helper f= unction when > >> creating an rte_flow rule in hardware. > >> > >> Similarly, the rte_flow_tunnel_port_match helper (drafted below) allow= s for > >> multiple hardware implementations to return a list of fte_flow items. > >> > > And if we're using solution 1 "Setting the virtual port on a hw > > register using the rte_flow_action_mark/ > > rte_flow_action_tag/rte_flow_set_meta objects." > > For the classification flow, does that mean HW no longer needs to > > translate tnl_pop to mark + jump, > > but the HW can directly execute the tnl_pop(vxlan_vport) action > > because the outer header is > > saved using rte_flow_set_meta? > > > > In this case we would need to map the outer header fields to a unique id. > This can be done either from the datapath (for capable hardware) or from = the > flows. The latter option, requires the flow to match on the outer header = fields > that should be stored. OVS matches on the outer header fields only after = it > classifies the tunnel port (i.e. after the tnl_pop action). > Hi Oz, Thanks for your explanation. It's much more clear to me now. William