netdev - Re: [Xen-devel] [PATCH net v5] xen-netback: fix fragment detection in checksum setup

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] [day] [month] [year] [list]

Date:	Wed, 11 Dec 2013 09:47:50 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Paul Durrant <Paul.Durrant@...rix.com>,
	Jan Beulich <JBeulich@...e.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Wei Liu <wei.liu2@...rix.com>,
	Zoltan Kiss <zoltan.kiss@...rix.com>,
	David Miller <davem@...emloft.net>,
	xen-devel <xen-devel@...ts.xenproject.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH net v5] xen-netback: fix fragment detection
 in checksum setup

On Tue, 2013-12-10 at 09:12 -0800, Eric Dumazet wrote:
> On Tue, 2013-12-10 at 16:24 +0000, Paul Durrant wrote:
> 
> > Yes, I guess that's true but if we decide to pull up at all then is it harmful to pull more than we absolutely need?
> 
> Pulling too many bytes might hurt aggregation.
> 
> When one skb is merged to another one (skb_try_coalesce()), if you have
> payload in skb->head, we cannot free the head, and need one additional
> 'frag'

Does that ever happen to skb's which are received by a NIC and passed up
to the network stack (including forwarding by bridging of netfilter)? I
thought this path only happened for locally generated traffic.

If it can happen for received skb's then that seems like a pretty solid
reason not to over estimate in the pull up phase.

Ian.

--
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