All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC 0/3] Add new data path for ethernet frame format
@ 2016-12-15  6:00 Vasanthakumar Thiagarajan
  2016-12-15  6:00 ` [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload Vasanthakumar Thiagarajan
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Vasanthakumar Thiagarajan @ 2016-12-15  6:00 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Vasanthakumar Thiagarajan

This patch set adds a new data path to offload 802.11 header
encap/decap to driver or hardware. Drivers having support
for ieee80211 header encap/decap and other offload functionalities
which can't be done before encap or after decap can make use of
this new data path. Currently it is implemented for STA and AP
interface type, this can be extend other interface types like
adhoc.  

With ath10k driver changes using this new Tx/Rx path, 10 - 15%
CPU usage and upto ~20Mbps TCP performance improvements are
observed with this ethernet data path. This patch set is
prepared on a older mac80211 code base on top of
commit 7d27a0ba7adc ("cfg80211: Add mesh peer AID setting API").
Sorry, I could not get a chance to rework it on top of latest
mac80211 code base.

TODO (from initial review):

	- Consider ieee8011 header and cipher header size also while updating tx/rx stats for
	  ethernet frame format.
	- Any optimization to reduce the amount of code change.
	- Improve commit log and doc

Vasanthakumar Thiagarajan (3):
  mac80211: Add provision for 802.11 encap/decap offload
  mac80211: Implement data xmit for 802.11 encap offload
  mac80211: Add receive path for ethernet frame format

 include/net/mac80211.h     |  68 +++++++++++++-
 net/mac80211/cfg.c         |   8 ++
 net/mac80211/debugfs.c     |   1 +
 net/mac80211/driver-ops.h  |  21 +++++
 net/mac80211/ieee80211_i.h |  12 +++
 net/mac80211/iface.c       | 147 +++++++++++++++++++++++++++++
 net/mac80211/key.c         |  16 +++-
 net/mac80211/main.c        |   7 ++
 net/mac80211/rx.c          | 189 ++++++++++++++++++++++++++++++++++++-
 net/mac80211/status.c      |  83 ++++++++++++++++-
 net/mac80211/trace.h       |  33 +++++++
 net/mac80211/tx.c          | 225 ++++++++++++++++++++++++++++++++++++++++++++-
 12 files changed, 800 insertions(+), 10 deletions(-)

-- 
1.9.1

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload
  2016-12-15  6:00 [RFC 0/3] Add new data path for ethernet frame format Vasanthakumar Thiagarajan
@ 2016-12-15  6:00 ` Vasanthakumar Thiagarajan
  2016-12-15  9:16   ` Johannes Berg
  2016-12-15  6:00 ` [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload Vasanthakumar Thiagarajan
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 21+ messages in thread
From: Vasanthakumar Thiagarajan @ 2016-12-15  6:00 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Vasanthakumar Thiagarajan

Drivers can have the capability to offload 802.11 encap/decap
to firmware or hardware for data frames. This patch adds a new
hw_flag for driver to advertise the offload support. Drivers
advertising the support have also to implement new ieee80211_ops
callback, get_vif_80211_hdr_offload(), to notify if the 802.11 encap/decap
offload is supported for a particular vif type. Transmit and receive
path offloading 802.11 header (including cipher headers) encap/decap
for data frames will be implemented in separate patches.

Drivers advertising this capability should also implement other
functionalities which deal with 802.11 frame format like below

	- Hardware encryption/Decryption
	- ADDBA/DELBA offload
	- Aggregation and deaggregation of A-MSDU offload
	- Fragmentation and defragmentation offload
	- Rx reordering of A-MPDU subframe offload
	- PN/TSC check offload
	- Rx duplication check offload
	- Hardware rate control
	- Powersave offload

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
---
 include/net/mac80211.h    | 16 ++++++++++++++++
 net/mac80211/debugfs.c    |  1 +
 net/mac80211/driver-ops.h | 21 +++++++++++++++++++++
 net/mac80211/main.c       |  4 ++++
 net/mac80211/trace.h      | 33 +++++++++++++++++++++++++++++++++
 5 files changed, 75 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index b4faadb..1e3c8b5 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2014,6 +2014,11 @@ struct ieee80211_txq {
  * @IEEE80211_HW_TX_FRAG_LIST: Hardware (or driver) supports sending frag_list
  *	skbs, needed for zero-copy software A-MSDU.
  *
+ * @IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP: Hardware/driver supports 802.11
+ *	encap/decap for data frames. Supporting driver have to implement
+ *	get_vif_80211_encap_decap_offload() to pass if 802.11 encap/decap
+ *	offload	is supported for the vif.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2054,6 +2059,7 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_USES_RSS,
 	IEEE80211_HW_TX_AMSDU,
 	IEEE80211_HW_TX_FRAG_LIST,
+	IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP,
 
 	/* keep last, obviously */
 	NUM_IEEE80211_HW_FLAGS
@@ -3401,6 +3407,12 @@ enum ieee80211_reconfig_type {
  *	synchronization which is needed in case driver has in its RSS queues
  *	pending frames that were received prior to the control path action
  *	currently taken (e.g. disassociation) but are not processed yet.
+ *
+ * @get_vif_80211_hdr_offload: Called to check if driver or hardware
+ *	supports 802.11 encap/decap offload for data frames for the vif.
+ *	Drivers implementing this callback should advertise the support
+ *	through hw_flags (%IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP).
+ *	This callback can sleep.
  */
 struct ieee80211_ops {
 	void (*tx)(struct ieee80211_hw *hw,
@@ -3639,6 +3651,10 @@ struct ieee80211_ops {
 	void (*wake_tx_queue)(struct ieee80211_hw *hw,
 			      struct ieee80211_txq *txq);
 	void (*sync_rx_queues)(struct ieee80211_hw *hw);
+
+	int (*get_vif_80211_hdr_offload)(struct ieee80211_hw *hw,
+					 struct ieee80211_vif *vif,
+					 bool is_4addr, bool *supported);
 };
 
 /**
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 2906c10..f49fea5 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -302,6 +302,7 @@ static const char *hw_flag_names[] = {
 	FLAG(USES_RSS),
 	FLAG(TX_AMSDU),
 	FLAG(TX_FRAG_LIST),
+	FLAG(SUPPORTS_80211_ENCAP_DECAP),
 #undef FLAG
 };
 
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 184473c..22847d2 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1179,4 +1179,25 @@ static inline void drv_wake_tx_queue(struct ieee80211_local *local,
 	local->ops->wake_tx_queue(&local->hw, &txq->txq);
 }
 
+static inline int
+drv_get_vif_80211_hdr_offload(struct ieee80211_local *local,
+			      struct ieee80211_sub_if_data *sdata,
+			      bool use_4addr, bool *supported)
+{
+	int ret = -EOPNOTSUPP;
+
+	might_sleep();
+
+	if (local->ops->get_vif_80211_hdr_offload)
+		ret = local->ops->get_vif_80211_hdr_offload(&local->hw,
+							    &sdata->vif,
+							    use_4addr,
+							    supported);
+
+	trace_drv_get_vif_80211_hdr_offload(local, sdata, use_4addr,
+					    *supported, ret);
+
+	return ret;
+}
+
 #endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index d00ea9b..2095d7c 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -818,6 +818,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 	     !local->ops->tdls_recv_channel_switch))
 		return -EOPNOTSUPP;
 
+	if (ieee80211_hw_check(hw, SUPPORTS_80211_ENCAP_DECAP) &&
+	    !local->ops->get_vif_80211_hdr_offload)
+		return -EINVAL;
+
 #ifdef CONFIG_PM
 	if (hw->wiphy->wowlan && (!local->ops->suspend || !local->ops->resume))
 		return -EINVAL;
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 77e4c53..aa4a2cd 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -2415,6 +2415,39 @@ TRACE_EVENT(drv_wake_tx_queue,
 	)
 );
 
+TRACE_EVENT(drv_get_vif_80211_hdr_offload,
+	TP_PROTO(struct ieee80211_local *local,
+		 struct ieee80211_sub_if_data *sdata,
+		 bool use_4addr,
+		 bool supported,
+		 int ret),
+
+	TP_ARGS(local, sdata, use_4addr, supported, ret),
+
+	TP_STRUCT__entry(
+		LOCAL_ENTRY
+		VIF_ENTRY
+		__field(bool, use_4addr)
+		__field(bool, supported)
+		__field(int, ret)
+	),
+
+	TP_fast_assign(
+		LOCAL_ASSIGN;
+		VIF_ASSIGN;
+		__entry->use_4addr = use_4addr;
+		__entry->supported = supported;
+		__entry->ret = ret;
+	),
+
+	TP_printk(
+		LOCAL_PR_FMT  VIF_PR_FMT " use_4addr:%d"
+		" 802.11 header offload supported%d ret:%d", LOCAL_PR_ARG,
+		VIF_PR_ARG, __entry->use_4addr, __entry->supported,
+		__entry->ret
+	)
+);
+
 #endif /* !__MAC80211_DRIVER_TRACE || TRACE_HEADER_MULTI_READ */
 
 #undef TRACE_INCLUDE_PATH
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-15  6:00 [RFC 0/3] Add new data path for ethernet frame format Vasanthakumar Thiagarajan
  2016-12-15  6:00 ` [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload Vasanthakumar Thiagarajan
@ 2016-12-15  6:00 ` Vasanthakumar Thiagarajan
  2016-12-15  9:29   ` Johannes Berg
  2016-12-15  6:00 ` [RFC 3/3] mac80211: Add receive path for ethernet frame format Vasanthakumar Thiagarajan
  2016-12-15  9:08 ` [RFC 0/3] Add new data " Johannes Berg
  3 siblings, 1 reply; 21+ messages in thread
From: Vasanthakumar Thiagarajan @ 2016-12-15  6:00 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Vasanthakumar Thiagarajan

Driver (or hw) supporting 802.11 encapsulation offload
for data frames can make use of this new xmit path.

This patch defines new ndo_ops, all these callbacks are same as
ieee80211_dataif_ops other than ndo_start_xmit() which does
minimal processing leaving 802.11 encap related to driver.
This patch makes netdev_ops registration dynamic based on the
interface type, at any time the netdev_ops of netdev will be
assigned to either the ndo_ops defined to do 802.11 encap or
the ones defined for 802.11 encap offload. There is a new hw
config notification, IEEE80211_CONF_CHANGE_80211_HDR_OFFL, to make
the driver aware of any configuration change in 802.11 encap/decap
offload.

There is a field, no_80211_encap, added to ieee80211_tx_info:control
to mark if the 802.11 encapsulation is offloaded to driver.
There is also a new callback for tx completion status indication
to handle data frames using 802.11 encap offload. Currently ath10k
fw is capable of doing 802.11 encapsulation/decapsulationi offload.
With the corresponding driver changes, using 802.11 encap/decap offload
might improve performance.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
---
 include/net/mac80211.h     |  33 ++++++-
 net/mac80211/cfg.c         |   8 ++
 net/mac80211/ieee80211_i.h |  12 +++
 net/mac80211/iface.c       | 147 +++++++++++++++++++++++++++++
 net/mac80211/key.c         |  16 +++-
 net/mac80211/main.c        |   3 +
 net/mac80211/status.c      |  83 ++++++++++++++++-
 net/mac80211/tx.c          | 225 ++++++++++++++++++++++++++++++++++++++++++++-
 8 files changed, 519 insertions(+), 8 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 1e3c8b5..225abaa 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -910,7 +910,12 @@ struct ieee80211_tx_info {
 			};
 			struct ieee80211_key_conf *hw_key;
 			u32 flags;
-			/* 4 bytes free */
+			/* XXX: This frame is not encaptulated with 802.11
+			 * header. Should this be added to %IEEE80211_TX_CTRL_*
+			 * flags?.
+			 */
+			bool no_80211_encap;
+			/* 3 bytes free */
 		} control;
 		struct {
 			u64 cookie;
@@ -1269,6 +1274,8 @@ enum ieee80211_conf_flags {
  * @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
  *	Note that this is only valid if channel contexts are not used,
  *	otherwise each channel context has the number of chains listed.
+ * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
+ *	implementing 802.11 encap/decap for data frames changed.
  */
 enum ieee80211_conf_changed {
 	IEEE80211_CONF_CHANGE_SMPS		= BIT(1),
@@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
 	IEEE80211_CONF_CHANGE_CHANNEL		= BIT(6),
 	IEEE80211_CONF_CHANGE_RETRY_LIMITS	= BIT(7),
 	IEEE80211_CONF_CHANGE_IDLE		= BIT(8),
+	IEEE80211_CONF_CHANGE_80211_HDR_OFFL	= BIT(9),
 };
 
 /**
@@ -1333,6 +1341,9 @@ enum ieee80211_smps_mode {
  *	configured for an HT channel.
  *	Note that this is only valid if channel contexts are not used,
  *	otherwise each channel context has the number of chains listed.
+ *
+ * @encap_decap_80211_offloaded: Whether 802.11 header encap/decap offload
+ *	is enabled
  */
 struct ieee80211_conf {
 	u32 flags;
@@ -1346,6 +1357,7 @@ struct ieee80211_conf {
 	struct cfg80211_chan_def chandef;
 	bool radar_enabled;
 	enum ieee80211_smps_mode smps_mode;
+	bool encap_decap_80211_offloaded;
 };
 
 /**
@@ -4178,6 +4190,25 @@ void ieee80211_tx_status_irqsafe(struct ieee80211_hw *hw,
 				 struct sk_buff *skb);
 
 /**
+ * ieee80211_tx_status_8023 - transmit status callback for 802.3 frame format
+ *
+ * Call this function for all transmitted data frames after their transmit
+ * completion. This callback should only be called for data frames which
+ * are are using driver's (or hardware's) offload capability of encap/decap
+ * 802.11 frames.
+ *
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other.
+ *
+ * @hw: the hardware the frame was transmitted by
+ * @vif: the interface for which the frame was transmitted
+ * @skb: the frame that was transmitted, owned by mac80211 after this call
+ */
+void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
+			      struct ieee80211_vif *vif,
+			      struct sk_buff *skb);
+
+/**
  * ieee80211_report_low_ack - report non-responding station
  *
  * When operating in AP-mode, call this function to report a non-responding
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 47e99ab8..0e53873 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -107,6 +107,10 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
 		}
 	}
 
+	ieee80211_if_check_80211_hdr_offl(sdata,
+					  params ? params->use_4addr : false,
+					  true);
+
 	return 0;
 }
 
@@ -2116,6 +2120,10 @@ static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
 	if (changed & WIPHY_PARAM_FRAG_THRESHOLD) {
 		ieee80211_check_fast_xmit_all(local);
 
+		if (!local->ops->set_frag_threshold &&
+		    local->data_80211_hdr_offloaded)
+			return -EINVAL;
+
 		err = drv_set_frag_threshold(local, wiphy->frag_threshold);
 
 		if (err) {
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index f56d342..8d6abad 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1373,6 +1373,8 @@ struct ieee80211_local {
 	/* TDLS channel switch */
 	struct work_struct tdls_chsw_work;
 	struct sk_buff_head skb_queue_tdls_chsw;
+
+	bool data_80211_hdr_offloaded;
 };
 
 static inline struct ieee80211_sub_if_data *
@@ -1641,6 +1643,10 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
 		     struct vif_params *params);
 int ieee80211_if_change_type(struct ieee80211_sub_if_data *sdata,
 			     enum nl80211_iftype type);
+void ieee80211_if_check_80211_hdr_offl(struct ieee80211_sub_if_data *sdata,
+				       bool use_4addr, bool add);
+void ieee80211_if_config_80211_hdr_offl(struct ieee80211_local *local,
+					bool enable_80211_hdr_offload);
 void ieee80211_if_remove(struct ieee80211_sub_if_data *sdata);
 void ieee80211_remove_interfaces(struct ieee80211_local *local);
 u32 ieee80211_idle_off(struct ieee80211_local *local);
@@ -1668,6 +1674,8 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 					 struct net_device *dev);
 netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
 				       struct net_device *dev);
+netdev_tx_t ieee80211_subif_8023_start_xmit(struct sk_buff *skb,
+					    struct net_device *dev);
 void __ieee80211_subif_start_xmit(struct sk_buff *skb,
 				  struct net_device *dev,
 				  u32 info_flags);
@@ -1822,6 +1830,10 @@ void __ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
 				 struct sk_buff *skb, int tid,
 				 enum nl80211_band band);
 
+int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
+			    struct sk_buff *skb,
+			    struct sta_info **sta_out);
+
 static inline void
 ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
 			  struct sk_buff *skb, int tid,
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index b123a9e..d5f6649 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -698,6 +698,11 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 		rcu_assign_pointer(local->p2p_sdata, sdata);
 	}
 
+	if (local->open_count == 0 && local->data_80211_hdr_offloaded) {
+		local->hw.conf.encap_decap_80211_offloaded = true;
+		hw_reconf_flags |= IEEE80211_CONF_CHANGE_80211_HDR_OFFL;
+	}
+
 	/*
 	 * set_multicast_list will be invoked by the networking core
 	 * which will check whether any increments here were done in
@@ -1148,6 +1153,18 @@ static const struct net_device_ops ieee80211_dataif_ops = {
 	.ndo_get_stats64	= ieee80211_get_stats64,
 };
 
+static const struct net_device_ops ieee80211_dataif_8023_ops = {
+	.ndo_open		= ieee80211_open,
+	.ndo_stop		= ieee80211_stop,
+	.ndo_uninit		= ieee80211_uninit,
+	.ndo_start_xmit		= ieee80211_subif_8023_start_xmit,
+	.ndo_set_rx_mode	= ieee80211_set_multicast_list,
+	.ndo_change_mtu		= ieee80211_change_mtu,
+	.ndo_set_mac_address	= ieee80211_change_mac,
+	.ndo_select_queue	= ieee80211_netdev_select_queue,
+	.ndo_get_stats64	= ieee80211_get_stats64,
+};
+
 static u16 ieee80211_monitor_select_queue(struct net_device *dev,
 					  struct sk_buff *skb,
 					  void *accel_priv,
@@ -1703,6 +1720,132 @@ static void ieee80211_assign_perm_addr(struct ieee80211_local *local,
 	mutex_unlock(&local->iflist_mtx);
 }
 
+void ieee80211_if_config_80211_hdr_offl(struct ieee80211_local *local,
+					bool enable_80211_hdr_offl)
+{
+	struct ieee80211_sub_if_data *sdata;
+	unsigned long flags;
+	int n_acs = IEEE80211_NUM_ACS;
+	int ac;
+
+	ASSERT_RTNL();
+
+	if (!ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP_DECAP) ||
+	    !(ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL)))
+		return;
+
+	if (local->hw.wiphy->frag_threshold != (u32)-1 &&
+	    !local->ops->set_frag_threshold)
+		return;
+
+	mutex_lock(&local->iflist_mtx);
+
+	list_for_each_entry(sdata, &local->interfaces, list) {
+		if (!sdata->dev)
+			continue;
+
+		netif_tx_stop_all_queues(sdata->dev);
+
+		if (enable_80211_hdr_offl)
+			sdata->dev->netdev_ops = &ieee80211_dataif_8023_ops;
+		else
+			sdata->dev->netdev_ops = &ieee80211_dataif_ops;
+	}
+
+	mutex_unlock(&local->iflist_mtx);
+
+	local->data_80211_hdr_offloaded = enable_80211_hdr_offl;
+
+	if (local->started) {
+		if (enable_80211_hdr_offl)
+			local->hw.conf.encap_decap_80211_offloaded = true;
+		else
+			local->hw.conf.encap_decap_80211_offloaded = false;
+		ieee80211_hw_config(local,
+				    IEEE80211_CONF_CHANGE_80211_HDR_OFFL);
+	}
+
+	mutex_lock(&local->iflist_mtx);
+
+	list_for_each_entry(sdata, &local->interfaces, list) {
+		if (!sdata->dev)
+			continue;
+
+		if (local->hw.queues < IEEE80211_NUM_ACS)
+			n_acs = 1;
+
+		spin_lock_irqsave(&local->queue_stop_reason_lock, flags);
+		if (sdata->vif.cab_queue == IEEE80211_INVAL_HW_QUEUE ||
+		    (local->queue_stop_reasons[sdata->vif.cab_queue] == 0 &&
+		     skb_queue_empty(&local->pending[sdata->vif.cab_queue]))) {
+			for (ac = 0; ac < n_acs; ac++) {
+				int ac_queue = sdata->vif.hw_queue[ac];
+
+				if (local->queue_stop_reasons[ac_queue] == 0 &&
+				    skb_queue_empty(&local->pending[ac_queue]))
+					netif_start_subqueue(sdata->dev, ac);
+			}
+		}
+		spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
+	}
+
+	mutex_unlock(&local->iflist_mtx);
+}
+
+void ieee80211_if_check_80211_hdr_offl(struct ieee80211_sub_if_data *sdata,
+				       bool use_4addr, bool add)
+{
+	struct ieee80211_local *local = sdata->local;
+	struct ieee80211_sub_if_data *iface;
+	bool supported = false;
+	bool switch_to_80211 = false;
+	int iface_num = 0;
+	int ret;
+
+	ASSERT_RTNL();
+
+	/* TODO: Extend this function to switch data tx/rx mode upon
+	 * deletion of an interface.
+	 */
+	if (!add)
+		return;
+
+	if (!ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP_DECAP) ||
+	    !(ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL)))
+		return;
+
+	if (local->hw.wiphy->frag_threshold != (u32)-1 &&
+	    !local->ops->set_frag_threshold)
+		return;
+
+	ret = drv_get_vif_80211_hdr_offload(local, sdata, use_4addr,
+					    &supported);
+	if (ret)
+		return;
+
+	mutex_lock(&local->iflist_mtx);
+	list_for_each_entry(iface, &local->interfaces, list) {
+		iface_num++;
+	}
+	mutex_unlock(&local->iflist_mtx);
+
+	if (WARN_ON(iface_num == 0))
+		return;
+
+	switch_to_80211 = local->data_80211_hdr_offloaded && !supported;
+
+	if (switch_to_80211) {
+		ieee80211_if_config_80211_hdr_offl(local, false);
+		return;
+	}
+
+	if (!supported || !sdata->dev)
+		return;
+
+	sdata->dev->netdev_ops = &ieee80211_dataif_8023_ops;
+	local->data_80211_hdr_offloaded = true;
+}
+
 int ieee80211_if_add(struct ieee80211_local *local, const char *name,
 		     unsigned char name_assign_type,
 		     struct wireless_dev **new_wdev, enum nl80211_iftype type,
@@ -1866,6 +2009,10 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
 	list_add_tail_rcu(&sdata->list, &local->interfaces);
 	mutex_unlock(&local->iflist_mtx);
 
+	ieee80211_if_check_80211_hdr_offl(sdata,
+					  params ? params->use_4addr : false,
+					  true);
+
 	if (new_wdev)
 		*new_wdev = &sdata->wdev;
 
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index edd6f29..efcb1c4 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -208,13 +208,25 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
 	case WLAN_CIPHER_SUITE_GCMP_256:
 		/* all of these we can do in software - if driver can */
 		if (ret == 1)
-			return 0;
+			goto check_8023_txrx;
 		if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL))
 			return -EINVAL;
-		return 0;
+		goto check_8023_txrx;
 	default:
 		return -EINVAL;
 	}
+
+check_8023_txrx:
+	/* When sw crypto is enabled make sure data tx/rx happens
+	 * in 802.11 format.
+	 */
+	if (key->local->data_80211_hdr_offloaded) {
+		rtnl_lock();
+		ieee80211_if_config_80211_hdr_offl(key->local, false);
+		rtnl_unlock();
+	}
+
+	return 0;
 }
 
 static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 2095d7c..a1dc809 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -164,6 +164,9 @@ int ieee80211_hw_config(struct ieee80211_local *local, u32 changed)
 
 	might_sleep();
 
+	if (!ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP_DECAP))
+		changed &= ~IEEE80211_CONF_CHANGE_80211_HDR_OFFL;
+
 	if (!local->use_chanctx)
 		changed |= ieee80211_hw_conf_chan(local);
 	else
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index c6d5c72..804fd53 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -506,12 +506,14 @@ static void ieee80211_report_used_skb(struct ieee80211_local *local,
 				      struct sk_buff *skb, bool dropped)
 {
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
-	struct ieee80211_hdr *hdr = (void *)skb->data;
+	struct ieee80211_hdr *hdr;
 	bool acked = info->flags & IEEE80211_TX_STAT_ACK;
 
 	if (dropped)
 		acked = false;
 
+	hdr = (void *)skb->data;
+
 	if (info->flags & IEEE80211_TX_INTFL_MLME_CONN_TX) {
 		struct ieee80211_sub_if_data *sdata;
 
@@ -945,6 +947,85 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
 }
 EXPORT_SYMBOL(ieee80211_tx_status);
 
+void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
+			      struct ieee80211_vif *vif,
+			      struct sk_buff *skb)
+{
+	struct ieee80211_local *local = hw_to_local(hw);
+	struct ieee80211_sub_if_data *sdata;
+	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+	struct sta_info *sta;
+	int retry_count;
+	int rates_idx;
+	bool acked;
+
+	if (WARN_ON(!ieee80211_hw_check(hw, SUPPORTS_80211_ENCAP_DECAP)))
+		goto skip_stats_update;
+
+	sdata = vif_to_sdata(info->control.vif);
+
+	acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
+	rates_idx = ieee80211_tx_get_rates(hw, info, &retry_count);
+
+	rcu_read_lock();
+
+	if (ieee80211_lookup_ra_sta(sdata, skb, &sta)) {
+		rcu_read_unlock();
+		goto counters_update;
+	}
+
+	if (!sta || IS_ERR(sta)) {
+		rcu_read_unlock();
+		goto counters_update;
+	}
+
+	if (!acked)
+		sta->status_stats.retry_failed++;
+
+	if (rates_idx != -1)
+		sta->tx_stats.last_rate = info->status.rates[rates_idx];
+
+	sta->status_stats.retry_count += retry_count;
+
+	if (ieee80211_hw_check(hw, REPORTS_TX_ACK_STATUS)) {
+		if (acked && vif->type == NL80211_IFTYPE_STATION)
+			ieee80211_sta_reset_conn_monitor(sdata);
+
+		sta->status_stats.last_ack = jiffies;
+		if (info->flags & IEEE80211_TX_STAT_ACK) {
+			if (sta->status_stats.lost_packets)
+				sta->status_stats.lost_packets = 0;
+
+			if (test_sta_flag(sta, WLAN_STA_TDLS_PEER_AUTH))
+				sta->status_stats.last_tdls_pkt_time = jiffies;
+		} else {
+			ieee80211_lost_packet(sta, info);
+		}
+	}
+
+	rcu_read_unlock();
+
+counters_update:
+	ieee80211_led_tx(local);
+
+	if (!(info->flags & IEEE80211_TX_STAT_ACK) &&
+	    !(info->flags & IEEE80211_TX_STAT_NOACK_TRANSMITTED))
+		goto skip_stats_update;
+
+	I802_DEBUG_INC(local->dot11TransmittedFrameCount);
+	if (is_multicast_ether_addr(skb->data))
+		I802_DEBUG_INC(local->dot11MulticastTransmittedFrameCount);
+	if (retry_count > 0)
+		I802_DEBUG_INC(local->dot11RetryCount);
+	if (retry_count > 1)
+		I802_DEBUG_INC(local->dot11MultipleRetryCount);
+
+skip_stats_update:
+	ieee80211_report_used_skb(local, skb, false);
+	dev_kfree_skb(skb);
+}
+EXPORT_SYMBOL(ieee80211_tx_status_8023);
+
 void ieee80211_report_low_ack(struct ieee80211_sta *pubsta, u32 num_packets)
 {
 	struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 91461c4..d73cf79 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1485,6 +1485,7 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
 	struct sk_buff *skb = NULL;
 	struct fq *fq = &local->fq;
 	struct fq_tin *tin = &txqi->tin;
+	struct ieee80211_tx_info *info;
 
 	spin_lock_bh(&fq->lock);
 
@@ -1497,11 +1498,15 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
 
 	ieee80211_set_skb_vif(skb, txqi);
 
+	info = IEEE80211_SKB_CB(skb);
+
+	if (info->control.no_80211_encap)
+		goto out;
+
 	hdr = (struct ieee80211_hdr *)skb->data;
 	if (txq->sta && ieee80211_is_data_qos(hdr->frame_control)) {
 		struct sta_info *sta = container_of(txq->sta, struct sta_info,
 						    sta);
-		struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 
 		hdr->seq_ctrl = ieee80211_tx_next_seq(sta, txq->tid);
 		if (test_bit(IEEE80211_TXQ_AMPDU, &txqi->flags))
@@ -2226,9 +2231,9 @@ static inline bool ieee80211_is_tdls_setup(struct sk_buff *skb)
 	       skb->data[14] == WLAN_TDLS_SNAP_RFTYPE;
 }
 
-static int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
-				   struct sk_buff *skb,
-				   struct sta_info **sta_out)
+int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
+			    struct sk_buff *skb,
+			    struct sta_info **sta_out)
 {
 	struct sta_info *sta;
 
@@ -3433,6 +3438,208 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
 	return NETDEV_TX_OK;
 }
 
+static bool ieee80211_tx_8023(struct ieee80211_local *local,
+			      struct sk_buff *skb, int led_len,
+			      struct sta_info *sta,
+			      bool txpending)
+{
+	struct ieee80211_tx_control control = {};
+	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+	struct ieee80211_vif *vif = info->control.vif;
+	struct ieee80211_sta *pubsta = NULL;
+	struct ieee80211_txq *txq = NULL;
+	struct fq *fq = &local->fq;
+	unsigned long flags;
+	int q = info->hw_queue;
+
+	if (sta)
+		pubsta = &sta->sta;
+
+	if (pubsta) {
+		u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
+
+		txq = pubsta->txq[tid];
+	} else if (vif) {
+		txq = vif->txq;
+	}
+
+	if (txq) {
+		struct txq_info *txqi = to_txq_info(txq);
+
+		info->control.vif = vif;
+
+		spin_lock_bh(&fq->lock);
+		ieee80211_txq_enqueue(local, txqi, skb);
+		spin_unlock_bh(&fq->lock);
+
+		drv_wake_tx_queue(local, txqi);
+
+		return true;
+	}
+
+	spin_lock_irqsave(&local->queue_stop_reason_lock, flags);
+
+	if (local->queue_stop_reasons[q] ||
+	    (!txpending && !skb_queue_empty(&local->pending[q]))) {
+		if (txpending)
+			skb_queue_head(&local->pending[q], skb);
+		else
+			skb_queue_tail(&local->pending[q], skb);
+
+		spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
+
+		return false;
+	}
+
+	spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
+
+	control.sta = pubsta;
+
+	drv_tx(local, &control, skb);
+
+	/* TODO: Update throughput led trigger with the number of tx bytes */
+
+	return true;
+}
+
+static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,
+				struct net_device *dev, struct sta_info *sta,
+				struct sk_buff *skb)
+{
+	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+	struct ethhdr *ehdr = (struct ethhdr *)skb->data;
+	struct ieee80211_local *local = sdata->local;
+	bool authorized = false;
+	bool multicast;
+	bool tdls_peer;
+	u8 ra_addr[ETH_ALEN] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
+
+	if (IS_ERR(sta) || (sta && !sta->uploaded))
+		sta = NULL;
+
+	/* XXX: Add a generic helper for this */
+	if (sdata->vif.type == NL80211_IFTYPE_AP ||
+	    sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+	    sdata->vif.type == NL80211_IFTYPE_ADHOC)
+		ether_addr_copy(ra_addr, ehdr->h_dest);
+
+	if (sdata->vif.type == NL80211_IFTYPE_STATION) {
+		tdls_peer = test_sta_flag(sta, WLAN_STA_TDLS_PEER);
+		if (tdls_peer)
+			memcpy(ra_addr, skb->data, ETH_ALEN);
+		else
+			memcpy(ra_addr, sdata->u.mgd.bssid, ETH_ALEN);
+	}
+
+	if (is_zero_ether_addr(ra_addr))
+		goto out_free;
+
+	multicast = is_multicast_ether_addr(ra_addr);
+
+	if (sta)
+		authorized = test_sta_flag(sta, WLAN_STA_AUTHORIZED);
+
+	/* XXX: Should we add new txrx stats for 802.3 to update stats
+	 * like if the frame is dropped due to unathourized port,
+	 * just like the ones available in tx_handlers?.
+	 */
+
+	if (!multicast && !authorized &&
+	    ((ehdr->h_proto != sdata->control_port_protocol) ||
+	    !ether_addr_equal(sdata->vif.addr, ehdr->h_source)))
+		goto out_free;
+
+	if (multicast && sdata->vif.type == NL80211_IFTYPE_AP &&
+	    !atomic_read(&sdata->u.ap.num_mcast_sta))
+		goto out_free;
+
+	if (unlikely(test_bit(SCAN_SW_SCANNING, &local->scanning)) &&
+	    test_bit(SDATA_STATE_OFFCHANNEL, &sdata->state))
+		goto out_free;
+
+	/* TODO: Handle frames requiring wifi tx status to be notified */
+	if (skb->sk && skb_shinfo(skb)->tx_flags & SKBTX_WIFI_STATUS)
+		goto out_free;
+
+	memset(info, 0, sizeof(*info));
+
+	if (unlikely(sdata->control_port_protocol == ehdr->h_proto)) {
+		if (sdata->control_port_no_encrypt)
+			info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
+		info->control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO;
+	}
+
+	if (multicast)
+		info->flags |= IEEE80211_TX_CTL_NO_ACK;
+
+	info->hw_queue = sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
+
+	ieee80211_tx_stats(dev, skb->len);
+
+	if (sta) {
+		sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
+		sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
+	}
+
+	if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+		sdata = container_of(sdata->bss,
+				     struct ieee80211_sub_if_data, u.ap);
+
+	info->control.no_80211_encap = true;
+
+	info->control.vif = &sdata->vif;
+
+	ieee80211_tx_8023(local, skb, skb->len, sta, false);
+
+	return;
+
+out_free:
+	kfree_skb(skb);
+}
+
+netdev_tx_t ieee80211_subif_8023_start_xmit(struct sk_buff *skb,
+					    struct net_device *dev)
+{
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	struct ieee80211_local *local = sdata->local;
+	struct sta_info *sta;
+
+	if (WARN_ON(unlikely(!local->data_80211_hdr_offloaded))) {
+		kfree_skb(skb);
+		return NETDEV_TX_OK;
+	}
+
+	if (unlikely(skb->len < ETH_HLEN)) {
+		kfree_skb(skb);
+		return NETDEV_TX_OK;
+	}
+
+	/* TODO: Extend it for Adhoc interface type */
+	if (WARN_ON(dev->ieee80211_ptr->use_4addr ||
+		    (sdata->vif.type != NL80211_IFTYPE_STATION &&
+		     sdata->vif.type != NL80211_IFTYPE_AP &&
+		     sdata->vif.type != NL80211_IFTYPE_AP_VLAN))) {
+		kfree_skb(skb);
+		return NETDEV_TX_OK;
+	}
+
+	rcu_read_lock();
+
+	if (ieee80211_lookup_ra_sta(sdata, skb, &sta))
+		goto out_free;
+
+	ieee80211_8023_xmit(sdata, dev, sta, skb);
+
+	goto out;
+
+ out_free:
+	kfree_skb(skb);
+ out:
+	rcu_read_unlock();
+
+	return NETDEV_TX_OK;
+}
+
 struct sk_buff *
 ieee80211_build_data_template(struct ieee80211_sub_if_data *sdata,
 			      struct sk_buff *skb, u32 info_flags)
@@ -3511,6 +3718,16 @@ static bool ieee80211_tx_pending_skb(struct ieee80211_local *local,
 		}
 		info->band = chanctx_conf->def.chan->band;
 		result = ieee80211_tx(sdata, NULL, skb, true);
+	} else if (info->control.no_80211_encap) {
+		if (ieee80211_lookup_ra_sta(sdata, skb, &sta)) {
+			dev_kfree_skb(skb);
+			return true;
+		}
+
+		if (IS_ERR(sta) || (sta && !sta->uploaded))
+			sta = NULL;
+
+		result = ieee80211_tx_8023(local, skb, skb->len, sta, true);
 	} else {
 		struct sk_buff_head skbs;
 
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [RFC 3/3] mac80211: Add receive path for ethernet frame format
  2016-12-15  6:00 [RFC 0/3] Add new data path for ethernet frame format Vasanthakumar Thiagarajan
  2016-12-15  6:00 ` [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload Vasanthakumar Thiagarajan
  2016-12-15  6:00 ` [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload Vasanthakumar Thiagarajan
@ 2016-12-15  6:00 ` Vasanthakumar Thiagarajan
  2016-12-15  9:38   ` Johannes Berg
  2016-12-15  9:08 ` [RFC 0/3] Add new data " Johannes Berg
  3 siblings, 1 reply; 21+ messages in thread
From: Vasanthakumar Thiagarajan @ 2016-12-15  6:00 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Vasanthakumar Thiagarajan

Implement rx path which does fewer processing on the
received data frame which has already gone through
802.11 header decapsulation and other functionalities
which require 802.11 header in the low level driver
or hardware. Currently this rx path is restricted
to AP and STA mode, but can be extended for Adhoc
mode as well.

This rx path only checks if the driver has advertised
it's support of 802.11 header encap/decap offload for
data frames. It is upto the low level driver to make
sure if the frame that it passes is in ethernet format
and the sta pointer is valid.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
---
 include/net/mac80211.h |  19 +++++
 net/mac80211/rx.c      | 189 ++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 206 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 225abaa..75c55e2 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1088,6 +1088,9 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  * @RX_FLAG_ALLOW_SAME_PN: Allow the same PN as same packet before.
  *	This is used for AMSDU subframes which can have the same PN as
  *	the first subframe.
+ * @RX_FLAG_MCAST: If the receiver address (addr1) in the frame is multicast.
+ *	This is used with the data frames by the drivers supporting 802.11 hdr
+ *	decap offload.
  */
 enum mac80211_rx_flags {
 	RX_FLAG_MMIC_ERROR		= BIT(0),
@@ -1123,6 +1126,7 @@ enum mac80211_rx_flags {
 	RX_FLAG_RADIOTAP_VENDOR_DATA	= BIT(31),
 	RX_FLAG_MIC_STRIPPED		= BIT_ULL(32),
 	RX_FLAG_ALLOW_SAME_PN		= BIT_ULL(33),
+	RX_FLAG_MCAST			= BIT_ULL(34),
 };
 
 #define RX_FLAG_STBC_SHIFT		26
@@ -3989,6 +3993,21 @@ static inline void ieee80211_rx_ni(struct ieee80211_hw *hw,
 }
 
 /**
+ * ieee80211_rx_decap_offl - Receive frames in 802.11 decapsulated format
+ *
+ * Low level driver capable of 802.11 header decap uses this function. The frame
+ * will be in ethernet format.
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other.
+ *
+ * @hw: the hardware this frame came in on
+ * @sta : the station the frame was received from, must not be %NULL
+ * @skb: the buffer to receive, owned by mac80211 after this call
+ */
+void ieee80211_rx_decap_offl(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
+			     struct sk_buff *skb);
+
+/**
  * ieee80211_sta_ps_transition - PS transition for connected sta
  *
  * When operating in AP mode with the %IEEE80211_HW_AP_LINK_PS
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 2e8a902..3cb8d6e 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2103,13 +2103,14 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx, bool *port_control)
 	return 0;
 }
 
+static const u8 pae_group_addr[ETH_ALEN] __aligned(2)
+	= { 0x01, 0x80, 0xC2, 0x00, 0x00, 0x03 };
+
 /*
  * requires that rx->skb is a frame with ethernet header
  */
 static bool ieee80211_frame_allowed(struct ieee80211_rx_data *rx, __le16 fc)
 {
-	static const u8 pae_group_addr[ETH_ALEN] __aligned(2)
-		= { 0x01, 0x80, 0xC2, 0x00, 0x00, 0x03 };
 	struct ethhdr *ehdr = (struct ethhdr *) rx->skb->data;
 
 	/*
@@ -4180,3 +4181,187 @@ void ieee80211_rx_irqsafe(struct ieee80211_hw *hw, struct sk_buff *skb)
 	tasklet_schedule(&local->tasklet);
 }
 EXPORT_SYMBOL(ieee80211_rx_irqsafe);
+
+/* Receive path for decap offloaded data frames */
+
+static void
+ieee80211_rx_handle_decap_offl(struct ieee80211_sub_if_data *sdata,
+				     struct sta_info *sta, struct sk_buff *skb)
+{
+	struct ieee80211_local *local = sdata->local;
+	struct ieee80211_vif *vif = &sdata->vif;
+	struct net_device *dev = sdata->dev;
+	struct ieee80211_rx_status *status;
+	struct ieee80211_key *key = NULL;
+	struct ieee80211_rx_data rx;
+	int i;
+	struct ethhdr *ehdr;
+
+	ehdr = (struct ethhdr *)skb->data;
+	status = IEEE80211_SKB_RXCB(skb);
+
+	/* TODO: Extend ieee80211_rx_decap_offl() with bssid so that Ethernet
+	 * encap/decap can be supported in Adhoc interface type as well.
+	 * Adhoc interface depends on bssid to udpate last_rx.
+	 */
+	if (vif->type != NL80211_IFTYPE_STATION &&
+	    vif->type != NL80211_IFTYPE_AP_VLAN &&
+	    vif->type != NL80211_IFTYPE_AP)
+		goto drop;
+
+	I802_DEBUG_INC(local->dot11ReceivedFragmentCount);
+
+	if (!(status->flag & RX_FLAG_MCAST)) {
+		sta->rx_stats.last_rx = jiffies;
+		sta->rx_stats.last_rate = sta_stats_encode_rate(status);
+	}
+
+	if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+	    !is_multicast_ether_addr(ehdr->h_dest))
+		ieee80211_sta_reset_conn_monitor(sdata);
+
+	sta->rx_stats.fragments++;
+
+	u64_stats_update_begin(&sta->rx_stats.syncp);
+	sta->rx_stats.bytes += skb->len;
+	u64_stats_update_end(&sta->rx_stats.syncp);
+
+	if (!(status->flag & RX_FLAG_NO_SIGNAL_VAL)) {
+		sta->rx_stats.last_signal = status->signal;
+		ewma_signal_add(&sta->rx_stats_avg.signal, -status->signal);
+	}
+
+	if (status->chains) {
+		sta->rx_stats.chains = status->chains;
+		for (i = 0; i < ARRAY_SIZE(status->chain_signal); i++) {
+			int signal = status->chain_signal[i];
+
+			if (!(status->chains & BIT(i)))
+				continue;
+
+			sta->rx_stats.chain_signal_last[i] = signal;
+			ewma_signal_add(&sta->rx_stats_avg.chain_signal[i],
+					-signal);
+		}
+	}
+
+	if (status->flag & RX_FLAG_MCAST) {
+		for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
+			key = rcu_dereference(sta->gtk[i]);
+			if (key)
+				break;
+		}
+	} else {
+		key = rcu_dereference(sta->ptk[sta->ptk_idx]);
+	}
+
+	if (key && unlikely(key->flags & KEY_FLAG_TAINTED))
+		goto drop;
+
+	if (status->flag & RX_FLAG_MMIC_ERROR) {
+		if (key)
+			key->u.tkip.mic_failures++;
+		goto mic_fail;
+	}
+
+	if (unlikely(!test_sta_flag(sta, WLAN_STA_AUTHORIZED))) {
+		if (ehdr->h_proto != sdata->control_port_protocol)
+			goto drop;
+		else if (!ether_addr_equal(ehdr->h_dest, vif->addr) &&
+			 !ether_addr_equal(ehdr->h_dest, pae_group_addr))
+			goto drop;
+	}
+
+	if (unlikely(ehdr->h_proto == cpu_to_be16(ETH_P_TDLS))) {
+		struct ieee80211_tdls_data *tf = (void *)skb->data;
+
+		if (pskb_may_pull(skb,
+				  offsetof(struct ieee80211_tdls_data, u)) &&
+		    tf->payload_type == WLAN_TDLS_SNAP_RFTYPE &&
+		    tf->category == WLAN_CATEGORY_TDLS &&
+		    (tf->action_code == WLAN_TDLS_CHANNEL_SWITCH_REQUEST ||
+		     tf->action_code == WLAN_TDLS_CHANNEL_SWITCH_RESPONSE)) {
+			skb_queue_tail(&local->skb_queue_tdls_chsw, skb);
+			schedule_work(&local->tdls_chsw_work);
+			sta->rx_stats.packets++;
+			return;
+		}
+	}
+
+	memset(&rx, 0, sizeof(rx));
+	rx.skb = skb;
+	rx.sdata = sdata;
+	rx.local = local;
+	rx.sta = sta;
+
+	if (vif->type == NL80211_IFTYPE_AP_VLAN && sdata->bss &&
+	    unlikely(ehdr->h_proto == sdata->control_port_protocol)) {
+		sdata = container_of(sdata->bss, struct ieee80211_sub_if_data,
+				     u.ap);
+		dev = sdata->dev;
+		rx.sdata = sdata;
+	}
+
+	rx.skb->dev = dev;
+
+	/* XXX: Since rx.seqno_idx is not available for decap offloaded frames
+	 * rx msdu stats update at the seqno_idx in ieee80211_deliver_skb()
+	 * will always be updated at index 0 and will not be very useful.
+	 */
+	ieee80211_deliver_skb(&rx);
+
+	return;
+
+mic_fail:
+	cfg80211_michael_mic_failure(sdata->dev, sta->addr,
+				     (status->flag & RX_FLAG_MCAST) ?
+				     NL80211_KEYTYPE_GROUP :
+				     NL80211_KEYTYPE_PAIRWISE,
+				     key ? key->conf.keyidx : -1,
+				     NULL, GFP_ATOMIC);
+
+drop:
+	sta->rx_stats.dropped++;
+	dev_kfree_skb(skb);
+}
+
+/* Receive path handler that a low level driver supporting 802.11 hdr decap
+ * offload can call. The frame is in ethernet format and the assumption is
+ * all necessary operations like decryption, defrag, deaggregation, etc.
+ * requiring 802.11 headers are already performed in the low level driver
+ * or hardware.
+ */
+void ieee80211_rx_decap_offl(struct ieee80211_hw *hw,
+			     struct ieee80211_sta *pubsta, struct sk_buff *skb)
+{
+	struct ieee80211_local *local = hw_to_local(hw);
+	struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
+
+	if (unlikely(local->quiescing || local->suspended))
+		goto drop;
+
+	if (unlikely(local->in_reconfig))
+		goto drop;
+
+	if (WARN_ON(!local->started))
+		goto drop;
+
+	/* TODO: Sanity checks on flags/rx_flags like done in
+	 * ieee80211_invoke_fast_rx() to confirm if the frame
+	 * has gone through all the functionalities which require
+	 * 802.11 frame header.
+	 */
+
+	rcu_read_lock();
+
+	/* TODO: Toggle Rx throughput LED */
+
+	ieee80211_rx_handle_decap_offl(sta->sdata, sta, skb);
+
+	rcu_read_unlock();
+
+	return;
+drop:
+	kfree_skb(skb);
+}
+EXPORT_SYMBOL(ieee80211_rx_decap_offl);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [RFC 0/3] Add new data path for ethernet frame format
  2016-12-15  6:00 [RFC 0/3] Add new data path for ethernet frame format Vasanthakumar Thiagarajan
                   ` (2 preceding siblings ...)
  2016-12-15  6:00 ` [RFC 3/3] mac80211: Add receive path for ethernet frame format Vasanthakumar Thiagarajan
@ 2016-12-15  9:08 ` Johannes Berg
  2016-12-15 10:03   ` Thiagarajan, Vasanthakumar
  3 siblings, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2016-12-15  9:08 UTC (permalink / raw)
  To: Vasanthakumar Thiagarajan; +Cc: linux-wireless

On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote:
> This patch set adds a new data path to offload 802.11 header
> encap/decap to driver or hardware. Drivers having support
> for ieee80211 header encap/decap and other offload functionalities
> which can't be done before encap or after decap can make use of
> this new data path. Currently it is implemented for STA and AP
> interface type, this can be extend other interface types like
> adhoc.  

Thanks for posting this!

> With ath10k driver changes using this new Tx/Rx path, 10 - 15%
> CPU usage and upto ~20Mbps TCP performance improvements are
> observed with this ethernet data path. 

I'm sure that's because your CPU is severely limited :-)

> This patch set is
> prepared on a older mac80211 code base on top of
> commit 7d27a0ba7adc ("cfg80211: Add mesh peer AID setting API").
> Sorry, I could not get a chance to rework it on top of latest
> mac80211 code base.

Ok. I guess that doesn't matter much for review now.

> 	- Consider ieee8011 header and cipher header size also while
> updating tx/rx stats for
> 	  ethernet frame format.

I wonder if we really shouldn't be going the other way around instead,
to be closer to what Ethernet and likely other drivers do.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload
  2016-12-15  6:00 ` [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload Vasanthakumar Thiagarajan
@ 2016-12-15  9:16   ` Johannes Berg
  2016-12-15 10:43     ` Thiagarajan, Vasanthakumar
  0 siblings, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2016-12-15  9:16 UTC (permalink / raw)
  To: Vasanthakumar Thiagarajan; +Cc: linux-wireless


> Drivers advertising this capability should also implement other
> functionalities which deal with 802.11 frame format like below

> 	- ADDBA/DELBA offload

This shouldn't be necessary.

> 	- Hardware rate control

Neither is this, if we find some API to do sampling. The existing rate
table API already allows setting the rates out of band, so the only
thing that you'd have to support out of band is sampling.

> 	- Powersave offload

That's ambiguous - you do need to handle sleeping stations (and PS-
Poll/U-APSD) in AP mode in the device with this, but I don't see a deep
technical reason to require it for client mode. OTOH, client mode is
almost always offloaded anyway.

I think you may have forgotten one important item,

	- control port handling

?

> + * @IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP: Hardware/driver
> supports 802.11
> + *	encap/decap for data frames. Supporting driver have to
> implement
> + *	get_vif_80211_encap_decap_offload() to pass if 802.11
> encap/decap
> + *	offload	is supported for the vif.

I don't see why you need this, when you have the method - you can just
assume that the method returns false when it's not implemented.

>  struct ieee80211_ops {
>  	void (*tx)(struct ieee80211_hw *hw,
> @@ -3639,6 +3651,10 @@ struct ieee80211_ops {
>  	void (*wake_tx_queue)(struct ieee80211_hw *hw,
>  			      struct ieee80211_txq *txq);
>  	void (*sync_rx_queues)(struct ieee80211_hw *hw);
> +
> +	int (*get_vif_80211_hdr_offload)(struct ieee80211_hw *hw,
> +					 struct ieee80211_vif *vif,
> +					 bool is_4addr, bool
> *supported);

Why are you not simply returning "supported"?

I don't like passing the vif pointer here. At this point, the vif
pointer isn't known to the driver yet (through drv_add_interface) so
it's a dead pointer as far as the sequencing is concerned.

Is there a possibility that drivers need to switch off ethernet format
handling entirely when an incompatible interface is added? For example,
if you add a mesh interface, is there a chance that the AP interface
might no longer be able to handle this?

I'd hope this doesn't happen because I think that would be extremely
complicated to handle safely.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-15  6:00 ` [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload Vasanthakumar Thiagarajan
@ 2016-12-15  9:29   ` Johannes Berg
  2016-12-15 12:01     ` Thiagarajan, Vasanthakumar
  0 siblings, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2016-12-15  9:29 UTC (permalink / raw)
  To: Vasanthakumar Thiagarajan; +Cc: linux-wireless


> There is a field, no_80211_encap, added to ieee80211_tx_info:control
> to mark if the 802.11 encapsulation is offloaded to driver.
> There is also a new callback for tx completion status indication
> to handle data frames using 802.11 encap offload.

I'm not sure I see the need for this? Maybe I'll find out in this patch
:)

> +			/* XXX: This frame is not encaptulated with
> 802.11
> +			 * header. Should this be added to
> %IEEE80211_TX_CTRL_*
> +			 * flags?.
> +			 */
> +			bool no_80211_encap;
> +			/* 3 bytes free */
>  		} control;

probably - just to preserve more space.

> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
> + *	implementing 802.11 encap/decap for data frames changed.
>   */
>  enum ieee80211_conf_changed {
>  	IEEE80211_CONF_CHANGE_SMPS		= BIT(1),
> @@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
>  	IEEE80211_CONF_CHANGE_CHANNEL		= BIT(6),
>  	IEEE80211_CONF_CHANGE_RETRY_LIMITS	= BIT(7),
>  	IEEE80211_CONF_CHANGE_IDLE		= BIT(8),
> +	IEEE80211_CONF_CHANGE_80211_HDR_OFFL	= BIT(9),
>  };

Given the requirements (PN check, etc.) I'm not sure how this can
change dynamically?

> + * @encap_decap_80211_offloaded: Whether 802.11 header encap/decap
> offload
> + *	is enabled
>   */
>  struct ieee80211_conf {
>  	u32 flags;
> @@ -1346,6 +1357,7 @@ struct ieee80211_conf {
>  	struct cfg80211_chan_def chandef;
>  	bool radar_enabled;
>  	enum ieee80211_smps_mode smps_mode;
> +	bool encap_decap_80211_offloaded;

Please don't add anything here that's interface specific.

> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -107,6 +107,10 @@ static int ieee80211_change_iface(struct wiphy
> *wiphy,
>  		}
>  	}
>  
> +	ieee80211_if_check_80211_hdr_offl(sdata,
> +					  params ? params->use_4addr 
> : false,
> +					  true);
> +
>  	return 0;
>  }

Wouldn't it be better to simply prohibit changing this while the
interface is up, and re-init it later when it goes up?

> +++ b/net/mac80211/ieee80211_i.h
> @@ -1373,6 +1373,8 @@ struct ieee80211_local {
>  	/* TDLS channel switch */
>  	struct work_struct tdls_chsw_work;
>  	struct sk_buff_head skb_queue_tdls_chsw;
> +
> +	bool data_80211_hdr_offloaded;

Again, don't put interface specific things into device structures.

> +int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
> +			    struct sk_buff *skb,
> +			    struct sta_info **sta_out);

Return the sta_info pointer, and ERR_PTR() if needed.

> +++ b/net/mac80211/iface.c
> @@ -698,6 +698,11 @@ int ieee80211_do_open(struct wireless_dev *wdev,
> bool coming_up)
>  		rcu_assign_pointer(local->p2p_sdata, sdata);
>  	}
>  
> +	if (local->open_count == 0 && local-
> >data_80211_hdr_offloaded) {
> +		local->hw.conf.encap_decap_80211_offloaded = true;
> +		hw_reconf_flags |=
> IEEE80211_CONF_CHANGE_80211_HDR_OFFL;
> +	}

I don't see how this helps anything, I think you should remove it.

> +void ieee80211_if_config_80211_hdr_offl(struct ieee80211_local
> *local,
> +					bool enable_80211_hdr_offl)
> +{
> +	struct ieee80211_sub_if_data *sdata;
> +	unsigned long flags;
> +	int n_acs = IEEE80211_NUM_ACS;
> +	int ac;
> +
> +	ASSERT_RTNL();
> +
> +	if (!ieee80211_hw_check(&local->hw,
> SUPPORTS_80211_ENCAP_DECAP) ||
> +	    !(ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL)))
> +		return;
> +
> +	if (local->hw.wiphy->frag_threshold != (u32)-1 &&
> +	    !local->ops->set_frag_threshold)
> +		return;
> +
> +	mutex_lock(&local->iflist_mtx);
> +
> +	list_for_each_entry(sdata, &local->interfaces, list) {
> +		if (!sdata->dev)
> +			continue;
> +
> +		netif_tx_stop_all_queues(sdata->dev);
> +
> +		if (enable_80211_hdr_offl)
> +			sdata->dev->netdev_ops =
> &ieee80211_dataif_8023_ops;
> +		else
> +			sdata->dev->netdev_ops =
> &ieee80211_dataif_ops;
> +	}
> +
> +	mutex_unlock(&local->iflist_mtx);
> +
> +	local->data_80211_hdr_offloaded = enable_80211_hdr_offl;
> +
> +	if (local->started) {
> +		if (enable_80211_hdr_offl)
> +			local->hw.conf.encap_decap_80211_offloaded =
> true;
> +		else
> +			local->hw.conf.encap_decap_80211_offloaded =
> false;
> +		ieee80211_hw_config(local,
> +				    IEEE80211_CONF_CHANGE_80211_HDR_
> OFFL);
> +	}
> +
> +	mutex_lock(&local->iflist_mtx);
> +
> +	list_for_each_entry(sdata, &local->interfaces, list) {
> +		if (!sdata->dev)
> +			continue;
> +
> +		if (local->hw.queues < IEEE80211_NUM_ACS)
> +			n_acs = 1;
> +
> +		spin_lock_irqsave(&local->queue_stop_reason_lock,
> flags);
> +		if (sdata->vif.cab_queue == IEEE80211_INVAL_HW_QUEUE
> ||
> +		    (local->queue_stop_reasons[sdata->vif.cab_queue] 
> == 0 &&
> +		     skb_queue_empty(&local->pending[sdata-
> >vif.cab_queue]))) {
> +			for (ac = 0; ac < n_acs; ac++) {
> +				int ac_queue = sdata-
> >vif.hw_queue[ac];
> +
> +				if (local-
> >queue_stop_reasons[ac_queue] == 0 &&
> +				    skb_queue_empty(&local-
> >pending[ac_queue]))
> +					netif_start_subqueue(sdata-
> >dev, ac);
> +			}
> +		}
> +		spin_unlock_irqrestore(&local-
> >queue_stop_reason_lock, flags);
> +	}
> +
> +	mutex_unlock(&local->iflist_mtx);
> +}

I really would prefer we could simply avoid doing these manipulations
while the interface is UP and can have data queued.

> +++ b/net/mac80211/key.c
> @@ -208,13 +208,25 @@ static int ieee80211_key_enable_hw_accel(struct
> ieee80211_key *key)
>  	case WLAN_CIPHER_SUITE_GCMP_256:
>  		/* all of these we can do in software - if driver
> can */
>  		if (ret == 1)
> -			return 0;
> +			goto check_8023_txrx;
>  		if (ieee80211_hw_check(&key->local->hw,
> SW_CRYPTO_CONTROL))
>  			return -EINVAL;
> -		return 0;
> +		goto check_8023_txrx;
>  	default:
>  		return -EINVAL;
>  	}
> +
> +check_8023_txrx:
> +	/* When sw crypto is enabled make sure data tx/rx happens
> +	 * in 802.11 format.
> +	 */
> +	if (key->local->data_80211_hdr_offloaded) {
> +		rtnl_lock();
> +		ieee80211_if_config_80211_hdr_offl(key->local,
> false);
> +		rtnl_unlock();
> +	}
> +
> +	return 0;
>  }

