From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 9D8127E7B for ; Tue, 21 Oct 2014 23:11:29 +0200 (CEST) Received: by mail-wg0-f50.google.com with SMTP id a1so2356056wgh.33 for ; Tue, 21 Oct 2014 14:19:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=GVZy86D88dt/4Zike2nMH/HRFY/SMa1+vKWAtNgMc/c=; b=Npyuw3lOQONMj2o6sK6KbuLlyrcpvzu/GVk1V9ovvL8oHGhcjw928y5JK92yQJG6yp eeDL+HyOXIFYb9VArLIhaAsJ7iy8fw3OqwS5liCVM3kMw4cmxgcU8r3UfXBnNXNinPTK pZSVUhpMWB58di+JDNUB/GZXNIfHrPpXtJ4Y2N6HQJBMjbNp3QrLXBRcOz/GEtN9FfUl 6LKAVcJcku8wolXCmh1pqueuqAAzxjp5t4whJ30Ds8KMKF+xDlX3oK49zSs6fDpA2qUu VcVU3rSVFddErbnd7p2ug57MdMYJpII0omjonGNaNegm/cq6gQr1NOu63dfdOKpUHA2b mimA== X-Gm-Message-State: ALoCoQnzWG/M5nrj9ZgDmS2caS7yVp9VBgVB2eJM673Xby5OqDpTuiM/zkF+IQ1e65FBeX8nNWqm X-Received: by 10.194.190.19 with SMTP id gm19mr24234385wjc.4.1413926386963; Tue, 21 Oct 2014 14:19:46 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id ky3sm16613685wjb.39.2014.10.21.14.19.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 14:19:46 -0700 (PDT) From: Thomas Monjalon To: "Liu, Jijiang" Date: Tue, 21 Oct 2014 23:19:29 +0200 Message-ID: <282785858.Uoneh1Nj8l@xps13> Organization: 6WIND User-Agent: KMail/4.14.1 (Linux/3.16.4-1-ARCH; KDE/4.14.1; x86_64; ; ) In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D82530@SHSMSX101.ccr.corp.intel.com> References: <1413881168-20239-1-git-send-email-jijiang.liu@intel.com> <3607443.z2coKxdkI7@xps13> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D82530@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:11:30 -0000 2014-10-21 13:48, Liu, Jijiang: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2014-10-21 16:46, Jijiang Liu: > > > int > > > +rte_eth_dev_udp_tunnel_add(uint8_t port_id, > > > + struct rte_eth_udp_tunnel *udp_tunnel, > > > + uint8_t count) > > > +{ > > > + uint8_t i; > > > + struct rte_eth_dev *dev; > > > + struct rte_eth_udp_tunnel *tunnel; > > > + > > > + if (port_id >= nb_ports) { > > > + PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id); > > > + return -ENODEV; > > > + } > > > + > > > + if (udp_tunnel == NULL) { > > > + PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n"); > > > + return -EINVAL; > > > + } > > > + tunnel = udp_tunnel; > > > + > > > + for (i = 0; i < count; i++, tunnel++) { > > > + if (tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) { > > > + PMD_DEBUG_TRACE("Invalid tunnel type\n"); > > > + return -EINVAL; > > > + } > > > + } > > > > I'm not sure it's a good idea to provide a count parameter to iterate in a > > loop. > > It's probably something that the application should do by itself. > > It is necessary to check if this prot_type(tunnel type) is valid here in case > applications don't do that. Yes, you have to check prot_type but looping for several tunnels is not needed at this level. > > But I doubt we should configure a tunnel type for a whole port. > > Yes, your understanding is correct. It is for a whole port/PF, that's why we > should add tunnel_type in rte_eth_conf structure. Please explain me why a tunnel type should be associated to a port. This design looks really broken. Thanks -- Thomas