From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by dpdk.org (Postfix) with ESMTP id F3BA01B479 for ; Mon, 6 Aug 2018 11:41:11 +0200 (CEST) Received: by mail-wm0-f65.google.com with SMTP id q8-v6so13623873wmq.4 for ; Mon, 06 Aug 2018 02:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3HGOUMH8q/rvFmu+/mI+QCOFP7juuWl8lFwCWnLnqds=; b=WqRlWPmCn9GPP2JWJY4mOmbvbOoupMYM9WtebSpz/Fu+jf/v8Xp9p+0aAfaQ/RDVao OwA2Ul6tU+HDnztZ2dwndKkCYT8QXMR23jjnpGXNiqpLjOOaXE0Vu7uC14H8VqNsEqHa rWAFY51MKglthG9il0oZhiP8eHN1qwGPAjv+uR6CTi1golHVWePbW/1ZCitSspwJBgFk 47b2Y3S8zw4MbIAaIIf0tFEKjQRj0VFb8TwKKH5RMXJ+ZLUJiLHPz43LiuKmoqNq8Juu JQUnjIibWdLC29h/2+VAvXDGAGaQT/dyqyKWzg6w/6YrgoY4JIgumhPynJtZA4YdzxdG 847A== 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=3HGOUMH8q/rvFmu+/mI+QCOFP7juuWl8lFwCWnLnqds=; b=aVp/K2SDNgKQGMISbPUroJvNo1gL7JmXg5QaZOajn5+R67ADsfjkSjpqX5EPRAogFp JLmukSlvg6yGy5NiAftH9oEOJ6+roDQvrz48orNSHurkCJKe7Sx6fWlTGgFgQB3enAJP O7igDOYUjisd2mjmWVoQ/68DSXa0mDECNr+AAYcs9M5aBRLLp7hCMR9KTUNrneyVEhYb 6/Y8K32YX0lJvYj4lu/4fkfjxzMiY98SYyoFRlGUUw0EE6SqsX6lNVGfoBACRlIECXOk wkToGuWcOIDQUquVCawSirZgTwk4Tw5es0etgYWuUvtq4s5vf2Oz7cgZjUUqymnI4fUV i2vg== X-Gm-Message-State: AOUpUlHLG6HgvHFXGL8Bzjcu4aqIm5Je0AVgoZrA+dK+1AtMzexIVelY nzLKpzXn7aGYZlCYXLOP2ck9hw== X-Google-Smtp-Source: AAOMgpeAzbV1lh0hF1B6m3HaFAeVE7AWYJcED+9oJzMKOb+gP/SIyoBI0Yd0WRx6VqjVMxpJZj2JEw== X-Received: by 2002:a1c:e54:: with SMTP id 81-v6mr11954483wmo.84.1533548471666; Mon, 06 Aug 2018 02:41:11 -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 p14-v6sm9037731wru.0.2018.08.06.02.41.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 02:41:10 -0700 (PDT) Date: Mon, 6 Aug 2018 11:40:53 +0200 From: Adrien Mazarguil To: Matan Azrad Cc: Keith Wiles , Ophir Munk , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20180806094053.GS5211@6wind.com> References: <1533205980-7874-1-git-send-email-matan@mellanox.com> <20180802142737.GO5211@6wind.com> <20180803082051.GP5211@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH] 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: Mon, 06 Aug 2018 09:41:12 -0000 On Sun, Aug 05, 2018 at 06:10:55AM +0000, Matan Azrad wrote: > Hi Adrien > > From: Adrien Mazarguil > > Hi Matan, > > > > On Thu, Aug 02, 2018 at 05:52:18PM +0000, Matan Azrad wrote: > > > Hi Adrien > > > > > > From: Adrien Mazarguil > > > > On Thu, Aug 02, 2018 at 10:33:00AM +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. > > > > > > > > I would go further, one should be able to match IP address 0.0.0.0 for > > instance. > > > > The PMD should only trust the mask on all fields without looking at spec. > > > > > > The PMD should convert the RTE flow API to the device configuration, > > > So I can think on scenarios that the PMD should look on spec. > > > > Obviously the PMD needs to take spec into account. What I meant is that for > > each field, spec must be taken into account according to mask only. > > > > For any given field, when mask is empty, don't look at spec, it's like a wildcard. > > When mask is full, take spec as is, even if spec only contains zeroed bits. > > > > User intent in that case is to match a zero value exactly, so it must not result in > > a wildcard match. If supported, when mask is partial, masked bits are also > > matched exactly, even if these turn out to be a zero value. Unmasked bits are > > considered wildcards. > > > > Yes I understand your point Adrien, but I mean that maybe sometimes some spec values should be converted to another spec values to get the correct translation of rte_flow for a special device. > > Here, maybe IP_spec=0.0.0.0 is a special case that should be taken into account, so we must validate what's happen in Tap for this case to apply your suggestion too, Maybe there was some intentions for spec=0 cases from the current code author. I understand that's a lot of maybes :) I've checked the code and I'am sure it's a mistake made by the original author. See tap_flow_create_eth() for instance: if (!is_zero_ether_addr(&spec->dst)) { Followed by: if (!is_zero_ether_addr(&mask->src)) This lack of consistency doesn't make any sense, it cannot be on purpose. To my credentials I wrote a very similar code which uses TC flower in mlx5 and relies on mask (only) in order to retrieve spec. Have a look at drivers/net/mlx5/mlx5_nl_flow.c. I validated that traffic where addresses were all zeroes could be successfully matched. -- Adrien Mazarguil 6WIND