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 A828945A2E; Wed, 25 Sep 2024 23:08:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 375F34025D; Wed, 25 Sep 2024 23:08:52 +0200 (CEST) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by mails.dpdk.org (Postfix) with ESMTP id 10EF1400EF for ; Wed, 25 Sep 2024 23:08:51 +0200 (CEST) Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-7a99de9beb2so20795885a.3 for ; Wed, 25 Sep 2024 14:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1727298530; x=1727903330; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=wnttvZuim5NmguLjorgg1gnfoQdGCo9Jky2Sv3JJWNM=; b=I3YXCVyXz03dZJhluJZJDjbPIi1ojqm626dEGLGrY1jC2WOImMjqUMiI/WKnSig7Qd jULw618HBbTJHlpmUlh1+4/hXsUR0Vogbo3EcO5k7PsvdCcJih0CUcFA8ohfUPZGny2+ +gDKHG5IHvvKy2XwlfJm50h/n1lsdmeHxguIj6fL9sqvcs2Pk7SnxAegjog2blMDNoML XzO6J+Ahok3+/IhiHyT3dggB0qlrb5o4QNiFQC48DJaZK+rr2GZ+G8b66QHHktzY+FBp YTSwu/ze9Ue+NwiltCTk7QjZBHkQNTN8IcBUtDuCNnA4513lujszijHaY55K8J/Cq+xG Nuqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727298530; x=1727903330; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wnttvZuim5NmguLjorgg1gnfoQdGCo9Jky2Sv3JJWNM=; b=KcK42rd11zlI7cRjKNxWkzQNFy3VvuoXNaer/6gL1+hcD9XmjiN7C3iChwfrFmPdj2 4QBh6KUsAvtqX/Ka6Oybmu08xoa/GwBcvKV46N6FNKOXYBAYT75ofvrqsOy2Pwb6xrl8 3b1Drzs2RrfGYTqCvMkpgTtRnXYJ/bkmOsu3IAUZ27Nlqo8JlRPaazys8yHDHU7iAJPh 6GuCkRqAzhcIRcwSivjb4yetTmy43woak0Gs8ansxVbqp5cxqRYqYuiikyirArbpalJn 7+t7nYNtppthr/UncJyyY5mMBMqdeCSGLA20s2tiKvVz/a7jWgiw9GKDL9VG2laOWyl6 fgtw== X-Gm-Message-State: AOJu0Yx4KArSS3+C9srxU+CUT3DOhl88x0k9r0BJPSrgqkJ6Pz7POuIO XAk+RU0pbydbZMYY2BzY1z/rgBN4/2dhCRKmtVArpQaKUXwTnApVYKHxLIKWc0Ci2F9XaDoMb9i CAZY= X-Google-Smtp-Source: AGHT+IEQGpPbRvwtmWGscL7lAjnxOHUHr7GnlZcGuUdLkOGd77ppRFHm586QqwZuWeFAVoEYt0hlCg== X-Received: by 2002:a05:620a:191a:b0:7a9:dcbc:f82b with SMTP id af79cd13be357-7ace74635cfmr557460285a.54.1727298530148; Wed, 25 Sep 2024 14:08:50 -0700 (PDT) Received: from fedora ([173.242.185.50]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7acde5cb95fsm206725485a.78.2024.09.25.14.08.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2024 14:08:49 -0700 (PDT) Date: Wed, 25 Sep 2024 14:08:48 -0700 From: Stephen Hemminger To: dev@dpdk.org Subject: Re: [PATCH v5 00/10] support reinit flow Message-ID: <20240925140848.2e6b2aca@fedora> In-Reply-To: <20230817042820.137957-1-okaya@kernel.org> References: <20230817042820.137957-1-okaya@kernel.org> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-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 On Thu, 17 Aug 2023 00:28:11 -0400 okaya@kernel.org wrote: > From: Sinan Kaya > > We want to be able to call rte_eal_init() and rte_eal_cleanup() > APIs back to back for maintanance reasons. > > Here is a summary of the code we have seen so far: > > 1. some code support getting called multiple times by keeping > a static variable. > 2. some code initializes once but never clean up after them and > don't have a cleanup API. > 3. some code assumes that they only get called once during the > lifecycle of the process. > > Most changes in this patch center around following the #1 design > principle. > > Why? > > It is not always ideal to reinitialize a DPDK process. Memory needs > to be reinitialized, hugetables need to warm up etc. > > Limitations: > > This sequence could only be done by main lcore, and never ever in a signal handler. > Do not try and trap signals like abort, bus error, illegal instruction and try to > use this for recovery. It is a recipe for failure. > This patch series suffers bit rot and does not apply anymore. Needs to be rebase and resubmit. There probably needs to be more unit-tests for restart. Also some documentation for example, for which NIC's does this work? Probably not all.