From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70088.outbound.protection.outlook.com [40.107.7.88]) by dpdk.org (Postfix) with ESMTP id E7AFB1B5B5; Sun, 5 Aug 2018 08:10:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UFIVMWus7mitPZUKhKH0oHsyN0BlBkSu9FmZTd8tngw=; b=AxuM5sfGMeMeoaU6YVbQU8Tv7gOgukNMfVONBQUXEOcZxYOnS45fXoW+iLsNI93EqNnu5QN/bdP18ibC3aX2NrW2k+ZWqjllOVSjdvQY3FVEIcl3EU5pc+wbx8+BasrIrfFD4fKk1dOUFsO/OtPQdbt8FfndMe+GR+4iQWPsd9s= Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com (52.133.41.11) by AM0PR0502MB3777.eurprd05.prod.outlook.com (52.133.47.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Sun, 5 Aug 2018 06:10:55 +0000 Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com ([fe80::9d98:d47f:5b50:1f49]) by AM0PR0502MB4019.eurprd05.prod.outlook.com ([fe80::9d98:d47f:5b50:1f49%2]) with mapi id 15.20.1017.018; Sun, 5 Aug 2018 06:10:55 +0000 From: Matan Azrad To: Adrien Mazarguil CC: Keith Wiles , Ophir Munk , "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] net/tap: fix zeroed flow mask configurations Thread-Index: AQHUKkxANy4bvWK4qUyNwHKWN0YqIaSshVOAgAA3A8CAAPTYgIAC/gDw Date: Sun, 5 Aug 2018 06:10:55 +0000 Message-ID: References: <1533205980-7874-1-git-send-email-matan@mellanox.com> <20180802142737.GO5211@6wind.com> <20180803082051.GP5211@6wind.com> In-Reply-To: <20180803082051.GP5211@6wind.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0502MB3777; 6:dbNncxxJWw6OlVBpxNgKwhci9qOa2cL8rbjj1iyl1VzZfucEk+99usMEgndn6Npb9uypEoF9N/Ddl4AluN2WQlcp2m4aVv3wsB3yn0aP9BN97lkTpaQLqmyvnx/mmRZq1XhiSDaymaLZfKVT8xPdr+65FzO61IUtdu/W37EimmANG8iaVCBnMlPS7oivawTY9m2lxZhm8bJ2NEBnxkSrLhlpnKWvCuImcAPAtmFx+HnlbneWC+NU++C0v4WTzsHvXsh+l53IWB3naNtAP6QcmNNfy7tdMOQLTi4QdCZkm52imF8bYxb79HoPbHPrXCSgZ4/eCkX9YMjKbWXET8hoKctJgYw/ROJlASxR0C5JMEpso6bxmjSryBbAOYFIFdLs8ItqiGkfbUj8BTDCMUWgaDgtiXU0Hwn66/yhSU7KeAP3ttAMM+UA2ylMXYk5+3FxQhBuKrcDIVBwbbBoev7zUA==; 5:4QuYxMYixFBTbbb4lUwTghyhLYHySFULSnobtuzDXyylPm8wCd9k7u8BWR4/4yuXwHjuEXIrmGcORAqJYUOIQCjC4atT8Rrqy00JMpUhMJgLLarSa3SrpgtpuvFKqH45eKyxdtw/IMpGfPbVtXVihihOdnauwWcS+KuwuBl6poU=; 7:q5yhwjv87h/OEONf5FIDwMo84mDxy1PEiunYAAs0zSTBZa4kf3FR5rGManjqpy6K5cGtD+DbPpYaqUt02BN5c8hECJzNOoi8iBzCNOmFj0avx1X1t3zS2ubBkcSt3CNlapgz4/rhxUYxfMl4HYXQEsmf89b7NmAWHQnBlmCjIgEbAh/ZmHaWIPDSerM2+oazhcSo3l5z9iAWA7APfoO/mxLZVm5UoYW/ptUlyEFwn0/38LOom6gzrP213YO+mcQP x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e893b498-bc01-4149-d79e-08d5fa9a34b2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM0PR0502MB3777; x-ms-traffictypediagnostic: AM0PR0502MB3777: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(200054503718035)(788757137089); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM0PR0502MB3777; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0502MB3777; x-forefront-prvs: 0755F54DD9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(39850400004)(136003)(376002)(199004)(189003)(97736004)(102836004)(476003)(6246003)(81156014)(53936002)(81166006)(26005)(8936002)(76176011)(186003)(486006)(99286004)(4326008)(316002)(7736002)(86362001)(2900100001)(305945005)(54906003)(8676002)(6506007)(74316002)(25786009)(7696005)(14444005)(256004)(11346002)(446003)(5250100002)(33656002)(2906002)(478600001)(6436002)(66066001)(93886005)(3846002)(229853002)(68736007)(6916009)(14454004)(106356001)(5660300001)(9686003)(105586002)(6116002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3777; H:AM0PR0502MB4019.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9jgwImeWox6LtzQufMOAnt4OCraBIGSRJvYLXeZJxok/JBf67PbN9+Gf6czFxM9SbloWpa5NA6f+CFrlXKD+y6WiUYKdgSxYgJ3MqtxW9V17QB8OvnG1w2orIsdTvd/W9+ibCiF6QddWlqd5deYAKlGjuS6rx/g8Lg3aBEv02JMMUvn85J0P36XvLzQPy4EVWXFgl75jqFBbOabyk8jvZck16yzq2NL4dauiJ33JSaObtBLOyOEnQrqLvK47lNQGk3C4AsN0z4K4WmcS2cI1rdQP4BHssi5j9EHgADNha0Db8bnfig30qfDbhl9WHVtCYWYbkjST29Kzk8MdIqmhEw9HhRxv/z+7Bi9XkFEOfLQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: e893b498-bc01-4149-d79e-08d5fa9a34b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2018 06:10:55.6244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0502MB3777 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: Sun, 05 Aug 2018 06:11:07 -0000 Hi Adrien From: Adrien Mazarguil > Hi Matan, >=20 > 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 fo= r > instance. > > > The PMD should only trust the mask on all fields without looking at s= pec. > > > > 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. >=20 > Obviously the PMD needs to take spec into account. What I meant is that f= or > each field, spec must be taken into account according to mask only. >=20 > 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 bit= s. >=20 > 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 als= o > matched exactly, even if these turn out to be a zero value. Unmasked bits= are > considered wildcards. >=20 Yes I understand your point Adrien, but I mean that maybe sometimes some sp= ec values should be converted to another spec values to get the correct tra= nslation of rte_flow for a special device. Here, maybe IP_spec=3D0.0.0.0 is a special case that should be taken into a= ccount, so we must validate what's happen in Tap for this case to apply you= r suggestion too, Maybe there was some intentions for spec=3D0 cases from t= he current code author. =20 > In short, to address both the issue mentioned in the commit log and the o= ne I'm > talking about, you only need to replace "spec" with "mask" in the origina= l code.