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