From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Subject: Re: networking checksum errors again Date: Sat, 1 Apr 2006 17:55:23 -0600 (CST) Message-ID: References: <20060331074641.E26981@web.ray.net> <20060331083153.F26981@web.ray.net> <442EF421.2080708@comcast.net> Reply-To: Jason Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Return-path: In-Reply-To: <442EF421.2080708@comcast.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Nivedita Singhvi Cc: Florian Kirstein , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org If I understand correctly, the offloading to a physical NIC only works when a physical NIC is present and being used for that traffic. In a purely virtual route setup, that traffic should be subject to this checksum issue. Is this just a recent development or is routing a fairly uncommon configuration in comparison to bridging with xen? -- Jason The place where you made your stand never mattered, only that you were there... and still on your feet On Sat, 1 Apr 2006, Nivedita Singhvi wrote: > Jason wrote: >> w00t! That fixed it. I read your email on the logic for not doing the tcp >> checksums and, while I >> am by no means in possesion of the brains the developers have, I am left >> wondering why that >> decision was made. Would anyone care to comment? >> > I think I missed a post somewhere along this thread... > > Which decision are you referring to? Avoiding the > TCP checksum between domains? The rationale for not > doing the checksum is that it is a significant savings > in performance. Even for traffic that goes out to > a public net and must contain a checksum, deferring > it to dom0 when the OS can offload it to the physical > NIC (most NICs these days are capable of computing the > checksums in hardware) is a significant saving. > > The native Linux stack offloads the calculation of > the checksum to the NIC, and not doing so in the virtual > environment increases the gap when comparing Xen to > bare metal Linux. > > There are a lot of other issues here to resolve, of > course, and fixing some of the current issues is being > worked. It's likely going to be an issue for discussion > when we're up for mainline inclusion. > > thanks, > Nivedita > >