Re: TX Multiqueue?

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

Relevant Pages

  • Re: Changes in the network interface queueing handoff model
    ... The main complication I've seen is when a driver needs to process multiple queues of packets things get more involved. ... With the current scheme you have two separate queues and the start method handles prioritization by polling the mgt q before the data q. ... If instead the packet is passed to the start method then it needs to be tagged in some way so the it's prioritized properly. ... Indeed, it does, but structurally, SLIP is split over the link layer and driver layer, which I had forgotten. ...
    (freebsd-arch)
  • Re: Changes in the network interface queueing handoff model
    ... The main complication I've seen is when a driver needs to process multiple queues of packets things get more involved. ... With the current scheme you have two separate queues and the start method handles prioritization by polling the mgt q before the data q. ... If instead the packet is passed to the start method then it needs to be tagged in some way so the it's prioritized properly. ... Indeed, it does, but structurally, SLIP is split over the link layer and driver layer, which I had forgotten. ...
    (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: [SLE] Missing function in yast
    ... > At one time there was an option in YaST to propose multiple queues ... It was removed because it did work only if a Foomatic PPD file was used. ... queues for one printer. ...
    (SuSE)
  • Re: Can a VxWorks task pend on multiple message queues?
    ... As I know VxWorks task cannot pend on multiple queues. ... I wanted to know that how can I make use of some VxWorks facilities to ...
    (comp.os.vxworks)