From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04olkn2031.outbound.protection.outlook.com [40.92.45.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F2CE83B29D for ; Wed, 10 Jan 2024 08:55:50 -0500 (EST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RdYByowBnodiX27qrurcj8Qewo+QnkK1M2d6WiFBBx4/72V/yvi4y6Hn7kGi+OK9p/hcxZhRJVbG2yTSwq1XvDwuQgPgMGs0N+xtBIJj+J7nQFqQA4UPni8RyPz5YekaFwDVYCYOJNwU5Q/qXm4puz5J19JVtBBNtnzVAemyLgjoH8NW4P4/Hrpj1QA6t+WuRiIMAvIXjEAi0vhPn/WvwP5KP6N1ZIHP542wV8AqXMZ67Wq81UrY6wxb+nCVnTqwJuh496fsKQwQz7RjLQV53JTL7wXCxIVTtAp2in6yPhjU7Y6sLyQE2C5nBpuoGsgcSJO/035F0GME7q7yBzdaFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=o/PSC/w6l/K+H0Ev/9qCIV6JpSDEUYmrIUrTHHwCjKg=; b=k9WxI4gnOHsRg9qnBaKKn8CP443j2ett1g5vkm54B/sk/eaIFXxO/XiUF94Gd1eSZWCejZWJLbzLnscwi2SR+jIF/xebqi7FTor/OojEbfRgQ2b1pz6cyxWYaiTfXCe0wf69hlcJ6myOjx+aXUcc+YXTOjVq1WoOlqrKWuJ+EfkIN9WQEheO+qsR5jrpCoCzh5jubDLbj+xjNcMaqLNuWb7VQMDvFbB5tVAJsvvEs7cE40P4m3eln74Q4h0Y4bgr0MIITF3iDUCcqkzinFvBhLJokloCkc+31rIjQqphtkCEIS1QedXsF3vK1yFUVeCwdqhFgLtOoHSkGIxvBbfh0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o/PSC/w6l/K+H0Ev/9qCIV6JpSDEUYmrIUrTHHwCjKg=; b=krwX53ARxIx7oTY8ZyTMQri9ucfGzIPojkCfaOo3LP3USgAUWovYEwbAr60IwCtJcK2TM/RKHovJildt7SPoC4I2EeapCeh6m318CRNRgXZL8mtH6RHX4hrJWxt4rNiMkvV/iVEX77qA3eqmeZcHgKkO8xeQkCFj5mOcWxpcrMsvrr5bG8PWML9vb5EE+jdoIUuPr7IRd09xL/ddHeWTX8FwFR0860zq9reb8BPNA2BVN5va8UnpTQ+jlOE3O0bR8W2XEu8KwRTKQM36f4GLOOOfZNU/OWU0CazWNHjH3hQpwEP3nOYdfDSWTTgi7eOPfhqW4r2WlnaDHIBS/YZJJw== Received: from MW4PR11MB6619.namprd11.prod.outlook.com (2603:10b6:303:1eb::13) by MW4PR11MB7151.namprd11.prod.outlook.com (2603:10b6:303:220::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.23; Wed, 10 Jan 2024 13:55:48 +0000 Received: from MW4PR11MB6619.namprd11.prod.outlook.com ([fe80::b4cf:6630:7830:33b8]) by MW4PR11MB6619.namprd11.prod.outlook.com ([fe80::b4cf:6630:7830:33b8%6]) with mapi id 15.20.7181.018; Wed, 10 Jan 2024 13:55:48 +0000 From: XianJun Jiao To: Bob McMahon , =?Windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= CC: Make-Wifi-fast Thread-Topic: [Make-wifi-fast] a cheer up tweet for y'all Thread-Index: AQHaQlbmHBKe/sBiekyHO0zjVTiWVrDQ56QAgABonoCAAHFwgIABKIAAgAAho6Q= Date: Wed, 10 Jan 2024 13:55:48 +0000 Message-ID: References: <877cki4vxq.fsf@toke.dk> <875y01xwi5.fsf@toke.dk> In-Reply-To: <875y01xwi5.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [BxdYwU1yu5j/EqyTIa4BnEkVCpQkbJfbTWIchqAjpz6D+uiRXwGNxEh+PMgoIG5S] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW4PR11MB6619:EE_|MW4PR11MB7151:EE_ x-ms-office365-filtering-correlation-id: e882fb1d-f19f-4939-327e-08dc11e3d9a7 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yFuqrdaMcagR1n1lPPatpZjxY5lD2rXEHoBw1eAklDWzG2ug2KxMmxGBYi2sdwMLgW18VK9yEODbVqic3WFCldjyOKsN974Lmf1ewDy8WU/Xo/D/W1jPZhI7OOK9EYJdirHJaDzZN8Eb5FNPg7vsSKwUFMMYTaoDkOIsYjgFGGmWpCTtTDYbYGqLbBJNTDMajm4b8bP94wcqu6RatTu6O0V+G7QQ6TdZj6+489B6ioD552HrBnJMvxdx1qNfIxRu+IJfYRdPDcB+pLbIunYI5FlxXWXjmZB1vmbD0+la90YnZ4YqMfeuwgwfc4tvVjcIRj0xbE2z6LerJ42ROz/KbOAeBwJUfb3XrvEeC+d4kC5HxtTMu16mSsS7axEMOL+eTg7xvE4VzUjHoKvIukOe1sW99jCqfc8jQN2VOlY5oKaglK1D/yRhDBEc5FOKAJQRRF4vt46tmdE/ZMDPDjgl1JBJ/FM4pg9gn6gfZz2WzWvGm6h/kUVqsKy6nr0AQmGTXqNHSW6Blfx5KqmG0fuYLtdz1f1AQkDSwCUQPTRR9/tIBsnju79vS2FPEwvaOM9ZClRhnKPadc6VqQdRDkwkxBelQxAfmKH/hs4lfmGZQGpsVW6sibeALbReXV/Cb+ZG x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?/4Pc7oPDBfQh5uhXeCsKuZnqt2IWuojAkI85QAu74uee2BVETE6DdKvY?= =?Windows-1252?Q?iQwDrqPS9JQDKuV/Sjp6LkysbBWCzZCiW4KLWxnk+v/2iqyYfLcqRIW0?= =?Windows-1252?Q?NamaWag58ZTp7gnGKY8vZdCQLNtfLFYN77ep6rha48BDREwvYstGO2d8?= =?Windows-1252?Q?ZgaZ/1zdGAw2wwkyIKpHCLVpNoLgVsqpt6kE49J0+ImgYt0OVJNTLEqv?= =?Windows-1252?Q?78PjRPZ5Es6kJpiTZiH2kqozcaQSQuwtY4yo463lvstZj1Ax6CGSaPYn?= =?Windows-1252?Q?ueeH/gHceQk9hdMk+faZbQ4XMpi2B4JXI/O5m/5LocbyMvN2PKdGyflj?= =?Windows-1252?Q?Y4QzIg6YrFsZRuV8rXyyxmB+BWoaNw/h7VCShM2Z7DHgjM5wwoWGhqs3?= =?Windows-1252?Q?4GQDFZ3As062VM9N4Rml5Qg+2g3VTAuziWydfiVGzNs+ku2oRccMW4uD?= =?Windows-1252?Q?ZpYW90SsCbkOQkY9mcHue/OXLTw5b9k9h66eaGS5yYAdwyhuyqOxcbTt?= =?Windows-1252?Q?tMBPG8L0T/t/aTqKe2KwJsRWF4mZ9XIYO5dyFS6FKCgR6IRGGC4fadG7?= =?Windows-1252?Q?xBOWZkPYIP/jhuo+NiB9uF0+mXBJeoY03NkT43N99XKShBKtDupjx2yG?= =?Windows-1252?Q?XyRjXqHBH4L9u7EtMhDCjzqrU3W8b+3OO780AJZghSCLdP6OtcCLnaIB?= =?Windows-1252?Q?gM8UlmU0pRaj7pu0n7sdSfj1YnYCvXqS9+41XNYLu5RDXr/OYGA0xhDg?= =?Windows-1252?Q?kfgjX5cZqIAQb4aKvx3IwdgWIjIsmyPthPmYneZnDA3twWKlF6gOMLCW?= =?Windows-1252?Q?siGXqGZPJLLtFprNA3UgO6ELT4Jcgkz6/FobdhsZXfZFwfo6IkfklMce?= =?Windows-1252?Q?PnrWy+Zht0VcSjvm0nphjN94PinqHgJIM1SMEOgepQuK3zdylAHRb9e7?= =?Windows-1252?Q?Ceu9GbGJgt0+3I4rO2LOhZqWlSgJ9QylG+2sOLzfbVa4sI5wmBA7L9R3?= =?Windows-1252?Q?XNBNGbmfkLG6fYJKT1CEk4Hl3sQGAkOZa1AkWSLe5TbuwxkA0MM50Qha?= =?Windows-1252?Q?UMlEc8jsvJJt2oHLYKYt0cTjHeev8i9bh+jTaeoWb64FZIVb0RPdy+Ei?= =?Windows-1252?Q?4Q4NKO2SYBXa/TzGmT6rTqQ66NHC0gsklHNtsy59RjLzcSl6CWlU2eSE?= =?Windows-1252?Q?V89iB2WqocKPxvwcdr0BRMG/esCjMOo8M9DYJ+VcpTzULDIkIrPBakNJ?= =?Windows-1252?Q?0l1QBDTyZMHuKC3iSfmjGmbQlOuHrBCYL8imsjOH9vy93DNJGd+wr3F0?= =?Windows-1252?Q?a4YJSCyfdGRgVs9OOtal9WbTGWhIHgCAbA75ha/iDu8mDFYG?= Content-Type: multipart/alternative; boundary="_000_MW4PR11MB661901BACBF22C375117865FD4692MW4PR11MB6619namp_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-e8f36.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB6619.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: e882fb1d-f19f-4939-327e-08dc11e3d9a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2024 13:55:48.6151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB7151 Subject: Re: [Make-wifi-fast] a cheer up tweet for y'all X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2024 13:55:51 -0000 --_000_MW4PR11MB661901BACBF22C375117865FD4692MW4PR11MB6619namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Regarding the forwarding, I feel that you two are argue different thing? If I remember correctly, the mac80211 framework also re-use the ethernet da= ta-path above some level, so the Linux kernel stack can handle both Wi-Fi d= ata and Ethernet data. I think we all agree on this level of forwarding. I think Bob raise an interesting observation about the NIC on a server: Eth= ernet VS Wi-Fi. 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 med= ia (medias are isolated by a switch). So the queue/packet in the Ethernet N= IC till on the media could achieve so called 'line rate forwarding' easily? On the contrary, the Wi-Fi always faces a shared media (ISM band, CSMA/CA/e= tc.), and this bring a big difference compared to the Ethernet NIC. I can e= laborate further on this: (because I am doing Wi-Fi chip/FPGA implementatio= n since 2017 =96 the openwifi project, and now we have implemented our Wi-F= i6.) * More and more complications are packed into the chip level instead of the d= river level, Especially since Wi-Fi6. =96 it doesn't matter there is "binar= y firmware blobs" or not. Even there isn't "binary firmware blobs", the com= plications will still be there. This is somehow the requirement from the re= al-time behaviour/aspect defined in the standard. * The Wi-Fi LMAC has to operate precisely in terms of the time (normall= y order of microsecond, or sub-microsecond). =96 this has to be in chip. * The Wi-Fi LMAC in the chip will decide: when (depends on CSMA/CA, que= ue status/priority, packet priority/etc ) the packet should be transmitted = on which sub-band (called RU in Wi-Fi6/7, OFDMA) through which spatial stre= am (MIMO, MU-MIMO). In summary: time, frequency and spatial for a packet. * Again reminding: the time, frequency, spatial are controlled by chip = not driver due to their real-time aspects. After the driver handles the pac= ket 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 re= sult from the chip. * I haven't mentioned that in the chip there could also be multiple re-= transmission processes, if the first attempts fail. The final packet delive= ry report only happens after all re-transmission attempts end. In summary, in the case of Wi-Fi there are more and more complicated low-le= vel behaviors out of the driver control, and this is not the case (most pro= bably, or less the case) for Ethernet NIC (I guess). Best regards, -- Xianjun Jiao ________________________________ From: Make-wifi-fast on beha= lf of Toke H=F8iland-J=F8rgensen via Make-wifi-fast Sent: Wednesday, January 10, 2024 12:23 PM To: Bob McMahon Cc: Make-Wifi-fast Subject: Re: [Make-wifi-fast] a cheer up tweet for y'all Bob McMahon writes: > This approach is not going to work. Sun workstations as the forwarding > planes for WiFi doesn't work nor scale and is cost & power inefficient. T= he > WiFi forwarding plane needs to be all hardware and not based off of BSD. = It > has to be like a port asic in an ethernet switch. No SoC. > > Ethernet NICs are targeting servers where the workstation/NIC model does > work. WiFi is never going to be the basis for cloud servers. Well, the original context of the question was "Linux WiFi drivers are terrible, what can we do about that", and, well, providing proper upstream drivers at HW launch is the way to solve that. And even so, every Linux-based CPE in existence is a contradiction of you assertion that software-based WiFi forwarding is "not going to work". On the contrary, the SOCs with proper open source drivers and support are the ones that work the best, because that means we can run OpenWrt on them instead of the vendor crapware that they ship with. -Toke _______________________________________________ Make-wifi-fast mailing list Make-wifi-fast@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/make-wifi-fast --_000_MW4PR11MB661901BACBF22C375117865FD4692MW4PR11MB6619namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Regarding the forwarding, I feel that you two are argue different thing?

If I remember correctly, the mac80211 framework also re-use the ethernet da= ta-path above some level, so the Linux kernel stack can handle both Wi-Fi d= ata and Ethernet data. I think we all agree on this level of forwarding.

I think Bob raise an interesting observation about the NIC on a server: Eth= ernet VS Wi-Fi.

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 med= ia (medias are isolated by a switch). So the queue/packet in the Ethernet N= IC till on the media could achieve so called 'line rate forwarding' easily?

On the contrary, the Wi-Fi always faces a shared media (ISM band, CSMA/CA/e= tc.), and this bring a big difference compared to the Ethernet NIC. I can e= laborate further on this: (because I am doing Wi-Fi chip/FPGA implementatio= n since 2017 =96 the openwifi project, and now we have implemented our Wi-Fi6.)

  • More and more complic= ations are packed into the chip level instead of the driver level, Especial= ly since Wi-Fi6. =96 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.
  • The Wi-Fi LMAC has to operate precisely in terms of= the time (normally order of microsecond, or sub-microsecond). =96 this has= to be in chip.
  • The Wi-Fi LMAC in the chip will decide: when (depen= ds on CSMA/CA, queue status/priority, packet priority/etc ) the packet shou= ld 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.
  • Again reminding: the time, frequency, spatial are c= ontrolled by chip not driver due to their real-time aspects. After the driv= er handles the packet to Wi-Fi chip (doesn't matter how good/up-to-date/open the driver is), then the only thi= ng driver can do is waiting for the packet transmission result from the chi= p.
  • I haven't mentioned that in the chip there could al= so be multiple re-transmission processes, if the first attempts fail. The f= inal packet delivery report only happens after all re-transmission attempts end.
In summary, in the case of Wi-Fi there are more and more complicated low-le= vel behaviors out of the driver control, and this is not the case (most pro= bably, or less the case) for Ethernet NIC (I guess).

Best regards,
--
Xianju= n Jiao
From: Make-w= ifi-fast <make-wifi-fast-bounces@lists.bufferbloat.net> on behalf of = Toke H=F8iland-J=F8rgensen via Make-wifi-fast <make-wifi-fast@lists.buff= erbloat.net>
Sent: Wednesday, January 10, 2024 12:23 PM
To: Bob McMahon <bob.mcmahon@broadcom.com>
Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>=
Subject: Re: [Make-wifi-fast] a cheer up tweet for y'all
 
Bob McMahon <bob.mcmahon@broadcom.com> w= rites:

> This approach is not going to work. Sun workstations as the forwarding=
> planes for WiFi doesn't work nor scale and is cost & power ineffic= ient. The
> WiFi forwarding plane needs to be all hardware and not based off of BS= D. It
> has to be like a port asic in an ethernet switch. No SoC.
>
> Ethernet NICs are targeting servers where the workstation/NIC model do= es
> work. WiFi is never going to be the basis for cloud servers.

Well, the original context of the question was "Linux WiFi drivers are=
terrible, what can we do about that", and, well, providing proper
upstream drivers at HW launch is the way to solve that.

And even so, every Linux-based CPE in existence is a contradiction of
you assertion that software-based WiFi forwarding is "not going to
work". On the contrary, the SOCs with proper open source drivers and support are the ones that work the best, because that means we can run
OpenWrt on them instead of the vendor crapware that they ship with.

-Toke
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast
--_000_MW4PR11MB661901BACBF22C375117865FD4692MW4PR11MB6619namp_--