Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Mar 2014 22:28:53 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Andrew Rybchenko <Andrew.Rybchenko@oktetlabs.ru>
Cc:        net@FreeBSD.org
Subject:   Re: [PATCH 2/6] sfxge: limit software Tx queue size
Message-ID:  <20140322182852.GW1499@glebius.int.ru>
In-Reply-To: <532D62F8.4080103@oktetlabs.ru>
References:  <532817F5.8010505@oktetlabs.ru> <20140318132440.GG1499@FreeBSD.org> <532D62F8.4080103@oktetlabs.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
  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> >
A> > - Inline sfxge_tx_qdpl_put() into sfxge_tx_packet_add().
A> > - Simplify the 'locked' logic.
A> > - Add your PATCH 1/6, the mbuf leak fix.
A> > - Add your PATCH 2/6, the SFXGE_TX_DPL_GET_PKT_LIMIT_DEFAULT check.
A> I don't like "locked" flag passed to qdpl_put() function as well.
A> However, I prefer to keep patches granular and avoid mixing of different 
A> changes in single patch. If the initial patch is OK, please, submit it 
A> to repository. Then, I'll rebase your patch, discuss it locally and come 
A> back to you.

As you wish. Committed, thanks.

A> BTW, I see that many drivers use drbr for software Tx queue. What do you 
A> think, would it be beneficial to use it instead of the list implemented 
A> here?

No idea. drbr(9) is definitely better than ifqueue(9), that's all I can
confident state. No idea how drbr(4) compares to the hand made queue of
sxfge(4).

You've got the hardware, you measure :)

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.

-- 
Totus tuus, Glebius.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140322182852.GW1499>