From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nivedita Singhvi Subject: Re: [PATCH] Network Checksum Removal Date: Wed, 25 May 2005 11:19:52 -0700 Message-ID: <4294C1C8.5050700@us.ibm.com> References: <200505251213.08192.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200505251213.08192.jdmason@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jon Mason Cc: Ian Pratt , Andrew Theurer , xen-devel@lists.xensource.com, bin.ren@cl.cam.ac.uk List-Id: xen-devel@lists.xenproject.org Jon Mason wrote: >>I'm surprised there's much benefit to csum offload on the tx side at all >>as its almost always done as part of a copy. > > > Why? The tx checksumming is just as expensive as the rx checksumming. Normally (i.e. non sendfile() case), on the transmit side, you have to copy the data from user space to kernel space, and usually, during this step, you perform the checksum operation for a few extra instructions - you have to take the hit of pulling in each byte of data in any case. So checksum offload on the transmit path _normally_ buys you no throughput gain, and very slight reduction in CPU utilization. Of course, for every segment sent out (or bunches thereof), we get an ack back. But checksumming a TCP header (pure ack case) is again, fairly trivial (20 bytes). thanks, Nivedita