From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 10 May 2002 14:44:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 10 May 2002 14:44:46 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:374 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id ; Fri, 10 May 2002 14:44:45 -0400 To: Jeff Garzik Cc: "Pedro M. Rodrigues" , chen_xiangping@emc.com, "David S. Miller" , linux-kernel@vger.kernel.org Subject: Re: Tcp/ip offload card driver In-Reply-To: <3CDBFF5B.32550.1364FB2@localhost> <3CDBE7EB.9060605@mandrakesoft.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: 10 May 2002 12:36:06 -0600 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jeff Garzik writes: > Pedro M. Rodrigues wrote: > > > Actually there is. Think iSCSI. Have a look at this article at LinuxJournal > > - http://linuxjournal.com/article.php?sid=4896 . > > > > Ug... why bother? Just buy an SMP system at that point... Or equally fix the kernel driver to do interrupt mitigation. From the article that looks like all they have managed to achieve. There may be a valid argument buried in there for remote DMA as well. But given in the low contention case the kernel with it's own network drivers was twice as fast. tcp/ip offload looks to have some serious weaknesses even for iSCSI. The embedded processor kept better performance going for just a little while but then it's performance crashed as well. Plus there is the general rule. The primary CPU, it's memory, and it's I/O subsystem improve out of necessity, while IO processors stagnate, because they can. The only exception to this I have seen are graphics coprocessors. Eric