TCP vs. UDP on SMP
Black_David@emc.com Sat, 16 September 2000 20:47 UTC
Return-Path: <owner-ips@ECE.cmu.edu>
Received: from ECE.CMU.EDU by cnoc.pdl.cs.cmu.edu id aa00073; 16 Sep 2000 16:47 EDT
Received: by ece.cmu.edu (8.9.2/8.8.8) id PAA01666 for ips-outgoing; Sat, 16 Sep 2000 15:53:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.9.2/8.8.8) with ESMTP id PAA01662 for <ips@ece.cmu.edu>; Sat, 16 Sep 2000 15:53:50 -0400 (EDT)
From: Black_David@emc.com
Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <SYT6MXP3>; Sat, 16 Sep 2000 15:53:06 -0400
Message-ID: <0F31E5C394DAD311B60C00E029101A0704C3568D@corpmx9.isus.emc.com>
To: cslee@FalconStor.com.tw, hufferd@us.ibm.com
Cc: ips@ece.cmu.edu
Subject: TCP vs. UDP on SMP
Date: Sat, 16 Sep 2000 15:53:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
> A multithread program will use different cpu in different thread. For example, we use one > cpu for receving packets to receive queue and the other CPU for sending packets from sending > queue. Hence we can have more CPU power in iSCSI path. An UDP program with its sending > and receiving can archive this situation. I think this will give a significant performance than TCP if > TCP can't use both CPUs proccesing power. > > TCP process its own queue in kernel mode. And will this TCP queue is processed with 2 CPU? The situation is somewhat more complex than this. iSCSI is REQUIRED to implement congestion control (for more information, see draft-floyd-cong-04.txt, which is about to be issued as a Best Current Practice RFC). UDP by itself does not implement congestion control, and adding this to UDP may affect SMP efficiency because congestion control solutions use information from the network (receive queue) to control transmission (send queue); this couples the receive and send processing in a way that tends to reduce SMP effectiveness. My recollection of published results on using multiple processors for TCP in Unix-like operating systems is that the big gains come from using different processors for different connections rather than handling send and receive on a single connection on different processors due in part to the send/receive coupling required by congestion control ... but it's been a while since I've checked/read this literature. So, I think the summary Q&A is approximately: Q1: Can a single TCP connection be processed by multiple CPUs? A1: Yes. Q2: Will this work as well as using separate CPUs to handle UDP send and receive? A2: Not in all cases, because TCP couples send and receive processing in a way that UDP does not. Q3: Is the UDP solution with independent send and receive processing on two CPUs applicable to iSCSI? A3: Probably not. It does not implement congestion control, and implementing congestion control will result in some coupling of send and receive processing. Let me remind everyone that while congestion control and flow control may be implemented in roughly the same area of protocol code, they are rather different functions. Flow control is concerned with the effective (e.g., reliable and high performance) delivery of individual flows of traffic. Congestion control is concerned with the response of the entire network as a system to overload conditions in which the network as a whole cannot deliver all of the offered traffic. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------
- TCP vs. UDP on SMP Black_David
- Re: TCP vs. UDP on SMP Michael Krause
- Re: TCP vs. UDP on SMP Franco Travostino
- Re: TCP vs. UDP on SMP julian_satran