From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v9 1/8] ethdev: use locks to protect Rx/Tx
	callback lists
Date: Wed, 15 Jun 2016 10:19:07 +0200
Message-ID: <10886152.VH5xYhdqG2@xps13>
References: <1465575534-23605-1-git-send-email-reshma.pattan@intel.com>
 <12886124.K2biJ8F8kE@xps13>
 <3AEA2BF9852C6F48A459DA490692831F0104E1EE@IRSMSX109.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Pattan, Reshma" <reshma.pattan@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
 by dpdk.org (Postfix) with ESMTP id BADD4C31C
 for <dev@dpdk.org>; Wed, 15 Jun 2016 10:19:09 +0200 (CEST)
Received: by mail-wm0-f43.google.com with SMTP id m124so23912829wme.1
 for <dev@dpdk.org>; Wed, 15 Jun 2016 01:19:09 -0700 (PDT)
In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F0104E1EE@IRSMSX109.ger.corp.intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-06-15 05:30, Pattan, Reshma:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-06-14 10:38, Reshma Pattan:
> > > Added spinlocks around add/remove logic of Rx and Tx callbacks to
> > > avoid corruption of callback lists in multithreaded context.
> > >
> > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > 
> > Why cb->next is not locked in burst functions?
> It is safe to do "read access" here and doesn't require any locking as rx/tx burst is initiated  by only local user(control plane) thread.
> 
> > Just protecting add/remove but not its usage seems useless.
> Here locks were required  around add/remove to protect "write access"  because write to callback list is now done from 2 threads 
> i.e. one from local user thread(control plane) and another from pdump control thread(initiated by remote pdump request). 

So read and write can be done by different threads.
I think the read access would need locking but we do not want it
in fast path.
Are you sure there is no issue in this design?