linux-kernel - Re: [PATCH net-next 0/3] net: Switch tag HW extraction/insertion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/