From owner-freebsd-current@FreeBSD.ORG  Wed May  5 16:38:45 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8D6B116A4CE; Wed,  5 May 2004 16:38:45 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id E229C43D2D; Wed,  5 May 2004 16:38:44 -0700 (PDT)
	(envelope-from gnagelhout@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72)
	id <HVCVTV63>; Wed, 5 May 2004 19:38:44 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337021AB385@mail.sandvine.com>
From: Gerrit Nagelhout <gnagelhout@sandvine.com>
To: 'Robert Watson' <rwatson@freebsd.org>,
	freebsd-current@freebsd.org
Date: Wed, 5 May 2004 19:38:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: 4.7 vs 5.2.1 SMP/UP bridging performance
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2004 23:38:45 -0000

Robert Watson wrote:

>> 
>> With previous platforms I have worked on (vxWorks), we had similar
>> issues, and ended up pushing buckets of packets through the 
>> data path,
>> so each mutex was only taken once for every 10-100 packets. 
>> 
>> Also, polling is currently done by only one CPU at a time.  
>> If this were
>> changed to have multiple threads poll multiple devices at 
>> the same time,
>> the performance should become much better. 
> 
> Getting polling and SMP to play nicely would be a very good thing, but
> isn't something I currently have the bandwidth to work on.  
> Don't suppose
> we could interest you in that? :-)
> 

I won't be able to work on that feature anytime soon, but if some
prototyping turns out to have good results, and the mutex cost issues
are worked out, it's quite likely that we'll try to implement it.  The
original author of the polling code (Luigi?) may have some input on
this as well.

Gerrit