From owner-freebsd-current@FreeBSD.ORG Sun Sep 23 22:38:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C26CC16A419; Sun, 23 Sep 2007 22:38:22 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6173113C455; Sun, 23 Sep 2007 22:38:22 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 604882F004; Sun, 23 Sep 2007 18:38:02 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 23 Sep 2007 18:38:02 -0400 X-Sasl-enc: cDFZ9oVuyYCmZjdT1cSqICDMJ8Rdc03EpCRDvBbpj+h1 1190587082 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 68F0420960; Sun, 23 Sep 2007 18:38:01 -0400 (EDT) Message-ID: <46F6EB10.8060505@freebsd.org> Date: Sun, 23 Sep 2007 15:39:12 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Louis Mamakos References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> <46F614F2.4050402@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kip Macy , FreeBSD Current , Jack Vogel , "freebsd-net@freebsd.org" Subject: Re: TX Multiqueue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2007 22:38:22 -0000 Louis Mamakos wrote: > We've seen problems on other OS's where the locking in the device driver > around the process of queuing packets to the device was a performance > issue > when trying to send relatively small packets. As a workaround, we > ended up > doing a multi-link/bonding thing over multiple interfaces to get the > throughput. This was on an SMP system and the application was such that > there were multiple execution threads running in parallel. > > Having multiple queues, even for a single class of traffic may enable > enough > additional concurrency in the driver to increase throughput. It's up to > driver to use some algorithm to spread the load over the queues to ensure > that specific "flows" stay in order, same as if you we doing > ether-channel > bonding. Maybe I'm not interested in the driver having its own algorithm. Maybe I want to reserve a tx/rx queue pair for ssh. Maybe I want to dedicate a tx/rx queue pair for my web server. etc. Darren > Of course, if the transmit path through the network stack isn't enabling > concurrency, a bottleneck there won't be an issue. > > Louis Mamakos > > Just something else to consider.. > > On Sep 23, 2007, at 3:25 AM, Darren Reed wrote: > >> Kip Macy wrote: >>> My ethng branch supports multiple rx and tx queues. >>> >>> -Kip >>> >> >> What are your plans for how we use/manage/interact with the mutiple >> rx/tx queues? >> >> Darren >> >> >>> On 9/22/07, Jack Vogel wrote: >>> > Our newest E1000 nic, the 82575, and the Oplin 10G hardware are >>> capable of >>> > multiple queues both on the receive and the send side. On the >>> receive end for >>> > the Oplin driver the queues actually help distribute interrupts >>> and improve >>> > performance without any special support in the stack. >>> > >>> > I have been asked about multiple queues on the TX side, embedded >>> appliance >>> > type system builders for instance are interested I suppose for >>> > priority queueing. >>> > Is anyone working on this right now, and if not does this sound >>> like something >>> > anyone is interested in doing? >>> > >>> > I would like to see MQ on both TX and RX that drivers could use if >>> able. >>> > >>> > Jack >>> > _______________________________________________ >>> > freebsd-net@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> > To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org" >>> > >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> >