Why not just refuse the key instead? It also seems wrong to do anything
with local-> here, it should be per interface.

> +++ b/net/mac80211/status.c
> @@ -506,12 +506,14 @@ static void ieee80211_report_used_skb(struct
> ieee80211_local *local,
>  				      struct sk_buff *skb, bool
> dropped)
>  {
>  	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> -	struct ieee80211_hdr *hdr = (void *)skb->data;
> +	struct ieee80211_hdr *hdr;
>  	bool acked = info->flags & IEEE80211_TX_STAT_ACK;
>  
>  	if (dropped)
>  		acked = false;
>  
> +	hdr = (void *)skb->data;

That change make no sense.

>  	if (info->flags & IEEE80211_TX_INTFL_MLME_CONN_TX) {
>  		struct ieee80211_sub_if_data *sdata;
>  
> @@ -945,6 +947,85 @@ void ieee80211_tx_status(struct ieee80211_hw
> *hw, struct sk_buff *skb)
>  }
>  EXPORT_SYMBOL(ieee80211_tx_status);
>  
> +void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
> +			      struct ieee80211_vif *vif,
> +			      struct sk_buff *skb)

I think this could share some code with the 802.11 version?

> +	/* XXX: Add a generic helper for this */
> +	if (sdata->vif.type == NL80211_IFTYPE_AP ||
> +	    sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
> +	    sdata->vif.type == NL80211_IFTYPE_ADHOC)
> +		ether_addr_copy(ra_addr, ehdr->h_dest);

nit, but the "A" in "RA" already means address ... :)

You also don't need to copy it - just keeping a pointer should be fine?

> +	/* TODO: Handle frames requiring wifi tx status to be
> notified */
> +	if (skb->sk && skb_shinfo(skb)->tx_flags &
> SKBTX_WIFI_STATUS)
> +		goto out_free;

Surely you shouldn't free them, even if you don't handle the status?!

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format
  2016-12-15  6:00 ` [RFC 3/3] mac80211: Add receive path for ethernet frame format Vasanthakumar Thiagarajan
@ 2016-12-15  9:38   ` Johannes Berg
  2016-12-16  6:47     ` Thiagarajan, Vasanthakumar
  0 siblings, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2016-12-15  9:38 UTC (permalink / raw)
  To: Vasanthakumar Thiagarajan; +Cc: linux-wireless


> This rx path only checks if the driver has advertised
> it's support of 802.11 header encap/decap offload for
> data frames. 

I'm not even sure I see the point in that? Other than that (and the
various other offload requirements), it seems that encap/decap could be
considered orthogonal.

> +	 * Adhoc interface depends on bssid to udpate last_rx.

type - update

> +	if (!(status->flag & RX_FLAG_MCAST)) {
> +		sta->rx_stats.last_rx = jiffies;
> +		sta->rx_stats.last_rate =
> sta_stats_encode_rate(status);
> +	}

You should probably rename that flag to something like
RX_FLAG_80211_MCAST since otherwise it's confusing with the next
multicast ether addr check:

> +	if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> +	    !is_multicast_ether_addr(ehdr->h_dest))
> +		ieee80211_sta_reset_conn_monitor(sdata);

But this could just also use the flag, since in station mode the two
are equivalent, and it'd be easier to figure out if this was "else if
(station mode)"?

> +	memset(&rx, 0, sizeof(rx));

That seems a bit pointless?

> +	rx.skb = skb;
> +	rx.sdata = sdata;
> +	rx.local = local;
> +	rx.sta = sta;
> +
> +	if (vif->type == NL80211_IFTYPE_AP_VLAN && sdata->bss &&
> +	    unlikely(ehdr->h_proto == sdata->control_port_protocol)) 
> {
> +		sdata = container_of(sdata->bss, struct
> ieee80211_sub_if_data,
> +				     u.ap);
> +		dev = sdata->dev;
> +		rx.sdata = sdata;
> +	}
> +
> +	rx.skb->dev = dev;
> +
> +	/* XXX: Since rx.seqno_idx is not available for decap
> offloaded frames
> +	 * rx msdu stats update at the seqno_idx in
> ieee80211_deliver_skb()
> +	 * will always be updated at index 0 and will not be very
> useful.
> +	 */
> +	ieee80211_deliver_skb(&rx);

Yeah, that's not nice - perhaps we can provide the TID out of band? If
not, we'll have to disable those statistics *all the way*, i.e. not
even report them to userspace when filling sinfo.

> +	return;
> +
> +mic_fail:
> +	cfg80211_michael_mic_failure(sdata->dev, sta->addr,
> +				     (status->flag & RX_FLAG_MCAST)
> ?
> +				     NL80211_KEYTYPE_GROUP :
> +				     NL80211_KEYTYPE_PAIRWISE,
> +				     key ? key->conf.keyidx : -1,
> +				     NULL, GFP_ATOMIC);

Do we really want to handle that inline here? The driver probably has a
different check to even set RX_FLAG_MMIC_ERROR, so we could just ask it
to call cfg80211_michael_mic_failure() [or a wrapper to get sdata->dev] 
instead? I guess this works too though, and might be easier to
understand.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 0/3] Add new data path for ethernet frame format
  2016-12-15  9:08 ` [RFC 0/3] Add new data " Johannes Berg
