Re: Problem using tc-sfq with tc-flow for arbitrary hashing

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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’t 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.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux