[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1438322920.20182.144.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Fri, 31 Jul 2015 08:08:40 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Florian Fainelli <florian@...hacore.org>
Cc: David Miller <davem@...emloft.net>, 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
On Thu, 2015-07-30 at 18:51 -0700, Florian Fainelli wrote:
> 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.
Which layer will read this tag after GRO processing ?
It seems you simply can use skb->cb[] like other layers : At offset 0.
BTW brcm_tag_rcv() does not even use GRO, as it calls
netif_receive_skb()
--
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