@ 2016-12-15 10:03   ` Thiagarajan, Vasanthakumar
  0 siblings, 0 replies; 21+ messages in thread
From: Thiagarajan, Vasanthakumar @ 2016-12-15 10:03 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMjozOCBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4gT24gVGh1LCAyMDE2LTEyLTE1IGF0IDExOjMwICswNTMwLCBWYXNhbnRoYWt1bWFyIFRo
aWFnYXJhamFuIHdyb3RlOg0KPj4gVGhpcyBwYXRjaCBzZXQgYWRkcyBhIG5ldyBkYXRhIHBhdGgg
dG8gb2ZmbG9hZCA4MDIuMTEgaGVhZGVyDQo+PiBlbmNhcC9kZWNhcCB0byBkcml2ZXIgb3IgaGFy
ZHdhcmUuIERyaXZlcnMgaGF2aW5nIHN1cHBvcnQNCj4+IGZvciBpZWVlODAyMTEgaGVhZGVyIGVu
Y2FwL2RlY2FwIGFuZCBvdGhlciBvZmZsb2FkIGZ1bmN0aW9uYWxpdGllcw0KPj4gd2hpY2ggY2Fu
J3QgYmUgZG9uZSBiZWZvcmUgZW5jYXAgb3IgYWZ0ZXIgZGVjYXAgY2FuIG1ha2UgdXNlIG9mDQo+
PiB0aGlzIG5ldyBkYXRhIHBhdGguIEN1cnJlbnRseSBpdCBpcyBpbXBsZW1lbnRlZCBmb3IgU1RB
IGFuZCBBUA0KPj4gaW50ZXJmYWNlIHR5cGUsIHRoaXMgY2FuIGJlIGV4dGVuZCBvdGhlciBpbnRl
cmZhY2UgdHlwZXMgbGlrZQ0KPj4gYWRob2MuDQo+DQo+IFRoYW5rcyBmb3IgcG9zdGluZyB0aGlz
IQ0KPg0KPj4gV2l0aCBhdGgxMGsgZHJpdmVyIGNoYW5nZXMgdXNpbmcgdGhpcyBuZXcgVHgvUngg
cGF0aCwgMTAgLSAxNSUNCj4+IENQVSB1c2FnZSBhbmQgdXB0byB+MjBNYnBzIFRDUCBwZXJmb3Jt
YW5jZSBpbXByb3ZlbWVudHMgYXJlDQo+PiBvYnNlcnZlZCB3aXRoIHRoaXMgZXRoZXJuZXQgZGF0
YSBwYXRoLg0KPg0KPiBJJ20gc3VyZSB0aGF0J3MgYmVjYXVzZSB5b3VyIENQVSBpcyBzZXZlcmVs
eSBsaW1pdGVkIDotKQ0KDQpSaWdodCwgbW9zdCBvZiB0aGUgdGltZSBJIHdhcyBvYnNlcnZpbmcg
bWF4IENQVSB1c2FnZS4NCg0KPg0KPj4gVGhpcyBwYXRjaCBzZXQgaXMNCj4+IHByZXBhcmVkIG9u
IGEgb2xkZXIgbWFjODAyMTEgY29kZSBiYXNlIG9uIHRvcCBvZg0KPj4gY29tbWl0IDdkMjdhMGJh
N2FkYyAoImNmZzgwMjExOiBBZGQgbWVzaCBwZWVyIEFJRCBzZXR0aW5nIEFQSSIpLg0KPj4gU29y
cnksIEkgY291bGQgbm90IGdldCBhIGNoYW5jZSB0byByZXdvcmsgaXQgb24gdG9wIG9mIGxhdGVz
dA0KPj4gbWFjODAyMTEgY29kZSBiYXNlLg0KPg0KPiBPay4gSSBndWVzcyB0aGF0IGRvZXNuJ3Qg
bWF0dGVyIG11Y2ggZm9yIHJldmlldyBub3cuDQo+DQo+PiAJLSBDb25zaWRlciBpZWVlODAxMSBo
ZWFkZXIgYW5kIGNpcGhlciBoZWFkZXIgc2l6ZSBhbHNvIHdoaWxlDQo+PiB1cGRhdGluZyB0eC9y
eCBzdGF0cyBmb3INCj4+IAkgIGV0aGVybmV0IGZyYW1lIGZvcm1hdC4NCj4NCj4gSSB3b25kZXIg
aWYgd2UgcmVhbGx5IHNob3VsZG4ndCBiZSBnb2luZyB0aGUgb3RoZXIgd2F5IGFyb3VuZCBpbnN0
ZWFkLA0KPiB0byBiZSBjbG9zZXIgdG8gd2hhdCBFdGhlcm5ldCBhbmQgbGlrZWx5IG90aGVyIGRy
aXZlcnMgZG8uDQoNCk9rLiBJIGNhcHR1cmVkIHRoYXQgYmVjYXVzZSByeC90eCBieXRlcyBzdGF0
cyB3aWxsIGJlIGluY29uc2lzdGVudCBiZXR3ZWVuIGV0aGVybmV0DQphbmQgODAyLjExIGZyYW1l
IGZvcm1hdC4NCg0KVmFzYW50aA==

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload
  2016-12-15  9:16   ` Johannes Berg
@ 2016-12-15 10:43     ` Thiagarajan, Vasanthakumar
  2016-12-16  9:30       ` Johannes Berg
  0 siblings, 1 reply; 21+ messages in thread
