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>