From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C100DA04AF; Sun, 3 May 2020 11:58:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 96C881D544; Sun, 3 May 2020 11:58:24 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id 1DCA51D529 for ; Sun, 3 May 2020 11:58:23 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id w4so9238229ioc.6 for ; Sun, 03 May 2020 02:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KRLU+ypGv1f05tD6jLA+ZnfEz/3OfZYlCqWUrBl735o=; b=CQZ1dz+aRgo2Net/Zgv4U3ZfuNzC/VSzJD5/QzOIIAJCFo3mFKxAO/dEb/jTEClTok jTyhPCIHLGqRBkdMrqW6+i3NJb5AeUGMfejXLlyTGAy7Wuy82/DArtzc9ozmoxfDrXqk wDHk/iZXI0WKUteK2ty+faQ1aus2NaFAZuMSiXufoVz2D42D6IAH7F2p/1sqa/F8iNaE +i/ZAZ5QfoogdmRkFnq8s4Vhd1043W8iO7SE1WQSdYzkcTDXKNcbSKtEyDilOrywRvkt oRXJv0J5FRn5ToK4S0nEXEIlNV583k+GtYTckPXdcYut88/5GlyDD+u6BzdqvdPoyH/6 eFsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KRLU+ypGv1f05tD6jLA+ZnfEz/3OfZYlCqWUrBl735o=; b=i5uBdmN2y9OrhgOZOb1W1EeFTyxlGjlAHS3kNmpJJ633Zjgd6nyDgXD0LR7tHb2DDF RBECpSzJU5GQ/r/lGDxdmDKw295IkWtJ3XOPNogFHvPXSxZui+Yw+HckzFDSXoePABlu Tptg2nwtsW0Q2aWnIUZjB+5Z1FxtRwJ/BTdRO1S0zpjoqoLGZOabiqV14D90xqXJ349j fL5ytz7Y8sa7iEfbGc1bHeI4O0y4LMqz1ap8ypJuArLZGqbgXbPh7dfkoh4bw0cuqACo u6fVasDbxlMlzba1vdoKROuzAgTKuaRSe/01+deuKd19ob2R97EZQNXdJDQGVsC76T3Y Q/Vw== X-Gm-Message-State: AGi0PuaOx5jrKMk84dF9OAlAOr01KZCx8ULU6r5ENLqKntK+Oa1I2KcM hs39CEDPTTwh9TxjHEvOvYKNIDOAe/uZwg7Hez4= X-Google-Smtp-Source: APiQypIgAeZhms9LUUGP0sKJlZzSk+RhJ9Mg0HvISec+7HIyehZfAr3wNKpsx81Uhg5L4ws202xrcQlfRrKodxeJTkg= X-Received: by 2002:a5d:8c89:: with SMTP id g9mr11050975ion.1.1588499902366; Sun, 03 May 2020 02:58:22 -0700 (PDT) MIME-Version: 1.0 References: <20200427181039.1943-1-pbhagavatula@marvell.com> <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D4BB9BC@BGSMSX101.gar.corp.intel.com> <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D4BBB62@BGSMSX101.gar.corp.intel.com> In-Reply-To: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D4BBB62@BGSMSX101.gar.corp.intel.com> From: Jerin Jacob Date: Sun, 3 May 2020 15:28:06 +0530 Message-ID: To: "Varghese, Vipin" Cc: Pavan Nikhilesh Bhagavatula , Jerin Jacob Kollanukkaran , "Burakov, Anatoly" , dpdk-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] eventdev: fix device probe and remove for secondary process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sun, May 3, 2020 at 6:45 AM Varghese, Vipin w= rote: > > Hi Pavan, > > Snipped > > > >> > > > > >> > > When probing event device in secondary process skip > > >> > > reinitializing the device data structure as it is already done i= n primary > > process. > > >> > > > > >> > > When removing event device in secondary process skip closing the > > >> > > event device as it should be done by primary process. > > >If primary has crashed or closed before secondary abnormally. Should > > >not close of secondary trigger removal of Eventdev services? > > > > Closing event device on exit of one secondary doesn=E2=80=99t make sens= e as there > > might be systems where there might be one primary and multiple secondar= ies > > and secondaries are spawned/destroyed on demand. > > > > Behavior of secondaries on primary process crash is undefined. > Absolutely true, there are work scenarios where primary configures ports = and Eventdev queues-ports pair. It would be multiple secondaries which proc= ess packets via event dev. In such cases, when primary segfaults or crashes= it will lead to undefined states. > > In such scenarios, would not it be preferer able for all secondaries to s= ubscribe to service function like health check. If the primary is not alive= anymore, then gracefully handle inflight events and events to dequeue. If = this is right understanding, should not there be option in secondary to gra= cefully shut down it's worker queue and ports (rather than event device ins= tance)? The health check function may not be limited to eventdev, it must apply for all the subsystems in multiprocess mode if primary dies. Such features can be designed/agreed based on every subsystem in mind. For rc2, Let's have this bug fix. New features can be implemented after an agreement with all stakeholders wrt multi-process semantics which applicable for all subsystems. > > snipped