Hi,

(With my cfg80211/mac80211 maintainer hat on)

			2.1.3 - QoS Provisioning
			-------------------------

				Hostapd extracts the QoS parameters from SCS/MSCS request, and
				sends the parameters via NL80211 command (NL80211_CMD_QOS_MGMT).

Do you have any idea yet what that would entail? I'm thinking it would
also need add/remove, perhaps, and some kind of lifetime tracking on the
station?

			2.1.4 - Networking Provisioning
			-------------------------------
				Hostapd if required and as indicated by the WLAN driver
				capabilities, would add rules in the netfilter subsystem
				via libnftables, such that flows matching the TCLAS
				parameters are marked with certain meta data using skb->mark
				to assist in prioritization in the MSDU processing in the WLAN
				driver data path.

				In MSCS, hostapd will receive the Rx flow tuple from WLAN
				driver using NL80211 command (NL80211_CMD_QOS_MGMT) and then
				make a decision to install an nftable rule in the netfilter
				subsystem based on MSCS parameters exchanged
				during handshake.

				The WLAN driver will be responsible for classifying the
				new flow received and parse the tuple information from the MSDU
				and use the framework to send event to hostapd. For
				identifying a new flow, the WLAN driver can make use of
				any HW offload assist features it supports, as maintaining
				flow information in software on a per-packet basis will be
				expensive for flow classification.

How would the classification propagate through the layers?

		(B) cfg80211
		-------------

			The cfg80211 layer receives the  NL(NL80211_CMD_QOS_MGMT), parses
			the parameters and passes further down into the mac80211 layer.

		(C) mac80211
		-------------

			The mac80211 calls into the WLAN driver with the QoS and
			networking parameters.

		(D) WLAN driver
		-----------------

			The WLAN driver receives the QoS characteristics and the
			TCLAS elements and can do the required resource allocation and
			the Firmware(FW)/Hardware(HW) programming based on the underlying HW
			capabilities.

Without really going into the actual implementation, structurally, what
would this contain? And architecturally, is it really just one set of
parameters? It would seem to be more specific, like for a given station?

	2.3 - Data Path (MSCS/SCS) - done at WLAN driver
	--------------------------------------------------
                                           3. Hostapd provisions the rule to NFT
                     ┌─────────────────────────────────┐
                     │                                 │ N/W provisioning
                     │           hostapd    ┌─────────┐┼────────────────────────┐
                     │                      │libnftnl ││                        │
                     └──────────────────────└──▲──────┘┘                        │
     user space                                │                                │
            ───────────────────────────────────┼────────────────                │
                    ┌──────────────────────────┼─────────┐                      │
                    │                          │         │ 4.                   │
     kernel space   │ ┌────────────────────────┴──────┐  │ NFT updates skb->mark│
                    │ │        nl80211/cfg80211       │  │ while adding the rule│
                    │ │                               │  │   ┌──────────────────┼──┐
                    │ └────────────────────────▲──────┘  │   │                  │  │
                    │                          │         │   │                  │  │
                    │ ┌────────────────────────┼──────┐  │   │  Linux N/W stack │  │
                    │ │           mac80211            ◄──┼───┼                  │  │
                    │ │                               │  │   │       ┌──────────▼─┐│
                    │ └───┬────────────────────▲──────┘  │   │       │netfilter   ││
5. The DL packet    │     │                    │         │   └───────└────────────┘┘
 comes with         │ ┌───▼────────────────────┼──────┐  │
 skb->mark          │ │                               │  │
 which is used      │ │                               │  │
 for classification │ │           WLAN drv            │  │2.
 along with         │ │                               │  │Driver then programs the rule to hostapd
 stored QoS         │ │                               │  │using NL80211
 params at the      │ │                               │  │
 driver             │ │                               │  │1.
                    │ └───┬────────────────────▲──────┘  │For MSCS flows, driver learns a new rx flow
                    │     │                    │         │using HW assist
                    └─────┼────────────────────┼─────────┘
                    ┌─────▼────────────────────┼─────────┐
                    │                                    │
                    │            Hardware                │
                    │                                    │
                    └────────────────────────────────────┘

Terminology wise, "driver then programs the rule to hostapd" seems ...
confusing. It's more like "notifies hostapd of the new flow" or so?

		* The Datapath decision making logic for the QoS features
		would be handled in the WLAN driver.

What decision making logic is even in the datapath?

		* In MSCS, Driver will be responsible to track all the uplink flows
		for a non-AP STA with MSCS session, based on
		TCLAS mask and should prioritize the corresponding downlink flows.

		* For prioritization in DL for MSCS, the driver should notify hostapd
		using NL80211 framework (via mac80211, cfg80211) to program the
		netfilter rules, when a new Rx uplink flow is received.

Here I don't follow - I can see how uplink needs the driver to
parse/classify the flow and tell hostapd about the mark or so, but on DL
the whole thing starts at higher layers, no?

		* As mentioned in Section 2.1.4., In MSCS  hostapd receives the
		Rx flow tuple from the driver via NL80211_CMD_QOS_MGMT,
		then decides whether to install an nftables rule in netfilter
		based on MSCS handshake parameters.

For an uplink flow, I'm not even sure what netfilter rules need to be
there be at all? Once a packet is received, it's effectively game over
for classification / air competition / etc. no?

johannes