On Thu, 2015-07-30 at 18:51 -0700, Florian Fainelli wrote: > On 30/07/15 15:51, David Miller wrote: > > From: David Miller <da...@davemloft.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
