From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751286AbbGaCCP (ORCPT ); Thu, 30 Jul 2015 22:02:15 -0400 Received: from alphacore.org ([94.143.118.29]:47818 "EHLO mail.alphacore.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750957AbbGaCCN (ORCPT ); Thu, 30 Jul 2015 22:02:13 -0400 X-Greylist: delayed 604 seconds by postgrey-1.27 at vger.kernel.org; Thu, 30 Jul 2015 22:02:13 EDT Message-ID: <55BAD4BD.20405@alphacore.org> Date: Thu, 30 Jul 2015 18:51:57 -0700 From: Florian Fainelli User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: David Miller CC: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, vivien.didelot@savoirfairelinux.com, jerome.oufella@savoirfairelinux.com, linux@roeck-us.net, andrew@lunn.ch, cphealy@gmail.com, mathieu@codeaurora.org, jonasj76@gmail.com, andrey.volkov@nexvision.fr, Chris.Packham@alliedtelesis.co.nz Subject: Re: [PATCH net-next 0/3] net: Switch tag HW extraction/insertion References: <1438209160-6898-1-git-send-email-f.fainelli@gmail.com> <20150730.141935.723435302404122784.davem@davemloft.net> <20150730.155124.2216613161860898066.davem@davemloft.net> In-Reply-To: <20150730.155124.2216613161860898066.davem@davemloft.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/07/15 15:51, David Miller wrote: > From: David Miller > Date: Thu, 30 Jul 2015 14:19:35 -0700 (PDT) > >> This looks fine, series applied, thanks. > > I think your control block is too large, you'll need to rework this > somehow. So napi_gro_cb really is 48 bytes on 64-bits architectures (had not realized it was so big). What would you recommend to do here considering that this driver is currently used on 32-bits platforms, but I see no reason why someone would no want to use this feature on a 64-bit platform, yet we are competing with napi_gro_cb, and adding a new skbuff member is pretty much a no-no? Would it be acceptable to have a new member which is ifdef CONFIG_NET_DSA_TAG_BRCM? FWIW, this does provide a small 2-3% throughput increase for RX. > > In function ‘dsa_copy_brcm_tag’, > inlined from ‘bcm_sysport_desc_rx’ at drivers/net/ethernet/broadcom/bcmsysport.c:707:4, > inlined from ‘bcm_sysport_poll’ at drivers/net/ethernet/broadcom/bcmsysport.c:864:12: > include/linux/compiler.h:447:38: error: call to ‘__compiletime_assert_2016’ declared with attribute error: BUILD_BUG_ON failed: sizeof(skb->cb) - sizeof(struct napi_gro_cb) < BRCM_TAG_LEN > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^ > include/linux/compiler.h:430:4: note: in definition of macro ‘__compiletime_assert’ > prefix ## suffix(); \ > ^ > include/linux/compiler.h:447:2: note: in expansion of macro ‘_compiletime_assert’ > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^ > include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’ > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^ > include/linux/bug.h:74:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) > ^ > include/linux/netdevice.h:2016:2: note: in expansion of macro ‘BUILD_BUG_ON’ > BUILD_BUG_ON(sizeof(skb->cb) - sizeof(struct napi_gro_cb) < BRCM_TAG_LEN); > ^ > scripts/Makefile.build:264: recipe for target 'drivers/net/ethernet/broadcom/bcmsysport.o' failed > -- Florian