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 6A537A0096 for ; Wed, 13 Mar 2019 21:36:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9E15A374E; Wed, 13 Mar 2019 21:36:18 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id A02AA2BD3 for ; Wed, 13 Mar 2019 21:36:16 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D54B421D45; Wed, 13 Mar 2019 16:36:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 13 Mar 2019 16:36:13 -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=F5JvLEYdlBQweh6wTNHDMCvB0EyTflXMNNX4drSYIac=; b=XVQt7HhSpRI4 3uf98v/NqB0cRCddUWlzIuEMIw3gC5d0iPY82nx8Hz0Gw4H7kya4CHc9ilrRLusT X0YUf+ieW6xAx6SIOJgt9Tb/JlOxRMnxHnJZZUUDJegwWDhUXnChVs52jYeOL72s VbdhWs5oUSPokL8cJRWff8gsDNhJDbg= 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=F5JvLEYdlBQweh6wTNHDMCvB0EyTflXMNNX4drSYI ac=; b=aIpPUp7RfRwRkFEzy9PE3vXTwaAcEvXKBLTCHeFdFkaDWODML4P5CCaYO ph/62TYI0spuNrrX/tSIk0icX4PZv3FqkDDnLXrisj82rAwC85E+99IdCzOBySbw h+Q2RLKPBJNNEOFnQ65nM4qAbdi2e+2JaBXNSl8HYOwYfP2oo5mWCXfYTMxUe38E dXv5DNCneJGUgxgFzcNSSwCZX8pD4rZFdfOf9fLxwHHz6tcxK6giX4ZBObX4m5cz x66dnTnBSkHDeMEWeQNA2q3uCkBj6Ea+tnDA+An+aTC3lpmCzDxFb/4J1rqjiJU2 Vesi7utRfvqyvXMmMAio+ONgw+ljA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedtgddufeelucetufdoteggodetrfdotf 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 54A5E10336; Wed, 13 Mar 2019 16:36:10 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , Hyong Youb Kim Cc: Andrew Rybchenko , Qi Zhang , dev@dpdk.org, John Daley , Shahaf Shuler , Jerin Jacob , David Marchand , Maxime Coquelin , Konstantin Ananyev , Hemant Agrawal , Stephen Hemminger Date: Wed, 13 Mar 2019 21:36:07 +0100 Message-ID: <155267265.tCld3OmuaL@xps> In-Reply-To: <399e1eeb-3c3f-ac73-03e9-2e37b2d8ef52@intel.com> References: <20190305055659.3095-1-hyonkim@cisco.com> <20190305071134.21725-1-hyonkim@cisco.com> <399e1eeb-3c3f-ac73-03e9-2e37b2d8ef52@intel.com> 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: <20190313203607.GRv6BimTk8HRitu0U1MqVqjsfWrtLYLPZez1KXc7FnE@z> 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?