Re: TX Multiqueue?

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@xxxxxxxxx> 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@xxxxxxxxxxx mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net- unsubscribe@xxxxxxxxxxx"
>
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current- unsubscribe@xxxxxxxxxxx"


_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current- unsubscribe@xxxxxxxxxxx"


_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: TX Multiqueue?
    ... 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 ... Having multiple queues, even for a single class of traffic may enable enough ...
    (freebsd-net)
  • Re: TX Multiqueue?
    ... around the process of queuing packets to the device was a performance issue ... Having multiple queues, even for a single class of traffic may enable enough ... additional concurrency in the driver to increase throughput. ...
    (freebsd-current)
  • Re: TX Multiqueue?
    ... around the process of queuing packets to the device was a performance issue ... Having multiple queues, even for a single class of traffic may enable enough ... additional concurrency in the driver to increase throughput. ...
    (freebsd-net)
  • Re: i386: pata_cs5520 does not work
    ... Device driver platform lacks bus and class support for being resumed. ... Device driver pci0000:00 lacks bus and class support for being resumed. ...
    (Linux-Kernel)
  • Re: 1394 Virtual Device Driver
    ... Try two machines connected via 1394, one with a virtual device ... > enumerates the bus successfully including the virtual device driver. ...
    (microsoft.public.development.device.drivers)