Date: Sun, 23 Sep 2007 15:39:12 -0700 From: Darren Reed <darrenr@freebsd.org> To: Louis Mamakos <louie@transsys.com> 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: <46F6EB10.8060505@freebsd.org> In-Reply-To: <E1C59706-4407-4907-AFD6-E71E40D68B73@transsys.com> References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> <b1fa29170709221701m3c13cddakd83c9550905b8bd8@mail.gmail.com> <46F614F2.4050402@freebsd.org> <E1C59706-4407-4907-AFD6-E71E40D68B73@transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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?46F6EB10.8060505>