Skip to content

Implement dynamic MCS selection based on signal strength in vWIFI driver #80

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

dingsen-Greenhorn
Copy link
Contributor

This commit enhances the vWIFI driver by implementing dynamic Modulation and Coding Scheme (MCS) selection in the vwifi_get_station function, adjusting the MCS index based on signal strength

After implement dynamic MCS can avoid TX power waste for a bad channel quality

@jserv jserv requested review from jychen0611 and rickywu0421 June 7, 2025 21:44
Copy link
Contributor

@jserv jserv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow the consistent coding style.

Copy link
Collaborator

@jychen0611 jychen0611 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that you are adjusting the MCS based on the current signal strength. However, what if a user wants to set the MCS manually using a command like iw dev wlan0 set bitrates ht-mcs-2.4 <mcs_index>?

To support this, you could consider implementing the set_bitrate_mask() callback in your cfg80211_ops and storing the specified MCS in the corresponding vwifi interface structure.

@dingsen-Greenhorn
Copy link
Contributor Author

It seems that you are adjusting the MCS based on the current signal strength. However, what if a user wants to set the MCS manually using a command like iw dev wlan0 set bitrates ht-mcs-2.4 <mcs_index>?

To support this, you could consider implementing the set_bitrate_mask() callback in your cfg80211_ops and storing the specified MCS in the corresponding vwifi interface structure.

Thanks for you suggestion ,I can try to included the MCS for maunally adjust !

This commit enhances the vWIFI driver by implementing
dynamic Modulation and Coding Scheme (MCS) selection in
the `vwifi_get_station` function, adjusting the MCS index
based on signal strength

After implement dynamic MCS can avoid TX power waste for
a bad channel quality
Implement the set_bitrate_mask callback in cfg80211_ops to support manual
MCS settings using `iw dev <interface> set bitrates ht-mcs-2.4 <mcs_index>`,
addressing reviewer feedback. Store the selected MCS in vwifi_vif->manual_mcs
and track its state with vwifi_vif->manual_mcs_set. Support MCS indices 7, 15,
23, and 31, with validation and logging.

Enable High Throughput (HT) in nf_band_2ghz with MCS 0–31, using
IEEE80211_HT_CAP_SUP_WIDTH_20_40 for 20 MHz compatibility. Fix compilation
errors by initializing rx_mask statically and removing const qualifiers from
channel/rate arrays. Improve vwifi_connect to ensure stable association.

Tested with `iw dev vw1 set bitrates ht-mcs-2.4 15`, achieving MCS 15 at
130.0 MBit/s (bitrate calculation pending refinement to ~52 MBit/s).

Test commands format

$sudo ip netns exec ns1 iw dev vw1 link
$sudo ip netns exec ns1 iw dev vw1 set bitrates ht-mcs-2.4 15 /*(changable 7,15,23,31)*/
$sudo ip netns exec ns1 iw dev vw1 link
Copy link
Collaborator

@jychen0611 jychen0611 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain in more detail how your design handles MCS settings? In particular, the MCS formula.

Also, why is the MCS index constrained to 7, 15, 23 and 31? Please clarify the reasoning behind these limits.

vwifi.c Outdated
@@ -88,6 +88,8 @@ struct vwifi_vif {
struct wireless_dev wdev;
struct net_device *ndev;
struct net_device_stats stats;
int manual_mcs; /* ADDED: Store user-specified MCS */
Copy link
Collaborator

@jychen0611 jychen0611 Jun 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove "ADDED:" prefix from the comment

vwifi.c Outdated
@@ -88,6 +88,8 @@ struct vwifi_vif {
struct wireless_dev wdev;
struct net_device *ndev;
struct net_device_stats stats;
int manual_mcs; /* ADDED: Store user-specified MCS */
bool manual_mcs_set; /* ADDED: Flag to indicate manual MCS override */
Copy link
Collaborator

@jychen0611 jychen0611 Jun 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove "ADDED:" prefix from the comment

vwifi.c Outdated
@@ -1728,13 +1743,8 @@ static int vwifi_start_ap(struct wiphy *wiphy,

/* Initialize hrtimer of beacon */
pr_info("vwifi: init beacon_timer.\n");
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 15, 0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't modify unrelated code segment!
You should align with the latest version of vwifi.

@dingsen-Greenhorn
Copy link
Contributor Author

Can you explain in more detail how your design handles MCS settings? In particular, the MCS formula.

Also, why is the MCS index constrained to 7, 15, 23 and 31? Please clarify the reasoning behind these limits.

First,the code handles MCS selection and modulation assignment, either manually (based on vif->manual_mcs_set and vif->manual_mcs) or automatically (based on signal strength).
Screenshot From 2025-06-09 00-56-25

Second,The vWIFI driver constrains MCS indices to 7, 15, 23, and 31 to simplify rate calculation, testing, and implementation. This avoids the need for a comprehensive calculation of data-rates to handle all 32 MCS indices, varying streams, and channel widths. The chosen indices represent a range of modulations (BPSK to 64-QAM) for 4 streams, supporting both manual (iw commands) and automatic (signal-based) modes. The code’s design prioritizes simplicity for a virtual driver, ensuring functionality (as shown in your test output) while limiting complexity.

And thanks for you thoughtful question,it might be the next PR to optimize it !

@EricccTaiwan
Copy link

Nit: It might be better to squash all the “Fix coding style” commits.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants