From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754411AbcKIRSr (ORCPT ); Wed, 9 Nov 2016 12:18:47 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:36976 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752065AbcKIRSq (ORCPT ); Wed, 9 Nov 2016 12:18:46 -0500 Date: Wed, 09 Nov 2016 12:18:44 -0500 (EST) Message-Id: <20161109.121844.1246735222647356131.davem@davemloft.net> To: madalin.bucur@nxp.com Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, oss@buserror.net, ppc@mindchasers.com, joe@perches.com, pebolle@tiscali.nl, joakim.tjernlund@transmode.se Subject: Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet From: David Miller In-Reply-To: References: <1478117854-8952-3-git-send-email-madalin.bucur@nxp.com> <20161103.155816.642712588084106823.davem@davemloft.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 09 Nov 2016 08:19:14 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Madalin-Cristian Bucur Date: Wed, 9 Nov 2016 17:16:12 +0000 >> From: Madalin-Cristian Bucur >> Sent: Monday, November 07, 2016 5:43 PM >> >> > From: David Miller [mailto:davem@davemloft.net] >> > Sent: Thursday, November 03, 2016 9:58 PM >> > >> > From: Madalin Bucur >> > Date: Wed, 2 Nov 2016 22:17:26 +0200 >> > >> > > This introduces the Freescale Data Path Acceleration Architecture > > >> > > + int numstats = sizeof(struct rtnl_link_stats64) / sizeof(u64); >> > ... >> > > + cpustats = (u64 *)&percpu_priv->stats; >> > > + >> > > + for (j = 0; j < numstats; j++) >> > > + netstats[j] += cpustats[j]; >> > >> > This is a memcpy() on well-typed datastructures which requires no >> > casting or special handling whatsoever, so use memcpy instead of >> > needlessly open coding the operation. >> >> Will fix. > > Took a second look at this, it's not copying but adding the percpu > statistics into consolidated results. Ok, then it looks fine, thanks for clarifying.