From: Thiagarajan, Vasanthakumar @ 2016-12-15 10:43 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMjo0NiBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+IERyaXZlcnMgYWR2ZXJ0aXNpbmcgdGhpcyBjYXBhYmlsaXR5IHNob3VsZCBhbHNv
IGltcGxlbWVudCBvdGhlcg0KPj4gZnVuY3Rpb25hbGl0aWVzIHdoaWNoIGRlYWwgd2l0aCA4MDIu
MTEgZnJhbWUgZm9ybWF0IGxpa2UgYmVsb3cNCj4NCj4+IAktIEFEREJBL0RFTEJBIG9mZmxvYWQN
Cj4NCj4gVGhpcyBzaG91bGRuJ3QgYmUgbmVjZXNzYXJ5Lg0KDQpPay4gU2luY2UgZHJpdmVyL2h3
IG5lZWRzIHRvIGltcGxlbWVudCBUeC9SeCBhZ2dyZWdhdGlvbiByZWxhdGVkIGZ1bmN0aW9uYWxp
dGllcw0KSSB0aG91Z2h0IEFEREJBL0RFTEJBIHByb2Nlc3Npbmcgd2lsbCBiZSBsaXR0bGUgaW1w
b3J0YW50IHRvIG1hYzgwMjExLiBNYXkgYmUgSSdtDQptaXNzaW5nIHNvbWV0aGluZy4NCg0KPg0K
Pj4gCS0gSGFyZHdhcmUgcmF0ZSBjb250cm9sDQo+DQo+IE5laXRoZXIgaXMgdGhpcywgaWYgd2Ug
ZmluZCBzb21lIEFQSSB0byBkbyBzYW1wbGluZy4gVGhlIGV4aXN0aW5nIHJhdGUNCj4gdGFibGUg
QVBJIGFscmVhZHkgYWxsb3dzIHNldHRpbmcgdGhlIHJhdGVzIG91dCBvZiBiYW5kLCBzbyB0aGUg
b25seQ0KPiB0aGluZyB0aGF0IHlvdSdkIGhhdmUgdG8gc3VwcG9ydCBvdXQgb2YgYmFuZCBpcyBz
YW1wbGluZy4NCg0KT2suDQoNCj4NCj4+IAktIFBvd2Vyc2F2ZSBvZmZsb2FkDQo+DQo+IFRoYXQn
cyBhbWJpZ3VvdXMgLSB5b3UgZG8gbmVlZCB0byBoYW5kbGUgc2xlZXBpbmcgc3RhdGlvbnMgKGFu
ZCBQUy0NCj4gUG9sbC9VLUFQU0QpIGluIEFQIG1vZGUgaW4gdGhlIGRldmljZSB3aXRoIHRoaXMs
DQoNCkkgZGlkIG5vdCBkaWcgZGVlcCBpbnRvIFBTIHJlcXVpcmVtZW50IHdpdGggZXRoZXJuZXQg
ZnJhbWUgZm9ybWF0IGJlY2F1c2UNCmZyYW1lIGNvbnRyb2wgaXMgbm90IGF2YWlsYWJsZSB0byBt
YWM4MDIxMSwgc28gSSB0aG91Z2h0IHRvIG1lbnRpb24gUFMgb2ZmbG9hZA0KaXMgYSByZXF1aXJl
bWVudC4gTWF5IGJlIHRoZXJlIGlzIGFscmVhZHkgYW4gaW5mcmFzdHJ1Y3R1cmUgaW4gbWFjODAy
MTEgdG8NCmxlYXJuIFBTIHN0YXRlIG9mIGNsaWVudCB3aGljaCB3YXMgbm90aWZpZWQgaW4gdGhl
IGN1cnJlbnQgZGF0YSBmcmFtZSAob3RoZXINCnRoYW4gODAyLjExIGZyYW1lIGNvbnRyb2wpLg0K
DQogIGJ1dCBJIGRvbid0IHNlZSBhIGRlZXANCj4gdGVjaG5pY2FsIHJlYXNvbiB0byByZXF1aXJl
IGl0IGZvciBjbGllbnQgbW9kZS4gT1RPSCwgY2xpZW50IG1vZGUgaXMNCj4gYWxtb3N0IGFsd2F5
cyBvZmZsb2FkZWQgYW55d2F5Lg0KDQpPay4NCg0KPg0KPiBJIHRoaW5rIHlvdSBtYXkgaGF2ZSBm
b3Jnb3R0ZW4gb25lIGltcG9ydGFudCBpdGVtLA0KPg0KPiAJLSBjb250cm9sIHBvcnQgaGFuZGxp
bmcNCg0KSG1tbSwgSSdtIGdldHRpbmcgV1BBLVBTSyB3b3JraW5nIHdpdGggdGhpcy4gTWF5IGJl
IHRoZXJlIGFyZSBvdGhlcg0KY29udHJvbCBwb3J0IGhhbmRsaW5nIHdoaWNoIHdpbGwgbm90IHdv
cmsgd2l0aCBldGhlcm5ldCBmcmFtZSBmb3JtYXQ/DQoNCj4NCj4gPw0KPg0KPj4gKyAqIEBJRUVF
ODAyMTFfSFdfU1VQUE9SVFNfODAyMTFfRU5DQVBfREVDQVA6IEhhcmR3YXJlL2RyaXZlcg0KPj4g
c3VwcG9ydHMgODAyLjExDQo+PiArICoJZW5jYXAvZGVjYXAgZm9yIGRhdGEgZnJhbWVzLiBTdXBw
b3J0aW5nIGRyaXZlciBoYXZlIHRvDQo+PiBpbXBsZW1lbnQNCj4+ICsgKglnZXRfdmlmXzgwMjEx
X2VuY2FwX2RlY2FwX29mZmxvYWQoKSB0byBwYXNzIGlmIDgwMi4xMQ0KPj4gZW5jYXAvZGVjYXAN
Cj4+ICsgKglvZmZsb2FkCWlzIHN1cHBvcnRlZCBmb3IgdGhlIHZpZi4NCj4NCj4gSSBkb24ndCBz
ZWUgd2h5IHlvdSBuZWVkIHRoaXMsIHdoZW4geW91IGhhdmUgdGhlIG1ldGhvZCAtIHlvdSBjYW4g
anVzdA0KPiBhc3N1bWUgdGhhdCB0aGUgbWV0aG9kIHJldHVybnMgZmFsc2Ugd2hlbiBpdCdzIG5v
dCBpbXBsZW1lbnRlZC4NCg0KT2ssIEkgd2FzIHRyeWluZyBkZWZpbmUgYW4gaW50ZXJmYWNlIGZv
ciBkcml2ZXIgdG8gcmV0dXJuIHZpZiB0eXBlIGJhc2VkDQplbmNhcC9kZWNhcCBjYXBhYmlsaXR5
IHNvIHRoYXQgaW4gNC1hZGRyIGFuZCBNZXNoIHR5cGUgODAyLjExIGZyYW1lIGZvcm1hdA0KaXMg
dXNlZC4NCg0KPg0KPj4gICBzdHJ1Y3QgaWVlZTgwMjExX29wcyB7DQo+PiAgIAl2b2lkICgqdHgp
KHN0cnVjdCBpZWVlODAyMTFfaHcgKmh3LA0KPj4gQEAgLTM2MzksNiArMzY1MSwxMCBAQCBzdHJ1
Y3QgaWVlZTgwMjExX29wcyB7DQo+PiAgIAl2b2lkICgqd2FrZV90eF9xdWV1ZSkoc3RydWN0IGll
ZWU4MDIxMV9odyAqaHcsDQo+PiAgIAkJCSAgICAgIHN0cnVjdCBpZWVlODAyMTFfdHhxICp0eHEp
Ow0KPj4gICAJdm9pZCAoKnN5bmNfcnhfcXVldWVzKShzdHJ1Y3QgaWVlZTgwMjExX2h3ICpodyk7
DQo+PiArDQo+PiArCWludCAoKmdldF92aWZfODAyMTFfaGRyX29mZmxvYWQpKHN0cnVjdCBpZWVl
ODAyMTFfaHcgKmh3LA0KPj4gKwkJCQkJIHN0cnVjdCBpZWVlODAyMTFfdmlmICp2aWYsDQo+PiAr
CQkJCQkgYm9vbCBpc180YWRkciwgYm9vbA0KPj4gKnN1cHBvcnRlZCk7DQo+DQo+IFdoeSBhcmUg
eW91IG5vdCBzaW1wbHkgcmV0dXJuaW5nICJzdXBwb3J0ZWQiPw0KPg0KPiBJIGRvbid0IGxpa2Ug
cGFzc2luZyB0aGUgdmlmIHBvaW50ZXIgaGVyZS4gQXQgdGhpcyBwb2ludCwgdGhlIHZpZg0KPiBw
b2ludGVyIGlzbid0IGtub3duIHRvIHRoZSBkcml2ZXIgeWV0ICh0aHJvdWdoIGRydl9hZGRfaW50
ZXJmYWNlKSBzbw0KPiBpdCdzIGEgZGVhZCBwb2ludGVyIGFzIGZhciBhcyB0aGUgc2VxdWVuY2lu
ZyBpcyBjb25jZXJuZWQuDQo+DQo+IElzIHRoZXJlIGEgcG9zc2liaWxpdHkgdGhhdCBkcml2ZXJz
IG5lZWQgdG8gc3dpdGNoIG9mZiBldGhlcm5ldCBmb3JtYXQNCj4gaGFuZGxpbmcgZW50aXJlbHkg
d2hlbiBhbiBpbmNvbXBhdGlibGUgaW50ZXJmYWNlIGlzIGFkZGVkPyBGb3IgZXhhbXBsZSwNCj4g
aWYgeW91IGFkZCBhIG1lc2ggaW50ZXJmYWNlLCBpcyB0aGVyZSBhIGNoYW5jZSB0aGF0IHRoZSBB
UCBpbnRlcmZhY2UNCj4gbWlnaHQgbm8gbG9uZ2VyIGJlIGFibGUgdG8gaGFuZGxlIHRoaXM/DQog
Pg0KID4gSSdkIGhvcGUgdGhpcyBkb2Vzbid0IGhhcHBlbiBiZWNhdXNlIEkgdGhpbmsgdGhhdCB3
b3VsZCBiZSBleHRyZW1lbHkNCiA+IGNvbXBsaWNhdGVkIHRvIGhhbmRsZSBzYWZlbHkuDQoNClVu
Zm9ydHVuYXRlbHkgIltSRkMgMi8zXSBtYWM4MDIxMTogSW1wbGVtZW50IGRhdGEgeG1pdCBmb3Ig
ODAyLjExIGVuY2FwIG9mZmxvYWQiDQp0cmllcyB0byBpbXBsZW1lbnQgdGhpcyBidXQgbW9yZSBs
aWtlbHkgYnVnZ3kgOiguIFlvdSBhcmUgcmlnaHQsIGl0IGlzIHZlcnkNCmNvbXBsZXggdG8gZ2V0
IHRoYXQgcmlnaHQuIE1heSBiZSB3ZSBzaG91bGQgbm90IGFsbG93IGludGVyZmFjZSBuZWVkaW5n
DQpkeW5hbWljIHN3aXRjaD8NCg0KVmFzYW50aA==

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-15  9:29   ` Johannes Berg
@ 2016-12-15 12:01     ` Thiagarajan, Vasanthakumar
  2016-12-15 13:32       ` Felix Fietkau
  0 siblings, 1 reply; 21+ messages in thread
From: Thiagarajan, Vasanthakumar @ 2016-12-15 12:01 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMjo1OSBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+IFRoZXJlIGlzIGEgZmllbGQsIG5vXzgwMjExX2VuY2FwLCBhZGRlZCB0byBpZWVl
ODAyMTFfdHhfaW5mbzpjb250cm9sDQo+PiB0byBtYXJrIGlmIHRoZSA4MDIuMTEgZW5jYXBzdWxh
dGlvbiBpcyBvZmZsb2FkZWQgdG8gZHJpdmVyLg0KPj4gVGhlcmUgaXMgYWxzbyBhIG5ldyBjYWxs
YmFjayBmb3IgdHggY29tcGxldGlvbiBzdGF0dXMgaW5kaWNhdGlvbg0KPj4gdG8gaGFuZGxlIGRh
dGEgZnJhbWVzIHVzaW5nIDgwMi4xMSBlbmNhcCBvZmZsb2FkLg0KPg0KPiBJJ20gbm90IHN1cmUg
SSBzZWUgdGhlIG5lZWQgZm9yIHRoaXM/IE1heWJlIEknbGwgZmluZCBvdXQgaW4gdGhpcyBwYXRj
aA0KPiA6KQ0KPg0KDQpJIHRoaW5rIHdlIG1heSBub3QgbmVlZCB0aGlzIGlmIHdlIG1ha2UgdGhl
IGRlc2lnbiBpbiBzdWNoIGEgd2F5IHRoYXQgYWxsDQp0aGUgaW50ZXJmYWNlcyB3aWxsIHVzZSB1
bmlmb3JtIGVuY2FwL2RlY2FwIG1vZGUgZm9yIHRoZSBkYXRhIHBhY2tldC4NCg0KPj4gKwkJCS8q
IFhYWDogVGhpcyBmcmFtZSBpcyBub3QgZW5jYXB0dWxhdGVkIHdpdGgNCj4+IDgwMi4xMQ0KPj4g
KwkJCSAqIGhlYWRlci4gU2hvdWxkIHRoaXMgYmUgYWRkZWQgdG8NCj4+ICVJRUVFODAyMTFfVFhf
Q1RSTF8qDQo+PiArCQkJICogZmxhZ3M/Lg0KPj4gKwkJCSAqLw0KPj4gKwkJCWJvb2wgbm9fODAy
MTFfZW5jYXA7DQo+PiArCQkJLyogMyBieXRlcyBmcmVlICovDQo+PiAgIAkJfSBjb250cm9sOw0K
Pg0KPiBwcm9iYWJseSAtIGp1c3QgdG8gcHJlc2VydmUgbW9yZSBzcGFjZS4NCg0KQ29ycmVjdC4N
Cg0KPg0KPj4gKyAqIEBJRUVFODAyMTFfQ09ORl9DSEFOR0VfODAyMTFfSERSX09GRkw6IE9mZmxv
YWQgY29uZmlndXJhdGlvbg0KPj4gKyAqCWltcGxlbWVudGluZyA4MDIuMTEgZW5jYXAvZGVjYXAg
Zm9yIGRhdGEgZnJhbWVzIGNoYW5nZWQuDQo+PiAgICAqLw0KPj4gICBlbnVtIGllZWU4MDIxMV9j
b25mX2NoYW5nZWQgew0KPj4gICAJSUVFRTgwMjExX0NPTkZfQ0hBTkdFX1NNUFMJCT0gQklUKDEp
LA0KPj4gQEAgLTEyNzksNiArMTI4Niw3IEBAIGVudW0gaWVlZTgwMjExX2NvbmZfY2hhbmdlZCB7
DQo+PiAgIAlJRUVFODAyMTFfQ09ORl9DSEFOR0VfQ0hBTk5FTAkJPSBCSVQoNiksDQo+PiAgIAlJ
RUVFODAyMTFfQ09ORl9DSEFOR0VfUkVUUllfTElNSVRTCT0gQklUKDcpLA0KPj4gICAJSUVFRTgw
MjExX0NPTkZfQ0hBTkdFX0lETEUJCT0gQklUKDgpLA0KPj4gKwlJRUVFODAyMTFfQ09ORl9DSEFO
R0VfODAyMTFfSERSX09GRkwJPSBCSVQoOSksDQo+PiAgIH07DQo+DQo+IEdpdmVuIHRoZSByZXF1
aXJlbWVudHMgKFBOIGNoZWNrLCBldGMuKSBJJ20gbm90IHN1cmUgaG93IHRoaXMgY2FuDQo+IGNo
YW5nZSBkeW5hbWljYWxseT8NCg0KSSBhZ3JlZS4gRHluYW1pYyBzd2l0Y2ggcGFydCBpcyBidWdn
eSwgd2UgY2FuIHN0YXJ0IHdpdGggbm90IGFsbG93aW5nDQppbnRlcmZhY2VzIHJlc3VsdGluZyBp
biBkeW5hbWljIHN3aXRjaC4NCg0KPg0KPj4gKyAqIEBlbmNhcF9kZWNhcF84MDIxMV9vZmZsb2Fk
ZWQ6IFdoZXRoZXIgODAyLjExIGhlYWRlciBlbmNhcC9kZWNhcA0KPj4gb2ZmbG9hZA0KPj4gKyAq
CWlzIGVuYWJsZWQNCj4+ICAgICovDQo+PiAgIHN0cnVjdCBpZWVlODAyMTFfY29uZiB7DQo+PiAg
IAl1MzIgZmxhZ3M7DQo+PiBAQCAtMTM0Niw2ICsxMzU3LDcgQEAgc3RydWN0IGllZWU4MDIxMV9j
b25mIHsNCj4+ICAgCXN0cnVjdCBjZmc4MDIxMV9jaGFuX2RlZiBjaGFuZGVmOw0KPj4gICAJYm9v
bCByYWRhcl9lbmFibGVkOw0KPj4gICAJZW51bSBpZWVlODAyMTFfc21wc19tb2RlIHNtcHNfbW9k
ZTsNCj4+ICsJYm9vbCBlbmNhcF9kZWNhcF84MDIxMV9vZmZsb2FkZWQ7DQo+DQo+IFBsZWFzZSBk
b24ndCBhZGQgYW55dGhpbmcgaGVyZSB0aGF0J3MgaW50ZXJmYWNlIHNwZWNpZmljLg0KDQpPaywg
dGhpcyBpcyBtYWlubHkgaHcgY29uZmlndXJhdGlvbiBvZiBlbmNhcC9kZWNhcCBtb2RlLCBub3QN
CnZpZiBzcGVjaWZpYyBwZXIgc2F5LiBBbnkgcG9pbnRlcnMgd2hlcmUgdGhpcyBzaG91bGQgYmVs
b25nIHRvPw0KDQo+DQo+PiAtLS0gYS9uZXQvbWFjODAyMTEvY2ZnLmMNCj4+ICsrKyBiL25ldC9t
YWM4MDIxMS9jZmcuYw0KPj4gQEAgLTEwNyw2ICsxMDcsMTAgQEAgc3RhdGljIGludCBpZWVlODAy
MTFfY2hhbmdlX2lmYWNlKHN0cnVjdCB3aXBoeQ0KPj4gKndpcGh5LA0KPj4gICAJCX0NCj4+ICAg
CX0NCj4+DQo+PiArCWllZWU4MDIxMV9pZl9jaGVja184MDIxMV9oZHJfb2ZmbChzZGF0YSwNCj4+
ICsJCQkJCSAgcGFyYW1zID8gcGFyYW1zLT51c2VfNGFkZHINCj4+IDogZmFsc2UsDQo+PiArCQkJ
CQkgIHRydWUpOw0KPj4gKw0KPj4gICAJcmV0dXJuIDA7DQo+PiAgIH0NCj4NCj4gV291bGRuJ3Qg
aXQgYmUgYmV0dGVyIHRvIHNpbXBseSBwcm9oaWJpdCBjaGFuZ2luZyB0aGlzIHdoaWxlIHRoZQ0K
PiBpbnRlcmZhY2UgaXMgdXAsIGFuZCByZS1pbml0IGl0IGxhdGVyIHdoZW4gaXQgZ29lcyB1cD8N
Cg0KSSBhZ3JlZS4NCg0KPg0KPj4gKysrIGIvbmV0L21hYzgwMjExL2llZWU4MDIxMV9pLmgNCj4+
IEBAIC0xMzczLDYgKzEzNzMsOCBAQCBzdHJ1Y3QgaWVlZTgwMjExX2xvY2FsIHsNCj4+ICAgCS8q
IFRETFMgY2hhbm5lbCBzd2l0Y2ggKi8NCj4+ICAgCXN0cnVjdCB3b3JrX3N0cnVjdCB0ZGxzX2No
c3dfd29yazsNCj4+ICAgCXN0cnVjdCBza19idWZmX2hlYWQgc2tiX3F1ZXVlX3RkbHNfY2hzdzsN
Cj4+ICsNCj4+ICsJYm9vbCBkYXRhXzgwMjExX2hkcl9vZmZsb2FkZWQ7DQo+DQo+IEFnYWluLCBk
b24ndCBwdXQgaW50ZXJmYWNlIHNwZWNpZmljIHRoaW5ncyBpbnRvIGRldmljZSBzdHJ1Y3R1cmVz
Lg0KDQpPaywgdGhpcyBpcyBhbHNvIGN1cnJlbnQgaHcgY29uZmlndXJhdGlvbiBvZiBlbmNhcC9k
ZWNhcCBtb2RlLCBub3QgdmlmDQpzcGVjaWZpYy4NCg0KPg0KPj4gK2ludCBpZWVlODAyMTFfbG9v
a3VwX3JhX3N0YShzdHJ1Y3QgaWVlZTgwMjExX3N1Yl9pZl9kYXRhICpzZGF0YSwNCj4+ICsJCQkg
ICAgc3RydWN0IHNrX2J1ZmYgKnNrYiwNCj4+ICsJCQkgICAgc3RydWN0IHN0YV9pbmZvICoqc3Rh
X291dCk7DQo+DQo+IFJldHVybiB0aGUgc3RhX2luZm8gcG9pbnRlciwgYW5kIEVSUl9QVFIoKSBp
ZiBuZWVkZWQuDQoNCkNvcnJlY3QsIHN0YV9vdXQgaXMgY2hlY2tlZCBmb3IgRVJSX1BUUigpIGFz
IHdlbGwgYmVmb3JlIHVzaW5nIGl0Lg0KDQo+DQo+PiArKysgYi9uZXQvbWFjODAyMTEvaWZhY2Uu
Yw0KPj4gQEAgLTY5OCw2ICs2OTgsMTEgQEAgaW50IGllZWU4MDIxMV9kb19vcGVuKHN0cnVjdCB3
aXJlbGVzc19kZXYgKndkZXYsDQo+PiBib29sIGNvbWluZ191cCkNCj4+ICAgCQlyY3VfYXNzaWdu
X3BvaW50ZXIobG9jYWwtPnAycF9zZGF0YSwgc2RhdGEpOw0KPj4gICAJfQ0KPj4NCj4+ICsJaWYg
KGxvY2FsLT5vcGVuX2NvdW50ID09IDAgJiYgbG9jYWwtDQo+Pj4gZGF0YV84MDIxMV9oZHJfb2Zm
bG9hZGVkKSB7DQo+PiArCQlsb2NhbC0+aHcuY29uZi5lbmNhcF9kZWNhcF84MDIxMV9vZmZsb2Fk
ZWQgPSB0cnVlOw0KPj4gKwkJaHdfcmVjb25mX2ZsYWdzIHw9DQo+PiBJRUVFODAyMTFfQ09ORl9D
SEFOR0VfODAyMTFfSERSX09GRkw7DQo+PiArCX0NCj4NCj4gSSBkb24ndCBzZWUgaG93IHRoaXMg
aGVscHMgYW55dGhpbmcsIEkgdGhpbmsgeW91IHNob3VsZCByZW1vdmUgaXQuDQoNClllYWgsIEkg
dGhpbmsgdGhpcyB3YXMgYWRkZWQgZm9yIGR5bmFtaWMgc3dpdGNoLg0KDQo+DQo+PiArdm9pZCBp
ZWVlODAyMTFfaWZfY29uZmlnXzgwMjExX2hkcl9vZmZsKHN0cnVjdCBpZWVlODAyMTFfbG9jYWwN
Cj4+ICpsb2NhbCwNCj4+ICsJCQkJCWJvb2wgZW5hYmxlXzgwMjExX2hkcl9vZmZsKQ0KPj4gK3sN
Cj4+ICsJc3RydWN0IGllZWU4MDIxMV9zdWJfaWZfZGF0YSAqc2RhdGE7DQo+PiArCXVuc2lnbmVk
IGxvbmcgZmxhZ3M7DQo+PiArCWludCBuX2FjcyA9IElFRUU4MDIxMV9OVU1fQUNTOw0KPj4gKwlp
bnQgYWM7DQo+PiArDQo+PiArCUFTU0VSVF9SVE5MKCk7DQo+PiArDQo+PiArCWlmICghaWVlZTgw
MjExX2h3X2NoZWNrKCZsb2NhbC0+aHcsDQo+PiBTVVBQT1JUU184MDIxMV9FTkNBUF9ERUNBUCkg
fHwNCj4+ICsJICAgICEoaWVlZTgwMjExX2h3X2NoZWNrKCZsb2NhbC0+aHcsIEhBU19SQVRFX0NP
TlRST0wpKSkNCj4+ICsJCXJldHVybjsNCj4+ICsNCj4+ICsJaWYgKGxvY2FsLT5ody53aXBoeS0+
ZnJhZ190aHJlc2hvbGQgIT0gKHUzMiktMSAmJg0KPj4gKwkgICAgIWxvY2FsLT5vcHMtPnNldF9m
cmFnX3RocmVzaG9sZCkNCj4+ICsJCXJldHVybjsNCj4+ICsNCj4+ICsJbXV0ZXhfbG9jaygmbG9j
YWwtPmlmbGlzdF9tdHgpOw0KPj4gKw0KPj4gKwlsaXN0X2Zvcl9lYWNoX2VudHJ5KHNkYXRhLCAm
bG9jYWwtPmludGVyZmFjZXMsIGxpc3QpIHsNCj4+ICsJCWlmICghc2RhdGEtPmRldikNCj4+ICsJ
CQljb250aW51ZTsNCj4+ICsNCj4+ICsJCW5ldGlmX3R4X3N0b3BfYWxsX3F1ZXVlcyhzZGF0YS0+
ZGV2KTsNCj4+ICsNCj4+ICsJCWlmIChlbmFibGVfODAyMTFfaGRyX29mZmwpDQo+PiArCQkJc2Rh
dGEtPmRldi0+bmV0ZGV2X29wcyA9DQo+PiAmaWVlZTgwMjExX2RhdGFpZl84MDIzX29wczsNCj4+
ICsJCWVsc2UNCj4+ICsJCQlzZGF0YS0+ZGV2LT5uZXRkZXZfb3BzID0NCj4+ICZpZWVlODAyMTFf
ZGF0YWlmX29wczsNCj4+ICsJfQ0KPj4gKw0KPj4gKwltdXRleF91bmxvY2soJmxvY2FsLT5pZmxp
c3RfbXR4KTsNCj4+ICsNCj4+ICsJbG9jYWwtPmRhdGFfODAyMTFfaGRyX29mZmxvYWRlZCA9IGVu
YWJsZV84MDIxMV9oZHJfb2ZmbDsNCj4+ICsNCj4+ICsJaWYgKGxvY2FsLT5zdGFydGVkKSB7DQo+
PiArCQlpZiAoZW5hYmxlXzgwMjExX2hkcl9vZmZsKQ0KPj4gKwkJCWxvY2FsLT5ody5jb25mLmVu
Y2FwX2RlY2FwXzgwMjExX29mZmxvYWRlZCA9DQo+PiB0cnVlOw0KPj4gKwkJZWxzZQ0KPj4gKwkJ
CWxvY2FsLT5ody5jb25mLmVuY2FwX2RlY2FwXzgwMjExX29mZmxvYWRlZCA9DQo+PiBmYWxzZTsN
Cj4+ICsJCWllZWU4MDIxMV9od19jb25maWcobG9jYWwsDQo+PiArCQkJCSAgICBJRUVFODAyMTFf
Q09ORl9DSEFOR0VfODAyMTFfSERSXw0KPj4gT0ZGTCk7DQo+PiArCX0NCj4+ICsNCj4+ICsJbXV0
ZXhfbG9jaygmbG9jYWwtPmlmbGlzdF9tdHgpOw0KPj4gKw0KPj4gKwlsaXN0X2Zvcl9lYWNoX2Vu
dHJ5KHNkYXRhLCAmbG9jYWwtPmludGVyZmFjZXMsIGxpc3QpIHsNCj4+ICsJCWlmICghc2RhdGEt
PmRldikNCj4+ICsJCQljb250aW51ZTsNCj4+ICsNCj4+ICsJCWlmIChsb2NhbC0+aHcucXVldWVz
IDwgSUVFRTgwMjExX05VTV9BQ1MpDQo+PiArCQkJbl9hY3MgPSAxOw0KPj4gKw0KPj4gKwkJc3Bp
bl9sb2NrX2lycXNhdmUoJmxvY2FsLT5xdWV1ZV9zdG9wX3JlYXNvbl9sb2NrLA0KPj4gZmxhZ3Mp
Ow0KPj4gKwkJaWYgKHNkYXRhLT52aWYuY2FiX3F1ZXVlID09IElFRUU4MDIxMV9JTlZBTF9IV19R
VUVVRQ0KPj4gfHwNCj4+ICsJCSAgICAobG9jYWwtPnF1ZXVlX3N0b3BfcmVhc29uc1tzZGF0YS0+
dmlmLmNhYl9xdWV1ZV0NCj4+ID09IDAgJiYNCj4+ICsJCSAgICAgc2tiX3F1ZXVlX2VtcHR5KCZs
b2NhbC0+cGVuZGluZ1tzZGF0YS0NCj4+PiB2aWYuY2FiX3F1ZXVlXSkpKSB7DQo+PiArCQkJZm9y
IChhYyA9IDA7IGFjIDwgbl9hY3M7IGFjKyspIHsNCj4+ICsJCQkJaW50IGFjX3F1ZXVlID0gc2Rh
dGEtDQo+Pj4gdmlmLmh3X3F1ZXVlW2FjXTsNCj4+ICsNCj4+ICsJCQkJaWYgKGxvY2FsLQ0KPj4+
IHF1ZXVlX3N0b3BfcmVhc29uc1thY19xdWV1ZV0gPT0gMCAmJg0KPj4gKwkJCQkgICAgc2tiX3F1
ZXVlX2VtcHR5KCZsb2NhbC0NCj4+PiBwZW5kaW5nW2FjX3F1ZXVlXSkpDQo+PiArCQkJCQluZXRp
Zl9zdGFydF9zdWJxdWV1ZShzZGF0YS0NCj4+PiBkZXYsIGFjKTsNCj4+ICsJCQl9DQo+PiArCQl9
DQo+PiArCQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZsb2NhbC0NCj4+PiBxdWV1ZV9zdG9wX3Jl
YXNvbl9sb2NrLCBmbGFncyk7DQo+PiArCX0NCj4+ICsNCj4+ICsJbXV0ZXhfdW5sb2NrKCZsb2Nh
bC0+aWZsaXN0X210eCk7DQo+PiArfQ0KPg0KPiBJIHJlYWxseSB3b3VsZCBwcmVmZXIgd2UgY291
bGQgc2ltcGx5IGF2b2lkIGRvaW5nIHRoZXNlIG1hbmlwdWxhdGlvbnMNCj4gd2hpbGUgdGhlIGlu
dGVyZmFjZSBpcyBVUCBhbmQgY2FuIGhhdmUgZGF0YSBxdWV1ZWQuDQoNCkFncmVlZC4NCg0KPg0K
Pj4gKysrIGIvbmV0L21hYzgwMjExL2tleS5jDQo+PiBAQCAtMjA4LDEzICsyMDgsMjUgQEAgc3Rh
dGljIGludCBpZWVlODAyMTFfa2V5X2VuYWJsZV9od19hY2NlbChzdHJ1Y3QNCj4+IGllZWU4MDIx
MV9rZXkgKmtleSkNCj4+ICAgCWNhc2UgV0xBTl9DSVBIRVJfU1VJVEVfR0NNUF8yNTY6DQo+PiAg
IAkJLyogYWxsIG9mIHRoZXNlIHdlIGNhbiBkbyBpbiBzb2Z0d2FyZSAtIGlmIGRyaXZlcg0KPj4g
Y2FuICovDQo+PiAgIAkJaWYgKHJldCA9PSAxKQ0KPj4gLQkJCXJldHVybiAwOw0KPj4gKwkJCWdv
dG8gY2hlY2tfODAyM190eHJ4Ow0KPj4gICAJCWlmIChpZWVlODAyMTFfaHdfY2hlY2soJmtleS0+
bG9jYWwtPmh3LA0KPj4gU1dfQ1JZUFRPX0NPTlRST0wpKQ0KPj4gICAJCQlyZXR1cm4gLUVJTlZB
TDsNCj4+IC0JCXJldHVybiAwOw0KPj4gKwkJZ290byBjaGVja184MDIzX3R4cng7DQo+PiAgIAlk
ZWZhdWx0Og0KPj4gICAJCXJldHVybiAtRUlOVkFMOw0KPj4gICAJfQ0KPj4gKw0KPj4gK2NoZWNr
XzgwMjNfdHhyeDoNCj4+ICsJLyogV2hlbiBzdyBjcnlwdG8gaXMgZW5hYmxlZCBtYWtlIHN1cmUg
ZGF0YSB0eC9yeCBoYXBwZW5zDQo+PiArCSAqIGluIDgwMi4xMSBmb3JtYXQuDQo+PiArCSAqLw0K
Pj4gKwlpZiAoa2V5LT5sb2NhbC0+ZGF0YV84MDIxMV9oZHJfb2ZmbG9hZGVkKSB7DQo+PiArCQly
dG5sX2xvY2soKTsNCj4+ICsJCWllZWU4MDIxMV9pZl9jb25maWdfODAyMTFfaGRyX29mZmwoa2V5
LT5sb2NhbCwNCj4+IGZhbHNlKTsNCj4+ICsJCXJ0bmxfdW5sb2NrKCk7DQo+PiArCX0NCj4+ICsN
Cj4+ICsJcmV0dXJuIDA7DQo+PiAgIH0NCj4NCj4gV2h5IG5vdCBqdXN0IHJlZnVzZSB0aGUga2V5
IGluc3RlYWQ/IEl0IGFsc28gc2VlbXMgd3JvbmcgdG8gZG8gYW55dGhpbmcNCj4gd2l0aCBsb2Nh
bC0+IGhlcmUsIGl0IHNob3VsZCBiZSBwZXIgaW50ZXJmYWNlLg0KDQpDb3JyZWN0LiBIZXJlIGFs
c28gZW5jYXAvZGVjYXAgdHlwZSBzd2l0Y2ggaGFwcGVucywgdGhpcyBjYW4gYmUgYXZvaWRlZCBq
dXN0DQpyZWZ1c2luZyB0aGUga2V5Lg0KDQo+DQo+PiArKysgYi9uZXQvbWFjODAyMTEvc3RhdHVz
LmMNCj4+IEBAIC01MDYsMTIgKzUwNiwxNCBAQCBzdGF0aWMgdm9pZCBpZWVlODAyMTFfcmVwb3J0
X3VzZWRfc2tiKHN0cnVjdA0KPj4gaWVlZTgwMjExX2xvY2FsICpsb2NhbCwNCj4+ICAgCQkJCSAg
ICAgIHN0cnVjdCBza19idWZmICpza2IsIGJvb2wNCj4+IGRyb3BwZWQpDQo+PiAgIHsNCj4+ICAg
CXN0cnVjdCBpZWVlODAyMTFfdHhfaW5mbyAqaW5mbyA9IElFRUU4MDIxMV9TS0JfQ0Ioc2tiKTsN
Cj4+IC0Jc3RydWN0IGllZWU4MDIxMV9oZHIgKmhkciA9ICh2b2lkICopc2tiLT5kYXRhOw0KPj4g
KwlzdHJ1Y3QgaWVlZTgwMjExX2hkciAqaGRyOw0KPj4gICAJYm9vbCBhY2tlZCA9IGluZm8tPmZs
YWdzICYgSUVFRTgwMjExX1RYX1NUQVRfQUNLOw0KPj4NCj4+ICAgCWlmIChkcm9wcGVkKQ0KPj4g
ICAJCWFja2VkID0gZmFsc2U7DQo+Pg0KPj4gKwloZHIgPSAodm9pZCAqKXNrYi0+ZGF0YTsNCj4N
Cj4gVGhhdCBjaGFuZ2UgbWFrZSBubyBzZW5zZS4NCg0KWWVzLCBJIGZvcmdvdCB0byByZW1vdmUg
dGhpcy4NCg0KPg0KPj4gICAJaWYgKGluZm8tPmZsYWdzICYgSUVFRTgwMjExX1RYX0lOVEZMX01M
TUVfQ09OTl9UWCkgew0KPj4gICAJCXN0cnVjdCBpZWVlODAyMTFfc3ViX2lmX2RhdGEgKnNkYXRh
Ow0KPj4NCj4+IEBAIC05NDUsNiArOTQ3LDg1IEBAIHZvaWQgaWVlZTgwMjExX3R4X3N0YXR1cyhz
dHJ1Y3QgaWVlZTgwMjExX2h3DQo+PiAqaHcsIHN0cnVjdCBza19idWZmICpza2IpDQo+PiAgIH0N
Cj4+ICAgRVhQT1JUX1NZTUJPTChpZWVlODAyMTFfdHhfc3RhdHVzKTsNCj4+DQo+PiArdm9pZCBp
ZWVlODAyMTFfdHhfc3RhdHVzXzgwMjMoc3RydWN0IGllZWU4MDIxMV9odyAqaHcsDQo+PiArCQkJ
ICAgICAgc3RydWN0IGllZWU4MDIxMV92aWYgKnZpZiwNCj4+ICsJCQkgICAgICBzdHJ1Y3Qgc2tf
YnVmZiAqc2tiKQ0KPg0KPiBJIHRoaW5rIHRoaXMgY291bGQgc2hhcmUgc29tZSBjb2RlIHdpdGgg
dGhlIDgwMi4xMSB2ZXJzaW9uPw0KPg0KPj4gKwkvKiBYWFg6IEFkZCBhIGdlbmVyaWMgaGVscGVy
IGZvciB0aGlzICovDQo+PiArCWlmIChzZGF0YS0+dmlmLnR5cGUgPT0gTkw4MDIxMV9JRlRZUEVf
QVAgfHwNCj4+ICsJICAgIHNkYXRhLT52aWYudHlwZSA9PSBOTDgwMjExX0lGVFlQRV9BUF9WTEFO
IHx8DQo+PiArCSAgICBzZGF0YS0+dmlmLnR5cGUgPT0gTkw4MDIxMV9JRlRZUEVfQURIT0MpDQo+
PiArCQlldGhlcl9hZGRyX2NvcHkocmFfYWRkciwgZWhkci0+aF9kZXN0KTsNCj4NCj4gbml0LCBi
dXQgdGhlICJBIiBpbiAiUkEiIGFscmVhZHkgbWVhbnMgYWRkcmVzcyAuLi4gOikNCg0KU3VyZSwg
dGhhbmtzLg0KDQo+DQo+IFlvdSBhbHNvIGRvbid0IG5lZWQgdG8gY29weSBpdCAtIGp1c3Qga2Vl
cGluZyBhIHBvaW50ZXIgc2hvdWxkIGJlIGZpbmU/DQoNClJpZ2h0Lg0KDQo+DQo+PiArCS8qIFRP
RE86IEhhbmRsZSBmcmFtZXMgcmVxdWlyaW5nIHdpZmkgdHggc3RhdHVzIHRvIGJlDQo+PiBub3Rp
ZmllZCAqLw0KPj4gKwlpZiAoc2tiLT5zayAmJiBza2Jfc2hpbmZvKHNrYiktPnR4X2ZsYWdzICYN
Cj4+IFNLQlRYX1dJRklfU1RBVFVTKQ0KPj4gKwkJZ290byBvdXRfZnJlZTsNCj4NCj4gU3VyZWx5
IHlvdSBzaG91bGRuJ3QgZnJlZSB0aGVtLCBldmVuIGlmIHlvdSBkb24ndCBoYW5kbGUgdGhlIHN0
YXR1cz8hDQoNCkNvcnJlY3QsIEkgdGhpbmsgd2UgY2FuIHN0aWxsIHBhc3MgdGhlIGZyYW1lIHRv
IGdvIHRocm91Z2ggZXZlbiBpZiB0eCBzdGF0dXMNCmlzIG5vdCBoYW5kbGVkLg0KDQpWYXNhbnRo
DQo=

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-15 12:01     ` Thiagarajan, Vasanthakumar
@ 2016-12-15 13:32       ` Felix Fietkau
  2016-12-15 13:53         ` Johannes Berg
  0 siblings, 1 reply; 21+ messages in thread
