From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 615ABA0545; Sat, 4 Jun 2022 14:52:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 08CA84021E; Sat, 4 Jun 2022 14:52:01 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id B267240041; Sat, 4 Jun 2022 14:51:59 +0200 (CEST) Received: from [192.168.1.126] (unknown [188.242.181.57]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 6617E13E; Sat, 4 Jun 2022 15:51:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 6617E13E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1654347118; bh=oq2UesGX2rZIDCLFLRnr7f/5xeqdJyZvhSMQih+McoA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=L0KIqOfSGDKXDkHnLTBgP9yU+LMN8unKvl9S5CGsmB3V/DMHmtHETElIRrv59gaFr JtAthAz9yuGrrAIW4CjMOvFylD+BCbT+bZk0PHg4wZMC5BSe7ajuIsjzd1Q+2eVO7B KL+m4e2TyhmsgOdUE4JeOwTtXZhC+fFPbmQMj3MU= Message-ID: Date: Sat, 4 Jun 2022 15:51:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Optimizations are not features Content-Language: en-US To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Jerin Jacob Cc: dpdk-dev , techboard@dpdk.org References: <98CBD80474FA8B44BF855DF32C47DC35D870EB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D870EF@smartserver.smartshare.dk> From: Andrew Rybchenko In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D870EF@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 6/4/22 15:19, Morten Brørup wrote: >> From: Jerin Jacob [mailto:jerinjacobk@gmail.com] >> Sent: Saturday, 4 June 2022 13.10 >> >> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko >> wrote: >>> >>> On 6/4/22 12:33, Jerin Jacob wrote: >>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup >> wrote: >>>>> >>>>> I would like the DPDK community to change its view on compile time >> options. Here is why: >>>>> >>>>> >>>>> >>>>> Application specific performance micro-optimizations like “fast >> mbuf free” and “mbuf direct re-arm” are being added to DPDK and >> presented as features. >>>>> >>>>> >>>>> >>>>> They are not features, but optimizations, and I don’t understand >> the need for them to be available at run-time! >>>>> >>>>> >>>>> >>>>> Instead of adding a bunch of exotic exceptions to the fast path of >> the PMDs, they should be compile time options. This will improve >> performance by avoiding branches in the fast path, both for the >> applications using them, and for generic applications (where the exotic >> code is omitted). >>>> >>>> Agree. I think, keeping the best of both worlds would be >>>> >>>> -Enable the feature/optimization as runtime >>>> -Have a compile-time option to disable the feature/optimization as >> an override. >>> >>> It is hard to find the right balance, but in general compile >>> time options are a nightmare for maintenance. Number of >>> required builds will grow as an exponent. > > Test combinations are exponential for N features, regardless if N are runtime or compile time options. But since I'm talking about build checks I don't care about exponential grows in run time. Yes, testing should care, but it is a separate story. > >>> Of course, we can >>> limit number of checked combinations, but it will result in >>> flow of patches to fix build in other cases. >> >> The build breakage can be fixed if we use (2) vs (1) >> >> 1) >> #ifdef ... >> My feature >> #endif >> >> 2) >> static __rte_always_inline int >> rte_has_xyz_feature(void) >> { >> #ifdef RTE_LIBRTE_XYZ_FEATURE >> return RTE_LIBRTE_XYZ_FEATURE; >> #else >> return 0; >> #endif >> } >> >> if(rte_has_xyz_feature())) { >> My feature code >> >> } >> Jerin, thanks, very good example. > I'm not sure all the features can be covered by that, e.g. added fields in structures. +1 > > Also, I would consider such features "opt in" at compile time only. As such, they could be allowed to break the ABI/API. > >> >> >>> Also compile time options tend to make code less readable >>> which makes all aspects of the development harder. >>> >>> Yes, compile time is nice for micro optimizations, but >>> I have great concerns that it is a right way to go. >>> >>>>> Please note that I am only talking about the performance >> optimizations that are limited to application specific use cases. I >> think it makes sense to require that performance optimizing an >> application also requires recompiling the performance critical >> libraries used by it. >>>>> >>>>> >>>>> >>>>> Allowing compile time options for application specific performance >> optimizations in DPDK would also open a path for other optimizations, >> which can only be achieved at compile time, such as “no fragmented >> packets”, “no attached mbufs” and “single mbuf pool”. And even more >> exotic optimizations, such as the “indexed mempool cache”, which was >> rejected due to ABI violations – they could be marked as “risky and >> untested” or similar, but still be part of the DPDK main repository. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Med venlig hilsen / Kind regards, >>>>> >>>>> -Morten Brørup >>>>> >>>>> >>> >