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 BB982A04C7; Tue, 15 Sep 2020 06:47:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F177AE07; Tue, 15 Sep 2020 06:47:34 +0200 (CEST) Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) by dpdk.org (Postfix) with ESMTP id C8291160 for ; Tue, 15 Sep 2020 06:47:33 +0200 (CEST) Received: by mail-oo1-f48.google.com with SMTP id t3so429726ook.8 for ; Mon, 14 Sep 2020 21:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1dlfohGDONbpgLp73QHg/DWod0j7gk7yimuaeZMrt7Q=; b=XUuj73i1hTYVxnRr2BcdLwgm+UBK8m82u+9UNk1OHrd9DdAJL//a60ndJS4/QDEO3O pElx7vsCrJxBPnz/o+21hvP01k4wpzANtXVqpNqDV5L17vlK427vePGm4HlJNis0a1B2 VQRrg+t+tFTjmNoIr6p3EsntuHrxoleShxGxU= 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; bh=1dlfohGDONbpgLp73QHg/DWod0j7gk7yimuaeZMrt7Q=; b=JPl0dzcri+RfGuyopDnmXs6CEAwmSOS0GxzJ5t+PY7xZ+O9elEKi+9q8wcVRg5hBUA U7dkLriIAo4/BHKgJvXdVl48BMjz3ny9MNXfR2EdjCdZkmlDFvQnNIhXBJH8uG4M1+8n FFq1MdwdtwvDhJYIdmhRna5+cNF3sJa4cui8dhEWxjBw9NxhctiYtbgs3ClVwmZlxy0L NpujMOhgwnF3MqMfcaWKj35MrNIpcBTOHPj5hdJEKmfRQ2WoPI917xlcqhu82z/5VQ14 uClf+rJmrWsloDA2Kxwaexyiy1vGDSQ5eESeoKzyT8Hr/Ipp9+qmntK5a4p+E+A3u7QJ zvjQ== X-Gm-Message-State: AOAM532Plp4p3DCYFjvppLEm0uH4sbe2adVbaXeWMOZAjVefVg3Iz/Hd 4rWr+v9pvcyoisUeOSvC29+jsIJq4+lkfEOAAF/kSA== X-Google-Smtp-Source: ABdhPJx7ahkOH8IGcAeEaqqk1GD0VB0LvAzMDr+7FrRppOf1GqlmAlN56/c+mA1SmZ93FSaw9DEe62REY9Uqpb4urbc= X-Received: by 2002:a4a:ea99:: with SMTP id r25mr12946333ooh.15.1600145252946; Mon, 14 Sep 2020 21:47:32 -0700 (PDT) MIME-Version: 1.0 References: <20200625160348.26220-1-getelson@mellanox.com> <20200908201552.14423-1-getelson@nvidia.com> <20200908201552.14423-5-getelson@nvidia.com> In-Reply-To: <20200908201552.14423-5-getelson@nvidia.com> From: Ajit Khaparde Date: Mon, 14 Sep 2020 21:47:16 -0700 Message-ID: To: Gregory Etelson Cc: dpdk-dev , matan@nvidia.com, rasland@nvidia.com, orika@nvidia.com, Ori Kam , Wenzhuo Lu , Beilei Xing , Bernard Iremonger Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 4/4] app/testpmd: support tunnel offload API 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 Tue, Sep 8, 2020 at 1:17 PM Gregory Etelson wrote: > ::::snip:::: > @@ -1520,6 +1574,75 @@ port_flow_create(portid_t port_id, > } > id = port->flow_list->id + 1; > } > + if (tunnel_ops->enabled) { > + int ret; > + pft = port_flow_locate_tunnel(port, tunnel_ops->id); > + if (!pft) { > + printf("failed to locate port flow tunnel #%u\n", > + tunnel_ops->id); > + return -ENOENT; > + } > + if (tunnel_ops->actions) { > + uint32_t num_actions; > + const struct rte_flow_action *aptr; > + > + ret = rte_flow_tunnel_decap_set(port_id, > &pft->tunnel, > + &pft->pmd_actions, > + > &pft->num_pmd_actions, > + &error); > Does tunnel_ops always indicate decap? Shouldn't there be a check for encap/decap? Or check for direction? > + if (ret) { > + port_flow_complain(&error); > + return -EINVAL; > + } > ::::snip:::: > >