From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 0E39D2C5; Tue, 7 Aug 2018 16:01:17 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 867AF214E0; Tue, 7 Aug 2018 10:01:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 07 Aug 2018 10:01:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=KAIsSdMGzQr87sH3XmROHbGy/J 0ikPePwWG3zWs8MoM=; b=JWy3vmeWPt00tJHivm0RYs0UatQJZ8BijSDD2fDmtZ rJy8R1z2ixlRBK/yAbY7s13rpwbPMMZiJ7VTtIvhweUaSVfldBHbL4twwW9FR+iz ShlmvexIWm6IXZwEcS+fZZBYDkdbZ92NPnpi1G68Z+WfBuC7Uv9RR1l6Kc5ze5CC U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=KAIsSd MGzQr87sH3XmROHbGy/J0ikPePwWG3zWs8MoM=; b=vQcReVroyjdxTHplIy5m+H Ru+81RHH4OkniMOjVb7v3x8KeTDbToZ1WatciBEty4N6FrBTA+VeT53MOsG66t2q QcjbIO0H7+wwT9G2OSvh2BDEkzw6to0wGLH2ZTuB0hWvC52zG79bzLdso8jB7/Au djaUMqI+fMqgNlRn7yaGQnZFcAIY8lQ9js1X2fxhWt4HGGx2FKflt+Xvf7Ope7pT ohe3ozXIDufP1ozzt64dGHX5eDzqUmU31x2v0NpO38+/0j8aMd1v8s/7b0LsBJJl rb2p6FOmeUZSmHdvBMnHmckPSMBUW7Kh466DmUdGkywSyVzcqTPjUjIEag5bOW6w == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (91.198.136.77.rev.sfr.net [77.136.198.91]) by mail.messagingengine.com (Postfix) with ESMTPA id D351110269; Tue, 7 Aug 2018 10:01:14 -0400 (EDT) From: Thomas Monjalon To: Matan Azrad Cc: stable@dpdk.org, Adrien Mazarguil , Keith Wiles , Ophir Munk , dev@dpdk.org Date: Tue, 07 Aug 2018 16:01:11 +0200 Message-ID: <7481994.pu8tkS1Bg6@xps> In-Reply-To: <20180806131626.GW5211@6wind.com> References: <1533205980-7874-1-git-send-email-matan@mellanox.com> <1533553127-18664-1-git-send-email-matan@mellanox.com> <20180806131626.GW5211@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v2] net/tap: fix zeroed flow mask configurations 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: , X-List-Received-Date: Tue, 07 Aug 2018 14:01:18 -0000 06/08/2018 15:16, Adrien Mazarguil: > On Mon, Aug 06, 2018 at 10:58:47AM +0000, Matan Azrad wrote: > > The rte_flow meaning of zero flow mask configuration is to match all > > the range of the item value. > > For example, the flow eth / ipv4 dst spec 1.2.3.4 dst mask 0.0.0.0 > > should much all the ipv4 traffic from the rte_flow API perspective. > > > > From some kernel perspectives the above rule means to ignore all the > > ipv4 traffic (e.g. Ubuntu 16.04, 4.15.10). > > > > Due to the fact that the tap PMD should provide the rte_flow meaning, > > it is necessary to ignore the spec in case the mask is zero when it > > forwards such like flows to the kernel. > > So, the above rule should be translated to eth / ipv4 to get the > > correct meaning. > > > > Ignore spec configurations when the mask is zero. > > > > Fixes: de96fe68ae95 ("net/tap: add basic flow API patterns and actions") > > Cc: stable@dpdk.org > > > > Signed-off-by: Matan Azrad > > --- > > drivers/net/tap/tap_flow.c | 18 +++++++++--------- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > > > V2: > > Address Adrien comments to fix also the spec=0 check. > > Thanks, > > Acked-by: Adrien Mazarguil Applied, thanks