From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751096AbWDVTv6 (ORCPT ); Sat, 22 Apr 2006 15:51:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751099AbWDVTv6 (ORCPT ); Sat, 22 Apr 2006 15:51:58 -0400 Received: from zeus1.kernel.org ([204.152.191.4]:58051 "EHLO zeus1.kernel.org") by vger.kernel.org with ESMTP id S1751096AbWDVTv5 convert rfc822-to-8bit (ORCPT ); Sat, 22 Apr 2006 15:51:57 -0400 From: Ingo Oeser To: =?iso-8859-1?q?J=F6rn_Engel?= Subject: Re: Van Jacobson's net channels and real-time Date: Sat, 22 Apr 2006 15:29:58 +0200 User-Agent: KMail/1.9.1 Cc: Ingo Oeser , "David S. Miller" , simlo@phys.au.dk, linux-kernel@vger.kernel.org, mingo@elte.hu, netdev@vger.kernel.org References: <200604211852.47335.netdev@axxeo.de> <20060422114846.GA6629@wohnheim.fh-wedel.de> In-Reply-To: <20060422114846.GA6629@wohnheim.fh-wedel.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200604221529.59899.ioe-lkml@rameria.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Jörn, On Saturday, 22. April 2006 13:48, Jörn Engel wrote: > Unless I completely misunderstand something, one of the main points of > the netchannels if to have *zero* fields written to by both producer > and consumer. Hmm, for me the main point was to keep the complete processing of a single packet within one CPU/Core where this is a non-issue. > Receiving and sending a lot can be expected to be the > common case, so taking a performance hit in this case is hardly a good > idea. There is no hit. If you receive/send in bursts you can simply aggregate them until a certain queueing threshold. The queue design outlined can split the queueing in reserve and commit stages, where the producer can be told how much in can produce and the consumer is told how much it can consume. Within their areas the producer and consumer can freely move around. So this is not exactly a queue, but a dynamic double buffer :-) So maybe doing queueing with the classic head/tail variant is better here, but the other variant might replace it without problems and allows for some nice improvements. Regards Ingo Oeser