[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150731.152409.2044548175661477590.davem@davemloft.net>
Date: Fri, 31 Jul 2015 15:24:09 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: florian@...hacore.org
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
vivien.didelot@...oirfairelinux.com,
jerome.oufella@...oirfairelinux.com, linux@...ck-us.net,
andrew@...n.ch, cphealy@...il.com, mathieu@...eaurora.org,
jonasj76@...il.com, andrey.volkov@...vision.fr,
Chris.Packham@...iedtelesis.co.nz
Subject: Re: [PATCH net-next 0/3] net: Switch tag HW extraction/insertion
From: Florian Fainelli <florian@...hacore.org>
Date: Thu, 30 Jul 2015 18:51:57 -0700
> On 30/07/15 15:51, David Miller wrote:
>> From: David Miller <davem@...emloft.net>
>> 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.
You really need to find a way to make it fit in it's current size
on 64-bit.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists