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 1E3F74221C; Fri, 1 Sep 2023 09:32:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ADEC140285; Fri, 1 Sep 2023 09:32:43 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id A2E074014F for ; Fri, 1 Sep 2023 09:32:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693553561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SAHE6ojLOySA/WspMXSEPmqTOxpAASfpPWFogDHkldM=; b=QNkSsnvj2a5gyfThkksv0LLQbrm8nEqLRCu/P9qCVzVVpkqyQLqinwji0HdDmeGWiG9Bvc XLJqpNvvI9K7Qwt+uOjrK0BcleuD57FFuDOvyoB3Vbdnv6+8r4iGE/bZCjZlaPfAwvEUpb J+TNd46/HHBZH0x3QnBK6oMYDpCR6LQ= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-646-u0Zc0kSxOZiXolIFrhQJrQ-1; Fri, 01 Sep 2023 03:32:40 -0400 X-MC-Unique: u0Zc0kSxOZiXolIFrhQJrQ-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-5009bdf5bdfso1941740e87.0 for ; Fri, 01 Sep 2023 00:32:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693553558; x=1694158358; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SAHE6ojLOySA/WspMXSEPmqTOxpAASfpPWFogDHkldM=; b=fvX/WXCYN1DaE1RbkqJZ1wujVKq/Zbme6J5GWgPWnNZgDIApe2xTlwQvEeuXUnlacE axZdYh7lH2Kn4wQJCA5RyoosZrWM/NOAw3hZSdGg9xM76gPjjgeVA9hWyeDrAxRtyz75 a8pBOePgDbNWgJ855+INUs+j1JZMO4d5wA8uzm+k3bl4sNjhMjYfzOllvQ45wkJDw1vl uws93f5WT0jFNIeIQV2Li+5rscwJVWbOQLcjWT9roU3g0fi29Pk0T/Cm8DPVApMGecvd D86VvKz5Fy0reSBi8U7i89Knkax8v8iOZR0e0w5HPzJ4y4dnP9u5M2HUhsuFyhuPnyuA j8PQ== X-Gm-Message-State: AOJu0Yy4A1lPVJvqVpYTu5znqYftg8XkXsE4NB/Gl+gKjD8t4XRWYlJF +FE1JKKEFd/PAJJp4YwUKtG5yHJPRvP4OHWZ1XHSJ+V4qIFBOgAQXC1KWVpeukO4EOG5EZCaYXS XN47NLaSTj7zfS3T5y1s= X-Received: by 2002:a05:6512:108a:b0:500:c00e:8f15 with SMTP id j10-20020a056512108a00b00500c00e8f15mr1619155lfg.16.1693553558635; Fri, 01 Sep 2023 00:32:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHA0o4d+E8On9n5vd8JIjDTXxeGzFHmWjZQEmF+SvQ9dMMxrrHLK1ZiH0Vf/d9t+HtOBgVc2P8qWBNULxy2WWg= X-Received: by 2002:a05:6512:108a:b0:500:c00e:8f15 with SMTP id j10-20020a056512108a00b00500c00e8f15mr1619143lfg.16.1693553558333; Fri, 01 Sep 2023 00:32:38 -0700 (PDT) MIME-Version: 1.0 References: <20230818091321.2404089-1-david.marchand@redhat.com> <20230821085806.3062613-1-david.marchand@redhat.com> <3559497.LM0AJKV5NW@thomas> In-Reply-To: <3559497.LM0AJKV5NW@thomas> From: David Marchand Date: Fri, 1 Sep 2023 09:32:26 +0200 Message-ID: Subject: Re: [PATCH v3 0/3] Release ethdev shared memory on port cleanup To: Thomas Monjalon Cc: dev@dpdk.org, probb@iol.unh.edu, matan@nvidia.com, ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru, anatoly.burakov@intel.com, bruce.richardson@intel.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Aug 31, 2023 at 6:14=E2=80=AFPM Thomas Monjalon wrote: > > 21/08/2023 10:58, David Marchand: > > This series was triggered after investigating why the > > eal_flags_file_prefix_autotest unit test was failing in the case of > > statically built binaries [1]). > > > > For now, I went with a simple (naive) approach and put all accesses to = the > > shared data under a single lock: ethdev maintainers, it is your turn to > > shine and give me reasons why we should keep the locks the way they > > were ;-). > > I think the reasons are: > - we wanted to call rte_spinlock_init() > - we didn't want to allocate an ethdev lock in EAL memory config Hum, it is a choice of implementation, not a list of locking requirements. As to why we would not want ethdev lock in EAL, I can understand the concer= n. This could be enhanced with a new service provided by EAL to register some space in the shared configuration for use by libraries. However, seeing how the mempool and timer libraries already had one lock stored there, I assumed it was ok to do the same. > How eliminating a lock is making the last patch easier exactly? Let's say that my goal is to cleanup resources once a DPDK application exits (no hugepage files left). Here, it is a first step in that direction, with releasing ethdev shared mem data. It is not a complete solution, as other device classes probably have the same issues of leaving some shared data behind. The ethdev shared memory hosts ethdev ports, and the ownership notion. The current code implicitly relies on the assumption that the shared memory will never go away. So I had to revisit and protect places accessing this shared memory, and having one shared lock for protecting access was necessary. But doing so, the ownership lock would be nested in this global lock while doing nothing more that the ethdev shared data lock. I will enhance the patches description. --=20 David Marchand