From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41])
 by dpdk.org (Postfix) with ESMTP id 599FEADEC
 for <dev@dpdk.org>; Wed, 15 Jun 2016 10:48:54 +0200 (CEST)
Received: by mail-wm0-f41.google.com with SMTP id v199so153155890wmv.0
 for <dev@dpdk.org>; Wed, 15 Jun 2016 01:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind-com.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:subject:date:message-id:user-agent:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=sKlIYj2/9fQQ37UcgQ14T5TQzP8KSfOhtubN9JD/rNM=;
 b=hhRPntHVQKUV8kNro/XT/fWLcYPHpLcV1xpEVNFfvf7GdftoidRk9fFT1eBLkYLZw3
 wVo7QT59z+DITUfm8GofS+jbnkuNHVN7JtWk/oiILzilfWs1EaXbtHn2ZW2098bZ/Vej
 zzigxPu8mGyPNpwQ/FHIXO0H0wSjcJQ/Ce58CWuRwrSzjgVsyITTLzBmrAwAqS35DNrJ
 tU6aiD1kuRzmWO8bihQqGonQr3nPwjaXHtFVminKrvI4gRX7DQBw/n7vJvIBNrNb0P+3
 KJbOWzcEvaw/UYSXOmmaw32N00nLUSdvxzDGKwrOw6bG2mmAtGbe1RbfEMmmcn4dbU5O
 jjsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=sKlIYj2/9fQQ37UcgQ14T5TQzP8KSfOhtubN9JD/rNM=;
 b=C6Y0Z2L1/lh1CmbrgCXLRwxz4G6Uk28SSOfw4XfjO616OIFiCn7gPpZxCKrlpEnC08
 Aj6p9eFqkDLV7pU8WNILPnh3pQEkJbYT3zG6mhcpqMclsPJhd889+mm+OjyV4KrrTjCZ
 j4brbXdU+a/uaQ5XOln7T5yMKlidhHaZQ6GFgvD8thnQBZaqLfS6QyslSh1BFy4pCh53
 ouoh2DKKsukm5WaxWPK/Mv1wOXaNn+fHWVHBl5H9K5nkYwEzyxZmsDpce2neKLvPiLDB
 B2nkE8/R16XWrjUSrSu/JWP+eoAngCQTQvcPCaQU/efq+Q9lpRYAFXDzVlIbLD9DA5mu
 Nw9A==
X-Gm-Message-State: ALyK8tLGoVmn3eHLO5461XFV+t8SOCjUJ7PSZVmug20hug6WTuxhZdWT9krFf/VWDt6yQV8r
X-Received: by 10.194.54.198 with SMTP id l6mr9785835wjp.67.1465980534149;
 Wed, 15 Jun 2016 01:48:54 -0700 (PDT)
Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184])
 by smtp.gmail.com with ESMTPSA id z5sm2524332wme.5.2016.06.15.01.48.52
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 15 Jun 2016 01:48:53 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "Pattan, Reshma" <reshma.pattan@intel.com>, dev@dpdk.org
Date: Wed, 15 Jun 2016 10:48:52 +0200
Message-ID: <2907169.iIEIeOfXh7@xps13>
User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <2601191342CEEE43887BDE71AB97725836B714ED@irsmsx105.ger.corp.intel.com>
References: <1465575534-23605-1-git-send-email-reshma.pattan@intel.com>
 <10886152.VH5xYhdqG2@xps13>
 <2601191342CEEE43887BDE71AB97725836B714ED@irsmsx105.ger.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v9 1/8] ethdev: use locks to protect Rx/Tx
	callback lists
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Wed, 15 Jun 2016 08:48:54 -0000

2016-06-15 08:37, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 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.
> 
> Yes, and this is possible even in current DPDK version (16.04).
> What is added by Reshma's patch - now it is possible to have concurrent write
> from 2 different thread to that list.  
> 
> > I think the read access would need locking but we do not want it
> > in fast path.
> 
> I don't think it would be needed.
> As I said - read/write interaction didn't change from what we have right now.
> But if you have some particular scenario in mind that you believe would cause
> a race condition - please speak up.  

If we add/remove a callback during a burst? Is it possible that the next
pointer would have a wrong value leading to a crash?
Maybe we need a comment to state that we should not alter burst
callbacks while running burst functions.