<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 23, 2020 at 1:57 PM Toke Høiland-Jørgensen <<a href="mailto:toke@redhat.com">toke@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maxime Bizon <<a href="mailto:mbizon@freebox.fr" target="_blank">mbizon@freebox.fr</a>> writes:<br>
<br>
> On Wednesday 22 Apr 2020 à 07:48:43 (-0700), Dave Taht wrote:<br>
><br>
> Hello,<br>
><br>
>> > Free has been using SFQ since 2005 (if I remember well).<br>
>> > They announced the wide deployment of SFQ in the <a href="http://free.fr" rel="noreferrer" target="_blank">free.fr</a> newsgroup.<br>
>> > Wi-Fi in the <a href="http://free.fr" rel="noreferrer" target="_blank">free.fr</a> router was not as good though.<br>
>> <br>
>> They're working on it. :)<br>
><br>
> yes indeed.<br>
><br>
> Switching to softmac approach, so now mac80211 will do rate control<br>
> and scheduling (using wake_tx_queue model).<br>
><br>
> for 5ghz, we use ath10k<br>
<br>
That is awesome! Please make sure you include the AQL patch for ath10k,<br>
it really works wonders, as Dave demonstrated:<br>
<br>
<a href="https://lists.bufferbloat.net/pipermail/make-wifi-fast/2020-March/002721.html" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/pipermail/make-wifi-fast/2020-March/002721.html</a><br>
<br>
>> I am very, very happy for y'all. Fiber has always been the sanest<br>
>> thing. Is there a SPF+ gpon card yet I can plug into a convention<br>
>> open source router yet?<br>
><br>
> FYI Free.fr uses 10G-EPON, not GPON.<br>
><br>
> Also most deployments are using an additionnal terminal equipement at<br>
> called "ONT" or "ONU" that handle the PON part and exposes an ethernet<br>
> port where the operator CPE is plugged. So we are back to the early<br>
> days of DSL, where the hardest part (scheduling) is done inside a<br>
> black box. That makes it easier to replace the operator CPE with your<br>
> own standard ethernet router though.<br>
><br>
> At least SOCs with integrated PON (supporting all flavours<br>
> GPON/EPON/..)  are starting to be deployed. Nothing available in<br>
> opensource.<br>
><br>
> Also note that it's not just kernel drivers, you also need some higher<br>
> OAM stack to make that work, and there are a lot of existing<br>
> standards, DPOE (EPON), OMCI (GPON)... all with interop challenges.<br>
<br>
It always bugged me that there was no open source support for these<br>
esoteric protocols and standards. It would seem like an obvious place to<br>
pool resources, but I guess proprietary vendors are going to keep doing<br>
their thing :/<br>
<br>
>> > The challenge becomes to keep up with these link rates in software<br>
>> > as there is a lot of hardware offloading.<br>
><br>
> Yes that's our pain point, because that's what the SOCs vendors<br>
> deliver and you need to use that because there is no alternative.<br>
><br>
> It's not entierely the SOCs vendors fault though.<br>
><br>
> 15 years ago, your average SOC's CPU would be something like 200Mhz<br>
> MIPS, Linux standard forwarding path (softirq => routing+netfilter =><br>
> qdisc) was too slow for this, too much cache footprint/overhead. So<br>
> every vendor started building alternatives forwarding path in their<br>
> hardware and never looked back.<br>
><br>
> Nowdays, the baseline SOC CPU would be ARM Cortex A53@~1Ghz, which<br>
> with a non crappy network driver and internal fabric should do be able<br>
> to route 1Gbit/s with out-of-the-box kernel forwarding.<br>
><br>
> But that's too late. SOC vendors compete against each others, and the<br>
> big telcos need a way to tell which SOC is better to make a buying<br>
> decision. So synthetic benchmarks have become the norm, and since<br>
> everybody was able to do fill their pipe with 1500 bytes packets,<br>
> benchmarks have moved to unrealistic 64 bytes packets (so called<br>
> wirespeed)<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">Yes, I'm not working anymore on these kinds of platforms</div><div class="gmail_default" style="font-family:monospace">but I do remember the pain.</div></div><div class="gmail_default" style="font-family:monospace">Hardware offloading may also have unexpected behaviours</div><div class="gmail_default" style="font-family:monospace">for stateful offloads. A flow starts in a slow path and </div><div class="gmail_default" style="font-family:monospace">then it moves to the fast path in hardware. </div><div class="gmail_default" style="font-family:monospace">Out of order at this stage can be nasty for a TCP connection.</div><div class="gmail_default" style="font-family:monospace">Worse a packet loss.</div><div class="gmail_default" style="font-family:monospace"><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> If you don't have hardware acceleration for forwarding, you don't<br>
> exist in those benchmarks and will not sell your chipset. Also they<br>
> invested so much in their alternative network stack that it's<br>
> difficult to stop (huge R&D teams). That being said, they do have a<br>
> point, when speed go above 1Gbit/s, the kernel becomes the bottleneck.<br>
><br>
> For Free.fr 10Gbit/s offer, we had to develop an alternative<br>
> (software) forwarding path using polling mode model (DPDK style),<br>
> otherwise our albeit powerful ARM Cortex A72@2Ghz could not forward<br>
> more than 2Gbit/s.<br>
<br>
We're working on that in kernel land - ever heard of XDP? On big-iron<br>
servers we have no issues pushing 10s and 100s of Gbps in software<br>
(well, the latter only given enough cores to throw at the problem :)).<br>
There's not a lot of embedded platforms support as of yet, but we do<br>
have some people in the ARM world working on that.<br>
<br>
Personally, I do see embedded platforms as an important (future) use<br>
case for XDP, though, in particular for CPEs. So I would be very<br>
interested in hearing details about your particular platform, and your<br>
DPDK solution, so we can think about what it will take to achieve the<br>
same with XDP. If you're interested in this, please feel free to reach<br>
out :)<br>
<br>
> And going multicore/RSS does not fly when the test case is single<br>
> stream TCP session, which is what most speedtest application do (ookla<br>
> only recently added multi-connections test).<br>
<br>
Setting aside the fact that those single-stream tests ought to die a<br>
horrible death, I do wonder if it would be feasible to do a bit of<br>
'optimising for the test'? With XDP we do have the ability to steer<br>
packets between CPUs based on arbitrary criteria, and while it is not as<br>
efficient as hardware-based RSS it may be enough to achieve line rate<br>
for a single TCP flow?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Toke yes I was implicitly thinking about XDP but I did </div><div class="gmail_default" style="font-family:monospace">not read yet any experience in CPEs using that.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">DPDK, netmap and kernel bypass may be an option but</div></div><div class="gmail_default" style="font-family:monospace">you lose all qdiscs. </div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace"><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Toke<br>
<br>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div></div>