Re: [RFC PATCH 00/15] wifi: SCS and MSCS

[Felix Fietkau <nbd@nbd.name>]

Hi Vivek,

On 13.09.26 21:23, Vivek Chettri wrote:

> The preference for reusing existing packet-classification infrastructure is driven by the need to have a centralized policy management and policy framework that operates across both software and hardware-offloaded forwarding paths, rather than introducing a separate classifier within the WLAN stack.
> 
> 1. Centralized QoS and Policy Management
> 
>     A centralized policy management framework provides the following advantages:
> 
>     • A centralized policy database enables end-to-end QoS policy enforcement across
>       different forwarding paths, improving manageability and policy visibility
>       throughout the system.
> 
>     • SCS/MSCS policies represent only one source of policy management.
>       Administrators may also configure firewall, QoS, or other policies that must
>       coexist with negotiated WLAN policies.
> 
>     • Centralized policy management provides clear visibility into the interaction
>       between administrator-defined policies and dynamically negotiated SCS/MSCS
>       policies, making conflicts easier to detect and manage.
> 
>     • Implementing packet prioritization independently within mac80211 can introduce
>       policy conflicts or ambiguous precedence when administrator-defined QoS
>       policies overlap with SCS/MSCS-derived priorities.
> 
>     • A common policy framework helps ensure consistent behavior across software
>       forwarding, bridging, routing, and hardware-offloaded data paths.

I don't think any of this really conflicts with my proposal.
A full end-to-end policy framework seems out of scope for direct 
implementation in hostapd anyway, so it should be an external component. 
hostapd should allow deferring management and policy decisions of 
client-requested SCS/MSCS exchanges to external components anyway to 
support things like EasyMesh well.

Having this separation would help if you intend to push flow 
classification for things like wired upstream links, which hostapd 
should not worry about at all.

In such a scenario, a custom implementation could choose to omit passing 
full classifiers to mac80211.
That said, for most common use cases, including standalone APs and 
simpler EasyMesh implementations, I believe that using the mac80211 
support that I added is the right choice due to the lower complexity and 
overhead.

> 2. Policy Framework: Considerations and Challenges
> 
>     A policy framework should help ensure consistent behavior across software
>     forwarding, bridging, routing, and hardware-offloaded data paths.
> 
>     The policy framework can be realized using either nftables or tc-flower.
>     Both approaches provide a persistent and centralized repository for traffic
>     classification and policy enforcement, but differ in integration complexity,
>     feature scope, and deployment model.
> 
>     Common Capabilities: nftables and tc-flower
> 
>     • Both nftables and tc-flower maintain centralized rule databases for traffic
>       classification and policy enforcement.
> 
>     • For software-forwarded traffic, both solutions require flow lookups against
>       installed rules and therefore have broadly comparable classification
>       overhead.
> 
>     • Both mechanisms can serve as the policy enforcement layer for
>       SCS/MSCS-derived traffic policies.
> 
>     Advantages of nftables
> 
>     • nftables provides a unified framework for firewalling, traffic
>       classification, and QoS policy marking.
> 
>     • nftables can support both software and hardware-accelerated forwarding
>       paths and can be extended to additional offload scenarios with minimal
>       architectural changes.
> 
>     • Existing support for nftables-based policy handling in hostapd reduces
>       integration effort and leverages infrastructure that is already available
>       and upstream-ready.
> 
>       The implementation is done using libmnl, which avoids licensing
>       incompatibility between hostapd (BSD-3-Clause) and libnftnl (GPLv2).
>       This approach was also reviewed with Jouni.
> 
>     • Using nftables allows SCS/MSCS policies to be integrated into a broader,
>       system-wide policy framework rather than introducing a WLAN-specific
>       policy engine.
> 
>     • Using nftables can also facilitate scalability by allowing these rules to
>       be applied at software acceleration decision-making stages. For example,
>       the NFT rule can be cleanly integrated into NFT flow tables as well.
> 
>     Challenges with a tc-flower-based Approach
> 
>     • A tc-flower solution would require substantial additional implementation
>       for rule programming from hostapd.
> 
>     • tc-flower typically requires qdisc configuration (at a minimum, a clsact
>       pseudo qdisc) before classification rules can be installed and enforced.

Most of these points are very abstract and in my opinion gloss over a 
lot of implementation complexity. I'd argue that just because nftables 
is used to enable offloading in some setups doesn't mean that it handles 
the different policy aspects of SCS and especially MSCS well, or 
provides good ways to deal with runtime changes to existing flows.

I get the impression that your proposal is designed to handle the needs 
of a single Qualcomm implementation of an out-of-tree policy framework 
service well, while neglecting in-tree kernel offload mechanisms, as 
well as standalone AP implementations by pushing extra complexity there.

Let me give you a specific example. On OpenWrt, Ethernet -> WLAN bridge 
hw flow acceleration works by having a user space daemon that replicates 
the bridge state, measures L2 flows via eBPF and programs no-sw 
tc-flower offload rules for L2 flows.
On the MTK driver side, the offload core uses the programmed L2 rules to 
trigger actual hw forwarding.
Only for routing/NAT flow offload does nftables get used.
The kernel side is fully implemented in upstream kernels without any 
out-of-tree subsystems.

The forwarding from Ethernet to WLAN works because the kernel code can 
resolve the hardware path via dev_fill_forward_path and query the 
relevant metadata (which happens by calling into the WLAN driver through 
mac80211).

In the series that I've built on top of this one (but not yet posted), 
the offload core driver can additionally query the classifier result for 
a flow at the point where it enables actual offloading (the trigger is 
PPS threshold exceeded). This works because mac80211 has the active 
classifiers, allowing the WLAN driver to provide them to the offload 
core driver.

This design allows transparently respecting the SCS/MSCS classifier for 
hw offloaded flows regardless of which API was used to trigger offload 
(tc or nftables).
Additionally, the user space components handling the offload for both 
approches do not have to worry about SCS/MSCS in any way.

I don't see how your hostapd programmed nftables rules approach would 
handle the same properly.

> 3. Summary
> 
>     • The primary role of SCS/MSCS handling within the WLAN subsystem should be
>       to negotiate and manage QoS policies between the AP and STA.
> 
>     • Packet classification and policy enforcement should be delegated to a
>       centralized policy framework such as nftables, which is already designed
>       to manage system-wide traffic policies.
> 
>     • The WLAN driver remains responsible for mapping classified traffic to the
>       appropriate transmission priorities and ensuring the negotiated QoS
>       behavior is achieved across the data path.
> 
> Also, what is the plan for supporting repeaters and backend devices?

Not sure what you mean by backend devices. For repeaters I would use a 
software component (preferably outside of hostapd/wpa_supplicant but 
interacting with both), which acts as a repeater for SCS policies 
requested by local clients (pushing them to the upstream AP) and tells 
hostapd to install local descriptors where local classification is needed.
If you have concerns about specific scenarios, please describe them to me.

Thanks,

- Felix