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

[Vivek Chettri <vivek.chettri@oss.qualcomm.com>]

Hi Felix,


On 9/14/2026 2:49 AM, Felix Fietkau wrote:
> 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.

The proposal is not to implement a full policy framework in hostapd.

Following is the functionality split:

Hostapd:
	Primarily responsible for SCS/MSCS protocol handling.
	Processing of the protocol descriptors ie TCLAS and QoS elements.
	Programming an existing kernel policy framework such as nftable.

Nftables:
	Policy storage.
	Classification.
	Packet marking along with offload enablement.

> 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.
> 

I agree that policy decisions can be delegated to external components for Easy
Mesh use cases, and I don't see a fundamental conflict there.

While the mac80211-centric approach is looking attractive for simpler
deployments, we should consider an approach that scales across varied use cases.

In deployments where SCS/MSCS, administrator-defined QoS policies (DSCP), and
hardware offload mechanisms coexist,having a central source for classification
can help as follows
	1. Avoid duplication of policy framework
	2. Simplify policy interaction, conflict resolution
	3. Consistent enforcement across different forwarding paths.

>> 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 agree that implementation complexity and runtime updates are important
considerations. For SCS/MSCS cases, nftables address the highlighted concerns
in following ways

Complexity: not a concern
  - Linux Kernel NFT Infra provides well defined APIs to program policies
which satisfies present use cases and does not add much implementation
complexity or overhead.

Runtime: supported
 - These APIs indeed having support for runtime modifications as per SCS/MSCS
protocol requirements.

Offload cases: supported seamlessly
 - nftables is already used as a general policy and classification framework
for both software-forwarded and software/hardware-offloaded traffic.

Protocol classifiers: all mandatory variations supported
 - The classifiers required mandatorily by SCS/MSCS, including cases such as
TCLAS Type 10 (ESP/SPI Based rules), are supported with nftables.

> 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.
> 

The nft based proposal is neither Qualcomm-specific nor based on out-of-tree
policy framework.

Qualcomm's approach using nftables works for systems with no offload, software
offload, or hardware offload by leveraging existing upstream infrastructure as
follows.

	1. SCS policies programmed by hostapd are part of the net filter egress hook
which maintains classifier info along with QoS identifier (nfttable rule->mark).

	2. Mark field part of the nftable gets populated into connmark of the ct
during connection establishment.

	3. The connmark information that is populated at the egress hook can be used
for HW offload programming by the vendor driver

	4. As the SCS policies are added at egress hook this would seamlessly work
even when software offload(nft flow table) is enabled

SCS/MSCS would simply act as a policy producer, while classification and
enforcement remain within common in-tree mechanisms.

The goal was not to push Qualcomm out-of tree implementation, but to have a
solution using existing in-tree kernel mechanisms
	1. Avoids Duplication of the same coming at mac80211
	2. Reduces system complexity with centralization.

Qualcomm offload mechanism can work with policy data base built at mac80211
also; however what we wanted to explore was avoiding non 802.11 network-wide
policy and classification decisions within mac80211. This helps prevent the
creation of a parallel policy framework and keeps mac80211 focused on Wi-Fi-
specific functionality and concepts.

> 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).
> 

Thanks for the example.

If both traffic types (bridged and routed) ultimately require policy
classification and offload decisions, having a common framework could provide
a single policy repository and a consistent programming model across all
forwarding paths.

Referring to the following article, can nftables be considered for bridge
offload as well?

https://lwn.net/Articles/1082320/

> 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.
> 

If possible, could you share the patches (or a draft branch) for the series
you mentioned?

We would be interested in reviewing the end-to-end architecture and
understanding how it integrates with the existing tc and nftables offload
paths separately.

> 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

Thanks!
Vivek.