From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Fri, 31 Mar 2017 14:12:10 +0000 Subject: Re: Problem using tc-sfq with tc-flow for arbitrary hashing Message-Id: List-Id: References: <18AC8370-6B1E-4A01-B5E4-BA637BA485C0@gmail.com> In-Reply-To: <18AC8370-6B1E-4A01-B5E4-BA637BA485C0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Carmelo Cascone wrote: > Andy, > > Thank you very much for the hint. The command is now accepted. > > Unfortunately, I see some strange behaviors when using tc-flow, in > the sense that sometimes the bandwidth allocation on a 10Gb/s NIC is > far form being fair. It looks like the whole bandwidth is capitalized > by a single flow, even if I use a small number of flows, even if I > wait a couple of perturbation intervals. Some other times it works > perfectly (apart for throughput degradation, ~8.5Gb/s). Not sure what > the cause is, but if I use tc-sfq alone without tc-flow iI don=E2=80=99t = see > this behavior, it always works as expected. > > I will test further, but if anyone as some hint, that is > appreciated. I have no experience with 10gig nics, but years ago putting sfq on a lowly 100mbit nic didn't work well due to it just sitting before a large fifo. Things may be different now with BQLs if enabled - but I have never tested. Random thoughts - 10 gig nic is likely to do some hardware offload, so the kernel may be sending huge packets out for locally generated traffic vs smaller for routed. ethtool -k will show -K to control - but turning off on 10 gig will I imagine be expensive CPU wise. Local traffic may limit its self vs routed with tcp pacing. SFQ default qlen is only 127 IIRC - which is small at such high rates. SFQ is possibly not coming into play until a larger queue fills up.