From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 566692C65 for ; Mon, 7 Mar 2016 10:30:25 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id l68so62701469wml.1 for ; Mon, 07 Mar 2016 01:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=6qTzr+UhJlhEX1+yt/icOLCE7KupPQxHm8wt8I68Q9Q=; b=g3b+6d15q4TycgSgzxqsbs2uZJ8gk4iWsXZKnFzHVH30TxMnFncEP7RS0IWwspRiiX gSzhmS5MNv8uG0XwnkD/3/DkaAUidv657Jc6U4UXi76YdYpRqly+oO/HE154y2p16Q1R QhEuRT5EViZfYprH3Ob61SeEBMdHqjyWpsHprWI/UQXX78IWJs6rbKG/M6gORSUSqSAV xkzcEkWVpiL28wqc3UrJMi3qrcs0BCz3xTf/x0MuUWJzWM4WfiTHy9TUaA2FlCZcVuVf VWUYa204VIR5T8E6YPPnVpN1gihS1YUji+CvKaQesOe9YX0IpH2QJY4k1qVzf86wVn0f EG3w== 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; bh=6qTzr+UhJlhEX1+yt/icOLCE7KupPQxHm8wt8I68Q9Q=; b=Tt+60aZK2X+ZZMv753ZxKaHQ47U/ijN06b0BFJ8oeEVyekFmHkKUt56HozFCuvCNHo 3vZvqJNc/MpW96VqFJF4lDpi6MNEDhAQQX2SC3XlfblXyR9sNWzfu2sMEAyGp1Sp4vzl pRVwp+rYKRDcC3lLGZj6/dTeZyARYMcrYnCgJmT44WCXKY6qAKZ1UoFdJBm+kOJhbrYu DcvqxtPMFiNuglR/jBfIdH5i+l/8em4QAjTikjI0vY14vUrl1F05QXnk+1eB/h1GY9rp OrGWtbv2fzuuV3uLH4QOK6znMV48+PdWykawF11UyOwoH25Gemm4p7RtrKIdu3Ob/mk6 g9wg== X-Gm-Message-State: AD7BkJKufQkZo5wZovOGWkl0DAe5D3UwRpF6d7ftrWfG1kTKW5Cs/M641K9bgzlNdQMGxXz0 X-Received: by 10.194.175.33 with SMTP id bx1mr21600605wjc.104.1457343025197; Mon, 07 Mar 2016 01:30:25 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id c128sm12657919wma.11.2016.03.07.01.30.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 01:30:24 -0800 (PST) From: Thomas Monjalon To: Helin Zhang Date: Mon, 07 Mar 2016 10:28:47 +0100 Message-ID: <1571443.EPqn3bY1d6@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1457338370-32744-1-git-send-email-helin.zhang@intel.com> References: <1453426623-8696-1-git-send-email-helin.zhang@intel.com> <1457338370-32744-1-git-send-email-helin.zhang@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 v2 0/3] i40e setting ether type of VLANs 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: Mon, 07 Mar 2016 09:30:25 -0000 2016-03-07 16:12, Helin Zhang: > The patch set was branched off rel_16_04 of repo dpdk-next-net, > on below commit. > - commit 4ac366ba647909c3b71818f9be9db86ba5e871da > nfp: fix non-x86 build Currently, changes on ethdev are directly applied on dpdk.git. > v2: > - Used RTE_NEXT_ABI to avoid ABI change issue. RTE_NEXT_ABI must be used only when it is really too difficult to keep the compatibility with librte_compat. Here you are just adding a parameter to some functions, so you should try versionning the functions with the help of macros in librte_compat. About the API change, you want to be able to insert a QinQ inner-vlan, right? The current comment of rte_eth_dev_set_vlan_ether_type is: * Set the Outer VLAN Ether Type by an Ethernet device, it can be inserted to * the VLAN Header. This is a register setup available on some Intel NIC, not * but all, please check the data sheet for availability. 2 comments: - you haven't changed "Outer VLAN" so the API description is wrong - it is announced as something Intel-specific About the new enum: + * VLAN types to indicate if it is for single VLAN, inner VLAN or outer VLAN. + * Note that most of time single VLAN is treated the same as inner VLAN. You cannot say "most of time" in an API. More generally, I am not convinced by the current VLAN API that you are extending. Why this function is not merged with rte_eth_dev_set_vlan_pvid?