Hi,
On 04/12/2012 3:02 PM, Andre Oppermann wrote:
On 04.12.2012 20:34, Adrian Chadd wrote:
.. and it's important to note that buf_ring itself doesn't have the
race condition; it's the general driver implementation that's racy.
I have the same races in ath(4) with the watchdog programming. Exac
Hi,
On 04/12/2012 3:02 PM, Andre Oppermann wrote:
On 04.12.2012 20:34, Adrian Chadd wrote:
.. and it's important to note that buf_ring itself doesn't have the
race condition; it's the general driver implementation that's racy.
I have the same races in ath(4) with the watchdog programming. Exac
On Tue, 4 Dec 2012, Andre Oppermann wrote:
For most if not all ethernet drivers from 100Mbit/s the TX DMA rings
are so large that buffering at the IFQ level doesn't make sense anymore
and only adds latency.
I found sort of the opposite for bge at 1Gbps. Most or all bge NICs
have a tx ring siz
On 4 December 2012 12:02, Andre Oppermann wrote:
> Our IF_* stack/driver boundary handoff isn't up to the task anymore.
Right. well, the current hand off is really "here's a packet, go do
stuff!" and the legacy if_start() method is just plain broken for SMP,
preemption and direct dispatch.
Thin
On 04.12.2012 20:34, Adrian Chadd wrote:
.. and it's important to note that buf_ring itself doesn't have the
race condition; it's the general driver implementation that's racy.
I have the same races in ath(4) with the watchdog programming. Exactly
the same issue.
Our IF_* stack/driver boundary
.. and it's important to note that buf_ring itself doesn't have the
race condition; it's the general driver implementation that's racy.
I have the same races in ath(4) with the watchdog programming. Exactly
the same issue.
Adrian
___
freebsd-net@freeb
On Sunday, November 18, 2012 12:24:01 pm Barney Cordoba wrote:
>
> --- On Thu, 1/19/12, John Baldwin wrote:
>
> > From: John Baldwin
> > Subject: Latency issues with buf_ring
> > To: n...@freebsd.org
> > Cc: "Ed Maste" , "Navdeep Parhar"
> > Date: Thursday, January 19, 2012, 11:41 AM
> > The c
