From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 450DFA0526; Wed, 8 Jul 2020 12:14:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1F2E71DA27; Wed, 8 Jul 2020 12:14:52 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 98DCC1D6D8 for ; Wed, 8 Jul 2020 12:14:50 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E2CCA5C00BA; Wed, 8 Jul 2020 06:14:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 08 Jul 2020 06:14:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= 3+yNH0Tj43FtJNjtXCCvPrVsuJODWFIJ8kc46cHQcIs=; b=coHnFwMOGlrt+4FQ M3bA7gG1+rA/ocue+hjuPhU/CUxf/2tGYphdpWe7TWkbsobkEEl7OxehDjgCi5F+ VpmiJluSq5DLGxkm2/wxpRMW6AT2hiVhao08PwU1QMSUBVCTveNVZYDA0taQJjBR T3yozRybBgjv/2FNxRiBCkRWcjaFWW/1CjceIFeaSvpKSwD5WSU0b3NxUKHxr44x w7/lv88RPvoxcwjk+UtIiCc+RKpYjzGcVRG3a8j+H+yxig57+PNlhq+34RtwvO4b D27VFqTLiDUh2PxcdalSljH2ALysPS/8RoHLU+PBpZv6GR/VR64NuGP+yS5xBr0/ 5KwFcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3+yNH0Tj43FtJNjtXCCvPrVsuJODWFIJ8kc46cHQc Is=; b=WWeUEzlWW8M05hWznk6K/pfYzDgfeVp1i56V6MPTdB0NPVIapSjp9sfxk QQYvNhIaE5h3UWpESpKsTgmRlF7AwkaEMqQG1l2BbX6mU4E+r/39+cV/uxfO4RFV /Ervyvwu8TLo73S+pPK6HoGPYM62sC70M9Yt/auw0+Ii4LTsUvnV5iNgBnvZMlsx yWYvmsx9MiN8hVMtPDLPIxrsrFjlRS7WbdneorQkUuXkmecBgKZOMEy+n74FwIH0 +BzwfXWWdu4oUdJEJArz5kxOBUpIOSlYHmwfK32BDxHrSrIGiXA0JtKRkZ52A26N H5/TO2eLhxMHHlL/6O1Ax639L0CyA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C18233280060; Wed, 8 Jul 2020 06:14:47 -0400 (EDT) From: Thomas Monjalon To: "Wei Hu (Xavier)" Cc: dev@dpdk.org, ferruh.yigit@intel.com, arybchenko@solarflare.com, tangchengchang@huawei.com, hyonkim@cisco.com, sachin.saxena@oss.nxp.com, cloud.wangxiaoyun@huawei.com, hkalra@marvell.com, viacheslavo@mellanox.com Date: Wed, 08 Jul 2020 12:14:46 +0200 Message-ID: <4862684.ztQDoVm40t@thomas> In-Reply-To: <40e3a1b0-3c7e-1807-67e1-41dd2850e350@huawei.com> References: <1594019191-54524-1-git-send-email-xavier.huwei@huawei.com> <3633587.h79vMgjPB0@thomas> <40e3a1b0-3c7e-1807-67e1-41dd2850e350@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 2/2] ethdev: fix VLAN offloads set if no relative capabilities 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 08/07/2020 05:37, Wei Hu (Xavier): > On 2020/7/7 22:11, Thomas Monjalon wrote: > > 06/07/2020 09:06, Wei Hu (Xavier): > >> Currently, there is a potential problem that calling the API function > >> rte_eth_dev_set_vlan_offload to start VLAN hardware offloads which the > >> driver does not support. If the PMD driver does not support certain VLAN > >> hardware offloads and does not check for it, the hardware setting will > >> not change, but the VLAN offloads in dev->data->dev_conf.rxmode.offloads > >> will be turned on. > >> > >> It is supposed to check the hardware capabilities to decide whether the > >> relative callback needs to be called just like the behavior in the API > >> function named rte_eth_dev_configure. And it is also needed to cleanup > >> duplicated checks which are done in some PMDs. Also, note that it is > >> behaviour change for some PMDs which simply ignore (with error/warning log > >> message) unsupported VLAN offloads, but now it will fail. [...] > >> @@ -3317,6 +3319,25 @@ rte_eth_dev_set_vlan_offload(uint16_t port_id, int offload_mask) > >> if (mask == 0) > >> return ret; > >> > >> + ret = rte_eth_dev_info_get(port_id, &dev_info); > >> + if (ret != 0) > >> + return ret; > >> + > >> + /* > >> + * New added Rx VLAN offloading which are not enabled in > >> + * rte_eth_dev_configure() must be within its device capabilities > >> + */ > > What means "New added Rx VLAN offloading"? > > The parameter offload_mask of rte_eth_dev_set_vlan_offload() function > includes some Rx VLAN offload, and some of them maybe are not enabled > in rte_eth_dev_configure(). OK I don't understand why checking only new features. All enabled features must be within capabilities, right?