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 78C1FA0554; Sat, 4 Jun 2022 13:10:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 285034021E; Sat, 4 Jun 2022 13:10:51 +0200 (CEST) Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by mails.dpdk.org (Postfix) with ESMTP id 5C9A140041; Sat, 4 Jun 2022 13:10:50 +0200 (CEST) Received: by mail-qt1-f173.google.com with SMTP id c8so7419821qtj.1; Sat, 04 Jun 2022 04:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rHBnN7O/HpwBnizgBF+0Sh/AhexsCap+jZRsTB0cV6g=; b=VkC0D0XCRXJbuNRtYGBpReNw7JtFA3Wsj/Sk8qcPHAFKrwYm7G4WO2Iga1vwwyDbiK cg4jeGhWYe4PcEo7nuRbSDA5jSHLFhxLEJfwuJpsqvJ8fqEM/D/aHhZg6IFVnbxRRS0p 8bHWKhUW0nv1oPmiBwgZ2ZlbGBqHfwz0DHpEDDChoZMO/kcfKPqZZa2qhLruHaVqfm02 JUc8VhHstzjofKxn8NSxhsJEpSA2G+SO/FczOd+Pl6JPCg4Qpd+9VcaDB+7m5diQeDpv RfBmt8ESEbWyihfWQs/7oFPp3aHUIDAiGxH5YkWKfRa5gfZPZABGWktdBMuUgN+b2TdJ p8Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rHBnN7O/HpwBnizgBF+0Sh/AhexsCap+jZRsTB0cV6g=; b=R1eKvOGfMoA08GoGoowqVj6+wsftnNzXY1HjAV7nUGaEHtqHXd4/hKDKY8B8VQJ0A8 MgpLEm+D2L/sEtvM62Xg1YtjH8Vj1LKqHym2WlGjLSgJlh+O5GfBsIaPaeBZdEOtQ0Lz CvdkAg4NXeYy5+LlN0VB0HkqdiMX28i6+B7w0qvvH0Hfj9OVrAA42btpjp14/cKIo43D t5k1m/IgBxzGLCOAp7UzP+JlGoQgy0Oqr/uRxhWTiniZ2OhTZZSGzT9+fJCCq/0mW+Bw t3jJ9lTmrxCQw4R5HTtmwEh7VQcT+q4UhCSbHUvDOgGuw/oJEjZu5oYlQFp3Yf/Bti1v QS9A== X-Gm-Message-State: AOAM533PQ+TrXP1qV/Wx+ZUEIywkNi1mrjB9SJ3Btf9swyvEExaoTkLi I0esgdAe0a1J8JlhiS5yLIGAYOiaaQxoa/gt+26T//jyBhs= X-Google-Smtp-Source: ABdhPJxg6uVnEZKcu5b+izK/gaXn8WVTJ9lv3pjS3VCefuyS3N8z+o/lIF2u+jgJNIv9jzOXbJlkBdGYYkEhhlreZcU= X-Received: by 2002:a05:622a:8f:b0:304:bbc4:7668 with SMTP id o15-20020a05622a008f00b00304bbc47668mr11398781qtw.172.1654341049618; Sat, 04 Jun 2022 04:10:49 -0700 (PDT) MIME-Version: 1.0 References: <98CBD80474FA8B44BF855DF32C47DC35D870EB@smartserver.smartshare.dk> In-Reply-To: From: Jerin Jacob Date: Sat, 4 Jun 2022 16:40:23 +0530 Message-ID: Subject: Re: Optimizations are not features To: Andrew Rybchenko Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= , dpdk-dev , techboard@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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=C3=B8rup wrote: > >> > >> I would like the DPDK community to change its view on compile time opt= ions. Here is why: > >> > >> > >> > >> Application specific performance micro-optimizations like =E2=80=9Cfas= t mbuf free=E2=80=9D and =E2=80=9Cmbuf direct re-arm=E2=80=9D are being add= ed to DPDK and presented as features. > >> > >> > >> > >> They are not features, but optimizations, and I don=E2=80=99t understa= nd 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 b= y 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 o= verride. > > 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. 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 } > 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 recomp= iling the performance critical libraries used by it. > >> > >> > >> > >> Allowing compile time options for application specific performance opt= imizations in DPDK would also open a path for other optimizations, which ca= n only be achieved at compile time, such as =E2=80=9Cno fragmented packets= =E2=80=9D, =E2=80=9Cno attached mbufs=E2=80=9D and =E2=80=9Csingle mbuf poo= l=E2=80=9D. And even more exotic optimizations, such as the =E2=80=9Cindexe= d mempool cache=E2=80=9D, which was rejected due to ABI violations =E2=80= =93 they could be marked as =E2=80=9Crisky and untested=E2=80=9D or similar= , but still be part of the DPDK main repository. > >> > >> > >> > >> > >> > >> Med venlig hilsen / Kind regards, > >> > >> -Morten Br=C3=B8rup > >> > >> >