<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regarding the forwarding, I feel that you two are argue different thing?</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
If I remember correctly, the mac80211 framework also re-use the ethernet data-path above some level, so the Linux kernel stack can handle both Wi-Fi data and Ethernet data. I think we all agree on this level of forwarding.</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I think Bob raise an interesting observation about the NIC on a server: Ethernet VS Wi-Fi.</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To my understanding about why Ethernet NIC works fine (or pretty good) on a server is that now a days the Ethernet NIC actually faces a non-shared media (medias are isolated by a switch). So the queue/packet in the Ethernet NIC till on the media could achieve
so called 'line rate forwarding' easily?</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
On the contrary, the Wi-Fi always faces a shared media (ISM band, CSMA/CA/etc.), and this bring a big difference compared to the Ethernet NIC. I can elaborate further on this: (because I am doing Wi-Fi chip/FPGA implementation since 2017 – the openwifi project,
and now we have implemented our Wi-Fi6.)</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<ul data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}">
<li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; list-style-type: "- "; color: rgb(0, 0, 0);">
<div class="elementToProof"><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">More and more complications are packed into the chip level instead of the driver level, Especially since Wi-Fi6. – it doesn't matter
there is "binary firmware blobs" or not. Even there isn't "binary firmware blobs", the complications will still be there. This is somehow the requirement from the real-time behaviour/aspect defined in the standard.</span></div>
</li><li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; list-style-type: "- "; color: rgb(0, 0, 0);">
<span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">The Wi-Fi LMAC has to operate precisely in terms of the time (normally order of microsecond, or sub-microsecond). – this has to be in chip.</span></li><li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; list-style-type: "- "; color: rgb(0, 0, 0);" class="elementToProof">
<span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">The Wi-Fi LMAC in the chip will decide: when (depends on CSMA/CA, queue status/priority, packet priority/etc ) the packet should be transmitted on which sub-band
(called RU in Wi-Fi6/7, OFDMA) through which spatial stream (MIMO, MU-MIMO). In summary: time, frequency and spatial for a packet.</span></li><li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; list-style-type: "- "; color: rgb(0, 0, 0);" class="elementToProof">
<span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Again reminding: the time, frequency, spatial are controlled by chip not driver due to their real-time aspects. After the driver handles the packet to Wi-Fi chip
(doesn't matter how good/up-to-date/open the driver is), then the only thing driver can do is waiting for the packet transmission result from the chip.</span></li><li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; list-style-type: "- "; color: rgb(0, 0, 0);" class="elementToProof">
<span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I haven't mentioned that in the chip there could also be multiple re-transmission processes, if the first attempts fail. The final packet delivery report only happens
after all re-transmission attempts end.<br>
</span></li></ul>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
In summary, in the case of Wi-Fi there are more and more complicated low-level behaviors out of the driver control, and this is not the case (most probably, or less the case) for Ethernet NIC (I guess).</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div style="background-color: rgb(255, 255, 255);"><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 15px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Best regards,</span><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 15px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">--</span><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 15px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Xianjun Jiao</span></div>
<div style="background-color: rgb(255, 255, 255);"><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
</div>
<div id="appendonsend"></div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Make-wifi-fast <make-wifi-fast-bounces@lists.bufferbloat.net> on behalf of Toke Høiland-Jørgensen via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net><br>
<b>Sent:</b> Wednesday, January 10, 2024 12:23 PM<br>
<b>To:</b> Bob McMahon <bob.mcmahon@broadcom.com><br>
<b>Cc:</b> Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net><br>
<b>Subject:</b> Re: [Make-wifi-fast] a cheer up tweet for y'all</span>
<div> </div>
</div>
<div><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">Bob McMahon <bob.mcmahon@broadcom.com> writes:<br>
<br>
> This approach is not going to work. Sun workstations as the forwarding<br>
> planes for WiFi doesn't work nor scale and is cost & power inefficient. The<br>
> WiFi forwarding plane needs to be all hardware and not based off of BSD. It<br>
> has to be like a port asic in an ethernet switch. No SoC.<br>
><br>
> Ethernet NICs are targeting servers where the workstation/NIC model does<br>
> work. WiFi is never going to be the basis for cloud servers.<br>
<br>
Well, the original context of the question was "Linux WiFi drivers are<br>
terrible, what can we do about that", and, well, providing proper<br>
upstream drivers at HW launch is the way to solve that.<br>
<br>
And even so, every Linux-based CPE in existence is a contradiction of<br>
you assertion that software-based WiFi forwarding is "not going to<br>
work". On the contrary, the SOCs with proper open source drivers and<br>
support are the ones that work the best, because that means we can run<br>
OpenWrt on them instead of the vendor crapware that they ship with.<br>
<br>
-Toke<br>
_______________________________________________<br>
Make-wifi-fast mailing list<br>
Make-wifi-fast@lists.bufferbloat.net<br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" id="OWAd058723d-4ab9-de6a-978e-ef04e35385a3" class="OWAAutoLink" data-auth="NotApplicable">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></span></div>
</body>
</html>