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 9797AA04FF; Thu, 24 Mar 2022 06:06:17 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 709C641151; Thu, 24 Mar 2022 06:06:17 +0100 (CET) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id A0A01410FC for ; Thu, 24 Mar 2022 06:06:15 +0100 (CET) Received: by mail-pl1-f172.google.com with SMTP id q5so3610875plg.3 for ; Wed, 23 Mar 2022 22:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=cAasDhaE3DTXUDqJ//UZ7y7B4NqaFLE6VnwpaGyNglE=; b=Qr1mkwZ6j07WDgkT2GHKZKCKFwi0yvM0ZdKMHuLhKsmQIUucLC+d62J4YXF4m5uUVD Btpm6HBw0U8hCgsM/1imXE/S6OEJu6qOgdZuNTnFD52UUVl3OL3uipTt7EZrP+qgHVod 5OXor12OWNrEFaSZvBNj1ilbISuQU5oiK5sSjNTg9C4vkglI+24JD0GoB3rK+EhkuaBJ oSGxlI/LZuSJYY+AljhBj+P6lzNnjoG3lya6Hz6gp8+W7eJGJMX/gcF3TYtfizTl9ZzB f5ZmrOtVYOrldWl4RAkWADkVvNio6yZtzI8htTy1REgA1fSIEoL3aE/NZbI2Br2erVhX lK8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=cAasDhaE3DTXUDqJ//UZ7y7B4NqaFLE6VnwpaGyNglE=; b=2fREx5g/vjq9gjMHbwpgfTHMcwxJMxS772x/8cApaPc9PoDTLc8PMFY9UcqH+JV3NN +kspdYTYFCHuqBVnd1MvIILxobfa/FM1nvn14wCja0IYfPJJQsjBRJHFrDEcA1P8XwUc GhjDGgFjBAjR4K360OR3xU1DqLUO8ONScfvNI+FhpMoJcmsD5ZkruBox693mTi6uJV1E 6hxVhrOWRQJ1beqaFu0w/9tQ08tsN85vJY5w9e2f73oivWGXC2v0SSf8uqo5eJiAxgZk agoasr7rBd442YADb2PMzienq0ke51TsZ5ol/KagBKA0ISUOhXxaEAB2aODzUF3nh/NN UjMQ== X-Gm-Message-State: AOAM530ED08D49TmDIQ03oVz6uhOaJb2k1v8Gauhknh1iuW0edHoLtQm ug5dNdCe/QK/A0/amlpDyfaF3w== X-Google-Smtp-Source: ABdhPJwkMsQJOm+bH0rr0rfud8N7qTpsUsH/joyGNayYelKIjpmuigJ+ST607vOyeD8j7RwgHMi+8A== X-Received: by 2002:a17:90b:1a81:b0:1bc:ec26:40a6 with SMTP id ng1-20020a17090b1a8100b001bcec2640a6mr4048287pjb.0.1648098374708; Wed, 23 Mar 2022 22:06:14 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id g6-20020a056a001a0600b004f7bd56cc08sm1499274pfv.123.2022.03.23.22.06.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 22:06:14 -0700 (PDT) Date: Wed, 23 Mar 2022 22:06:11 -0700 From: Stephen Hemminger To: Honnappa Nagarahalli Cc: "Ananyev, Konstantin" , "mattias.ronnblom" , "dev@dpdk.org" , nd Subject: Re: DPDK seqlock Message-ID: <20220323220611.2f967a50@hermes.local> In-Reply-To: References: <1c140536-c79a-d7c3-604b-984f05ad2bf8@ericsson.com> 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, 24 Mar 2022 04:52:07 +0000 Honnappa Nagarahalli wrote: > > > > > > Hi Mattias, > > > > > > > > Would it make sense to have a seqlock implementation in DPDK? > I do not have any issues with adding the seqlock to DPDK. > > However, I am interested in understanding the use case. As I understand, seqlock is a type of reader-writer lock. This means that it is possible that readers (data plane) may be blocked till the writer completes the updates. Does not this mean, data plane might drop packets while the writer is updating entries? > > > > > > > I think so, since it's a very useful synchronization primitive in data > > > plane applications. > > > > > > > Agree, it might be useful. > > As I remember rte_hash '_lf' functions do use something similar to seqlock, but > > in hand-made manner. > > Probably some other entities within DPDK itself or related projects will benefit > > from it too... > > > > Konstantin As inventor of seqlock, it is really just a kind of reader/writer spinlock where spinning trys to do useful work. It useful for cases where the data being accessed is too large for __atomic primitives.