From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hyong Youb Kim Subject: Re: [PATCH v2] net/enic: add private API to set ingress VLAN rewrite mode Date: Thu, 14 Mar 2019 11:58:01 +0900 Message-ID: <20190314025800.GA24620@HYONKIM-7R0DR.cisco.com> References: <20190305055659.3095-1-hyonkim@cisco.com> <155267265.tCld3OmuaL@xps> <119440374.MxkLxCl2uq@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "John Daley (johndale)" , Ferruh Yigit , Andrew Rybchenko , Qi Zhang , "dev@dpdk.org" , Shahaf Shuler , Jerin Jacob , David Marchand , Maxime Coquelin , Konstantin Ananyev , Hemant Agrawal , Stephen Hemminger To: Thomas Monjalon Return-path: Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by dpdk.org (Postfix) with ESMTP id 13F46324D for ; Thu, 14 Mar 2019 03:58:08 +0100 (CET) Content-Disposition: inline In-Reply-To: <119440374.MxkLxCl2uq@xps> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Mar 13, 2019 at 10:29:53PM +0100, Thomas Monjalon wrote: > 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? > > As is, there seem to be two ways apps deal with NIC-specific tweaks/quirks. 1. Leave everything to the user. Let the human user specify NIC-specific settings (e.g. devarg, not-so-standard MTU/MRU, offloads with not-so-uniform behavior). The app simply passes these to DPDK and does nothing else. Devargs are passed to rte_eal_init. Other settings are applied during the configure phase after rte_eal_init. For example, OVS seems to go for a smallest common denominator that works with most NICs out of the box. Otherwiese, it kinda falls into this camp. For a problematic NIC that needs user intervention, troubleshooting goes like this :-) - Install app. - Run with settings that worked on a previous machine. - Some features suddenly do not work. - Google search this and that ("why this does not work on this server?"). - Contact vendors. - Find out this NIC has unexpected behavior. - Set devarg, tweak MTU/MRU, ... ("Oh need to set this for .."). - Now the features work. 2. Hide ugly tweaks from the user. VPP falls into this camp. The user specifies BDFs in the config (no devargs). The app calls rte_eal_init(BDFs), iterates through the discovered ports, applies whatever NIC-specific settings necessary during the configure phase (i.e. do this for vendor A NIC, do that for vendor B NIC), and then start the ports. The ingress vlan rewrite mode is devarg now, so is not usable in this model. One way around it is a private API. Driver specific flags during the configure phase would also work fine. Though, enic might be the only user of those flags. Thanks. -Hyong