From: Eric Dumazet <eric.dumazet@gmail.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
Linux Netdev List <netdev@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>,
Christoph Lameter <cl@linux-foundation.org>
Subject: Re: [PATCH] net: Fix struct sock bitfield annotation
Date: Fri, 09 Oct 2009 03:46:09 +0200 [thread overview]
Message-ID: <4ACE95E1.30301@gmail.com> (raw)
In-Reply-To: <4ACE8CEC.3020905@gmail.com>
Eric Dumazet a écrit :
>
> I am currently writing a tool to re-organize 'struct sock' fields,
> for net-next-2.6 using offsetof() macro, this is how I spot the problem.
>
For networking guys, here is the actual mess with "struct sock" on x86_64,
related to UDP handling (critical latencies for some people). We basically touch
all cache lines, in every paths, bad effects on SMP...
- rx softirq reception
- rx recvmsg() time
- tx sendto() time
- tx completion time
sizeof(struct sk_buff) =232 (0x e8)
sizeof(struct sock) =528 (0x210)
sizeof(struct inet_sock)=680 (0x2a8)
Following offsets in hexadecimal
offsetof(struct sock, sk_refcnt) = 10 (rw by reception of udp frame, __udp4_lib_lookup())
(unavoidable hot spot unfortunatly, but not anymore touched by sock_wfree())
offsetof(struct sock, sk_hash) = 14 (read rx softirq )
offsetof(struct sock, sk_family) = 18 (read " "
offsetof(struct inet_sock, daddr) =210 (read " "
offsetof(struct inet_sock, rcv_saddr) =214 (read " "
offsetof(struct inet_sock, dport) =218 (read " "
offsetof(struct inet_sock, mc_list) =240 (read " multicast reception
offsetof(struct sock, sk_bound_dev_if) = 1c (read rx softirq)
(First patch I'll submit is move daddr/rcv_saddr/dport to struct sock_common,
so that lookup() use one cache line instead of two per socket in hash chain)
offsetof(struct sock, sk_prot) = 30 (read by sk_has_account())
offsetof(struct sock, sk_rcvbuf) = 3c (read)
offsetof(struct sock, sk_protocol) = 39
offsetof(struct sock, sk_allocation) = e0 (read at send() time)
offsetof(struct sock, sk_flags) = f8 (read)
offsetof(struct sock, sk_lock) = 40 (rw by udp_sendmsg())
offsetof(struct sock, sk_dst_lock) = 90 (rw by udp_sendmsg() on connected socks)
offsetof(struct sock, sk_dst_cache) = 78 (read by udp_sendmsg() on connected socks)
offsetof(struct sock, sk_mark) =1d8 (read at sendto() time)
offsetof(struct sock, sk_write_queue) = c0 (rw by sendto())
offsetof(struct inet_sock, id) =232 (rw by sendto() on connected socks)
offsetof(struct sock, sk_wmem_alloc) = 98 (RW, both at sendto() and tx completion handler time)
offsetof(struct sock, sk_sndbuf) = a0 (read at tx completion time and sendto())
offsetof(struct sock, sk_sndmsg_page) =1b8 (rw by send())
offsetof(struct sock, sk_send_head) =1c0 (rw by send(), tcp)
offsetof(struct sock, sk_rmem_alloc) = 94 (RW, both when frame is received by softirq and dequeued at recvmsg() time)
offsetof(struct sock, sk_receive_queue)= a8 (RW, both when frame is received by softirq and dequeued at recvmsg() time)
offsetof(struct sock, sk_forward_alloc)= dc (rw rx softirq and recvmsg() time)
offsetof(struct sock, sk_drops) =134 (read when udp frame is received in softirq handler)
offsetof(struct sock, sk_stamp) =1a0 (write at recvmsg() time)
offsetof(struct sock, sk_sleep) = 70 (read by softirq handlers (rx/tx))
offsetof(struct sock, sk_filter) =160 (read when udp frame is received in softirq handler)
offsetof(struct sock, sk_socket) =1a8 (read)
offsetof(struct sock, sk_callback_lock)=128 (rw at softirq time
offsetof(struct sock, sk_data_ready) =1e8 (read)
offsetof(struct sock, sk_write_space) =1f0 (read at TX completion time)
used by TCP
offsetof(struct sock, sk_timer) =170
offsetof(struct sock, sk_ack_backlog) =138 (listen socks)
Almost never used
offsetof(struct sock, sk_lingertime) =100
offsetof(struct sock, sk_write_pending)=1cc
offsetof(struct sock, sk_prot_creator )=120
next prev parent reply other threads:[~2009-10-09 1:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-08 15:16 [PATCH] net: Fix struct sock bitfield annotation Eric Dumazet
2009-10-08 21:31 ` David Miller
2009-10-08 21:54 ` Vegard Nossum
2009-10-08 22:08 ` David Miller
2009-10-09 1:07 ` Eric Dumazet
2009-10-09 1:46 ` Eric Dumazet [this message]
2009-10-09 19:39 ` Christoph Lameter
2009-10-09 20:41 ` Eric Dumazet
2009-10-13 21:59 ` [RFC net-next-2.6] udp: Dont use lock_sock()/release_sock() in rx path Eric Dumazet
2009-10-09 7:54 ` [PATCH] net: Fix struct sock bitfield annotation David Miller
2009-10-09 8:50 ` Eric Dumazet
2009-10-12 6:07 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ACE95E1.30301@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=cl@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.