From: Felix Fietkau @ 2016-12-15 13:32 UTC (permalink / raw)
  To: Thiagarajan, Vasanthakumar, Johannes Berg; +Cc: linux-wireless

On 2016-12-15 13:01, Thiagarajan, Vasanthakumar wrote:
> On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote:
>>> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
>>> + *	implementing 802.11 encap/decap for data frames changed.
>>>    */
>>>   enum ieee80211_conf_changed {
>>>   	IEEE80211_CONF_CHANGE_SMPS		= BIT(1),
>>> @@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
>>>   	IEEE80211_CONF_CHANGE_CHANNEL		= BIT(6),
>>>   	IEEE80211_CONF_CHANGE_RETRY_LIMITS	= BIT(7),
>>>   	IEEE80211_CONF_CHANGE_IDLE		= BIT(8),
>>> +	IEEE80211_CONF_CHANGE_80211_HDR_OFFL	= BIT(9),
>>>   };
>>
>> Given the requirements (PN check, etc.) I'm not sure how this can
>> change dynamically?
> 
> I agree. Dynamic switch part is buggy, we can start with not allowing
> interfaces resulting in dynamic switch.
Does this mean that when bringing up multiple interfaces, users would
need to figure out the 'magic' order that works?

- Felix

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-15 13:32       ` Felix Fietkau
@ 2016-12-15 13:53         ` Johannes Berg
  2016-12-16  5:37           ` Thiagarajan, Vasanthakumar
  0 siblings, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2016-12-15 13:53 UTC (permalink / raw)
  To: Felix Fietkau, Thiagarajan, Vasanthakumar; +Cc: linux-wireless


> > I agree. Dynamic switch part is buggy, we can start with not
> > allowing interfaces resulting in dynamic switch.
> 
> Does this mean that when bringing up multiple interfaces, users would
> need to figure out the 'magic' order that works?

I think we need to talk about hardware capabilities at this point.

I was assuming that it would actually be possible to run two interfaces
with different paths here concurrently - is that not true? If that's
not true, then we absolutely _need_ dynamic switching, I agree with
Felix, but then we have a pretty big complication to figure out. But we
can't let this optimisation affect user experience.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-15 13:53         ` Johannes Berg
@ 2016-12-16  5:37           ` Thiagarajan, Vasanthakumar
  2016-12-16  9:25             ` Johannes Berg
  2016-12-19 11:45             ` Kalle Valo
  0 siblings, 2 replies; 21+ messages in thread
From: Thiagarajan, Vasanthakumar @ 2016-12-16  5:37 UTC (permalink / raw)
  To: Johannes Berg, nbd; +Cc: linux-wireless

T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwNzoyMyBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+PiBJIGFncmVlLiBEeW5hbWljIHN3aXRjaCBwYXJ0IGlzIGJ1Z2d5LCB3ZSBjYW4g
c3RhcnQgd2l0aCBub3QNCj4+PiBhbGxvd2luZyBpbnRlcmZhY2VzIHJlc3VsdGluZyBpbiBkeW5h
bWljIHN3aXRjaC4NCj4+DQo+PiBEb2VzIHRoaXMgbWVhbiB0aGF0IHdoZW4gYnJpbmdpbmcgdXAg
bXVsdGlwbGUgaW50ZXJmYWNlcywgdXNlcnMgd291bGQNCj4+IG5lZWQgdG8gZmlndXJlIG91dCB0
aGUgJ21hZ2ljJyBvcmRlciB0aGF0IHdvcmtzPw0KPg0KPiBJIHRoaW5rIHdlIG5lZWQgdG8gdGFs
ayBhYm91dCBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXQgdGhpcyBwb2ludC4NCg0KUUNBOTg4WCBk
b2VzIG5vdCBoYXZlIGNhcGFiaWxpdHkgdG8gY29uZmlndXJlIHZpZiBzcGVjaWZpYyBkZWNhcCBt
b2RlLiBFbmNhcCBtb2RlDQppcyBjb25maWd1cmFibGUgcGVyIHBhY2tldCBmb3IgYWxsIHRoZSBh
dGgxMGsgYmFzZWQgY2hpcHMgc28gdGhpcyBwYXJ0IHNob3VsZCBiZQ0KZmluZSB0byBzdXBwb3J0
IHBlciB2aWYgY29uZmlndXJhdGlvbi4gTmV3ZXIgUUNBIGNoaXBzIGxpa2UgUUNBOTk4NCwgUUNB
NDAxOSwgUUNBOTg4OA0KYW5kIFFDQTk5WDAgc3VwcG9ydHMgZGVjYXAgbW9kZSBjb25maWd1cmF0
aW9uIHBlciB2aWYuIFRvIHJlZHVjZSB0aGUgY29tcGxleGl0eSwNCndlIGNhbiBwcm9iYWJseSBt
YWtlIHBlciB2aWYgZW5jYXAvZGVjYXAgY29uZmlndXJhdGlvbiBtYW5kYXRvcnkgdG8gZW5hYmxl
IGV0aGVybmV0DQpmcmFtZSBmb3JtYXQsIG5vdCBzdXJlIGhvdyB0aGlzIHdpbGwgd29yayB3aXRo
IG5vbi1RQ0EgY2FwYWJsZSBoYXJkd2FyZS4NCg0KPg0KPiBJIHdhcyBhc3N1bWluZyB0aGF0IGl0
IHdvdWxkIGFjdHVhbGx5IGJlIHBvc3NpYmxlIHRvIHJ1biB0d28gaW50ZXJmYWNlcw0KPiB3aXRo
IGRpZmZlcmVudCBwYXRocyBoZXJlIGNvbmN1cnJlbnRseSAtIGlzIHRoYXQgbm90IHRydWU/IElm
IHRoYXQncw0KPiBub3QgdHJ1ZSwgdGhlbiB3ZSBhYnNvbHV0ZWx5IF9uZWVkXyBkeW5hbWljIHN3
aXRjaGluZywgSSBhZ3JlZSB3aXRoDQo+IEZlbGl4LCBidXQgdGhlbiB3ZSBoYXZlIGEgcHJldHR5
IGJpZyBjb21wbGljYXRpb24gdG8gZmlndXJlIG91dC4gQnV0IHdlDQo+IGNhbid0IGxldCB0aGlz
IG9wdGltaXNhdGlvbiBhZmZlY3QgdXNlciBleHBlcmllbmNlLg0KDQpTdXJlLg0KDQpWYXNhbnRo

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format
  2016-12-15  9:38   ` Johannes Berg
