wifi-7 + MLO: wlan is not seen in /proc/net/wireless

wifi-7 + MLO: wlan is not seen in /proc/net/wireless

[Ben Greear]

Hello,

I'm testing a wifi-7 radio against MLO AP.  I notice the link-0 debugfgs links
show up and STA is associated and acquired DHCP, but wlan is not in /proc/net/wireless.
I'm in 6.5.5+ kernel.

Is this expected?

# cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets               | Missed | WE
  face | tus | link level noise |  nwid  crypt   frag  retry   misc | beacon | 22

# iw dev wlan0 info
Interface wlan0
	ifindex 65
	wdev 0xc00000006
	addr [removed]
	ssid NETGEAR69-6G
	type managed
	wiphy 12
	txpower 0.00 dBm
	multicast TXQ:
		qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
		0	0	0	0	0	0	0	0		0

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: wifi-7 + MLO: wlan is not seen in /proc/net/wireless

[Kalle Valo]

Ben Greear <greearb@candelatech.com> writes:

> I'm testing a wifi-7 radio against MLO AP.  I notice the link-0 debugfgs links
> show up and STA is associated and acquired DHCP, but wlan is not in /proc/net/wireless.
> I'm in 6.5.5+ kernel.
>
> Is this expected?

wext doesn't support Wi-Fi 7, see:

https://git.kernel.org/linus/52fd90638a72

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: wifi-7 + MLO: wlan is not seen in /proc/net/wireless

[Ben Greear]

On 10/3/23 10:06 PM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
> 
>> I'm testing a wifi-7 radio against MLO AP.  I notice the link-0 debugfgs links
>> show up and STA is associated and acquired DHCP, but wlan is not in /proc/net/wireless.
>> I'm in 6.5.5+ kernel.
>>
>> Is this expected?
> 
> wext doesn't support Wi-Fi 7, see:
> 
> https://git.kernel.org/linus/52fd90638a72

For somewhat similar reasons, ethtool stats are broken for MLO
too (see my patches from yesterday).

To keep at least some backwards compatibility, would it be worth
reporting the 'best' link's information?  To me best is highest
band that is connected.  It could also just be the first link that is
connected.

Any suggestions for how to do ethtool stats better for MLO?

Maybe the original values would be for the first, or maybe best link,
and then add new stats fields for second and third links?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: wifi-7 + MLO: wlan is not seen in /proc/net/wireless

[Johannes Berg]

On Wed, 2023-10-04 at 06:19 -0700, Ben Greear wrote:
> On 10/3/23 10:06 PM, Kalle Valo wrote:
> > Ben Greear <greearb@candelatech.com> writes:
> > 
> > > I'm testing a wifi-7 radio against MLO AP.  I notice the link-0 debugfgs links
> > > show up and STA is associated and acquired DHCP, but wlan is not in /proc/net/wireless.
> > > I'm in 6.5.5+ kernel.
> > > 
> > > Is this expected?
> > 
> > wext doesn't support Wi-Fi 7, see:
> > 
> > https://git.kernel.org/linus/52fd90638a72
> 
> For somewhat similar reasons, ethtool stats are broken for MLO
> too (see my patches from yesterday).
> 
> To keep at least some backwards compatibility, would it be worth
> reporting the 'best' link's information?  To me best is highest
> band that is connected.  It could also just be the first link that is
> connected.

So I think we should differentiate here. For wext, certainly no. I don't
want to support wext forever, and multi-link is a really good reason to
say "nope, things just stop working here, stop using 1996 technology".

For ethtool, well, to be honest I never really liked it in the first
place (*), but I guess we should somehow fix some things there...
Perhaps report some cumulative values?

But let's discuss that on the individual patches I guess.


(*) I also don't like your iwlwifi patch for those 'buckets', FWIW,
there's no real explanation for why the buckets should be this way, and
putting an array into flat ethtool also feels just wrong.

johannes

Re: wifi-7 + MLO: wlan is not seen in /proc/net/wireless

[Ben Greear]

On 10/10/23 07:28, Johannes Berg wrote:
> On Wed, 2023-10-04 at 06:19 -0700, Ben Greear wrote:
>> On 10/3/23 10:06 PM, Kalle Valo wrote:
>>> Ben Greear <greearb@candelatech.com> writes:
>>>
>>>> I'm testing a wifi-7 radio against MLO AP.  I notice the link-0 debugfgs links
>>>> show up and STA is associated and acquired DHCP, but wlan is not in /proc/net/wireless.
>>>> I'm in 6.5.5+ kernel.
>>>>
>>>> Is this expected?
>>>
>>> wext doesn't support Wi-Fi 7, see:
>>>
>>> https://git.kernel.org/linus/52fd90638a72
>>
>> For somewhat similar reasons, ethtool stats are broken for MLO
>> too (see my patches from yesterday).
>>
>> To keep at least some backwards compatibility, would it be worth
>> reporting the 'best' link's information?  To me best is highest
>> band that is connected.  It could also just be the first link that is
>> connected.
> 
> So I think we should differentiate here. For wext, certainly no. I don't
> want to support wext forever, and multi-link is a really good reason to
> say "nope, things just stop working here, stop using 1996 technology".
> 
> For ethtool, well, to be honest I never really liked it in the first
> place (*), but I guess we should somehow fix some things there...
> Perhaps report some cumulative values?

Ok, how about for anything that makes sense as a sum, the current ethtool values will be sum
of all links.  For anything that doesn't make sense as a sum, it will be from link
connected on the highest band.

And as follow on patch(es), add some per-link stats as seems useful.

Does that sound like a good approach?

> 
> But let's discuss that on the individual patches I guess.
> 
> 
> (*) I also don't like your iwlwifi patch for those 'buckets', FWIW,
> there's no real explanation for why the buckets should be this way, and
> putting an array into flat ethtool also feels just wrong.

Ethtool is best option available for driver stats, considering only other thing I am
aware of in this area is parsing debugfs files.

Ethtool API makes it easy to grow arrays or otherwise add stats.  User-space that
is paying attention can map strings to indices and then grab data efficiently
after that.  To make mapping stings to indices work best, it is good if drivers use
the same ethtool strings when possible.  So, I originally coded up the histogram logic
for mt76, and it has specific way of reporting ampdu buckets from its firmware.
To make iwlwifi 'just work' with same ethtool strings mappings, I chose same buckets
as mt76 uses.  If you have a specific reason you would like a different bucket layout,
and if that would make patches acceptable into iwlwifi, then please propose your
preferred layout.  I'd like to get patches upstream, even at cost of me having to do more
user-space hacking to use the new stats.

For reference, with all of my ethtool patches to mnac80211 and iwlwifi, here is stats
dump.  The tx/rx ampdu and mcs histograms give what I think is a pretty good view into
how the wifi is performing in different scenarios.

