From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 7DE7795B5 for ; Fri, 12 Feb 2016 17:40:18 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id g62so69829757wme.0 for ; Fri, 12 Feb 2016 08:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=4u2p+iuPOFrH+ADFUsNPQyUZgYR621VEKTCE75y2394=; b=Zk7qzWrgdeKKE1vVgjp8rwB/z7zfEDLvUjnozgTTae6yzPn8S7JMEFbxUKUORxYr3M 55p0w4QjvwNdjmnyfT/PAKXxyqlJXetch9SqpMTij6YaX3+uOlNzt8VwlENaoZq/oN9Q ziZ3NPMQV8r57U/L1sZYdVkC2T4gO5ekhXa8ODEThSkKqtVXwzBqFQFKyn2pIvLhme8x rMGr9fjL8Y/z4g8NAHnrz6xMZe3jdTLrApgzDPHbqkKc0spqWWE72sciCrV5RO2Dh/C1 lf+HR7nnEr/ntTvwsovH5M7lmLqTmmfuAV6507kDUSkRHKrme8fA+Rbw30wD2MNXSVdC kThA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4u2p+iuPOFrH+ADFUsNPQyUZgYR621VEKTCE75y2394=; b=bDqgjaD3ilfv6r4hqTeLgIhF/vxUx2Eq+PtED6FOvqwfHLqxVOTXhUbqVd1aBIU1YW WKghgP+ZrGGi35m+xCUllWzRj82osQ6NR+6jSuWkdIdnvaTrkmKqn4GUu8omkemFHHm1 ImLelbqHKUgzL6YBe6Q3vly5tTZSciih6vxVJaH3zxKskpNjH6BtqqsHATR/T/3tM7y8 WwR5jiiQLTt8ECajGRAI3/JsnMD4VzHCA/3oXxO5l2O00tOvaw7fJJSArVxFvieVgA0R l6XmtDhfPRLb4111Tkuvlm6TTrdXkmt+RD2cGET5p4vPrKbltnpCjtaM8Zq+gu5rMvG0 n3nQ== X-Gm-Message-State: AG10YOTw3mH1NkkbushiDS5s1W/uUJezudAn1opHMJGuQTocmzhyybCw39o3tHJYLOE8OZ8O X-Received: by 10.28.55.74 with SMTP id e71mr5694642wma.26.1455295218351; Fri, 12 Feb 2016 08:40:18 -0800 (PST) Received: from [10.16.0.189] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id z65sm7293377wmg.1.2016.02.12.08.40.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 08:40:17 -0800 (PST) To: "Ananyev, Konstantin" , "Kulasek, TomaszX" , "dev@dpdk.org" 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> From: Ivan Boule Message-ID: <56BE0AE2.8080305@6wind.com> Date: Fri, 12 Feb 2016 17:40:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB97725836B062E2@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 16:40:18 -0000 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