@ 2016-12-16  6:47     ` Thiagarajan, Vasanthakumar
  2016-12-16  9:13       ` Johannes Berg
  0 siblings, 1 reply; 21+ messages in thread
From: Thiagarajan, Vasanthakumar @ 2016-12-16  6:47 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMzowOCBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+IFRoaXMgcnggcGF0aCBvbmx5IGNoZWNrcyBpZiB0aGUgZHJpdmVyIGhhcyBhZHZl
cnRpc2VkDQo+PiBpdCdzIHN1cHBvcnQgb2YgODAyLjExIGhlYWRlciBlbmNhcC9kZWNhcCBvZmZs
b2FkIGZvcg0KPj4gZGF0YSBmcmFtZXMuDQo+DQo+IEknbSBub3QgZXZlbiBzdXJlIEkgc2VlIHRo
ZSBwb2ludCBpbiB0aGF0PyBPdGhlciB0aGFuIHRoYXQgKGFuZCB0aGUNCj4gdmFyaW91cyBvdGhl
ciBvZmZsb2FkIHJlcXVpcmVtZW50cyksIGl0IHNlZW1zIHRoYXQgZW5jYXAvZGVjYXAgY291bGQg
YmUNCj4gY29uc2lkZXJlZCBvcnRob2dvbmFsLg0KDQpPay4gU28gaXQgaXMgbWFpbmx5IGZvciBl
bmNhcCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudA0KZnJv
bSBkcml2ZXIgYmVjYXVzZSBmb3IgZGVjYXAgZHJpdmVyIHdvdWxkIHVzZSBhcHByb3ByaWF0ZSBt
YWM4MDIxMSBSeCBmdW5jdGlvbg0KdG8gaW5kaWNhdGU/DQoNCj4NCj4+ICsJICogQWRob2MgaW50
ZXJmYWNlIGRlcGVuZHMgb24gYnNzaWQgdG8gdWRwYXRlIGxhc3RfcnguDQo+DQo+IHR5cGUgLSB1
cGRhdGUNCj4NCj4+ICsJaWYgKCEoc3RhdHVzLT5mbGFnICYgUlhfRkxBR19NQ0FTVCkpIHsNCj4+
ICsJCXN0YS0+cnhfc3RhdHMubGFzdF9yeCA9IGppZmZpZXM7DQo+PiArCQlzdGEtPnJ4X3N0YXRz
Lmxhc3RfcmF0ZSA9DQo+PiBzdGFfc3RhdHNfZW5jb2RlX3JhdGUoc3RhdHVzKTsNCj4+ICsJfQ0K
Pg0KPiBZb3Ugc2hvdWxkIHByb2JhYmx5IHJlbmFtZSB0aGF0IGZsYWcgdG8gc29tZXRoaW5nIGxp
a2UNCj4gUlhfRkxBR184MDIxMV9NQ0FTVCBzaW5jZSBvdGhlcndpc2UgaXQncyBjb25mdXNpbmcg
d2l0aCB0aGUgbmV4dA0KPiBtdWx0aWNhc3QgZXRoZXIgYWRkciBjaGVjazoNCg0KU3VyZS4NCg0K
Pg0KPj4gKwlpZiAoc2RhdGEtPnZpZi50eXBlID09IE5MODAyMTFfSUZUWVBFX1NUQVRJT04gJiYN
Cj4+ICsJICAgICFpc19tdWx0aWNhc3RfZXRoZXJfYWRkcihlaGRyLT5oX2Rlc3QpKQ0KPj4gKwkJ
aWVlZTgwMjExX3N0YV9yZXNldF9jb25uX21vbml0b3Ioc2RhdGEpOw0KPg0KPiBCdXQgdGhpcyBj
b3VsZCBqdXN0IGFsc28gdXNlIHRoZSBmbGFnLCBzaW5jZSBpbiBzdGF0aW9uIG1vZGUgdGhlIHR3
bw0KPiBhcmUgZXF1aXZhbGVudCwgYW5kIGl0J2QgYmUgZWFzaWVyIHRvIGZpZ3VyZSBvdXQgaWYg
dGhpcyB3YXMgImVsc2UgaWYNCj4gKHN0YXRpb24gbW9kZSkiPw0KDQpBaCwgY29ycmVjdC4NCg0K
Pg0KPj4gKwltZW1zZXQoJnJ4LCAwLCBzaXplb2YocngpKTsNCj4NCj4gVGhhdCBzZWVtcyBhIGJp
dCBwb2ludGxlc3M/DQoNCkhtbW0sIGlzIGl0IG5vdCB0aGF0IGFsbCBtZW1iZXIgb3RoZXIgdGhh
biB0aGUgb25lcyBpbml0aWFsaXplZCB3aWxsIGJlIGp1bmsgYW5kIG1pZ2h0DQpyZXN1bHQgaW4g
Y3Jhc2ggd2hlbiBhY2Nlc3NpbmcgdW5pbml0aWFsaXplZCBwb2ludGVyIG1lbWJlciBsaWtlIG5h
cGk/DQoNCj4NCj4+ICsJcnguc2tiID0gc2tiOw0KPj4gKwlyeC5zZGF0YSA9IHNkYXRhOw0KPj4g
KwlyeC5sb2NhbCA9IGxvY2FsOw0KPj4gKwlyeC5zdGEgPSBzdGE7DQo+PiArDQo+PiArCWlmICh2
aWYtPnR5cGUgPT0gTkw4MDIxMV9JRlRZUEVfQVBfVkxBTiAmJiBzZGF0YS0+YnNzICYmDQo+PiAr
CSAgICB1bmxpa2VseShlaGRyLT5oX3Byb3RvID09IHNkYXRhLT5jb250cm9sX3BvcnRfcHJvdG9j
b2wpKQ0KPj4gew0KPj4gKwkJc2RhdGEgPSBjb250YWluZXJfb2Yoc2RhdGEtPmJzcywgc3RydWN0
DQo+PiBpZWVlODAyMTFfc3ViX2lmX2RhdGEsDQo+PiArCQkJCSAgICAgdS5hcCk7DQo+PiArCQlk
ZXYgPSBzZGF0YS0+ZGV2Ow0KPj4gKwkJcnguc2RhdGEgPSBzZGF0YTsNCj4+ICsJfQ0KPj4gKw0K
Pj4gKwlyeC5za2ItPmRldiA9IGRldjsNCj4+ICsNCj4+ICsJLyogWFhYOiBTaW5jZSByeC5zZXFu
b19pZHggaXMgbm90IGF2YWlsYWJsZSBmb3IgZGVjYXANCj4+IG9mZmxvYWRlZCBmcmFtZXMNCj4+
ICsJICogcnggbXNkdSBzdGF0cyB1cGRhdGUgYXQgdGhlIHNlcW5vX2lkeCBpbg0KPj4gaWVlZTgw
MjExX2RlbGl2ZXJfc2tiKCkNCj4+ICsJICogd2lsbCBhbHdheXMgYmUgdXBkYXRlZCBhdCBpbmRl
eCAwIGFuZCB3aWxsIG5vdCBiZSB2ZXJ5DQo+PiB1c2VmdWwuDQo+PiArCSAqLw0KPj4gKwlpZWVl
ODAyMTFfZGVsaXZlcl9za2IoJnJ4KTsNCj4NCj4gWWVhaCwgdGhhdCdzIG5vdCBuaWNlIC0gcGVy
aGFwcyB3ZSBjYW4gcHJvdmlkZSB0aGUgVElEIG91dCBvZiBiYW5kPw0KDQpSaWdodC4gVGhpcyBp
cyBwb3NzaWJsZSB3aXRoIGF0aDEwayB3aGVyZSA4MDIuMTEgaGVhZGVyIGlzIGFsc28gYXZhaWxh
YmxlIGluIFJ4DQpkZXNjIG9mIHRoZSBmcmFtZSBpcnJlc3BlY3RpdmUgb2YgdGhlIGZvcm1hdCBv
ZiB0aGUgUnggcGF5bG9hZA0KDQogIElmDQo+IG5vdCwgd2UnbGwgaGF2ZSB0byBkaXNhYmxlIHRo
b3NlIHN0YXRpc3RpY3MgKmFsbCB0aGUgd2F5KiwgaS5lLiBub3QNCj4gZXZlbiByZXBvcnQgdGhl
bSB0byB1c2Vyc3BhY2Ugd2hlbiBmaWxsaW5nIHNpbmZvLg0KDQpZZXMsIHRoaXMgbWF5IGJlIHRo
ZSBvcHRpb24gd2hlbiBkcml2ZXIgaXMgdW5hd2FyZSBvZiByeCBwYWNrZXQgdGlkLg0KDQo+DQo+
PiArCXJldHVybjsNCj4+ICsNCj4+ICttaWNfZmFpbDoNCj4+ICsJY2ZnODAyMTFfbWljaGFlbF9t
aWNfZmFpbHVyZShzZGF0YS0+ZGV2LCBzdGEtPmFkZHIsDQo+PiArCQkJCSAgICAgKHN0YXR1cy0+
ZmxhZyAmIFJYX0ZMQUdfTUNBU1QpDQo+PiA/DQo+PiArCQkJCSAgICAgTkw4MDIxMV9LRVlUWVBF
X0dST1VQIDoNCj4+ICsJCQkJICAgICBOTDgwMjExX0tFWVRZUEVfUEFJUldJU0UsDQo+PiArCQkJ
CSAgICAga2V5ID8ga2V5LT5jb25mLmtleWlkeCA6IC0xLA0KPj4gKwkJCQkgICAgIE5VTEwsIEdG
UF9BVE9NSUMpOw0KPg0KPiBEbyB3ZSByZWFsbHkgd2FudCB0byBoYW5kbGUgdGhhdCBpbmxpbmUg
aGVyZT8gVGhlIGRyaXZlciBwcm9iYWJseSBoYXMgYQ0KPiBkaWZmZXJlbnQgY2hlY2sgdG8gZXZl
biBzZXQgUlhfRkxBR19NTUlDX0VSUk9SLCBzbyB3ZSBjb3VsZCBqdXN0IGFzayBpdA0KPiB0byBj
YWxsIGNmZzgwMjExX21pY2hhZWxfbWljX2ZhaWx1cmUoKSBbb3IgYSB3cmFwcGVyIHRvIGdldCBz
ZGF0YS0+ZGV2XQ0KPiBpbnN0ZWFkPyBJIGd1ZXNzIHRoaXMgd29ya3MgdG9vIHRob3VnaCwgYW5k
IG1pZ2h0IGJlIGVhc2llciB0bw0KPiB1bmRlcnN0YW5kLg0KDQpZZWFoLCBkcml2ZXIgZGlyZWN0
bHkgcmVwb3J0aW5nIE1JQyBmYWlsdXJlIHdpbGwgYmUgZmluZS4gSSB0aGluayBhIHdyYXBwZXIN
Cm1heSBiZSByZXF1aXJlZCByYXRoZXIgdGhhbiBtYWM4MDIxMSBiYXNlZCBkcml2ZXIgZGlyZWN0
bHkgY2FsbGluZyBjZmc4MDIxMQ0KZnVuY3Rpb24/DQoNClZhc2FudGg=

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format
  2016-12-16  6:47     ` Thiagarajan, Vasanthakumar
@ 2016-12-16  9:13       ` Johannes Berg
  2016-12-16  9:14         ` Johannes Berg
  0 siblings, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2016-12-16  9:13 UTC (permalink / raw)
  To: Thiagarajan, Vasanthakumar; +Cc: linux-wireless


> Ok. So it is mainly for encap there needs to be some capability
> advertisement from driver 

Obviously, since mac80211 needs to pick the ndo struct to use.

> because for decap driver would use appropriate mac80211 Rx function
> to indicate?

That should be sufficient, no?

In fact, for RX, assuming that the relevant things are offloaded (and
we should ensure that in the RX function(s)), the driver could be
allowed to switch around as dynamically as it wants to (as long as it's
not mixing in _irqsafe calls or doing other things that might cause
reordering)

> > > +	memset(&rx, 0, sizeof(rx));
> > 
> > That seems a bit pointless?
> 
> Hmmm, is it not that all member other than the ones initialized will
> be junk and might result in crash when accessing uninitialized
> pointer member like napi?

Oh, ok. I thought it was actually all filled.

You really should support NAPI though.

> > Yeah, that's not nice - perhaps we can provide the TID out of band?
> 
> Right. This is possible with ath10k where 802.11 header is also
> available in Rx desc of the frame irrespective of the format of the
> Rx payload

We could go with that for now then. Leave a comment indicating that if
it can't be provided, we need to disable statistics for it?

> > 
> > > +	return;
> > > +
> > > +mic_fail:
> > > +	cfg80211_michael_mic_failure(sdata->dev, sta->addr,
> > > +				     (status->flag &
> > > RX_FLAG_MCAST)
> > > ?
> > > +				     NL80211_KEYTYPE_GROUP :
> > > +				     NL80211_KEYTYPE_PAIRWISE,
> > > +				     key ? key->conf.keyidx :
> > > -1,
> > > +				     NULL, GFP_ATOMIC);
> > 
> > Do we really want to handle that inline here? The driver probably
> > has a different check to even set RX_FLAG_MMIC_ERROR, so we could
> > just ask it to call cfg80211_michael_mic_failure() [or a wrapper to
> > get sdata->dev] instead? I guess this works too though, and might
> > be easier to understand.
> 
> Yeah, driver directly reporting MIC failure will be fine. I think a
> wrapper may be required rather than mac80211 based driver directly
> calling cfg80211 function?

It would be, because the driver can't get sdata->dev (although I think
there's now a hidden path to do this?)

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format
  2016-12-16  9:13       ` Johannes Berg
