netdev - Re: [PATCH net-next] tcp: change tcp_skb

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 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:	Sun, 28 Sep 2014 16:37:07 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org, ncardwell@...gle.com, ycheng@...gle.com,
	willemb@...gle.com
Subject: Re: [PATCH net-next] tcp: change tcp_skb_pcount() location

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Wed, 24 Sep 2014 04:11:22 -0700

> From: Eric Dumazet <edumazet@...gle.com>
> 
> Our goal is to access no more than one cache line access per skb in
> a write or receive queue when doing the various walks.
> 
> After recent TCP_SKB_CB() reorganizations, it is almost done.
> 
> Last part is tcp_skb_pcount() which currently uses
> skb_shinfo(skb)->gso_segs, which is a terrible choice, because it needs
> 3 cache lines in current kernel (skb->head, skb->end, and
> shinfo->gso_segs are all in 3 different cache lines, far from skb->cb)
> 
> This very simple patch reuses space currently taken by tcp_tw_isn
> only in input path, as tcp_skb_pcount is only needed for skb stored in
> write queue.
> 
> This considerably speeds up tcp_ack(), granted we avoid shinfo->tx_flags
> to get SKBTX_ACK_TSTAMP, which seems possible.
> 
> This also speeds up all sack processing in general.
> 
> This speeds up tcp_sendmsg() because it no longer has to access/dirty
> shinfo.
> 
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> ---
> Note : This patch applies cleanly after "tcp: better TCP_SKB_CB layout"
> patch serie.

Also applied, thanks Eric.
--
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