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 BF42BA034C; Sat, 4 Jun 2022 12:00:28 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AACDE4021E; Sat, 4 Jun 2022 12:00:28 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 34F3840041; Sat, 4 Jun 2022 12:00:27 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 938F1148; Sat, 4 Jun 2022 13:00:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 938F1148 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1654336826; bh=7hir5Dn5pVwo+SUY7D6xSMdNo6rup1CAEKg6yK6Zy0w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BX0QSmZfCpaMqhbIXd8Vinqcaw7R3mrIzDvDt9Ooogtd7n4oubaO9zpYGEUitW9M7 KqQ7+/hChkuYYAxdBlle4+V5/XUTBTD5JlqusjgTYXhkL2/9OEnsBYffsDeVcX/Yz1 XaWLx0N6JYM/kVGdcSJ4stKGW0pPMZ3e1CEN5SlY= Message-ID: Date: Sat, 4 Jun 2022 13:00:26 +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: Jerin Jacob , =?UTF-8?Q?Morten_Br=c3=b8rup?= Cc: dpdk-dev , techboard@dpdk.org References: <98CBD80474FA8B44BF855DF32C47DC35D870EB@smartserver.smartshare.dk> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: 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 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. Of course, we can limit number of checked combinations, but it will result in flow of patches to fix build in other cases. 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 >> >>