From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Wed, 15 Jun 2016 10:48:54 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id v199so153155890wmv.0 for ; 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 To: "Ananyev, Konstantin" Cc: "Pattan, Reshma" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > > > > > > > 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.