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 5158DA04B7; Sun, 4 Oct 2020 07:41:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2C0411BEE6; Sun, 4 Oct 2020 07:40:59 +0200 (CEST) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by dpdk.org (Postfix) with ESMTP id 6A5E01BEE4 for ; Sun, 4 Oct 2020 07:40:56 +0200 (CEST) Received: by mail-oi1-f193.google.com with SMTP id z26so5516508oih.12 for ; Sat, 03 Oct 2020 22:40:56 -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=PFAaNagQZc9OtcVZ1iKQZShJZw391vOL1plo5ymxgu0=; b=SqEWf4V8yiPQvSXCClykOupnaHGTxnKpD/Hy5K5ROikmKYY2EbHVVWeYPo3UzY99jB 3BiL7VjX9xnssLqi+YIyjS9mCU4i0EdT1QJlOSSpaHhRMiNNIC9XF19k2VrzH1ml+R83 iEuK64t0O6efn4LIZhtLnUu9VwtGwMNYOguo0= 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=PFAaNagQZc9OtcVZ1iKQZShJZw391vOL1plo5ymxgu0=; b=Uk9otChCX3X5XSxjiRJJjIaJrFxHnW+czhSxztH7VSU33wwNQpRNehUMHhOhlGxpWg 6T7JvIR8tNRSGv8PDXt6kdDRsi8arvumfC3PI18aPRgh4+ts5+mcl+meDgd1Bq2ciPg8 yC85OCRrr/rIB/UZLq4vR4gN7u2cN/ftPvZb6I6Pfp47U5xFQoRyoqrcX51nENZDgkel Lkp572bQ4IL03XHjiWga1wG8vd9pZBVDnpWCr9j5b+MghjOYCXeWxGBjUZP31nmarr3G WXp8F+OzhUD1yRiQmtKVaCF1fX0hzZWVJxjldxDEs9mTGWVTrfrqiENQnVGALl0MdyVj UoTA== X-Gm-Message-State: AOAM532CUl+wX92B2iFPyHuzPyMBOQtmltjfhWZTbQiGngWyboLDAwhH 0CHj1COUvVMMCs0rhlxIfMQuM8XhvaENoZsltLV5mg== X-Google-Smtp-Source: ABdhPJzjvZnkD4daMAWukEaQfnLXVq68IfuIaHJF09GJgTdvl+RriM0U6o4yIr+KjlLge0ZL+Pg4o0//FxtLIRi2vEY= X-Received: by 2002:aca:31d4:: with SMTP id x203mr2108107oix.168.1601790054592; Sat, 03 Oct 2020 22:40:54 -0700 (PDT) MIME-Version: 1.0 References: <20200625160348.26220-1-getelson@mellanox.com> <20200930091854.19768-1-getelson@nvidia.com> <20200930091854.19768-5-getelson@nvidia.com> In-Reply-To: From: Ajit Khaparde Date: Sat, 3 Oct 2020 22:40:38 -0700 Message-ID: To: Gregory Etelson Cc: dpdk-dev , Matan Azrad , Raslan Darawsheh , Ori Kam , Wenzhuo Lu , Beilei Xing , Bernard Iremonger , John McNamara , Marko Kovacevic , Eli Britstein , Oz Shlomo Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 4/4] app/testpmd: add commands for 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" Gregory, [snip] > > > testpmd> flow tunnel 0 type vxlan > > > port 0: flow tunnel #1 type vxlan > > > testpmd> flow create 0 ingress group 0 tunnel_set 1 > > > pattern eth /ipv4 / udp dst is 4789 / vxlan / end > > > actions jump group 0 / end > > > > I could not get enough time to completely look at this. > > Can you help understand the sequence a bit. > > > > So when this flow create is issued, it looks like the application issues > > one of the helper APIs. > > In response the PMD returns the vendor specific items/actions. > > So what happens to the original match and action criteria provided by the > > user > > or applications? > > > > Does the vendor provided actions and items in the tunnel descriptor > > take precedence over what was used by the application? > > > > And is the criteria provided by the PMD opaque to the application? > > Such that only the PMD can decipher it when the application calls it > > for subsequent flow create(s)? > > > > Flow rules that implement tunnel offload API are compiled from application and > PMD actions and items. Both application and PMD elements are equally important > for offload rule creation. Application is "aware" what type of tunnel offload > flow rule, decap_set or match, it builds. Therefore, application elements are > created according to tunnel offload rule type and the API helper function, that > matches selected rule type, is activated to provide PMD elements. > PMD elements are opaque. When all elements are present, application concatenates > PMD items with application items and PMD actions with application actions. > As the result application will have pattern & actions arrays for flow rule > creation. For the decap_set rule, the API expects application to provide pattern > that describes a tunnel and the JUMP action, although the JUMP is not strictly > required. And for the match rule, application pattern should describe packet > headers and actions refer to inner parts. Since the application concatenates the elements provided by the PMD with that of its own, the PMD is free to validate, parse and use a subset or all of them? [snip]