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 EC62442870; Thu, 30 Mar 2023 14:54:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 818BF410D3; Thu, 30 Mar 2023 14:54:14 +0200 (CEST) Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by mails.dpdk.org (Postfix) with ESMTP id 78A9E40E25 for ; Thu, 30 Mar 2023 14:54:13 +0200 (CEST) Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 1B4233F23A for ; Thu, 30 Mar 2023 12:54:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1680180853; bh=u1yZI1/sOu3jCe2HuuINdSYvTaepobMInCOKShaScdY=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=NsRG1N0mPgKwhpPAya5mJvmUGDd9L+8ZokpXxxq8IfWc9xud1K1Vb77eBBgLWD/rU jWNbVaw2/of5LuWV8D3xEompAhmOZz7E3VRKM0mLeAon+zx8yHcfrcncUrYHOYPXvB ru6TUMRab57qi9FivozFEEoUtIykveE7V6duo365snEV51+KGKGqjp7kjybW8Iopx/ 0htWvFoSv47pQ760XOQNTphR5HKE3myAp4ZEYLyrR35TtPXHLOQEixe8T15QnBMWr7 YA/QLF+VWoFS7RCjvx11I9X8Ktmq7ehIfIOs6d2nXDw+dER7ggxcOgxuaspcXXouAS R/D4jmFmuEHbA== Received: by mail-pg1-f198.google.com with SMTP id e36-20020a631e24000000b0050f76fb84b6so5269876pge.8 for ; Thu, 30 Mar 2023 05:54:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680180848; x=1682772848; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=u1yZI1/sOu3jCe2HuuINdSYvTaepobMInCOKShaScdY=; b=bF1RPhiTHun/cmAa9pHO2v63zJMlbHIQMj48vYQvZinteirM8Tpt3kl2skbfHt59X9 XMxTbqJBtVmoJNK6C0njunSMPB2CuPGjzg+uHmB6uLHVnALZW/GMuZ/IufZLSphbeZKe dQKFkEiDhRdCKk/3Oxgq5K+NHBhauZW/ybpCEMgpv1KVBPM3V9mvDZjyi/6Qc3PQWJ4K 1xsta0hrfkLisfC+fJWCRnTQFiFBvGD+1eRNuYgFs88V/XeSsWbAp9UOgD97OenLEniX sqa+uAE7iWYbzF5DkIMV4Nz8ZVM887I1XTfaAmY90d/5SwHMQFIZ1NHfca9sv4l2mY8L jv7g== X-Gm-Message-State: AAQBX9dr2Zf5NS3StFLKNqWXIbYtHsV/GbuN7WOMCRAa6/povUkiREBP YM9QPq7RbdFolMKcwQ0Fi4fYRF7avUki5/5y9V3B8G3YPzv2V7FT+I3vYSacj3/iQkreVm53l89 wdFACIGoYsd8iJq4yPry10FT1+arU01qZ38qB2QAPbkHaGqg= X-Received: by 2002:a17:902:ea0e:b0:199:1a40:dccc with SMTP id s14-20020a170902ea0e00b001991a40dcccmr8597678plg.9.1680180847912; Thu, 30 Mar 2023 05:54:07 -0700 (PDT) X-Google-Smtp-Source: AKy350Y0HerKwdBAz0+nFUb/aAAlV2tjMl1zQ7Iow3LH+k5+zR/a6LyGKCVFAUrG7Xl+MkNsRsSy2rSYkKefz6g3SwE= X-Received: by 2002:a17:902:ea0e:b0:199:1a40:dccc with SMTP id s14-20020a170902ea0e00b001991a40dcccmr8597665plg.9.1680180847522; Thu, 30 Mar 2023 05:54:07 -0700 (PDT) MIME-Version: 1.0 From: Christian Ehrhardt Date: Thu, 30 Mar 2023 14:53:41 +0200 Message-ID: Subject: Should we try to be more graceful in library init on old Hardware? To: dev , Luca Boccassi Content-Type: text/plain; charset="UTF-8" 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 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? -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd