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 648C7A054F; Sat, 4 Jun 2022 11:09:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 01D7F4021E; Sat, 4 Jun 2022 11:09:23 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id E115F40041; Sat, 4 Jun 2022 11:09:21 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01D877F2.C72C2CFF" Subject: Optimizations are not features Date: Sat, 4 Jun 2022 11:09:20 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D870EB@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimizations are not features Thread-Index: Adh38saBhCzWrq13QiKXVs+Vki9E2A== From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: Cc: 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01D877F2.C72C2CFF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like the DPDK community to change its view on compile time = options. Here is why: =20 Application specific performance micro-optimizations like "fast mbuf = free" and "mbuf direct re-arm" are being added to DPDK and presented as = features. =20 They are not features, but optimizations, and I don't understand the = need for them to be available at run-time! =20 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). =20 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. =20 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. =20 =20 Med venlig hilsen / Kind regards, -Morten Br=F8rup =20 ------_=_NextPart_001_01D877F2.C72C2CFF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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).

 

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=F8rup

 

------_=_NextPart_001_01D877F2.C72C2CFF--