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 3511F4340A for ; Thu, 30 Nov 2023 08:45:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9E80642E5D; Thu, 30 Nov 2023 08:45:58 +0100 (CET) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id 1A11042E5C for ; Thu, 30 Nov 2023 08:45:58 +0100 (CET) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-6cdedb683f9so100933b3a.0 for ; Wed, 29 Nov 2023 23:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701330357; x=1701935157; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=bSLYA/FziL+eNnq9glqRf2B8zSS9Dz35PtDkvVGkBUY=; b=P5KhrcAz/xC8pr4E9XKzK2c1ghGOiaEmngg0i5G+sJfPTxkBHhGvwc4vQO2F855xT5 aotmPq9/EkHusdSuOw6tbZ5gYAhdgC9rCcnZTEWRCog2VaUXsm7Na0ZQuJAT50wpxQ0s Ay/kUO/OBa15+mqjdA0aDfr73Vv8GNB++A9RDrxvzGcHVXl267yDmHpRUdJLeUYsJ5Tc YqRtOEJsacaekkMIfwfBCscjqy7MjMHJuk/691vmLkxXLYI/Fe6Wusf4tPh2Lm7XH2/i Qq1Z6TAEuiG6nhRUvLz47Y6D0MGFxaP0R7ESbRQ71WiyuS2lB+Cj8ong1ujjJyGdDH4a ze1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701330357; x=1701935157; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bSLYA/FziL+eNnq9glqRf2B8zSS9Dz35PtDkvVGkBUY=; b=WSsRcnpWWkPnDWqv+Q3T7GO5RWwVRcO78O1IQtlWyqwhWLmVATW53gsyuPd521MzNU +Mvga4G0U1RbGMhRSgF78spQ242SqW+0jInGHx0qStkDFd3CPp6vwUBdqGZoCVhSoASp ZIkLhYJnGpqxErN45LF0dEl0+d4+uN7zX08vlZ/iUlxaxQmSSOMdLi6H5fhtPbNM3DwA Wb0tdfYxgUHokkFB7IABWqJXknoCwFURlLqsk2X1fCVd7GTAhIbBTGyjjMin69TEt3XY cW5Sfop/MNfXiZQJj2eOCLucClT0SyREzr7sRvTgiU/7CR8IXzCJS1B/GVGS3kS/sBml TZcQ== X-Gm-Message-State: AOJu0Yzcgccq9BR0D3OEuErKVxF5HVhVA5VSLYe1/bKERc0tK9OWcSMr WGxU3B/tiJGuCtcvyorG+5mCy8E3yRSSDzsOP0WmM7KRyAI= X-Google-Smtp-Source: AGHT+IFMbiNQsTuu6l7h4e43HEXvYlWG6aUp/d/yr4lRmPiokeo8e/Clhs7+wWyvJ4gJFoVcK/QvVDKsUAFL9Wd1Dnk= X-Received: by 2002:a05:6a00:14c6:b0:6c4:dc5b:5b2b with SMTP id w6-20020a056a0014c600b006c4dc5b5b2bmr23289996pfu.20.1701330356863; Wed, 29 Nov 2023 23:45:56 -0800 (PST) MIME-Version: 1.0 From: Fuji Nafiul Date: Thu, 30 Nov 2023 13:45:45 +0600 Message-ID: Subject: how to make dpdk processes tolerable to segmantation fault? To: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000091067a060b59d7f0" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --00000000000091067a060b59d7f0 Content-Type: text/plain; charset="UTF-8" In a normal c program, I saw that the segmentation fault in 1 loosely coupled thread doesn't necessarily affect other threads or the main program. There, I can check all the threads by process ID of it in every certain period of time and if some unexepected segmentation fault occurs or got killed I can re run the thread and it works fine. I can later monitor the logs and inspect the situation. But I saw that, segmentation fault or other unexpected error in remotely launched (using DPDK) functions on different core affects the whole dpdk process and whole dpdk program crashes.. why is that? Is there any alternative way to handle this scenario ? How can I take measures for unexpected future error occurance where I should auto rerun dpdk remote processes in live system? --00000000000091067a060b59d7f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In a normal c program, I saw that the segmentation fault i= n 1 loosely coupled thread doesn't necessarily affect other threads or = the main program. There, I can check all the threads by process ID of it in= every certain period of time and if some unexepected segmentation fault oc= curs or got killed I can re run the thread and it works fine. I can later m= onitor the logs and inspect the situation.

But I saw that, segmentat= ion fault or other unexpected error in remotely launched (using DPDK) funct= ions on different core affects the whole dpdk process and whole dpdk progra= m crashes.. why is that?

Is there any alternative way to handle thi= s scenario ? How can I take measures for unexpected future error occurance = where I should auto rerun dpdk remote processes in live system?

--00000000000091067a060b59d7f0--