Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Sep 2007 17:12:40 -0400
From:      Louis Mamakos <louie@transsys.com>
To:        Darren Reed <darrenr@freebsd.org>
Cc:        Kip Macy <kip.macy@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org>, Jack Vogel <jfvogel@gmail.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: TX Multiqueue?
Message-ID:  <E1C59706-4407-4907-AFD6-E71E40D68B73@transsys.com>
In-Reply-To: <46F614F2.4050402@freebsd.org>
References:  <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> <b1fa29170709221701m3c13cddakd83c9550905b8bd8@mail.gmail.com> <46F614F2.4050402@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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 <jfvogel@gmail.com> 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"
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1C59706-4407-4907-AFD6-E71E40D68B73>