From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id F150D2B8B for ; Thu, 5 Jan 2017 01:01:31 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP; 04 Jan 2017 16:01:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,318,1477983600"; d="scan'208";a="50194047" Received: from dpdk19.sh.intel.com (HELO dpdk19) ([10.239.129.113]) by fmsmga006.fm.intel.com with ESMTP; 04 Jan 2017 16:01:28 -0800 Date: Thu, 5 Jan 2017 07:56:08 +0800 From: Tiwei Bie To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" , "adrien.mazarguil@6wind.com" , "Lu, Wenzhuo" , "Mcnamara, John" , "olivier.matz@6wind.com" , "thomas.monjalon@6wind.com" , "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" Message-ID: <20170104235608.GA133542@dpdk19> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772583F100375@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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 00:01:32 -0000 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. Thanks & regards, Tiwei Bie