From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 610D62BD3 for ; Wed, 13 Mar 2019 22:29:58 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DEB9321286; Wed, 13 Mar 2019 17:29:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 13 Mar 2019 17:29:57 -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=mesmtp; bh=Ozn5p9uXo8KjgCWM5fqTFkxdsilVWA/1vzPmGuTveQk=; b=Ztju2k2CxdG2 yOaiOZKUMYqvuIAwlruZcVEsi3AtFo+tIjGeNPiVMS/n5XPjlkpGflI29h3WHz+C YEwMaqiT/CHO6p+d9WX5ZiTuccHDWBoHt5ixSLSP72nuXM90N2JIleZilSGhOufx 9ka2f6ttu9yFCVOS0DZCTR69mu8mxB0= 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=fm2; bh=Ozn5p9uXo8KjgCWM5fqTFkxdsilVWA/1vzPmGuTve Qk=; b=8JsMdX3z4dFJuFSR/nArVyz0s38gPtvvZDskqo5jHi0V0922L54qmdBi/ zMqLQrNH52Gl2xuBLnK9bwv4mgRZpI4Lw5lZUmDWlGygxYgBeDhnarusIVrI2+Gv CGEdl2C8uUXMX9a7Cpr4CB6sNCQxvdu+7T3RPM8CMMUfi+e4W7DtUN4bpov8d2tI AgDwidEXD5oP+7KnKr71mLpFnL150wFVzoTJKRcnouwKhPEu/x+5XPUCl5QOMaWc WxGa+g83ZuMdDMhpSjiiRXRHYbcgwLYFxkJ/Iz0GoY4t0/9fzLh4nkMBi2+os4aN MtYXBsbLabeG6l/iza0m0q4ZEb8GA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedtgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 CA919E40C1; Wed, 13 Mar 2019 17:29:54 -0400 (EDT) From: Thomas Monjalon To: "John Daley (johndale)" Cc: Ferruh Yigit , "Hyong Youb Kim (hyonkim)" , Andrew Rybchenko , Qi Zhang , "dev@dpdk.org" , Shahaf Shuler , Jerin Jacob , David Marchand , Maxime Coquelin , Konstantin Ananyev , Hemant Agrawal , Stephen Hemminger Date: Wed, 13 Mar 2019 22:29:53 +0100 Message-ID: <119440374.MxkLxCl2uq@xps> In-Reply-To: References: <20190305055659.3095-1-hyonkim@cisco.com> <155267265.tCld3OmuaL@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] net/enic: add private API to set ingress VLAN rewrite mode 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: Wed, 13 Mar 2019 21:29:58 -0000 13/03/2019 22:11, John Daley (johndale): > From: Thomas Monjalon > > 13/03/2019 19:32, Ferruh Yigit: > > > On 3/5/2019 7:11 AM, Hyong Youb Kim wrote: > > > > The driver currently has a devarg to set the rewrite mode during > > > > init. Some apps want to programatically set it after running > > > > rte_eal_init() and finding that ports are VIC. Add a private > > > > function to support such applications. > > > > > > It is not good idea to have PMD specific APIs (although we already have > > some). > > > > > > Specific to this case, as far as I can see it is to pass a config > > > value and do the action related to it, what would you think having a > > > generic key/value set/get API in ethdev for this? Similar to rawdev > > get_attr/set_attr [1]? > > > > > > My concern is it may turn into something like ioctl with many things > > > pushed to it, and cause possible duplication ... > > > > Yes, it is clearly ioctl style. > > > > Please could you explain more what is the rewrite mode? > > Does it apply to the port or the queue? > > > It applies to a port. By default the Cisco VIC VLAN tags every packet on ingress even if they were untagged coming in on the wire. They are tagged with VLAN 0 or a VLAN id programmed into the NIC depending on the configuration. Its part of the original design, to maintain priority bits, ancient history. > > Some apps don't like this (VPP) or take a slower path (OVS). Hyong added a ig-vlan-rewrite=untag devarg to disable this (leave untagged/default vlan packets untagged) during rte_eal_init and this is helpful for OVS, but VPP likes to set the rewrite mode after rte_eal_init() and finding the ports are VIC ports. So that is the reasoning behind the private API call. It looks like an application will always set this flag or never. So I don't see the need for an API function. Why VPP prefers set this flag later? Would it be better to have some driver-specific flags, no matter the ports? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 108DDA0096 for ; Wed, 13 Mar 2019 22:30:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1E1C83572; Wed, 13 Mar 2019 22:29:59 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 610D62BD3 for ; Wed, 13 Mar 2019 22:29:58 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DEB9321286; Wed, 13 Mar 2019 17:29:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 13 Mar 2019 17:29:57 -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=mesmtp; bh=Ozn5p9uXo8KjgCWM5fqTFkxdsilVWA/1vzPmGuTveQk=; b=Ztju2k2CxdG2 yOaiOZKUMYqvuIAwlruZcVEsi3AtFo+tIjGeNPiVMS/n5XPjlkpGflI29h3WHz+C YEwMaqiT/CHO6p+d9WX5ZiTuccHDWBoHt5ixSLSP72nuXM90N2JIleZilSGhOufx 9ka2f6ttu9yFCVOS0DZCTR69mu8mxB0= 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=fm2; bh=Ozn5p9uXo8KjgCWM5fqTFkxdsilVWA/1vzPmGuTve Qk=; b=8JsMdX3z4dFJuFSR/nArVyz0s38gPtvvZDskqo5jHi0V0922L54qmdBi/ zMqLQrNH52Gl2xuBLnK9bwv4mgRZpI4Lw5lZUmDWlGygxYgBeDhnarusIVrI2+Gv CGEdl2C8uUXMX9a7Cpr4CB6sNCQxvdu+7T3RPM8CMMUfi+e4W7DtUN4bpov8d2tI AgDwidEXD5oP+7KnKr71mLpFnL150wFVzoTJKRcnouwKhPEu/x+5XPUCl5QOMaWc WxGa+g83ZuMdDMhpSjiiRXRHYbcgwLYFxkJ/Iz0GoY4t0/9fzLh4nkMBi2+os4aN MtYXBsbLabeG6l/iza0m0q4ZEb8GA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedtgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 CA919E40C1; Wed, 13 Mar 2019 17:29:54 -0400 (EDT) From: Thomas Monjalon To: "John Daley (johndale)" Cc: Ferruh Yigit , "Hyong Youb Kim (hyonkim)" , Andrew Rybchenko , Qi Zhang , "dev@dpdk.org" , Shahaf Shuler , Jerin Jacob , David Marchand , Maxime Coquelin , Konstantin Ananyev , Hemant Agrawal , Stephen Hemminger Date: Wed, 13 Mar 2019 22:29:53 +0100 Message-ID: <119440374.MxkLxCl2uq@xps> In-Reply-To: References: <20190305055659.3095-1-hyonkim@cisco.com> <155267265.tCld3OmuaL@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2] net/enic: add private API to set ingress VLAN rewrite mode 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" Message-ID: <20190313212953.vnASUhxwB8G9YeMgrurllPDqDJtqO2DK6CKlMwt8gOw@z> 13/03/2019 22:11, John Daley (johndale): > From: Thomas Monjalon > > 13/03/2019 19:32, Ferruh Yigit: > > > On 3/5/2019 7:11 AM, Hyong Youb Kim wrote: > > > > The driver currently has a devarg to set the rewrite mode during > > > > init. Some apps want to programatically set it after running > > > > rte_eal_init() and finding that ports are VIC. Add a private > > > > function to support such applications. > > > > > > It is not good idea to have PMD specific APIs (although we already have > > some). > > > > > > Specific to this case, as far as I can see it is to pass a config > > > value and do the action related to it, what would you think having a > > > generic key/value set/get API in ethdev for this? Similar to rawdev > > get_attr/set_attr [1]? > > > > > > My concern is it may turn into something like ioctl with many things > > > pushed to it, and cause possible duplication ... > > > > Yes, it is clearly ioctl style. > > > > Please could you explain more what is the rewrite mode? > > Does it apply to the port or the queue? > > > It applies to a port. By default the Cisco VIC VLAN tags every packet on ingress even if they were untagged coming in on the wire. They are tagged with VLAN 0 or a VLAN id programmed into the NIC depending on the configuration. Its part of the original design, to maintain priority bits, ancient history. > > Some apps don't like this (VPP) or take a slower path (OVS). Hyong added a ig-vlan-rewrite=untag devarg to disable this (leave untagged/default vlan packets untagged) during rte_eal_init and this is helpful for OVS, but VPP likes to set the rewrite mode after rte_eal_init() and finding the ports are VIC ports. So that is the reasoning behind the private API call. It looks like an application will always set this flag or never. So I don't see the need for an API function. Why VPP prefers set this flag later? Would it be better to have some driver-specific flags, no matter the ports?