From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A246195D4 for ; Fri, 12 Feb 2016 18:33:32 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 12 Feb 2016 09:33:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,436,1449561600"; d="scan'208";a="745009726" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.63]) by orsmga003.jf.intel.com with SMTP; 12 Feb 2016 09:33:29 -0800 Received: by (sSMTP sendmail emulation); Fri, 12 Feb 2016 17:33:28 +0025 Date: Fri, 12 Feb 2016 17:33:28 +0000 From: Bruce Richardson To: Ivan Boule Message-ID: <20160212173328.GB12176@bricha3-MOBL3> References: <1452869038-9140-1-git-send-email-tomaszx.kulasek@intel.com> <1452869038-9140-2-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB97725836AE637C@irsmsx105.ger.corp.intel.com> <3042915272161B4EB253DA4D77EB373A14E440C3@IRSMSX102.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836B024AC@irsmsx105.ger.corp.intel.com> <3042915272161B4EB253DA4D77EB373A14E46576@IRSMSX102.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836B05728@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836B062E2@irsmsx105.ger.corp.intel.com> <56BE0AE2.8080305@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56BE0AE2.8080305@6wind.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 17:33:33 -0000 On Fri, Feb 12, 2016 at 05:40:02PM +0100, Ivan Boule wrote: > On 02/12/2016 12:44 PM, Ananyev, Konstantin wrote: > > > >> > >>>-----Original Message----- > ... > >> > >>In that case we don't need to make any changes at rte_ethdev.[h,c] to alloc/free/maintain tx_buffer inside each queue... > >>It all will be upper layer responsibility. > >>So no need to modify existing rte_ethdev structures/code. > >>Again, no need for error callback - caller would check return value and decide what to do with unsent packets in the tx_buffer. > >> > > > >Just to summarise why I think it is better to have tx buffering managed on the app level: > > > >1. avoid any ABI change. > >2. Avoid extra changes in rte_ethdev.c: tx_queue_setup/tx_queue_stop. > >3. Provides much more flexibility to the user: > > a) where to allocate space for tx_buffer (stack, heap, hugepages, etc). > > b) user can mix and match plain tx_burst() and tx_buffer/tx_buffer_flush() > > in any way he fills it appropriate. > > c) user can change the size of tx_buffer without stop/re-config/start queue: > > just allocate new larger(smaller) tx_buffer & copy contents to the new one. > > d) user can preserve buffered packets through device restart circle: > > i.e if let say TX hang happened, and user has to do dev_stop/dev_start - > > contents of tx_buffer will stay unchanged and its contents could be > > (re-)transmitted after device is up again, or through different port/queue if needed. > > > >As a drawbacks mentioned - tx error handling becomes less transparent... > >But we can add error handling routine and it's user provided parameter > >into struct rte_eth_dev_tx_buffer', something like that: > > > >+struct rte_eth_dev_tx_buffer { > >+ buffer_tx_error_fn cbfn; > >+ void *userdata; > >+ unsigned nb_pkts; > >+ uint64_t errors; > >+ /**< Total number of queue packets to sent that are dropped. */ > >+ struct rte_mbuf *pkts[]; > >+}; > > > >Konstantin > > > > Just to enforce Konstantin's comments. > As a very basic - not to say fundamental - rule, one should avoid adding in > the PMD RX/TX API any extra processing that can be handled at a higher > level. > The only and self-sufficient reason is that we must avoid impacting > performances on the critical path, in particular for those - usually the > majority of - applications that do not need such extra operations, or better > implement them at upper level. > > Maybe in a not so far future will come a proposal for forking a new open > source fast-dpdk project aiming at providing API simplicity, zero-overhead, > modular design, and all those nice properties that every one claims to seek > :-) > > Ivan > Hi Ivan, I completely agree with your comments. However, none of the proposals for TX buffering would impact the existing fast-path processing paths. They simply add an optional buffering layer above it - as is done by a very large number of our sample apps. The point of this patchset is to reduce or eliminate this duplication of code by centralising it in the libs. Of the different ways of doing this proposed, my slight preference is for the original one due to the simplicity of the APIs it provides, but the advantages in flexibility provided by Konstantin's proposals may outway the additional "ugliness" in the APIs. Regards, /Bruce