From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f179.google.com (mail-wj0-f179.google.com [209.85.210.179]) by dpdk.org (Postfix) with ESMTP id C9D933777 for ; Thu, 5 Jan 2017 09:33:30 +0100 (CET) Received: by mail-wj0-f179.google.com with SMTP id tn15so29417633wjb.1 for ; Thu, 05 Jan 2017 00:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=D79SsU6KEgNjk2HqAVhI6MPJy+zm2BsgbHoNrEm56Ok=; b=1VF7QmzH3GvIILag5JZD/L9+D6IuU8qmHH8s6/sq1YDy5K1f0/sPRcFDk0oURJYTDp U1JvAKwnpKPnwI/dFItXCXZivrScITYFAnOj7xzMk2zRhrpe1Lhq70xHdaG2H0DslZwx XDdWht7/h5TT1NZNTynIMyetgNZyJ3YHbHtGdNK1eaLZ/UL7xFEAkM+MiA1C/kcPoJ/C an9kg7Fojzp0BJW6Q0Z7Q5tyF3moVx+npr8cjzkDYCraIdAkRKKTW+ygdErGr+OkpVbN JIj1X4U7s2VjqDtCyJx03/H1GwcUsf462oAWlt3ZGlOg2ad+5sLB30LGNVkEu90lYom8 LgdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=D79SsU6KEgNjk2HqAVhI6MPJy+zm2BsgbHoNrEm56Ok=; b=tRsb7nU5BCxU1HWHxQ7QVoeyhpGN7jqIAUV6F85r/VCFI4GOjp+r875lDNsyZpOUgy fSRRahlVI03JJsEkELgcsHYHeu4D76wiwxcR++F3U9x1jRvcuw/etfddeC3p3jocj4M9 NZjzEtOuhpVpITAztSMhBb1eUEi2EEbtGxt1rvemQ3k4h1JabC5AUrFc64zgcFzbD/ZV u8muLxzfyHXL/+wc6MraDyDGW+xLwyjuKmNOzi0Oyqkn/KyV+L0JhWT0zVHhO15yBbh5 uB7F2esnGgR+2AS4q96lc1prKidIvwhJpTHBv8AEDbsiPgtmj9igL3IeDGwUe7upKTMw 2Vfg== X-Gm-Message-State: AIkVDXISPqCWMyfDxiPcug4JQ1x+peeuys0qxjAaS1FWEuEouUABI9hfRaym6RWhIMhOVkK5 X-Received: by 10.194.124.162 with SMTP id mj2mr59459821wjb.111.1483605210421; Thu, 05 Jan 2017 00:33:30 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id hp2sm6104381wjb.26.2017.01.05.00.33.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 00:33:29 -0800 (PST) Date: Thu, 5 Jan 2017 09:33:22 +0100 From: Adrien Mazarguil To: Tiwei Bie Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "Lu, Wenzhuo" , "Mcnamara, John" , "olivier.matz@6wind.com" , "thomas.monjalon@6wind.com" , "Zhang, Helin" , "Dai, Wei" , "Wang, Xiao W" Message-ID: <20170105083322.GK12822@6wind.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104235608.GA133542@dpdk19> 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 08:33:30 -0000 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. 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