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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Ben Greear <[email protected]> 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
On 10/3/23 10:06 PM, Kalle Valo wrote:
> Ben Greear <[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Wed, 2023-10-04 at 06:19 -0700, Ben Greear wrote:
> On 10/3/23 10:06 PM, Kalle Valo wrote:
> > Ben Greear <[email protected]> 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
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 <[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com