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

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

Hi Felix,


On 9/22/2026 3:35 PM, Felix Fietkau wrote:
> Hi Vivek,
> 
> On 20.09.26 18:22, Vivek Chettri wrote:
> 
>> 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.
> 
> I'm not sure that nftables is a good policy storage for SCS/MSCS.
> In my proposal, all accepted SCS descriptors sent to mac80211 are enforced without direct policy override. That is by design, because it is expected by the standard.
> If system policy contradicts SCS descriptors requested by the stations, that's fundamentally an admission problem that needs to be dealt with in user space before descriptors ever reach mac80211, so that the station is told what is accepted and what isn't.
> 

We believe admission control can still be handled through a centralized policy database.
Instead of always giving SCS/MSCS requests higher priority,
administrators could choose whether SCS/MSCS policies or existing system policies take precedence.
This provides flexibility for different deployments.
When policy conflicts occur, the centralized policy layer can make an admission decision before enforcement,
rather than automatically prioritizing SCS/MSCS requests.

Consider a deployment where a station successfully negotiates an SCS stream
for a video application and the corresponding QoS policy is accepted and programmed.
Later, an administrator updates the network policy to de prioritize or block that traffic class,
for example due to congestion, bandwidth quotas, or enterprise policy requirements.

In a centralized policy model, the new administrative policy can be viewed and compared
against the previously accepted SCS policy, the conflict can be detected.
With the SCS policy in mac80211, the admin is not even aware of the policies.
The SCS session can be re-evaluated or torn down as appropriate.
This ensures that policy changes made after SCS admission can still be enforced consistently across the system.

>>>> 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.
> 
> You can claim that, but reading the QSDK implementation of the hostapd/nft integration code gives me the opposite impression.
> 

While the implementation is not particularly complex,
its size is largely driven by the need to implement wrapper APIs
for programming nftables rules via Netlink messages.

Due to licensing constraints, libnftnl cannot be used directly with hostapd,
requiring the use of libmnl and direct construction of Netfilter Netlink messages.

Much of the code therefore consists of standard message encoding and communication
with existing nftables kernel interfaces rather than complex policy or algorithmic logic.

>> 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.
> 
> One aspect this ignores is intra-AP forwarding handled by mac80211.
> 

This should not be a major concern.
In such scenarios, traffic can be forwarded via the bridge using hairpin mode,

In addition, upcoming peer-isolation support introduces per-peer controls for intra-AP forwarding,
either at the mac80211 or bridge layer.
This would allow SCS/MSCS clients to be configured to use bridge-based hairpin forwarding
and for other clients we can still do forwarding from mac80211.

As a result, intra-AP forwarding does not fundamentally alter the architectural considerations discussed here.

The same policy classification, storage, and forwarding mechanisms
can continue to be applied through the common policy framework,
while keeping network-wide policy decisions outside of mac80211.

>>> 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
> 
> Having the driver make DSCP tagging decisions based on connmark seems like a band-aid hack to me. connmark can be used by the user for multiple purposes, including policy related decisions.
> Relying on it in the driver for a specific purpose seems like a bad idea to me.

We understand the concern that connmark is a generic field and may be used for other policy decisions.
However, using conntrack marks for QoS-related state is already an established pattern in the kernel networking stack.

The NET_ACT_CTINFO documentation explicitly states:

▎ "Current actions transfer connmark stored DSCP into ipv4/v6 diffserv and/or to transfer connmark to packet mark.
Both are useful for restoring egress based marks back onto ingress connections for qdisc priority mapping purposes."

This is further reinforced by the upstream commit introducing act_ctinfo (Kevin Darbyshire-Bryant, 2019),
which explains the motivation directly:

▎ "Ingress classification is traditionally a challenging task since iptables rules haven't yet run
and tc filter/eBPF programs are pre-NAT lookups...
Thus marking the connection in some manner on egress for later restoration of classification on ingress is easier to implement."

This indicates that carrying QoS classification information in conntrack state,
and consuming it later for QoS-related decisions, is already an intended and documented use case within the kernel.
Importantly, our proposal does not have the driver read connmark directly.
The connmark → skb->mark translation is performed by an explicit, nftables rule. The driver only consumes skb->mark.
Therefore, the proposal is not introducing a new semantic for connmark,
but leveraging a mechanism that is already used for QoS-related classification and priority handling.

>>     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.
> 
> I also don't see how nft handles MSCS well. It learns per flow from the TID of received uplink frames, with a per station classifier mask, UP bitmap, UP limit, entry timeout and entry limit. How does a dynamic nft set expresses "record the UP of this uplink flow under this station's mask, expire it after this station's timeout, cap it at this station's limit".

Our proposal for MSCS is that mac80211 parses the uplink priority for a client with active
MSCS session, it updates the skb->mark which then updates the conmark in the ingress hook.

Since the mirror flow is part of the same ct,
we can extract the meta data and update for the down link flow as well.

>> 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.
> 
> While I do agree that avoiding duplication is useful, I believe in this case it comes at a cost that makes it seem like a bad trade-off to me.
> The main reason for that is the unhandled gaps and the extra overhead it introduces.
> 
> Gaps:
>  - mac80211 intra-AP forwarding not handled
>  - TC offload API not handled
>  - hw offload depends on abusing existing fields
> 
> Costs:
>  - mandatory conntrack
>  - mandatory extra packet filter table
>  - complexity of translating standard mandated behavior into nft rulesets, which do not always align well.
>  - extra subsystem dependency
> 
>>> 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/
> 
> So you're saying we should force user space away from existing actively used offload APIs because they don't fit into your design?
> 

The goal is not to replace or discourage existing offload APIs.
The bridge offload solutions based on tc flower that you mentioned
can continue to be used where they already fit the deployment needs.
The point is that, for SCS/MSCS policy enforcement and offload,
using a common framework such as nftables across both bridged and routed traffic
may provide a single policy store and a consistent programming model.

This is not a requirement. Vendors can choose the approach that best fits their architecture and offload capabilities.
Some may continue using separate bridge and routing mechanisms, while others may prefer a unified framework.
Our proposed approach remains compatible with existing offload mechanisms for two reasons:
1. The egress path is already part of the transmit flow, where SCS policy matching can be performed
   and the resulting QoS state encoded in conntrack metadata.
2. Hardware offload continues to use the standard ndo offload APIs,
   allowing drivers to extract the required QoS information without introducing new offload interfaces.

Following are the high level view of the flows for pure SW, nft flowtable offload(Bridging/Routing/NAT)

1. Software Flow


                                                │
                                                │
                                                │
                                                │1. Packets of flow
                                                │
      ┌────────────┐  ┌────────────┐   ┌────────▼────────┐  2. Initial packet, set conmark
      │  ingress   │  │  forward   │   │     egress      │  Subsequent packets, skb->mark = conmark
      └────────────┘  └────────────┘   └────┬────────────┘
                                            │
                                            │                       netfilter
  ──────────────────────────────────────────┼────────────────────────────────────
                                            │                       mac80211
                                   ┌────────▼──────────┐                +
                                   │      mac80211     │          vendor driver
                                   └────────┬──────────┘
                                            │
                                   ┌────────▼──────────┐
                                   │   vendor driver   │
                                   └───────────────────┘
                                   3. Use skb mark data,
                                      program the HW descriptors



2. nft flowtable offload flow


                    │  1. flowtable rules created
                    │      (Bridged/Routed Flows)
                    │
              ┌─────▼──────┐
              │    nft     │
              └─────┬──────┘
       userspace    │
       ─────────────┼──────────────────────────────────────────────────────────────────────────────
       kernel       │
                    │                             │                            │
                    │                             │                            │
                    │                             │                            │
                    │                             │ 5. Flow state              │3. Inital packets of flow
  2. ndo_tc_setup   │                             │    CT ESTABLISHED          │
                    │       ┌────────────┐ ┌──────▼─────┐             ┌────────▼────────┐
                    │       │  ingress   │ │  forward   │             │   egress        │  4. Initial packet, set conmark
                    │       └────────────┘ └──────┬─────┘             └─────────────────┘
                    │                             │ 6. flow_block_cb
                    │                             │    (flow data)
                    │                             │
                    │                             │
                    │                             │
                    │                             │                                               netfilter
                  ──┼─────────────────────────────┼────────────────────────────────────────────────────────────
                    │                             │                                               mac80211
           ┌────────▼───────────┐       ┌─────────▼─────────┐                                         +
           │      mac80211      │       │   vendor driver   │                                   vendor driver
           └────────────────────┘       └───────────────────┘
                                         7. Use con mark QoS data
                                            program the HW


>>> 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.
> 
> Will do. I need to post RFC v2 of this series first though.
> 
> Thanks,
> 
> - Felix