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 7DE65A04B1; Tue, 8 Sep 2020 18:03:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 042C74C99; Tue, 8 Sep 2020 18:02:59 +0200 (CEST) Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by dpdk.org (Postfix) with ESMTP id BDB35A3 for ; Tue, 8 Sep 2020 18:02:58 +0200 (CEST) Received: by mail-pg1-f174.google.com with SMTP id w186so10335797pgb.8 for ; Tue, 08 Sep 2020 09:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=yFxGgW7gh099VPyHjiinJe17vozdi2EUPprWVcNf8SA=; b=PPIl7/3TLvjwZ4HkH/uzoowV3uAuvhAVj/BXZGEI/6C4FFJxZTjOrJUzif+LbJ6ME8 3Za8/msoxFhmelYlilAjADJkhnzUWgiBxZcOr3N8VxDEhRfYCpb0tH4pmgMxD1WQpp9B ccY5DwG4az19l8W9QGD1ZyhS0PMseEJUl44VneFH7Nh+pc/dtQdMqsGZESxZhBoNS598 lB9Pjp1j/sUih4Xj+bzdAlr4YMmXvlW8usYq0MYe2UEX9cxLYw6ylvzBqLxuKTajAe5O 5XNw54TvK0GXMR4//4PTgeV8wmHbwENGsl45SvMZn7X4hmf8C1Mn6XtU/qW2ZHuNev+K 0o3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=yFxGgW7gh099VPyHjiinJe17vozdi2EUPprWVcNf8SA=; b=YWHaA3fxWRtiDYPepEWeqFFlCbNMB1KWtGsaCrAtJsx0LM1NEiarKHwWbfhDKOC7GC 5BpqdTxXa2iwaq8qRyQj3/pEkanybAolZG0ez6O0FbFzeGfkHwXl86tjA4B7VssOsumS bymfY15VjIneEX/PY+zSE1QrkZzrSBhSSqJ8D0/SYKo/z4MUjJt+eusGmldK5Kebc3YS 2jhVw7R8jzul9azshgmFsdHBGb/oyerYw8IWjTi2OOKlW/+/DLDbD/pXI22amwM9mQ3Z oJ1eqLIIfh1rmdB+NLAqWME98orLRgBR0K4nz1rQHXSOgPgQ9Njf+tzKVbM/Y25hl3dx jRJw== X-Gm-Message-State: AOAM531OYDGJ4JwXTZtPJvX0Vv9v41SzRpMX7cA6LyNgPJZMMTCTHi+P QkjWDb95GnU8+Zh4avgk29hTSw== X-Google-Smtp-Source: ABdhPJyfbnmCpPIcSlsl4uSGPE9F454Tam3g9m5uDoVlFATkOytzbsB1PxDETxI/09yTkI3+WnPTcg== X-Received: by 2002:aa7:998a:: with SMTP id k10mr7020577pfh.151.1599580977618; Tue, 08 Sep 2020 09:02:57 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id gm17sm10210502pjb.46.2020.09.08.09.02.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 09:02:57 -0700 (PDT) Date: Tue, 8 Sep 2020 09:02:48 -0700 From: Stephen Hemminger To: Thomas Monjalon Cc: Suanming Mou , Ori Kam , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , joyce.kong@arm.com, phil.yang@arm.com, steve.capper@arm.com, honnappa.nagarahalli@arm.com Message-ID: <20200908090248.7a78888a@hermes.lan> In-Reply-To: <3402903.UWDKPdykxe@thomas> References: <1599108782-230624-1-git-send-email-suanmingm@nvidia.com> <20200908075208.048bfa02@hermes.lan> <3402903.UWDKPdykxe@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] ethdev: make rte flow API thread safe 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 Tue, 08 Sep 2020 17:03:53 +0200 Thomas Monjalon wrote: > 08/09/2020 16:52, Stephen Hemminger: > > On Mon, 7 Sep 2020 02:36:48 +0000 > > Suanming Mou wrote: > > > > What is the performance impact of this for currently working applications that > > > > use a single thread to program flow rules. You are adding a couple of system > > > > calls to what was formerly a totally usermode operation. > > > > Read the source for glibc and see what pthread_mutex does > > What would be the best lock for rte_flow? > We have spin lock, ticket lock, MCS lock (and rwlock) in DPDK. The tradeoff is between speed, correctness, and simplicity. The flow case is performance sensitive (for connection per second tests); but not super critical (ie every packet). Fastest would be RCU but probably not necessary here. There would rarely be contention on this (thread safety is new), and there is no case where reader makes sense. For hardware, programming flow rules would basic interaction with TCAM (ie fast). For software drivers, typically making flow rule requires system call to set classifier etc. Holding spin lock across system calls leads to preemption and other issues. Would it be possible to push the choice of mutual exclusion down to the device driver? For fast HW devices they could use spinlock and for slow SW devices it would be pthread.