[PATCH net-next-2.6] net: speedup udp receive path

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Eric Dumazet
Date: Wednesday, April 28, 2010 - 7:06 am

Le mercredi 28 avril 2010 à 08:36 -0400, jamal a écrit :

Here it is ;)

Thanks

[PATCH net-next-2.6] net: speedup udp receive path

Since commit 95766fff ([UDP]: Add memory accounting.), 
each received packet needs one extra sock_lock()/sock_release() pair.

This added latency because of possible backlog handling. Then later,
ticket spinlocks added yet another latency source in case of DDOS.

This patch introduces lock_sock_bh() and unlock_sock_bh()
synchronization primitives, avoiding one atomic operation and backlog
processing.

skb_free_datagram_locked() uses them instead of full blown
lock_sock()/release_sock(). skb is orphaned inside locked section for
proper socket memory reclaim, and finally freed outside of it.

UDP receive path now take the socket spinlock only once.

Signed-off-by: Eric DUmazet <eric.dumazet@gmail.com>
---
 include/net/sock.h  |   10 ++++++++++
 net/core/datagram.c |   10 +++++++---
 net/ipv4/udp.c      |   12 ++++++------
 net/ipv6/udp.c      |    4 ++--
 4 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index cf12b1e..d361c77 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1021,6 +1021,16 @@ extern void release_sock(struct sock *sk);
 				SINGLE_DEPTH_NESTING)
 #define bh_unlock_sock(__sk)	spin_unlock(&((__sk)->sk_lock.slock))
 
+static inline void lock_sock_bh(struct sock *sk)
+{
+	spin_lock_bh(&sk->sk_lock.slock);
+}
+
+static inline void unlock_sock_bh(struct sock *sk)
+{
+	spin_unlock_bh(&sk->sk_lock.slock);
+}
+
 extern struct sock		*sk_alloc(struct net *net, int family,
 					  gfp_t priority,
 					  struct proto *prot);
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 5574a5d..95b851f 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -229,9 +229,13 @@ EXPORT_SYMBOL(skb_free_datagram);
 
 void skb_free_datagram_locked(struct sock *sk, struct sk_buff *skb)
 {
-	lock_sock(sk);
-	skb_free_datagram(sk, skb);
-	release_sock(sk);
+	lock_sock_bh(sk);
+	skb_orphan(skb);
+	sk_mem_reclaim_partial(sk);
+	unlock_sock_bh(sk);
+
+	/* skb is now orphaned, might be freed outside of locked section */
+	consume_skb(skb);
 }
 EXPORT_SYMBOL(skb_free_datagram_locked);
 
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 63eb56b..1f86965 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1062,10 +1062,10 @@ static unsigned int first_packet_length(struct sock *sk)
 	spin_unlock_bh(&rcvq->lock);
 
 	if (!skb_queue_empty(&list_kill)) {
-		lock_sock(sk);
+		lock_sock_bh(sk);
 		__skb_queue_purge(&list_kill);
 		sk_mem_reclaim_partial(sk);
-		release_sock(sk);
+		unlock_sock_bh(sk);
 	}
 	return res;
 }
@@ -1196,10 +1196,10 @@ out:
 	return err;
 
 csum_copy_err:
-	lock_sock(sk);
+	lock_sock_bh(sk);
 	if (!skb_kill_datagram(sk, skb, flags))
 		UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
-	release_sock(sk);
+	unlock_sock_bh(sk);
 
 	if (noblock)
 		return -EAGAIN;
