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 B7014A0487 for ; Thu, 4 Jul 2019 14:13:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9756B1BE08; Thu, 4 Jul 2019 14:13:45 +0200 (CEST) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 331BF1BDFA for ; Thu, 4 Jul 2019 14:13:44 +0200 (CEST) Received: by mail-wm1-f68.google.com with SMTP id z23so5907581wma.4 for ; Thu, 04 Jul 2019 05:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GQKcljQ/KCHV7wenpXEI7eDxPO1CuLQsaIppOU8a9wU=; b=gmdRAZViefOxV9sfBSLPQeG4Wy92QhTMqUGyXjTMUhkd6aKoM8pq0MSNoxbLQJudTl /pZzpUkB1wV8NqgdcEgUY4r03IvvJmiri/58zz2UOG3KDubnX3qzqn+mOxvTWqyCU86c WK4F+sLpCiI0WMll/eMajc3NEBTPBku9I7gmSL1n5EcxVSVDgZF28WmZX7SIWoKXBR8g Fa6fpt161qz+7KB4SJPreDRKlJt9cnTjmt0+I7qSmyqj74RSzN9oJcITpoggKz/n1RYh QNXxhMvB9g6ANEkYSsSWpAsckxr7KBQHMNQzkJkuinJXXYCqE+2PlmpVaMdMw1OblwIb 9ogw== 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:references :mime-version:content-disposition:in-reply-to; bh=GQKcljQ/KCHV7wenpXEI7eDxPO1CuLQsaIppOU8a9wU=; b=DjUmQSBAtqE8OwEnqM2R5/+KHvTU+4efGreXo/MxRHulb9tdbIieUzMgwOJ/kWi/Ll hg/Q/myGHsIUZ+a5a4YJipKbehzC9LgyXIjTlB7XZz22/N1PZzGquaL5lNMZrimxV/rE /2SElXUNUWPZ8Su7kxtGRzOg1wxbFcb9xJ6wD1k9rJ2TM0Ufo9WuOsawmR7Wx+nzwuDh p4m4iRehOqKHtwXvo+lMmt+bNXsxyOXJu49nxxUJNAw+n+m9Uz97GSN0WThr6Q28o6E/ Vie/gKWUGCi+XF9Xu+Js7rkmKYybfs0zSXGvveadraSYV/g3HFLbiEc7N5Y5+ZaP57nQ 4zLw== X-Gm-Message-State: APjAAAXwaKtlRLmrsis+1h95r411J1lFqVclVmdbeF3z7JGORQ2Hfqa+ 4NbS/ISl9jJ8N6W3fdqhE1vS7Q== X-Google-Smtp-Source: APXvYqwwkxnxoKFeXOO0XnIIqhUVHbfomg8J8vcCYqgyZDnK+pbTRD5K/W+Hx5HSof+ZPx3aPh5p/g== X-Received: by 2002:a1c:2dd2:: with SMTP id t201mr12922564wmt.109.1562242423837; Thu, 04 Jul 2019 05:13:43 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id o11sm4244893wmh.37.2019.07.04.05.13.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 05:13:42 -0700 (PDT) Date: Thu, 4 Jul 2019 14:13:41 +0200 From: Adrien Mazarguil To: Jack Min Cc: Ori Kam , Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , John McNamara , Marko Kovacevic , "dev@dpdk.org" Message-ID: <20190704121341.GM4512@6wind.com> References: <20190624154018.128379-1-jackmin@mellanox.com> <5d9e2fcd3a1bf439b0cff354ca5b5bf1f43e090d.1562058723.git.jackmin@mellanox.com> <20190703152516.GI4512@6wind.com> <20190704055231.bpwbvbd6g2zosbl6@mellanox.com> <20190704095202.GL4512@6wind.com> <20190704115625.umjpfsztht3ypcnn@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190704115625.umjpfsztht3ypcnn@mellanox.com> Subject: Re: [dpdk-dev] [PATCH v4 4/4] app/testpmd: match GRE's key and present bits 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 Thu, Jul 04, 2019 at 11:56:35AM +0000, Jack Min wrote: > On Thu, 19-07-04, 11:52, Adrien Mazarguil wrote: > > On Thu, Jul 04, 2019 at 05:52:43AM +0000, Jack Min wrote: > > > On Wed, 19-07-03, 17:25, Adrien Mazarguil wrote: > > > > On Tue, Jul 02, 2019 at 05:45:55PM +0800, Xiaoyu Min wrote: > > > > > support matching on GRE key and present bits (C,K,S) > > > > > > > > > > example testpmd command could be: > > > > > testpmd>flow create 0 ingress group 1 pattern eth / ipv4 / > > > > > gre crksv is 0x2000 crksv mask 0xb000 / > > > > > gre_key key is 0x12345678 / end > > > > > actions rss queues 1 0 end / mark id 196 / end > > > > > > > > > > Which will match GRE packet with k present bit set and key value is > > > > > 0x12345678. > > > > > > > > > > Signed-off-by: Xiaoyu Min [...] > > > Well, actullay, when a user explicitly set spec/mask K as "0" and still > > > provide gre_key item, MLX5 PMD will implicitly set match on K bit as > > > "1", just ingore the K bit set by user. > > > > Not good then. You should spit an error out if it's an impossible > > combination. You can't match both K == 0 *and* a GRE key, unless perhaps if > > key mask is also 0, e.g.: > > > > gre crksv is 0x0000 crksv mask 0xb000 / > > gre_key value spec 0x00000000 value mask 0x00000000 > > > > Never thought man will wirte thing like this, they don't wanna match > gre_key why put the item there ? > But, since you have raised this example, I'll update PMD part to handle this. It's just an example of valid yet convoluted command mind you, I'm not forcing you to support it, however if you don't, you must raise an error, you can't just ignore the K bit if user provides GRE_KEY. [...] > > Depends. They may want to match all GRE traffic with a key, doesn't matter > > which, in order to process it through a different path. To do so they could > > either: > > > > 1. Use the GRE item only to match K bit == 1. > > > > 2. Use the GRE_KEY item to match a nonspecific key value (mask == 0). > > > > 3. Use a combination of both. > > > > I think you can easily support all three of them with mlx5 if you support > > partial masks on GRE keys (I haven't checked), even if you're unable to > > specifically match the K bit itself. > > > > Already support this. OK, nice. [...] > > > Well, actully, we also wanna testpmd can match on C,S bits with K bit > > > together so we can test on gre packet with key only or csum + key, or > > > csum + key + sequence. > > > > OK no problem. Perhaps you could make this easier by allowing users to match > > individual bits, let me explain: > > > > The flow command in testpmd is a direct interface to manipulate rte_flow's > > structures. The "crksv" field doesn't exist in rte_flow_item_gre, its name > > is "c_rsvd0_ver". Testpmd must use the same in its command and internal > > code. > > > > However since bit-masks are usually a pain to mentally work out, you can > > provide extras for convenience. The "types" field of the RSS action > > (ACTION_RSS_TYPES) is an extreme example of this approach. > > > > So I suggest adding ITEM_GRE_C_RSVD0_VER taking a 16-bit value like CRKSV, > > and complete it with ITEM_GRE_C_BIT, ITEM_GRE_S_BIT and ITEM_GRE_K_BIT > > addressing the individual bits you would like to expose for convenience. > > > > So something like: > eth / ipv4 / gre c_rsvd0_ver c_bit is 0 s_bit is 0 k_bit is 1 / ... > > Is it right? Looks like "c_rsvd0_ver" is incomplete, I assume you meant: eth / ipv4 / gre c_rsvd0_ver is 0 c_bit is 0 s_bit is 0 k_bit is 1 / ... And yes it's valid. Of course since nothing is matched by default, users will typically not provide c_rsvd0_ver at all and focus on the relevant bits for their use case: eth / ipv4 / gre k_bit is 1 / ... Another suggestion, use BOOLEAN instead of INTEGER type for C/K/S to support other binary expressions: eth / ipv4 / gre k_bit is on / ... -- Adrien Mazarguil 6WIND