# ethtool -S wlan0
NIC statistics:
      rx_packets: 1116301
      rx_bytes: 210234100
      rx_duplicates: 0
      rx_fragments: 565617
      rx_dropped: 1
      tx_packets: 1560
      tx_bytes: 103527
      tx_filtered: 0
      tx_retry_failed: 1
      tx_retries: 139
      sta_state: 4
      txrate: 2882300000
      rxrate: 2268500000
      signal: 220
      signal_beacon: 219
      signal_chains: 56278
      signal_chains_avg: 43990
      channel: 6135
      noise: 18446744073709551615
      ch_time: 18446744073709551615
      ch_time_busy: 18446744073709551615
      ch_time_ext_busy: 18446744073709551615
      ch_time_rx: 18446744073709551615
      ch_time_tx: 18446744073709551615
      tx_pkts_nic: 1559
      tx_bytes_nic: 103417
      rx_pkts_nic: 559239
      rx_bytes_nic: 212001488
      tx_mpdu_attempts: 1699
      tx_mpdu_fail: 1
      tx_mpdu_retry: 139
      txo_tx_mpdu_attempts: 0
      txo_tx_mpdu_fail: 0
      txo_tx_mpdu_retry: 0
      txo_tx_mpdu_ok: 0
      tx_direct_done: 0
      tx_postpone_delay: 0
      tx_postpone_few_bytes: 0
      tx_postpone_bt_prio: 0
      tx_postpone_quiet_period: 0
      tx_postpone_calc_ttak: 0
      tx_fail_internal_x_retry: 0
      tx_fail_short_limit: 0
      tx_fail_long_limit: 1
      tx_fail_underrun: 0
      tx_fail_drain_flow: 0
      tx_fail_rfkill_flush: 0
      tx_fail_life_expire: 0
      tx_fail_dest_ps: 0
      tx_fail_host_aborted: 0
      tx_fail_bt_retry: 0
      tx_fail_sta_invalid: 0
      tx_fail_frag_dropped: 0
      tx_fail_tid_disable: 0
      tx_fail_fifo_flushed: 0
      tx_fail_small_cf_poll: 0
      tx_fail_fw_drop: 0
      tx_fail_color_mismatch: 0
      tx_fail_internal_abort: 0
      tx_fail_unknown_oor: 0
      tx_mode_cck: 0
      tx_mode_ofdm: 7
      tx_mode_ht: 0
      tx_mode_vht: 0
      tx_mode_he: 0
      tx_mode_eht: 1553
      tx_mode_he_su: 1553
      tx_mode_he_ext_su: 0
      tx_mode_he_mu: 0
      tx_mode_he_trig: 0
      tx_ampdu_len:0-1: 3120
      tx_ampdu_len:2-10: 0
      tx_ampdu_len:11-19: 0
      tx_ampdu_len:20-28: 0
      tx_ampdu_len:29-37: 0
      tx_ampdu_len:38-46: 0
      tx_ampdu_len:47-55: 0
      tx_ampdu_len:56-79: 0
      tx_ampdu_len:80-103: 0
      tx_ampdu_len:104-127: 0
      tx_ampdu_len:128-151: 0
      tx_ampdu_len:152-175: 0
      tx_ampdu_len:176-199: 0
      tx_ampdu_len:200-223: 0
      tx_ampdu_len:224-247: 0
      tx_bw_20: 7
      tx_bw_40: 0
      tx_bw_80: 0
      tx_bw_160: 1553
      tx_bw_320: 0
      tx_bw_106_tone: 0
      tx_mcs_0: 7
      tx_mcs_1: 0
      tx_mcs_2: 0
      tx_mcs_3: 17
      tx_mcs_4: 20
      tx_mcs_5: 20
      tx_mcs_6: 20
      tx_mcs_7: 20
      tx_mcs_8: 20
      tx_mcs_9: 20
      tx_mcs_10: 20
      tx_mcs_11: 20
      tx_mcs_12: 39
      tx_mcs_13: 1337
      tx_nss_1: 7
      tx_nss_2: 1553
      rx_crc_err: 0
      rx_fifo_underrun: 0
      rx_failed_decrypt: 0
      rx_dup: 1
      rx_bad_header_len: 0
      rx_mode_cck: 108
      rx_mode_ofdm: 558779
      rx_mode_ht: 0
      rx_mode_vht: 0
      rx_mode_he: 0
      rx_mode_eht: 455
      rx_mode_he_su: 160
      rx_mode_he_ext_su: 0
      rx_mode_he_mu: 295
      rx_mode_he_trig: 0
      rx_bw_20: 558887
      rx_bw_40: 0
      rx_bw_80: 0
      rx_bw_160: 455
      rx_bw_320: 0
      rx_bw_he_ru: 0
      rx_mcs_0: 558887
      rx_mcs_1: 0
      rx_mcs_2: 0
      rx_mcs_3: 0
      rx_mcs_4: 0
      rx_mcs_5: 0
      rx_mcs_6: 0
      rx_mcs_7: 0
      rx_mcs_8: 0
      rx_mcs_9: 0
      rx_mcs_10: 0
      rx_mcs_11: 172
      rx_mcs_12: 260
      rx_mcs_13: 23
      rx_ampdu_len:0-1: 454
      rx_ampdu_len:2-10: 0
      rx_ampdu_len:11-19: 0
      rx_ampdu_len:20-28: 0
      rx_ampdu_len:29-37: 0
      rx_ampdu_len:38-46: 0
      rx_ampdu_len:47-55: 0
      rx_ampdu_len:56-79: 0
      rx_ampdu_len:80-103: 0
      rx_ampdu_len:104-127: 0
      rx_ampdu_len:128-151: 0
      rx_ampdu_len:152-175: 0
      rx_ampdu_len:176-199: 0
      rx_ampdu_len:200-223: 0
      rx_ampdu_len:224-247: 0
      rx_nss_1: 558887
      rx_nss_2: 455

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com