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 3C375A00C5; Sun, 26 Apr 2020 19:02:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8E7AE1C0B9; Sun, 26 Apr 2020 19:02:29 +0200 (CEST) Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by dpdk.org (Postfix) with ESMTP id E83221C06D for ; Sun, 26 Apr 2020 19:02:27 +0200 (CEST) Received: by mail-pf1-f193.google.com with SMTP id x2so3887518pfx.7 for ; Sun, 26 Apr 2020 10:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BEIVycSkx2QitPQPVf7HRMVUJlCRYzpTQxh3cyELrQs=; b=Jk/xwV2qHUatDxbKTiPBRYNjvn7kzx5ZSF+x1MfYmE/RyloAjrwZIpXO6tv8IC+0hv yg11iBeD5EGk0GUNZq9oNPwWn1ugQAALuUXNqPjvv+cbPZ88BSJl1gYv5j8qX867RfUi EWRMQbViZWgk808KWk3OIkdbldlA2c5+tIRjI4VtYPH6lRlg35pV6KIzXbB1WTRDpq/S iuV5q2l8OKzjPLbV4kPw53Yso10FO5uXApMtDgzMu0jlT5lQwBAevTMkAINkJvKgWLVm E2JMrjgjjAPyUOJfbhpT+yTvzk3jPztRT7+ZZzNsRzftE6JmNpIrm/UozD2BBG+WUnML b84Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=BEIVycSkx2QitPQPVf7HRMVUJlCRYzpTQxh3cyELrQs=; b=moKKJyCvxXnaOJFPH5NemqCSDfGgbXhMkmCWkZnOsV7FNoXHDXBmt9woe+2tfP8bIC SOev1Dj/Io9DhH5dsUTJgwWgzNFkuG8sHq0QxuakvuIAnort+nflNKvRh7no3CtTGbNJ Fs0lsWTJ+X7nXeqGsOlSE+8uCuV4EyKJleo9huQczcIRE2w+WRtxazqa9rZyjp4HMtck jAPP/u8qlpzuQVVf1RPJt+Hh1GFy12wRrWLA94nAmuuGF4t58pYv5K66sMzDnQXQ2JMx uR+OA6AcnC83iwx+mppewX7WsU+MgddPx+oEOIS0I+D34wP6f/bomgR2UdanNYB6cNs4 4SrQ== X-Gm-Message-State: AGi0PubVzCyCbxDw9x8nfO9SlBXZvSWlV6XPGNq8jQyCVqMHOwQ0jN3L whYVORa2AyEbA/uS+cKQseA+zA== X-Google-Smtp-Source: APiQypINb3xI9voRCPp0J3b8Z5UC9k9XUUZRv0UOArsEGPQPsQtdu06ozMVmxIncozi+iBDj0DG/4g== X-Received: by 2002:a62:fc82:: with SMTP id e124mr20035827pfh.126.1587920546796; Sun, 26 Apr 2020 10:02:26 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 10sm10229766pfn.204.2020.04.26.10.02.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Apr 2020 10:02:26 -0700 (PDT) Date: Sun, 26 Apr 2020 10:02:18 -0700 From: Stephen Hemminger To: Dekel Peled Cc: Andrew Rybchenko , Ori Kam , "john.mcnamara@intel.com" , "marko.kovacevic@intel.com" , Thomas Monjalon , "ferruh.yigit@intel.com" , "dev@dpdk.org" , Asaf Penso Message-ID: <20200426100218.35d50cfb@hermes.lan> In-Reply-To: References: <7b474ff0-7e9c-aa01-637b-61cc61d34aa4@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] doc: refine ethernet and VLAN flow rule items 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, 26 Apr 2020 09:18:54 +0000 Dekel Peled wrote: > Thanks, PSB. > > > -----Original Message----- > > From: Andrew Rybchenko > > Sent: Saturday, April 25, 2020 5:00 PM > > To: Dekel Peled ; Ori Kam ; > > john.mcnamara@intel.com; marko.kovacevic@intel.com; Thomas Monjalon > > ; ferruh.yigit@intel.com > > Cc: dev@dpdk.org; Asaf Penso > > Subject: Re: [PATCH] doc: refine ethernet and VLAN flow rule items > > > > On 4/23/20 9:30 PM, Dekel Peled wrote: > > > Specified pattern may be translated in different manner. > > > For example the pattern "eth / ipv4" can be translated to match > > > untagged packets only, since the pattern doesn't specify a vlan item. > > > > vlan -> VLAN > > I will change to uppercase. > > > > > > It can also be translated to match both tagged and untagged packets, > > > for the same reason. > > > This patch updates the rte_flow documentation to clearly specify the > > > required pattern to use. > > > For example: > > > To match tagged ipv4 packets, the pattern "eth type is 0x8100 / vlan / > > > ipv4 / end" should be used. > > > > Isn't eth / vlan / ipv4 /end sufficient? What's the difference? > > I guess later should allow any VLAN TPID, but it is greyish since it is HW > > dependent. > > In the example I wanted to show explicit rule, to emphasize the importance of detailed pattern structure. > > > > > > To match untagged ipv4 packets, the pattern "eth type is 0x0800 / > > > ipv4 / end" should be used. > > > > What about eth / ipv4 / end? > > Does usage of ipv4 assume that EtherType is 0x0800? > > Same as above. > > > > > > To match both tagged and untagged packets, the pattern "eth / end" > > > should be used. > > > > The interesting question is what should be used if I want either tagged or > > untagged IPv4 packets. I think it worse to mention to make the picture > > complete. > > To match any IPV4 packet, either tagged or untagged, need to apply two rules. > One for tagged packets and the other for untagged packets. > I will add this example as well. > > > > > > Signed-off-by: Dekel Peled All this reminds me that "code is the best documentation" and there is no working code that does a complete software implementation of the rte_flow engine. This means the actual interpretation of what the rte_flow means is left to documentation and hardware vendors choices in implementation.