From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 5D5342B91 for ; Thu, 5 Jan 2017 11:06:04 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 05 Jan 2017 02:06:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,320,1477983600"; d="scan'208";a="805385418" Received: from debian.sh.intel.com (HELO debian) ([10.239.67.170]) by FMSMGA003.fm.intel.com with ESMTP; 05 Jan 2017 02:06:00 -0800 Date: Thu, 5 Jan 2017 18:05:02 +0800 From: Tiwei Bie To: "thomas.monjalon@6wind.com" , "olivier.matz@6wind.com" Cc: Adrien Mazarguil , "Ananyev, Konstantin" , "dev@dpdk.org" , "Lu, Wenzhuo" , "Mcnamara, John" , "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" Message-ID: <20170105100502.GA28772@debian> References: <1482939691-34855-1-git-send-email-tiwei.bie@intel.com> <1483514502-32841-1-git-send-email-tiwei.bie@intel.com> <1483514502-32841-4-git-send-email-tiwei.bie@intel.com> <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com> <20170104143923.GA57552@dpdk19> <2601191342CEEE43887BDE71AB9772583F0FEE6D@irsmsx105.ger.corp.intel.com> <20170104170011.GB56511@dpdk19> <2601191342CEEE43887BDE71AB9772583F100375@irsmsx105.ger.corp.intel.com> <20170104235608.GA133542@dpdk19> <20170105083322.GK12822@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170105083322.GK12822@6wind.com> User-Agent: Mutt/1.7.2 (2016-11-26) Subject: Re: [dpdk-dev] [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API 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: Thu, 05 Jan 2017 10:06:05 -0000 On Thu, Jan 05, 2017 at 09:33:22AM +0100, Adrien Mazarguil wrote: > On Thu, Jan 05, 2017 at 07:56:08AM +0800, Tiwei Bie wrote: > > On Thu, Jan 05, 2017 at 01:44:18AM +0800, Ananyev, Konstantin wrote: > > [...] > > > > > > > > > > I understand that. > > > > > My question was: suppose user would like to create a bonded device over 2 NICs. > > > > > One of them is ixgbe, while other would be some other type. > > > > > In future get_dev_info() for each of them might return DEV_RX_OFFLOAD_RESERVED_0 bit as set. > > > > > But it would mean completely different thing. > > > > > How bonded device would know that to deal properly? > > > > > > > > > > Another example - user has 2 NICs of different type and would like to send the same packet on both of them simultaneously. > > > > > As PKT_TX_RESERVED might mean different things for these devices, and user would like to use let say > > > > > PKT_TX_IXGBE_MACSEC on one of them, he would need to do a copy of them, instead just increment a refcnt. > > > > > > > > > > Similar issues might arise at RX handling: user got a packet with PKT_RX_RESERVED_0 set. > > > > > What does it really mean if there are different NIC types in the system? > > > > > The only way to answer that question, as I can see, is to keep track from what NIC that packet was received. > > > > > Which I suppose, is not always convenient. > > > > > > > > > > > > > The main purpose is to put the PMD-specific APIs in a separate > > > > namespace instead of mixing the PMD-specific APIs and global APIs > > > > up, and also save the bits in mbuf.ol_flags. > > > > > > > > There are other ways to achieve this goal, such as introducing > > > > the PMD specific ol_flags in mbuf second cache line as you said. > > > > I just thought defining some reserved bits seems to be the most > > > > simple way which won't introduce many changes. > > > > > > > > What's your suggestions? Should I just revert the changes and > > > > define the generic flags directly? > > > > > > Yes, that would be my preference. > > > As I said above - spending extra bit in ol_flags doesn't look like a big problem to me. > > > In return there would be no need to consider how to handle all that confusing scenarios in future. > > > > Okay. I'll update my patches. Thanks a lot for your comments. > > Well, I do not agree with Konstantin (no one saw this coming eh?) and do not > think you need to update your series again. > Hi Adrien, Thank you very much! :-) Hi Thomas and Olivier, I don't have strong opinions here, although I prefer to put the PMD-specific APIs in a separate namespace. I'd like to hear or follow your opinions since you are the maintainers of ethdev and mbuf. Best regards, Tiwei Bie > PMD-specific symbols have nothing to do in the global namespace in my > opinion, they are not versioned and may evolve without notice. Neither > applications nor the bonding PMD can rely on them. That's the trade-off. > > Therefore until APIs are made global, the safe compromise is to define > neutral, reserved symbols that any PMD can use to implement their own > temporary APIs for testing purposes. These can be renamed later without > changing their value as long as a single PMD uses them. > > -- > Adrien Mazarguil > 6WIND