From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 152CB1B42F for ; Mon, 9 Jul 2018 15:58:25 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id r16-v6so11114083wrt.11 for ; Mon, 09 Jul 2018 06:58:25 -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:content-transfer-encoding:in-reply-to :user-agent; bh=SSTroEZOPKvKGgH2pxuXzeocVUHvfctSK8C0eptEEBA=; b=PaaGHiai4FTHIlJ/g6lb0zUfBM2IOPQbEWcjllnSP25veXJ5FA4gFU9yy/7lAvCzLi aWExRDAQf1XP51mNPk7gv67QV5Ow/PP/PbKA9a2+1YK/WxqovffoZYuEEek8mMl9xgxj Hz7w31dTiq3nf04S7apH9BaWWgEEb/D22jmjR/otEk6mODQBi2/SDnX0Lu9U6tq8+qCC aLlLnFDf18jtJl9J0Cv4fMuttqNpV7ctfolCeemoZ5H6tUPAYNtsxKBuI8pV1fDlc5xq MLQxt51fCd/5DUdT3n0ud7Zqilrjvwj3+HgxcURfc5lMmTqdLSqU1B48wyobbRciqvjK 4U4g== 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:content-transfer-encoding :in-reply-to:user-agent; bh=SSTroEZOPKvKGgH2pxuXzeocVUHvfctSK8C0eptEEBA=; b=GA0c3KhOZ9RnOnn+UEsonFIWLrNDss+Jg4d9uu7FQIOU4DiVC4e7vBmt0KvUqUuSSI h3E0yj0zlmIiK4SBJzW6o9WxKQzJUiNXiLLzpJEhqckIVL00np/j2J/+IeszrXTXhvsm BaGkrIRCPyQ4WUQmaUp9XATD2Ca+gEnNDUe5yipVMj1LqkowM1PnCZH+Am7+YeMtUYoX dYLNWyBl01a1J+ZWjXtN2UxHxPM2mwrEgau5/H5eEfkGLK6vveSzGfhGHuO5l1EOWBof SNkumksEj1J1PzxGP1JPCNXhv8MQtp2Kt+UTI9JNm1r+aOMOvNCeTw5z7ZZvvUC5G37K XujQ== X-Gm-Message-State: APt69E381Y7Z5XEkq3P3dbMCV+p4VDHKMRk+MdlrhT1X1Hpl0MRLQuhj FdSInVVZtaVySzDBPS/WmQAU X-Google-Smtp-Source: AAOMgpfn1IayJULCy3vjmw3jIIgtO1uqPP6iUItLFYOfQm4vDl2kzNQug/SMJxS9OXxbkcaOyQI3tQ== X-Received: by 2002:a5d:44c6:: with SMTP id z6-v6mr9162786wrr.236.1531144704842; Mon, 09 Jul 2018 06:58:24 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 11-v6sm16838447wrw.67.2018.07.09.06.58.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 09 Jul 2018 06:58:24 -0700 (PDT) Date: Mon, 9 Jul 2018 15:58:08 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Yongseok Koh Cc: dev@dpdk.org, Adrien Mazarguil Message-ID: <20180709135808.nwaopl6mk2ya4xjx@laranjeiro-vm.dev.6wind.com> References: <6190b2d787d3a9d2095e2eed17db1c20b2e3c4e1.1530111623.git.nelio.laranjeiro@6wind.com> <20180706234610.GC53779@yongseok-MBP.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180706234610.GC53779@yongseok-MBP.local> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v2 18/20] net/mlx5: add flow GRE item 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, 09 Jul 2018 13:58:25 -0000 Hi Yongseok, Only discussing here question, other comments are address, as I don't have any objection I'll make the modification for them. On Fri, Jul 06, 2018 at 04:46:11PM -0700, Yongseok Koh wrote: >[...] > > + > > /** Handles information leading to a drop fate. */ > > struct mlx5_flow_verbs { > > LIST_ENTRY(mlx5_flow_verbs) next; > > @@ -1005,12 +1010,23 @@ mlx5_flow_item_ipv6(const struct rte_flow_item *item, struct rte_flow *flow, > > item, > > "L3 cannot follow an L4" > > " layer"); > > + /* > > + * IPv6 is not recognised by the NIC inside a GRE tunnel. > > + * Such support has to be disabled as the rule will be > > + * accepted. Tested with Mellanox OFED 4.3-3.0.2.1 > > + */ > > This comment doesn't look appropriate. Do you think it is a bug of OFED/FW, > which can be fixed? Or, is it a HW erratum? Let's talk offline. By the time it was as this Mellanox OFED was the latest GA 4.3-3.0.2.1, this is no more the case today as it cannot be downloaded anymore. A verification is still necessary. If the issue is not present anymore I'll remove the comment with the test. >[...] > > +{ > > + unsigned int i; > > + const enum ibv_flow_spec_type search = IBV_FLOW_SPEC_IPV6; > > + struct ibv_spec_header *hdr = (struct ibv_spec_header *) > > + ((uint8_t *)attr + sizeof(struct ibv_flow_attr)); > > + > > + if (!attr) > > + return; > > + for (i = 0; i != attr->num_of_specs; ++i) { > > + if (hdr->type == search) { > > + struct ibv_flow_spec_ipv6 *ip = > > + (struct ibv_flow_spec_ipv6 *)hdr; > > + > > + if (!ip->val.next_hdr) { > > What if protocol in IP header does have wrong value other than 47 (IPPROTO_GRE)? > Shouldn't we have a validation check for it in mlx5_flow_item_gre()? >[...] Already added, the same issue occurs also with UDP/TCP. If the user uses some protocol it must match the following layer, otherwise its request won't be respected which is a bug. Thanks, -- Nélio Laranjeiro 6WIND