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 CEB44A0540; Mon, 4 Jul 2022 18:33:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 572BA40E50; Mon, 4 Jul 2022 18:33:17 +0200 (CEST) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by mails.dpdk.org (Postfix) with ESMTP id CC3C94021D for ; Mon, 4 Jul 2022 18:33:16 +0200 (CEST) Received: by mail-pj1-f51.google.com with SMTP id a15so3084085pjs.0 for ; Mon, 04 Jul 2022 09:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/i1j6HiQsr1l3IXEF9pj7eNKhtg/8hHyMsvIJEKMJfY=; b=Qy/ewOK9pJ+VBZBtpDFevmLw5s3cpIvEmnverDqF8UmL2CDSizi7Cj4O6c6kx8731W XQClXgtOwQJPwT6oInz/pAZOq/dxnC8D8m29/V9NIDfZa5xiAG1kAD1LqXvONOEKlOSa UfkPHKK1wDkZYqjGVcWrGRzy83zJlbzR+0q5XRym5aar8kCml+iLvV2xbwIufNjqQY+R TjF9gmKHwk56sIp5FFUSaFBZI4k5iBNGNg5BK4OVlpYOVCo7icK13C70p5me6fctz9tg Apk23iGk/bbMkRlPWpKQVJxWC6Hr8S3oNUYLUGBzx9H4EUb11bXWM31z98YwtOmPY50M b4ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/i1j6HiQsr1l3IXEF9pj7eNKhtg/8hHyMsvIJEKMJfY=; b=z5WVE5DRoy4O05b10hnKCX0D5PGYugKGB8R0hWGQfrpeyfv6rXRrHeOJhJ9S6R+2o9 O93nf+tLqDns5fvUZ4+e7mOrDNRvqw/6pQ1d9Eu49/M6woh6h4QsACayLDsgWuT7q580 dlxt5m8gEMOHln2DBm/3FdYGsjw8zDt5XvNkWfHt/Kmw8uDi2X3SD68CALMc3AwggXg2 HxctvArh3+Oan5Li2p0aY7qyJ+Buvqweree7fHcUhXXHZoLGwEWGtwXGxu9CB4+EyDud wKAFB++wHRJFtzy2+C90eGv4Fiyz1y6cETSX6KSQaBsVp9iECMwdFARQ6ZdVSWYflEiY rD9Q== X-Gm-Message-State: AJIora/Q//td6N+20OS6nutVMWLEH1EIArIpAQdtkrH1IhUvpUkLRAlA KRFypEri6zagh46pUs/MzNMNng== X-Google-Smtp-Source: AGRyM1sRjn0LmVasyNzEDZ5/MJKcEXkPlbYmG74iM4234bNuNgyEJyylXD70CID4MDHwB3hKaKCl2Q== X-Received: by 2002:a17:902:9f88:b0:16b:e3f3:cb6c with SMTP id g8-20020a1709029f8800b0016be3f3cb6cmr6004593plq.14.1656952395854; Mon, 04 Jul 2022 09:33:15 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id s7-20020a17090302c700b00168e83eda56sm21505869plk.3.2022.07.04.09.33.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Jul 2022 09:33:14 -0700 (PDT) Date: Mon, 4 Jul 2022 09:33:11 -0700 From: Stephen Hemminger To: Konstantin Ananyev Cc: Honnappa Nagarahalli , Andrew Rybchenko , Morten =?UTF-8?B?QnLDuHJ1cA==?= , Jerin Jacob , dpdk-dev , "techboard@dpdk.org" , nd Subject: Re: Optimizations are not features Message-ID: <20220704093311.0582d592@hermes.local> In-Reply-To: <91f748cd-14c1-91ca-befe-64db36789346@yandex.ru> References: <98CBD80474FA8B44BF855DF32C47DC35D870EB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D870EF@smartserver.smartshare.dk> <497ed526-2fb7-805a-f72c-5909b85a62c1@yandex.ru> <91f748cd-14c1-91ca-befe-64db36789346@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Sun, 3 Jul 2022 20:38:21 +0100 Konstantin Ananyev wrote: > > > > The base/existing design for DPDK was done with one particular HW architecture in mind where there was an abundance of resources. Unfortunately, that HW architecture is fast evolving and DPDK is adopted in use cases where that kind of resources are not available. For ex: efficiency cores are being introduced by every CPU vendor now. Soon enough, we will see big-little architecture in networking as well. The existing PMD design introduces 512B of stores (256B for copying to stack variable and 256B to store lcore cache) and 256B load/store on RX side every 32 packets back to back. It doesn't make sense to have that kind of memcopy for little/efficiency cores just for the driver code. > > I don't object about specific use-case optimizations. > Specially if the use-case is a common one. > But I think such changes has to be transparent to the user as > much as possible and shouldn't cause further DPDK code fragmentation > (new CONFIG options, etc.). > I understand that it is not always possible, but for pure SW based > optimizations, I think it is a reasonable expectation. Great discussion. Also, if you look back at the mailing list history, you can see that lots of users just use DPDK because it is "go fast" secret sauce and have not understanding of the internals. My concern, is that if one untestable optimization goes in for one hardware platform then users will enable it all the time thinking it makes any and all uses cases faster. Try explaining to a Linux user that the real-time kernel is *not* faster than the normal kernel...