> Btw, there are some opinions that with modern cards any software
> queing is a bad idea. Driver should simply hold as much as hardware
> tx ring can hold. There is no yet stable decision about this, just
> thoughts floating around.
The drbr queue gives the driver the ability to source packets fr
Andrew,
On Sat, Mar 22, 2014 at 02:16:24PM +0400, Andrew Rybchenko wrote:
A> > The interaction between sfxge_tx_qdpl_put() and sfxge_tx_packet_add()
A> > is quite complex and I couldn't resist from suggesting you to
A> > simplify the code.
A> >
A> > Can you please look into attached patch?
A> >
Gleb,
On 03/18/2014 05:24 PM, Gleb Smirnoff wrote:
Andrew,
On Tue, Mar 18, 2014 at 01:55:01PM +0400, Andrew Rybchenko wrote:
A> sfxge: limit software Tx queue size
A>
A> Previous implementation limits put queue size only (when Tx lock can't
A> be acquired),
A> but get queue may grow unbounde
Andrew,
On Tue, Mar 18, 2014 at 01:55:01PM +0400, Andrew Rybchenko wrote:
A> sfxge: limit software Tx queue size
A>
A> Previous implementation limits put queue size only (when Tx lock can't
A> be acquired),
A> but get queue may grow unboundedly which results in mbuf pools
A> exhaustion and
A>
sfxge: limit software Tx queue size
Previous implementation limits put queue size only (when Tx lock can't
be acquired),
but get queue may grow unboundedly which results in mbuf pools
exhaustion and
latency growth.
Submitted-by: Andrew Rybchenko
Sponsored by: Solarflare Communications, I