@@ -1624,9 +1624,9 @@ int udp_rcv(struct sk_buff *skb)
 
 void udp_destroy_sock(struct sock *sk)
 {
-	lock_sock(sk);
+	lock_sock_bh(sk);
 	udp_flush_pending_frames(sk);
-	release_sock(sk);
+	unlock_sock_bh(sk);
 }
 
 /*
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 3ead20a..91c60f0 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -424,7 +424,7 @@ out:
 	return err;
 
 csum_copy_err:
-	lock_sock(sk);
+	lock_sock_bh(sk);
 	if (!skb_kill_datagram(sk, skb, flags)) {
 		if (is_udp4)
 			UDP_INC_STATS_USER(sock_net(sk),
@@ -433,7 +433,7 @@ csum_copy_err:
 			UDP6_INC_STATS_USER(sock_net(sk),
 					UDP_MIB_INERRORS, is_udplite);
 	}
-	release_sock(sk);
+	unlock_sock_bh(sk);
 
 	if (flags & MSG_DONTWAIT)
 		return -EAGAIN;


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH net-next-2.6] bnx2x: Remove two prefetch(), Eric Dumazet, (Tue Apr 27, 3:18 pm)
Re: [PATCH net-next-2.6] bnx2x: Remove two prefetch(), David Miller, (Tue Apr 27, 3:19 pm)
Re: [PATCH net-next-2.6] bnx2x: Remove two prefetch(), Eric Dumazet, (Wed Apr 28, 5:33 am)
Re: [PATCH net-next-2.6] bnx2x: Remove two prefetch(), Eilon Greenstein, (Wed Apr 28, 6:14 am)
[PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Wed Apr 28, 7:06 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Wed Apr 28, 7:19 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Wed Apr 28, 7:34 am)
Re: [PATCH net-next-2.6] bnx2x: Remove two prefetch(), Eliezer Tamir, (Wed Apr 28, 8:44 am)
Re: [PATCH net-next-2.6] bnx2x: Remove two prefetch(), David Miller, (Wed Apr 28, 9:53 am)
Re: [PATCH net-next-2.6] bnx2x: Remove two prefetch(), David Miller, (Wed Apr 28, 9:55 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, David Miller, (Wed Apr 28, 2:36 pm)
[PATCH net-next-2.6] net: ip_queue_rcv_skb() helper, Eric Dumazet, (Wed Apr 28, 3:22 pm)
Re: [PATCH net-next-2.6] net: ip_queue_rcv_skb() helper, David Miller, (Wed Apr 28, 3:39 pm)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Wed Apr 28, 9:09 pm)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Changli Gao, (Thu Apr 29, 5:12 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Thu Apr 29, 5:45 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Thu Apr 29, 6:21 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Thu Apr 29, 6:49 am)
OFT - reserving CPU's for networking, Stephen Hemminger, (Thu Apr 29, 11:10 am)
Re: OFT - reserving CPU's for networking, Thomas Gleixner, (Thu Apr 29, 12:19 pm)
Re: OFT - reserving CPU's for networking, Eric Dumazet, (Thu Apr 29, 1:02 pm)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Changli Gao, (Thu Apr 29, 4:07 pm)
Re: OFT - reserving CPU's for networking, Brian Bloniarz, (Fri Apr 30, 11:15 am)
Re: OFT - reserving CPU's for networking, David Miller, (Fri Apr 30, 11:57 am)
Re: OFT - reserving CPU's for networking, Thomas Gleixner, (Fri Apr 30, 12:58 pm)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Fri Apr 30, 1:40 pm)
Re: OFT - reserving CPU's for networking, Andi Kleen, (Fri Apr 30, 2:01 pm)
Re: OFT - reserving CPU's for networking, David Miller, (Fri Apr 30, 3:30 pm)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Fri Apr 30, 10:57 pm)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Fri Apr 30, 11:14 pm)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Sat May 1, 3:47 am)
Re: OFT - reserving CPU's for networking, Andi Kleen, (Sat May 1, 3:53 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Sat May 1, 4:42 am)
Re: [PATCH net-next-2.6] net: speedup udp receive path, Eric Dumazet, (Sat May 1, 6:22 am)
Re: OFT - reserving CPU's for networking, Martin Josefsson, (Sat May 1, 1:31 pm)
Re: OFT - reserving CPU's for networking, David Miller, (Sat May 1, 3:03 pm)
Re: OFT - reserving CPU's for networking, David Miller, (Sat May 1, 3:13 pm)
Re: OFT - reserving CPU's for networking, Andi Kleen, (Sat May 1, 3:58 pm)
Re: OFT - reserving CPU's for networking, David Miller, (Sat May 1, 4:29 pm)
Re: OFT - reserving CPU's for networking, Ben Hutchings, (Sat May 1, 4:44 pm)