@ 2016-12-16  9:14         ` Johannes Berg
  0 siblings, 0 replies; 21+ messages in thread
From: Johannes Berg @ 2016-12-16  9:14 UTC (permalink / raw)
  To: Thiagarajan, Vasanthakumar; +Cc: linux-wireless


> > > > +	return;
> > > > +
> > > > +mic_fail:
> > > > +	cfg80211_michael_mic_failure(sdata->dev, sta->addr,
> > > > +				     (status->flag &
> > > > RX_FLAG_MCAST)
> > > > ?
> > > > +				     NL80211_KEYTYPE_GROUP :
> > > > +				     NL80211_KEYTYPE_PAIRWISE,
> > > > +				     key ? key->conf.keyidx :
> > > > -1,
> > > > +				     NULL, GFP_ATOMIC);
> > > 
> > > Do we really want to handle that inline here? The driver probably
> > > has a different check to even set RX_FLAG_MMIC_ERROR, so we could
> > > just ask it to call cfg80211_michael_mic_failure() [or a wrapper
> > > to
> > > get sdata->dev] instead? I guess this works too though, and might
> > > be easier to understand.
> > 
> > Yeah, driver directly reporting MIC failure will be fine. I think a
> > wrapper may be required rather than mac80211 based driver directly
> > calling cfg80211 function?
> 
> It would be, because the driver can't get sdata->dev (although I
> think there's now a hidden path to do this?)

However, we can do both ways, I don't really care that much. It seems
possible though that a driver would not even report the frame, but only
the necessary info, in this case - so that we might need an out-of-band 
path for it anyway?

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-16  5:37           ` Thiagarajan, Vasanthakumar
@ 2016-12-16  9:25             ` Johannes Berg
  2016-12-19 11:45             ` Kalle Valo
  1 sibling, 0 replies; 21+ messages in thread
From: Johannes Berg @ 2016-12-16  9:25 UTC (permalink / raw)
  To: Thiagarajan, Vasanthakumar, nbd; +Cc: linux-wireless

On Fri, 2016-12-16 at 05:37 +0000, Thiagarajan, Vasanthakumar wrote:

> QCA988X does not have capability to configure vif specific decap
> mode. Encap mode is configurable per packet for all the ath10k based
> chips so this part should be fine to support per vif configuration. 

Ok, that's good.

> Newer QCA chips like QCA9984, QCA4019, QCA9888 and QCA99X0 supports
> decap mode configuration per vif.

Also good.

> To reduce the complexity, we can probably make per vif encap/decap
> configuration mandatory to enable ethernet frame format, not sure how
> this will work with non-QCA capable hardware.

I don't know either, nobody else has talked about it yet :-)

Anyway, if we (for now) we can assume that TX can be constant 802.3
encap mode once enabled, we don't have to deal with the messy dynamic
switching you had there.

RX can switch more dynamically independent of all the mac80211 code
since it basically just means the driver calls one function or the
other - if everything is offloaded correctly there shouldn't really be
a difference.

Then also things like IEEE80211_CONF_CHANGE_80211_HDR_OFFL etc. can go
away entirely because you don't have to switch anything dynamically at
a global level. That will simplify everything a lot.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload
  2016-12-15 10:43     ` Thiagarajan, Vasanthakumar
@ 2016-12-16  9:30       ` Johannes Berg
  0 siblings, 0 replies; 21+ messages in thread
From: Johannes Berg @ 2016-12-16  9:30 UTC (permalink / raw)
  To: Thiagarajan, Vasanthakumar; +Cc: linux-wireless

On Thu, 2016-12-15 at 10:43 +0000, Thiagarajan, Vasanthakumar wrote:
> On Thursday 15 December 2016 02:46 PM, Johannes Berg wrote:
> > 
> > > Drivers advertising this capability should also implement other
> > > functionalities which deal with 802.11 frame format like below
> > > 	- ADDBA/DELBA offload
> > 
> > This shouldn't be necessary.
> 
> Ok. Since driver/hw needs to implement Tx/Rx aggregation related
> functionalities I thought ADDBA/DELBA processing will be little
> important to mac80211. May be I'm missing something.

It needs to do the aggregation of the data flows, but I don't think the
control flows will need to be offloaded entirely? We'd need to have
some feedback mechanism for the SN used etc., so that might be up to
the driver to implement and might not be easy.

Anyway, I'm only suggesting to drop this from the documentation since
it doesn't seem strictly necessary, assuming the driver can report the
correct SSN in the callback all the A-MPDU setup should work more or
less as-is (except I think mac80211 won't buffer frames while doing it,
so also that would have to be done by the driver).

> > > 	- Powersave offload
> > 
> > That's ambiguous - you do need to handle sleeping stations (and PS-
> > Poll/U-APSD) in AP mode in the device with this,
> 
> I did not dig deep into PS requirement with ethernet frame format
> because frame control is not available to mac80211, so I thought to
> mention PS offload is a requirement. May be there is already an
> infrastructure in mac80211 to learn PS state of client which was
> notified in the current data frame (other than 802.11 frame control).
> 
>   but I don't see a deep
> > technical reason to require it for client mode. OTOH, client mode
> > is
> > almost always offloaded anyway.
> 
> Ok.

Actually, come to think of it, the whole client-side powersave stuff is
so broken that I can't recommend using it - perhaps just clarify this
and say:

 * AP: offloaded support for powersaving clients
 * non-AP: offloaded support for powersave (if desired)

> > I think you may have forgotten one important item,
> > 
> > 	- control port handling
> 
> Hmmm, I'm getting WPA-PSK working with this. May be there are other
> control port handling which will not work with ethernet frame format?

I think I later saw control port handling in your 802.3 RX code - my
review at this point was tainted by some thoughts I had how I thought
it should work, but it's different :)

> > > +	int (*get_vif_80211_hdr_offload)(struct ieee80211_hw
> > > *hw,
> > > +					 struct ieee80211_vif
> > > *vif,
> > > +					 bool is_4addr, bool
> > > *supported);
> > 
> > Why are you not simply returning "supported"?
> > 
> > I don't like passing the vif pointer here. At this point, the vif
> > pointer isn't known to the driver yet (through drv_add_interface)
> > so it's a dead pointer as far as the sequencing is concerned.
> > 
> > Is there a possibility that drivers need to switch off ethernet
> > format handling entirely when an incompatible interface is added?
> > For example, if you add a mesh interface, is there a chance that
> > the AP interface might no longer be able to handle this?
> 
>  >
>  > I'd hope this doesn't happen because I think that would 
> be extremely
>  > complicated to handle safely.
> 
> Unfortunately "[RFC 2/3] mac80211: Implement data xmit for 802.11
> encap offload" tries to implement this but more likely buggy :(. You
> are right, it is very complex to get that right. May be we should not
> allow interface needing dynamic switch?

We discussed this over in the other part of the thread :)

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-16  5:37           ` Thiagarajan, Vasanthakumar
  2016-12-16  9:25             ` Johannes Berg
@ 2016-12-19 11:45             ` Kalle Valo
  2016-12-19 12:02               ` Thiagarajan, Vasanthakumar
  1 sibling, 1 reply; 21+ messages in thread
From: Kalle Valo @ 2016-12-19 11:45 UTC (permalink / raw)
  To: Thiagarajan, Vasanthakumar; +Cc: Johannes Berg, nbd, linux-wireless

"Thiagarajan, Vasanthakumar" <vthiagar@qti.qualcomm.com> writes:

> On Thursday 15 December 2016 07:23 PM, Johannes Berg wrote:
>>
>>>> I agree. Dynamic switch part is buggy, we can start with not
>>>> allowing interfaces resulting in dynamic switch.
>>>
>>> Does this mean that when bringing up multiple interfaces, users would
>>> need to figure out the 'magic' order that works?
>>
>> I think we need to talk about hardware capabilities at this point.
>
> QCA988X does not have capability to configure vif specific decap mode. Encap mode
> is configurable per packet for all the ath10k based chips so this part should be
> fine to support per vif configuration. Newer QCA chips like QCA9984, QCA4019, QCA9888
> and QCA99X0 supports decap mode configuration per vif.

When you say "all" are you also taking into account QCA6174 and QCA9377?

Just checking...

-- 
Kalle Valo

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
  2016-12-19 11:45             ` Kalle Valo
@ 2016-12-19 12:02               ` Thiagarajan, Vasanthakumar
  0 siblings, 0 replies; 21+ messages in thread
From: Thiagarajan, Vasanthakumar @ 2016-12-19 12:02 UTC (permalink / raw)
  To: Kalle Valo; +Cc: Johannes Berg, nbd, linux-wireless

On Monday 19 December 2016 05:15 PM, Kalle Valo wrote:
> "Thiagarajan, Vasanthakumar" <vthiagar@qti.qualcomm.com> writes:
>
>> On Thursday 15 December 2016 07:23 PM, Johannes Berg wrote:
>>>
>>>>> I agree. Dynamic switch part is buggy, we can start with not
>>>>> allowing interfaces resulting in dynamic switch.
>>>>
>>>> Does this mean that when bringing up multiple interfaces, users would
>>>> need to figure out the 'magic' order that works?
>>>
>>> I think we need to talk about hardware capabilities at this point.
>>
>> QCA988X does not have capability to configure vif specific decap mode. E=
ncap mode
>> is configurable per packet for all the ath10k based chips so this part s=
hould be
>> fine to support per vif configuration. Newer QCA chips like QCA9984, QCA=
4019, QCA9888
>> and QCA99X0 supports decap mode configuration per vif.
>
> When you say "all" are you also taking into account QCA6174 and QCA9377?

Good point. I see some workarounds for QCA6174 to send data frames in ether=
net mode,
so QCA6174 should be fine in this regard. I assume QCA9377 also works fine =
with
ethernet encap configuration per htt desc, need to confirm.

Vasanth=

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2016-12-19 12:02 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-15  6:00 [RFC 0/3] Add new data path for ethernet frame format Vasanthakumar Thiagarajan
2016-12-15  6:00 ` [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload Vasanthakumar Thiagarajan
2016-12-15  9:16   ` Johannes Berg
2016-12-15 10:43     ` Thiagarajan, Vasanthakumar
2016-12-16  9:30       ` Johannes Berg
2016-12-15  6:00 ` [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload Vasanthakumar Thiagarajan
2016-12-15  9:29   ` Johannes Berg
2016-12-15 12:01     ` Thiagarajan, Vasanthakumar
2016-12-15 13:32       ` Felix Fietkau
2016-12-15 13:53         ` Johannes Berg
2016-12-16  5:37           ` Thiagarajan, Vasanthakumar
2016-12-16  9:25             ` Johannes Berg
2016-12-19 11:45             ` Kalle Valo
2016-12-19 12:02               ` Thiagarajan, Vasanthakumar
2016-12-15  6:00 ` [RFC 3/3] mac80211: Add receive path for ethernet frame format Vasanthakumar Thiagarajan
2016-12-15  9:38   ` Johannes Berg
2016-12-16  6:47     ` Thiagarajan, Vasanthakumar
2016-12-16  9:13       ` Johannes Berg
2016-12-16  9:14         ` Johannes Berg
2016-12-15  9:08 ` [RFC 0/3] Add new data " Johannes Berg
2016-12-15 10:03   ` Thiagarajan, Vasanthakumar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.