From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 22 11:13:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91EFE1065705 for ; Mon, 22 Jun 2009 11:13:03 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::2]) by mx1.freebsd.org (Postfix) with ESMTP id ECCBB8FC25 for ; Mon, 22 Jun 2009 11:13:01 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [IPv6:::1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n5MBCBGT029043; Mon, 22 Jun 2009 13:12:11 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n5MBC9bW029034; Mon, 22 Jun 2009 13:12:10 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 22 Jun 2009 13:12:08 +0200 (CEST) From: Wojciech Puchar To: Pyun YongHyeon In-Reply-To: <20090622001705.GA10712@michelle.cdnetworks.co.kr> Message-ID: References: <20090622001705.GA10712@michelle.cdnetworks.co.kr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: is RTL8139 THAT bad? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 11:13:09 -0000 >> >> Why it's THAT bad? >> > > Because CPU always have to copy frames to/from the controller. comment says card do DMA. just then it has to copy but within main memory not PCI. > These CPU cycles could have been used in other task to give more > performance such as SSH encryption/decryption, checksum computation > etc. > >> 3.5MB/s is less that 2500 packets/second. 50% at 200Mhz means 100000000 >> cycles spend on interrupt service, which is 40000 CPU cycles per packet. >> > > That depends on your application. It would be ok for normal desktop > PCs with fast CPU but it wouldn't be acceptable on servers that > have to do lots of other processing. If you have fxp(4) or txp(4) i know all this, but i'm asking why processing single interrupt takes 40000 CPU cycles.