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 B3A9742871; Thu, 30 Mar 2023 16:31:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 52349410D3; Thu, 30 Mar 2023 16:31:06 +0200 (CEST) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by mails.dpdk.org (Postfix) with ESMTP id 4F91540E25 for ; Thu, 30 Mar 2023 16:31:05 +0200 (CEST) Received: by mail-lf1-f45.google.com with SMTP id j11so24749844lfg.13 for ; Thu, 30 Mar 2023 07:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680186664; x=1682778664; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=i6c2wLQ1hETbMNCaucU9bPrjc7C2mkJTErJQAWHYxmU=; b=P4KP6y40+V9BtWKN7B+tjcqs+jxe/9lQ/S/fdLdWrJcUsCMM9SiPNu4ATbEyNu0thJ BSuK4GUjaZiJVhi7yDwjYfLdmC3NFA3BeQYRfgSzrFhidGZ3BZg7xiKEvZZlUNxdp3Id RBNCFjRyGN4pDuQreiODQR7RXCbtNAYx6LPR8QT6LCW1LtOdiBZ7Ym96381womN0JTMx RSnAv42N5xM1Oh6ZiZonb9bu3RGs7lBfx9c4E+vay87TEVkCbA2JUtgdyxxLDKhBh499 r1Bf2/CCvLI3T9AyeJGbHGQlk9Y8s7CFJZ3A4O1FKvflgVIKvCvOlbc3+xjFEeyrxV7z BJKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680186664; x=1682778664; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=i6c2wLQ1hETbMNCaucU9bPrjc7C2mkJTErJQAWHYxmU=; b=apkmbUs+aQKR5GhBZVfkWsOU4+F+MdVfxo5JcT661W5W8FHa95uZQliWPQ54TUX2xn QgVJRUzcHv3MqMkH05uObiMUJivQv9VDOmNZp0pO+KivrWmODejlhs/jwvSOMKZS+84z KLrANpwrjcNH1n14sCU5lOL3bQM7tWOTiWo298C+27BHn5zwGJ48CmHuheynp6/LPERj 7lMMGjOpYcBN3M0GdTjJBtLOsnbB1AnV2wN9wCkcZ9Ew65DAS3v29eaHEVmyVRcEESE8 wjBJuphip0jFlluAAMbOEiEOnJqVhVgAITPBk9WhdTNx1gdSUquSp6rGA7tHSY/2C6ks 86Rg== X-Gm-Message-State: AAQBX9ckMq+vZZ/3ud1CUNgnTESdQiOdmmtytlXyDpaFzOZuOv/fCgih GFgf/GLhxg7ARggELbNDfLw= X-Google-Smtp-Source: AKy350ZyD+ANtsBDzmP5q4B/2t6eThX9s8LzEjqvSWeIVa8nPdWoqtZBIJKzJJhBafLpjYCNfLz7hw== X-Received: by 2002:ac2:538a:0:b0:4eb:4ee:7c25 with SMTP id g10-20020ac2538a000000b004eb04ee7c25mr1826827lfh.8.1680186664413; Thu, 30 Mar 2023 07:31:04 -0700 (PDT) Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id x4-20020a19f604000000b004eb0eafaa02sm1762832lfe.243.2023.03.30.07.31.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 07:31:04 -0700 (PDT) Date: Thu, 30 Mar 2023 17:31:02 +0300 From: Dmitry Kozlyuk To: Bruce Richardson Cc: Christian Ehrhardt , dev , Luca Boccassi Subject: Re: Should we try to be more graceful in library init on old Hardware? Message-ID: <20230330173102.2c60fce5@sovereign> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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 2023-03-30 14:28 (UTC+0100), Bruce Richardson: > On Thu, Mar 30, 2023 at 02:15:42PM +0100, Bruce Richardson wrote: > > On Thu, Mar 30, 2023 at 02:53:41PM +0200, Christian Ehrhardt wrote: > > > Hi, > > > I've recently gotten a kind of bug I was waiting for many years. > > > In fact I wondered if it would still come up as each year made it less likely. > > > But it happened and I got a crash report of someone using dpdk a > > > rather old pre sse4.2 hardware. > > > => https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2009635/comments/9 > > > > > > The reporter was nice and tried the newer 22.11, but that is just as affected. > > > > > > I understand that DPDK, as a project, has set this as the minimal > > > accepted hardware capability. > > > But due to some programs - in this case UHD - being able to do many > > > other things it might happen that UHD or any else just links to DPDK > > > (as it could be used with it) and due to that runs into a crash when > > > loading. In theory other tools like collectd which has dpdk support > > > would be affected by the same. > > > > > > Example: > > > root@1bee22d20ca0:/# uhd_usrp_probe > > > Illegal instruction (core dumped) > > > > > > (gdb) bt > > > #0 0x00007f4b2d3a3374 in rte_srand () from > > > /lib/x86_64-linux-gnu/librte_eal.so.23 > > > #1 0x00007f4b2d3967ec in ?? () from /lib/x86_64-linux-gnu/librte_eal.so.23 > > > #2 0x00007f4b2e5d1fbe in call_init (l=, > > > argc=argc@entry=1, argv=argv@entry=0x7ffeabf5b488, > > > env=env@entry=0x7ffeabf5b498) > > > at ./elf/dl-init.c:70 > > > #3 0x00007f4b2e5d20a8 in call_init (env=0x7ffeabf5b498, > > > argv=0x7ffeabf5b488, argc=1, l=) at ./elf/dl-init.c:33 > > > #4 _dl_init (main_map=0x7f4b2e6042e0, argc=1, argv=0x7ffeabf5b488, > > > env=0x7ffeabf5b498) at ./elf/dl-init.c:117 > > > #5 0x00007f4b2e5ea8b0 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 > > > #6 0x0000000000000001 in ?? () > > > #7 0x00007ffeabf5c844 in ?? () > > > #8 0x0000000000000000 in ?? () > > > > > > Right now all we could do is: > > > a) say bad luck old hardware (not nice) > > > b) make super complex alternative builds with and without dpdk support > > > c) ask the DPDK project to work on non sse4.2 (unlikely and too late > > > in 2023 I guess) > > > d) Somehow make the initialization graceful (that is what I'm RFC here) > > > > > > If we could manage to get that DPDK to ensure the lib loading paths > > > are SSE4.2 free. > > > Then we could check the capabilities on the actual initialization and > > > return a proper bad result instead of a crash. > > > Due to that only real-users of DPDK would be required to have > > > sufficiently new hardware. > > > And OTOH users of software that links, but in the current config would > > > not use DPDK would suffer less. > > > > > > WDYT? > > > Maybe it has been already discussed and I did neither remember nor find it? > > > > > It certainly hasn't been discussed previously, but there is meant to be > > support for this in EAL init itself. Almost the first function called > > from eal_init() is "rte_cpu_is_supported()" [1] which checks the build-time > > CPU flags against those of the current system. > > Unfortunately, from the error message you are getting, that doesn't seem to > > be working ok in the case of SSE4.2. It seems the compiler is inserting > > SSE4 instructions before we even get to that point. :-( > > > > Perhaps we need to move eal init to a new file, and compile it (and the > > cpuflag checks) with very minimal CPU flags. > > > > Following up to my own mail... > > I believe we may be able to solve this easier by maybe using the "target" > attribute for those functions. For x86 builds I don't see why eal init > cannot be compiled for an earlier SSE version, (march=core2, perhaps). It's > not a performance-sensitive function. > > Thoughts? > /Bruce The error originates from some RTE_INIT() routine called on library load. They can also be augmented with the "target" attribute and a check before calling the actual code supplied by DPDK developer. The latter is needed because we can't ensure (systematically) that this code doesn't call some external function that uses SSE4.2. As for rte_eal_init(), I think the check there is enough with one big "if": main() must also be compiled for the generic CPU to get there. So app developers can't be completely freed from thinking about this. BTW, rte_cpu_is_supported() itself is not protected against being compiled into unsupported instructions :)