<div dir="ltr"><div>><span style="font-size:12.8px">And the</span></div><span style="font-size:12.8px">crypto itself should be offloaded to hardware (shouldn't it? we do see a</span><br style="font-size:12.8px"><span style="font-size:12.8px">marked drop in overall throughput from just enabling crypto)</span><div><br></div><div>Seems like you need to deterministically determine if the hw crypto is enabled, and actually happening.  If not, then SW crypto could be consuming, um, more CPU than you want.  I assume you are working on this.</div><div><br></div><div>Beyond that, yes, the use of crypto will add about 16 B of overhead to each MPDU, so maybe 1%.  Maybe the reported MTU might be less than 1500B so something must fragment??</div><div><br></div><div>K++</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 16, 2016 at 1:47 PM, Eric Dumazet <span dir="ltr"><<a href="mailto:eric.dumazet@gmail.com" target="_blank">eric.dumazet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Do you have tcpdumps of<br>
<br>
1) sample with crypto<br>
<br>
2) sample without crypto.<br>
<br>
Looks like some TCP Small queue interaction with skb->truesize, if GSO<br>
is involved, or encapsulation adding overhead.<br>
<div><div class="h5"><br>
<br>
On Tue, 2016-08-16 at 22:41 +0200, Toke Høiland-Jørgensen wrote:<br>
> So Dave and I have been spending the last couple of days trying to<br>
> narrow down why there's a performance regression in some cases on ath9k<br>
> with the softq-FQ patches. Felix first noticed this regression, and LEDE<br>
> currently carries a patch [1] to disable the FQ portion of the softq<br>
> patches to avoid it.<br>
><br>
> While we have been able to narrow it down a little bit, no solution has<br>
> been forthcoming, so this is an attempt to describe the bug in the hope<br>
> that someone else will have an idea about what could be causing it.<br>
><br>
> What we're seeing is the following (when the access point is running<br>
> ath9k with the softq patches):<br>
><br>
> When running two or more flows to a station, their combined throughput<br>
> will be roughly 20-30% lower than the throughput of a single flow to the<br>
> same station. This happens:<br>
><br>
> - for both TCP and UDP traffic.<br>
> - independent of the base rate (i.e. signal quality).<br>
> - but only with crypto enabled (WPA2 CCMP in this case).<br>
><br>
> However, the regression completely disappears if either of the<br>
> following is true:<br>
><br>
> - no crypto is enabled.<br>
> - the FQ part of mac80211 is disabled (as in [1]).<br>
><br>
> We have been able to reproduce this behaviour on two different ath9k<br>
> hardware chips and two different architectures.<br>
><br>
> The cause of the regression seems to be that the aggregates are smaller<br>
> when there are two flows than when there is only one. Adding debug<br>
> statements to the aggregate forming code indicates that this is because<br>
> no more packets are available when the aggregates are built (i.e.<br>
> ieee80211_tx_dequeue() returns NULL).<br>
><br>
> We have not been able to determine why the queues run empty when this<br>
> combination of circumstances arise. Since we easily get upwards of 120<br>
> Mbps of TCP throughput without crypto but with full FQ, it's clearly not<br>
> the hashing overhead in itself that does it (and the hashing also<br>
> happens with just one flow, so the overhead is still there). And the<br>
> crypto itself should be offloaded to hardware (shouldn't it? we do see a<br>
> marked drop in overall throughput from just enabling crypto), so how<br>
> would the queueing (say, mixing of packets from different flows)<br>
> influence that?<br>
><br>
> Does anyone have any ideas? We are stumped...<br>
><br>
> -Toke<br>
><br>
> [1] <a href="https://git.lede-project.org/?p=lede/nbd/staging.git;a=blob;f=package/kernel/mac80211/patches/220-fq_disable_hack.patch;h=7f420beea56335d5043de6fd71b5febae3e9bd79;hb=HEAD" rel="noreferrer" target="_blank">https://git.lede-project.org/?<wbr>p=lede/nbd/staging.git;a=blob;<wbr>f=package/kernel/mac80211/<wbr>patches/220-fq_disable_hack.<wbr>patch;h=<wbr>7f420beea56335d5043de6fd71b5fe<wbr>bae3e9bd79;hb=HEAD</a><br>
</div></div>> ______________________________<wbr>_________________<br>
> Make-wifi-fast mailing list<br>
> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.<wbr>bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/make-wifi-fast</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Kevin Hayes<br></div>
</div>