[RFCv2 0/2] Add new transmit data path for ethernet frame format

[RFCv2 0/2] Add new transmit data path for ethernet frame format

[mpubbise]

From: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>

This patch set adds a new transmit data path to offload 802.11 header
encap to driver/hardware. Drivers having support for ieee80211
header encap and other offload functionalities which can't be done
before encap 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.

This patchset only adds support for tx in ethernet frame format
and receive can happen in 802.11 format with existing rx framework.

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.

Vasanthakumar Thiagarajan (2):
  mac80211: Add provision for 802.11 encap offload
  mac80211: Implement data xmit for 802.11 encap offload

V2:
 * 802.11 decap offload is removed from the patchset
 * Code changes as per review comments of v1.

 include/net/mac80211.h     |   30 ++++++-
 net/mac80211/cfg.c         |    9 ++
 net/mac80211/debugfs.c     |    1 +
 net/mac80211/ieee80211_i.h |   10 +++
 net/mac80211/iface.c       |   72 +++++++++++++++
 net/mac80211/key.c         |    3 +
 net/mac80211/status.c      |   79 +++++++++++++++++
 net/mac80211/tx.c          |  207 +++++++++++++++++++++++++++++++++++++++++++-
 8 files changed, 406 insertions(+), 5 deletions(-)

-- 
1.7.9.5

[RFCv2 1/2] mac80211: Add provision for 802.11 encap offload

[mpubbise]

From: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>

Drivers can have the capability to offload 802.11 encap
to firmware or hardware for data frames. This patch adds a new
hw_flag for driver to advertise the offload support.
Transmit path offloading 802.11 header (including cipher headers)
encap for data frames will be implemented in a separate patch.

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

        - Hardware encryption
        - Aggregation of A-MSDU offload
        - Fragmentation offload

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
---
 include/net/mac80211.h |    4 ++++
 net/mac80211/debugfs.c |    1 +
 2 files changed, 5 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 3edb469..0239b7d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2049,6 +2049,9 @@ struct ieee80211_txq {
  *	The stack will not do fragmentation.
  *	The callback for @set_frag_threshold should be set as well.
  *
+ * @IEEE80211_HW_SUPPORTS_80211_ENCAP: Hardware/driver supports 802.11
+ *	encap for data frames.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2091,6 +2094,7 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_TX_FRAG_LIST,
 	IEEE80211_HW_REPORTS_LOW_ACK,
 	IEEE80211_HW_SUPPORTS_TX_FRAG,
+	IEEE80211_HW_SUPPORTS_80211_ENCAP,
 
 	/* keep last, obviously */
 	NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 5fae001..b97ffb4 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -211,6 +211,7 @@ static ssize_t reset_write(struct file *file, const char __user *user_buf,
 	FLAG(TX_FRAG_LIST),
 	FLAG(REPORTS_LOW_ACK),
 	FLAG(SUPPORTS_TX_FRAG),
+	FLAG(SUPPORTS_80211_ENCAP),
 #undef FLAG
 };
 
-- 
1.7.9.5

Re: [RFCv2 1/2] mac80211: Add provision for 802.11 encap offload

[Johannes Berg]

On Fri, 2017-03-03 at 17:03 +0530, mpubbise@qti.qualcomm.com wrote:
> From: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
> 
> Drivers can have the capability to offload 802.11 encap
> to firmware or hardware for data frames. This patch adds a new
> hw_flag for driver to advertise the offload support.
> Transmit path offloading 802.11 header (including cipher headers)
> encap for data frames will be implemented in a separate patch.
> 
> Drivers advertising this capability should also implement other
> functionalities which deal with 802.11 frame format like below
> 
>         - Hardware encryption
>         - Aggregation of A-MSDU offload
>         - Fragmentation offload

Not much point in having this as a separate patch, but this
documentation paragraph should move into the documentation for the new
flag in mac80211.h

johannes

RE: [RFCv2 1/2] mac80211: Add provision for 802.11 encap offload

[Pubbisetty, Manikanta]

Pj4gRHJpdmVycyBjYW4gaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBvZmZsb2FkIDgwMi4xMSBlbmNh
cCB0byBmaXJtd2FyZSBvcg0KPj4gaGFyZHdhcmUgZm9yIGRhdGEgZnJhbWVzLiBUaGlzIHBhdGNo
IGFkZHMgYSBuZXcgaHdfZmxhZyBmb3IgZHJpdmVyIHRvDQo+PiBhZHZlcnRpc2UgdGhlIG9mZmxv
YWQgc3VwcG9ydC4NCj4+IFRyYW5zbWl0IHBhdGggb2ZmbG9hZGluZyA4MDIuMTEgaGVhZGVyIChp
bmNsdWRpbmcgY2lwaGVyIGhlYWRlcnMpDQo+PiBlbmNhcCBmb3IgZGF0YSBmcmFtZXMgd2lsbCBi
ZSBpbXBsZW1lbnRlZCBpbiBhIHNlcGFyYXRlIHBhdGNoLg0KPj4NCj4+IERyaXZlcnMgYWR2ZXJ0
aXNpbmcgdGhpcyBjYXBhYmlsaXR5IHNob3VsZCBhbHNvIGltcGxlbWVudCBvdGhlcg0KPj4gZnVu
Y3Rpb25hbGl0aWVzIHdoaWNoIGRlYWwgd2l0aCA4MDIuMTEgZnJhbWUgZm9ybWF0IGxpa2UgYmVs
b3cNCj4+DQo+PiDCoMKgwqDCoMKgwqDCoMKgLSBIYXJkd2FyZSBlbmNyeXB0aW9uDQo+PiDCoMKg
wqDCoMKgwqDCoMKgLSBBZ2dyZWdhdGlvbiBvZiBBLU1TRFUgb2ZmbG9hZA0KPj4gwqDCoMKgwqDC
oMKgwqDCoC0gRnJhZ21lbnRhdGlvbiBvZmZsb2FkDQo+DQo+Tm90IG11Y2ggcG9pbnQgaW4gaGF2
aW5nIHRoaXMgYXMgYSBzZXBhcmF0ZSBwYXRjaCwgYnV0IHRoaXMgZG9jdW1lbnRhdGlvbg0KPnBh
cmFncmFwaCBzaG91bGQgbW92ZSBpbnRvIHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGUgbmV3IGZs
YWcgaW4NCj5tYWM4MDIxMS5oDQoNCltNYW5pa2FudGFdIFN1cmUuDQoNCi0tDQpNYW5pa2FudGEN
Cg==

[RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[mpubbise]

From: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>

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 based on the
driver/hardware capability for 802.11 encap offload and interface type.

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 offload
and with the corresponding driver changes, 802.11 encap offload
might improve performance.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
---
 include/net/mac80211.h     |   26 +++++-
 net/mac80211/cfg.c         |    9 ++
 net/mac80211/ieee80211_i.h |   11 +++
 net/mac80211/iface.c       |   72 +++++++++++++++
 net/mac80211/key.c         |    3 +
 net/mac80211/status.c      |   82 ++++++++++++++++++
 net/mac80211/tx.c          |  207 +++++++++++++++++++++++++++++++++++++++++++-
 7 files changed, 405 insertions(+), 5 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 0239b7d..b9e74b3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -921,7 +921,12 @@ struct ieee80211_tx_info {
 			};
 			struct ieee80211_key_conf *hw_key;
 			u32 flags;
-			/* 4 bytes free */
+			/* XXX: This frame is not encapsulated with 802.11
+			 * header. Should this be added to %IEEE80211_TX_CTRL_*
+			 * flags?.
+			 */
+			bool no_80211_encap;
+			/* 3 bytes free */
 		} control;
 		struct {
 			u64 cookie;
@@ -4265,6 +4270,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 9c7490c..e1c6f3e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -129,6 +129,9 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
 		}
 	}
 
+	if (!ieee80211_sdata_running(sdata))
+		ieee80211_if_check_80211_encap_offl(sdata);
+
 	return 0;
 }
 
@@ -2273,6 +2276,12 @@ static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
 	if (changed & WIPHY_PARAM_FRAG_THRESHOLD) {
 		ieee80211_check_fast_xmit_all(local);
 
+		if (ieee80211_iface_uses_80211_encap_offl(local))
+			return -EINVAL;
+
+		if (!local->ops->set_frag_threshold)
+			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 0e71843..1618806 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -966,6 +966,8 @@ struct ieee80211_sub_if_data {
 	} debugfs;
 #endif
 
+	bool data_80211_encap_offloaded;
+
 	/* must be last, dynamically sized area in this! */
 	struct ieee80211_vif vif;
 };
@@ -1696,6 +1698,8 @@ 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_encap_offl(struct ieee80211_sub_if_data *sdata);
+bool ieee80211_iface_uses_80211_encap_offl(struct ieee80211_local *local);
 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);
@@ -1723,6 +1727,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);
@@ -1877,6 +1883,11 @@ void __ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
 				 struct sk_buff *skb, int tid,
 				 enum nl80211_band band);
 
+/* sta_out needs to be checked for ERR_PTR() before using */
+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 40813dd..d8cabfa 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1161,6 +1161,17 @@ static u16 ieee80211_netdev_select_queue(struct net_device *dev,
 	.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_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,
@@ -1194,6 +1205,63 @@ static u16 ieee80211_monitor_select_queue(struct net_device *dev,
 	.ndo_get_stats64	= ieee80211_get_stats64,
 };
 
+static bool
+ieee80211_if_encap_offl_supported(struct ieee80211_sub_if_data *sdata)
+{
+	struct ieee80211_local *local = sdata->local;
+
+	if (!ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP))
+		return false;
+
+	if (local->hw.wiphy->frag_threshold != (u32)-1 &&
+	    !local->ops->set_frag_threshold)
+		return false;
+
+	switch (sdata->vif.type) {
+	case NL80211_IFTYPE_AP:
+		return true;
+	case NL80211_IFTYPE_STATION:
+		if (sdata->u.mgd.use_4addr)
+			return false;
+		return true;
+	case NL80211_IFTYPE_AP_VLAN:
+		if (sdata->wdev.use_4addr)
+			return false;
+		return true;
+	default:
+		return false;
+	}
+}
+
+void ieee80211_if_check_80211_encap_offl(struct ieee80211_sub_if_data *sdata)
+{
+	if (!sdata->dev)
+		return;
+
+	if (!ieee80211_if_encap_offl_supported(sdata))
+		return;
+
+	sdata->dev->netdev_ops = &ieee80211_dataif_8023_ops;
+	sdata->data_80211_encap_offloaded = true;
+}
+
+bool ieee80211_iface_uses_80211_encap_offl(struct ieee80211_local *local)
+{
+	struct ieee80211_sub_if_data *sdata;
+	bool offloaded = false;
+
+	mutex_lock(&local->iflist_mtx);
+	list_for_each_entry(sdata, &local->interfaces, list) {
+		if (sdata->data_80211_encap_offloaded) {
+			offloaded = true;
+			break;
+		}
+	}
+	mutex_unlock(&local->iflist_mtx);
+
+	return offloaded;
+}
+
 static void ieee80211_if_free(struct net_device *dev)
 {
 	free_percpu(dev->tstats);
@@ -1425,6 +1493,8 @@ static void ieee80211_setup_sdata(struct ieee80211_sub_if_data *sdata,
 
 	sdata->noack_map = 0;
 
+	sdata->data_80211_encap_offloaded = false;
+
 	/* only monitor/p2p-device differ */
 	if (sdata->dev) {
 		sdata->dev->netdev_ops = &ieee80211_dataif_ops;
@@ -1907,6 +1977,8 @@ 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_encap_offl(sdata);
+
 	if (new_wdev)
 		*new_wdev = &sdata->wdev;
 
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index a98fc2b..960eed1 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -193,6 +193,9 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
 			  key->conf.keyidx,
 			  sta ? sta->sta.addr : bcast_addr, ret);
 
+	if (sdata->data_80211_encap_offloaded)
+		return -EINVAL;
+
  out_unsupported:
 	switch (key->conf.cipher) {
 	case WLAN_CIPHER_SUITE_WEP40:
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index a3af6e1..620a826 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -952,6 +952,88 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
 }
 EXPORT_SYMBOL(ieee80211_tx_status);
 
+/* TODO: Check the possibility to use ieee80211_tx_status for reporting the tx status
+ * of 802.11 encap offloaded frames.
+ */
+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)))
+		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 ba8d7db..1d7844e 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1250,12 +1250,18 @@ static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
 	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct ieee80211_txq *txq = NULL;
+	bool is_data;
 
 	if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ||
 	    (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
 		return NULL;
 
-	if (!ieee80211_is_data(hdr->frame_control))
+	if (!info->control.no_80211_encap)
+		is_data = ieee80211_is_data(hdr->frame_control);
+	else
+		is_data = true;
+
+	if (!is_data)
 		return NULL;
 
 	if (sta) {
@@ -1427,6 +1433,7 @@ void ieee80211_txq_purge(struct ieee80211_local *local,
 {
 	struct fq *fq = &local->fq;
 	struct fq_tin *tin = &txqi->tin;
+	struct ieee80211_tx_info *info;
 
 	fq_tin_reset(fq, tin, fq_skb_free_func);
 	ieee80211_purge_tx_queue(&local->hw, &txqi->frags);
@@ -2262,9 +2269,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;
 
@@ -3432,6 +3439,9 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
 	hdr = (struct ieee80211_hdr *)skb->data;
 	info = IEEE80211_SKB_CB(skb);
 
+	if (info->control.no_80211_encap)
+		goto out;
+
 	memset(&tx, 0, sizeof(tx));
 	__skb_queue_head_init(&tx.skbs);
 	tx.local = local;
@@ -3705,6 +3715,185 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
 	return NETDEV_TX_OK;
 }
 
+static bool ieee80211_tx_8023(struct ieee80211_sub_if_data *sdata,
+			      struct sk_buff *skb, int led_len,
+			      struct sta_info *sta,
+			      bool txpending)
+{
+	struct ieee80211_local *local = sdata->local;
+	struct ieee80211_tx_control control = {};
+	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+	struct ieee80211_sta *pubsta = NULL;
+	unsigned long flags;
+	int q = info->hw_queue;
+
+	if (ieee80211_queue_skb(local, sdata, sta, skb))
+		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);
+
+
+	if (sta && sta->uploaded)
+		pubsta = &sta->sta;
+
+	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;
+	unsigned char *ra = NULL;
+
+	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)
+		ra = ehdr->h_dest;
+
+	if (sdata->vif.type == NL80211_IFTYPE_STATION) {
+		tdls_peer = test_sta_flag(sta, WLAN_STA_TDLS_PEER);
+		if (tdls_peer)
+			ra = skb->data;
+		else
+			ra = sdata->u.mgd.bssid;
+	}
+
+	if (!ra)
+		goto out_free;
+
+	multicast = is_multicast_ether_addr(ra);
+
+	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 */
+
+	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(sdata, 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 sta_info *sta;
+
+	if (WARN_ON(unlikely(!sdata->data_80211_encap_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)
@@ -3783,6 +3972,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(sdata, skb, skb->len, sta, true);
 	} else {
 		struct sk_buff_head skbs;
 
-- 
1.7.9.5

Re: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Johannes Berg]

> There is a field, no_80211_encap, added to ieee80211_tx_info:control
> to mark if the 802.11 encapsulation is offloaded to driver.

Why is that needed? Since you have a separate TX path (ndo_start_xmit),
wouldn't it make more sense to call into a drv_tx_8023() or something
like that instead?

> There is also a new callback for tx completion status indication
> to handle data frames using 802.11 encap offload.

Maybe you could just use _noskb?

Haven't really looked at the rest all that much, few comments:

 * not sure you're handling non-linear frames right, are you assuming
   the driver can handle them? probably a fair assumption, but should
   be documented
 * you seem to also be assuming that the driver not only does all
   encryption in HW (which is obviously needed) but also does all the
   key lookups etc. - also seems fair, but also should be documented
 * similarly for a lot of other (all?) fields in tx_info
 * you seem to be assuming that if encap offload is supported then it's
   also *desired* for AP/VLAN and client interfaces, if not 4-addr.
   This seems ... probably about right, but if drivers don't always
   support it? Or support it in more cases? Perhaps we can move the
   SUPPORTS_80211_ENCAP flag into a VIF flag instead, so they can do it
   more fine-grained?

johannes

RE: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Pubbisetty, Manikanta]

Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogSm9oYW5uZXMgQmVyZyBbbWFpbHRv
OmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdDQo+U2VudDogRnJpZGF5LCBNYXJjaCAzLCAyMDE3
IDY6MDkgUE0NCj5UbzogUHViYmlzZXR0eSwgTWFuaWthbnRhIDxtcHViYmlzZUBxdGkucXVhbGNv
bW0uY29tPg0KPkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFRoaWFnYXJhamFu
LCBWYXNhbnRoYWt1bWFyDQo+PHZ0aGlhZ2FyQHF0aS5xdWFsY29tbS5jb20+DQo+U3ViamVjdDog
UmU6IFtSRkN2MiAyLzJdIG1hYzgwMjExOiBJbXBsZW1lbnQgZGF0YSB4bWl0IGZvciA4MDIuMTEg
ZW5jYXANCj5vZmZsb2FkDQo+DQo+DQo+PiBUaGVyZSBpcyBhIGZpZWxkLCBub184MDIxMV9lbmNh
cCwgYWRkZWQgdG8gaWVlZTgwMjExX3R4X2luZm86Y29udHJvbA0KPj4gdG8gbWFyayBpZiB0aGUg
ODAyLjExIGVuY2Fwc3VsYXRpb24gaXMgb2ZmbG9hZGVkIHRvIGRyaXZlci4NCj4NCj5XaHkgaXMg
dGhhdCBuZWVkZWQ/IFNpbmNlIHlvdSBoYXZlIGEgc2VwYXJhdGUgVFggcGF0aCAobmRvX3N0YXJ0
X3htaXQpLA0KPndvdWxkbid0IGl0IG1ha2UgbW9yZSBzZW5zZSB0byBjYWxsIGludG8gYSBkcnZf
dHhfODAyMygpIG9yIHNvbWV0aGluZyBsaWtlDQo+dGhhdCBpbnN0ZWFkPw0KPg0KW01hbmlrYW50
YV0gIFllcywgaXQgbWFrZXMgc2Vuc2UgaGF2aW5nIGEgc2VwYXJhdGUgZHJpdmVyIGhvb2sgaW5z
dGVhZCBvZiB1c2luZyBkcnZfdHgsIGJ1dCBpbiBjYXNlIG9mIGRyaXZlcnMgKGZlIGF0aDEwaykg
DQp3aGVyZSBlbnF1ZXVpbmcgYW5kIGRlcXVldWluZyB0eCBsb2dpYyAod2FrZV90eF9xdWV1ZSBh
bmQgaWVlZTgwMjExX3R4X2RlcXVldWUpIGlzIHVzZWQgdGhlcmUgc2hvdWxkIGJlIGEgd2F5DQp0
byBpbmRpY2F0ZSB0aGF0IHRoZSBwYWNrZXQgaXMgbm90IDgwMjExIGVuY2Fwc3VsYXRlZCwgaXNu
J3QgaXQ/IENvcnJlY3QgbWUgaWYgSSBhbSBtaXNzaW5nIGFueXRoaW5nLg0KDQo+PiBUaGVyZSBp
cyBhbHNvIGEgbmV3IGNhbGxiYWNrIGZvciB0eCBjb21wbGV0aW9uIHN0YXR1cyBpbmRpY2F0aW9u
IHRvDQo+PiBoYW5kbGUgZGF0YSBmcmFtZXMgdXNpbmcgODAyLjExIGVuY2FwIG9mZmxvYWQuDQo+
DQo+TWF5YmUgeW91IGNvdWxkIGp1c3QgdXNlIF9ub3NrYj8NCj4NCltNYW5pa2FudGFdICBIbW1t
IHlvdSBhcmUgcmlnaHQuIEkganVzdCB3ZW50IHRocm91Z2ggdGhlIGNvZGUsIHNlZW1zIGllZWU4
MDIxMV90eF9zdGF0dXNfbm9za2IgZG9lcyBtb3N0IG9mIHRoZW0gd2hhdCBpZWVlODAyMTFfdHhf
c3RhdHVzXzgwMjMgaXMgZG9pbmcsDQpyZXNldHRpbmcgdGhlIHN0YXRpb24gY29ubmVjdGlvbiBt
b25pdG9yaW5nIGxvZ2ljIGFuZCB1cGRhdGluZyBsYXN0IGtub3duIHR4IHJhdGUgaXMgbWlzc2lu
ZyBpbiBfbm9za2IuIFRoZXNlIGFyZSByZXF1aXJlZCwgaXNuJ3QgaXQ/DQoNCj5IYXZlbid0IHJl
YWxseSBsb29rZWQgYXQgdGhlIHJlc3QgYWxsIHRoYXQgbXVjaCwgZmV3IGNvbW1lbnRzOg0KPg0K
PiAqIG5vdCBzdXJlIHlvdSdyZSBoYW5kbGluZyBub24tbGluZWFyIGZyYW1lcyByaWdodCwgYXJl
IHlvdSBhc3N1bWluZw0KPiAgIHRoZSBkcml2ZXIgY2FuIGhhbmRsZSB0aGVtPyBwcm9iYWJseSBh
IGZhaXIgYXNzdW1wdGlvbiwgYnV0IHNob3VsZA0KPiAgIGJlIGRvY3VtZW50ZWQNCj4NCltNYW5p
a2FudGFdIFN1cmUNCg0KPiAqIHlvdSBzZWVtIHRvIGFsc28gYmUgYXNzdW1pbmcgdGhhdCB0aGUg
ZHJpdmVyIG5vdCBvbmx5IGRvZXMgYWxsDQo+ICAgZW5jcnlwdGlvbiBpbiBIVyAod2hpY2ggaXMg
b2J2aW91c2x5IG5lZWRlZCkgYnV0IGFsc28gZG9lcyBhbGwgdGhlDQo+ICAga2V5IGxvb2t1cHMg
ZXRjLiAtIGFsc28gc2VlbXMgZmFpciwgYnV0IGFsc28gc2hvdWxkIGJlIGRvY3VtZW50ZWQNCj4N
CltNYW5pa2FudGFdIEkgd2lsbCBkb2N1bWVudCB0aGVzZSBpbiBteSBuZXh0IHZlcnNpb24uDQoN
Cj4gKiBzaW1pbGFybHkgZm9yIGEgbG90IG9mIG90aGVywqAoYWxsPykgZmllbGRzIGluIHR4X2lu
Zm8NCj4gKiB5b3Ugc2VlbSB0byBiZSBhc3N1bWluZyB0aGF0IGlmIGVuY2FwIG9mZmxvYWQgaXMg
c3VwcG9ydGVkIHRoZW4gaXQncw0KPiAgIGFsc28gKmRlc2lyZWQqIGZvciBBUC9WTEFOIGFuZCBj
bGllbnQgaW50ZXJmYWNlcywgaWYgbm90IDQtYWRkci4NCj4gICBUaGlzIHNlZW1zIC4uLiBwcm9i
YWJseSBhYm91dCByaWdodCwgYnV0IGlmIGRyaXZlcnMgZG9uJ3QgYWx3YXlzDQo+ICAgc3VwcG9y
dCBpdD8gT3Igc3VwcG9ydCBpdCBpbiBtb3JlIGNhc2VzPyBQZXJoYXBzIHdlIGNhbiBtb3ZlIHRo
ZQ0KPiAgIFNVUFBPUlRTXzgwMjExX0VOQ0FQIGZsYWcgaW50byBhIFZJRiBmbGFnIGluc3RlYWQs
IHNvIHRoZXkgY2FuIGRvIGl0DQo+ICAgbW9yZSBmaW5lLWdyYWluZWQ/DQo+DQpbTWFuaWthbnRh
XSBZb3UgYXJlIGNvcnJlY3QuIEl0IGlzIGdvb2QgaWYgZHJpdmVyIGFkdmVydGlzZXMgdGhlIHZp
ZiB0eXBlcyBpdCBzdXBwb3J0IGluIGVuY2FwIG9mZmxvYWQgbW9kZSwgYnV0IGhvdyBjYW4gd2Ug
ZGVjaWRlIHRoZSBuZXRkZXZfb3BzIHRvIGJlIHVzZWQgd2hpbGUgY3JlYXRpbmcgdGhlIHZpZj8g
ZHJ2X2FkZF9pbnRlcmZhY2Ugd2lsbCBiZSBpbnZva2VkIGZyb20gbmRvX29wZW4gYW5kDQpldmVu
IGJlZm9yZSBpbnZva2luZyBkcml2ZXIgYWRkX2ludGVyZmFjZSB3ZSBoYXZlIHRvIG1ha2UgdGhl
IGRlY2lzaW9uIG9mIHVzaW5nIEV0aGVybmV0IG1vZGUgbmV0ZGV2X29wcyBvciB0aGUgZGVmYXVs
dCBuZXRkZXZfb3BzLCBpc24ndCBpdD8NCg0KQ2FuIHdlIGhhdmUgYSBzZXBhcmF0ZSBkcml2ZXIg
aG9vayB3aGljaCBnaXZlcyB3aGV0aGVyIDgwMjExIGVuY2FwIG9mZmxvYWQgaXMgc3VwcG9ydGVk
IGZvciB0aGUgZ2l2ZW4gaW50ZXJmYWNlIHR5cGUgYW5kIHRoZW4gZGVjaWRlIHRoZSBuZXRkZXZf
b3BzIHRvIGJlIGF0dGFjaGVkIGZvciB0aGUgdmlmPw0KLS0NCk1hbmlrYW50YQ0K

Re: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Johannes Berg]

> > Why is that needed? Since you have a separate TX path
> > (ndo_start_xmit),
> > wouldn't it make more sense to call into a drv_tx_8023() or
> > something like that instead?
> > 
> 
> [Manikanta]  Yes, it makes sense having a separate driver hook
> instead of using drv_tx, but in case of drivers (fe ath10k) 
> where enqueuing and dequeuing tx logic (wake_tx_queue and
> ieee80211_tx_dequeue) is used there should be a way
> to indicate that the packet is not 80211 encapsulated, isn't it?
> Correct me if I am missing anything.

Ah, interesting. Yeah, I guess that makes some sense then, though I'm
not super happy with sharing the code paths between differently
encapsulated frames - best to leave that as minimal as possible.

> [Manikanta]  Hmmm you are right. I just went through the code, seems
> ieee80211_tx_status_noskb does most of them what
> ieee80211_tx_status_8023 is doing, resetting the station connection
> monitoring logic and updating last known tx rate is missing in
> _noskb. These are required, isn't it?

Maybe. I don't think the tx rate is strictly required but would be
nice, while the monitoring logic is probably needed only to avoid
spurious null data packets over the air.

However, come to think of it, we need to see how this interacts with
the tx status thing - if tx status is requested then I believe _no_skb
cannot be used.

> [Manikanta] You are correct. It is good if driver advertises the vif
> types it support in encap offload mode, but how can we decide the
> netdev_ops to be used while creating the vif? drv_add_interface will
> be invoked from ndo_open and
> even before invoking driver add_interface we have to make the
> decision of using Ethernet mode netdev_ops or the default netdev_ops,
> isn't it?

It might not be a problem to swap the dev->netdev_ops, changing only
the start_xmit, while the interface is being brought up. I assume the
driver can make this decision in add_interface(), and I think swapping
there should be OK. It might be problematic if this value changes
during suspend/resume or HW restart though.

> Can we have a separate driver hook which gives whether 80211 encap
> offload is supported for the given interface type and then decide the
> netdev_ops to be attached for the vif?

I don't think that makes sense, since you can't know if the interface
will ever be brought up, so the driver can't make a good decision since
it normally doesn't have to care about interfaces that aren't brought
up.

The only real alternative I see, which might be preferable, is for the
driver to advertise a bitmap of interface types that it wants to use
ethernet framing with.

johannes

RE: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Pubbisetty, Manikanta]

Pj4gPiBXaHkgaXMgdGhhdCBuZWVkZWQ/IFNpbmNlIHlvdSBoYXZlIGEgc2VwYXJhdGUgVFggcGF0
aA0KPj4gPiAobmRvX3N0YXJ0X3htaXQpLCB3b3VsZG4ndCBpdCBtYWtlIG1vcmUgc2Vuc2UgdG8g
Y2FsbCBpbnRvIGENCj4+ID4gZHJ2X3R4XzgwMjMoKSBvciBzb21ldGhpbmcgbGlrZSB0aGF0IGlu
c3RlYWQ/DQo+PiA+DQo+Pg0KPj4gW01hbmlrYW50YV3CoMKgWWVzLCBpdCBtYWtlcyBzZW5zZSBo
YXZpbmcgYSBzZXBhcmF0ZSBkcml2ZXIgaG9vayBpbnN0ZWFkDQo+PiBvZiB1c2luZyBkcnZfdHgs
IGJ1dCBpbiBjYXNlIG9mIGRyaXZlcnMgKGZlIGF0aDEwaykgd2hlcmUgZW5xdWV1aW5nDQo+PiBh
bmQgZGVxdWV1aW5nIHR4IGxvZ2ljICh3YWtlX3R4X3F1ZXVlIGFuZA0KPj4gaWVlZTgwMjExX3R4
X2RlcXVldWUpIGlzIHVzZWQgdGhlcmUgc2hvdWxkIGJlIGEgd2F5IHRvIGluZGljYXRlIHRoYXQN
Cj4+IHRoZSBwYWNrZXQgaXMgbm90IDgwMjExIGVuY2Fwc3VsYXRlZCwgaXNuJ3QgaXQ/DQo+PiBD
b3JyZWN0IG1lIGlmIEkgYW0gbWlzc2luZyBhbnl0aGluZy4NCj4NCj5BaCwgaW50ZXJlc3Rpbmcu
IFllYWgsIEkgZ3Vlc3MgdGhhdCBtYWtlcyBzb21lIHNlbnNlIHRoZW4sIHRob3VnaCBJJ20gbm90
DQo+c3VwZXIgaGFwcHkgd2l0aCBzaGFyaW5nIHRoZSBjb2RlIHBhdGhzIGJldHdlZW4gZGlmZmVy
ZW50bHkgZW5jYXBzdWxhdGVkDQo+ZnJhbWVzIC0gYmVzdCB0byBsZWF2ZSB0aGF0IGFzIG1pbmlt
YWwgYXMgcG9zc2libGUuDQo+DQpbTWFuaWthbnRhXSBJbiB0aGF0IGNhc2UgSSB3aWxsIGtlZXAg
dGhpcyBjaGFuZ2UsIHNob3VsZCB3ZSBjb25zaWRlciBhIHNlcGFyYXRlIGRyaXZlciBob29rIGZv
ciBsZWdhY3kvbWdtdCB0eCBsaWtlIGRydl90eF84MDIzPz8NCkhvdyBhYm91dCBoYXZpbmcgd2Fr
ZV90eF9xdWV1ZV84MDIzIGFuZCBpZWVlODAyMTFfdHhfZGVxdWV1ZV84MDIzIHNvIHRoYXQgRXRo
ZXJuZXQgdHJhbnNtaXQgcGF0aCBpcyB0b3RhbGx5IGV4Y2x1c2l2ZS4gVGhvdWdodHM/Pw0KDQo+
PiBbTWFuaWthbnRhXcKgwqBIbW1tIHlvdSBhcmUgcmlnaHQuIEkganVzdCB3ZW50IHRocm91Z2gg
dGhlIGNvZGUsIHNlZW1zDQo+PiBpZWVlODAyMTFfdHhfc3RhdHVzX25vc2tiIGRvZXMgbW9zdCBv
ZiB0aGVtIHdoYXQNCj4+IGllZWU4MDIxMV90eF9zdGF0dXNfODAyMyBpcyBkb2luZywgcmVzZXR0
aW5nIHRoZSBzdGF0aW9uIGNvbm5lY3Rpb24NCj4+IG1vbml0b3JpbmcgbG9naWMgYW5kIHVwZGF0
aW5nIGxhc3Qga25vd24gdHggcmF0ZSBpcyBtaXNzaW5nIGluIF9ub3NrYi4NCj4+IFRoZXNlIGFy
ZSByZXF1aXJlZCwgaXNuJ3QgaXQ/DQo+DQo+TWF5YmUuIEkgZG9uJ3QgdGhpbmsgdGhlIHR4IHJh
dGUgaXMgc3RyaWN0bHkgcmVxdWlyZWQgYnV0IHdvdWxkIGJlIG5pY2UsIHdoaWxlDQo+dGhlIG1v
bml0b3JpbmcgbG9naWMgaXMgcHJvYmFibHkgbmVlZGVkIG9ubHkgdG8gYXZvaWQgc3B1cmlvdXMg
bnVsbCBkYXRhDQo+cGFja2V0cyBvdmVyIHRoZSBhaXIuDQo+DQo+SG93ZXZlciwgY29tZSB0byB0
aGluayBvZiBpdCwgd2UgbmVlZCB0byBzZWUgaG93IHRoaXMgaW50ZXJhY3RzIHdpdGggdGhlIHR4
DQo+c3RhdHVzIHRoaW5nIC0gaWYgdHggc3RhdHVzIGlzIHJlcXVlc3RlZCB0aGVuIEkgYmVsaWV2
ZSBfbm9fc2tiIGNhbm5vdCBiZSB1c2VkLg0KPg0KW01hbmlrYW50YV0gSG1tbSwgSSB3b3VsZCBs
aWtlIHRvIGhhdmUgaWVlZTgwMjExX3R4X3N0YXR1c184MDIzIGZvciBub3cgYW5kIGdvIHdpdGgg
YSBUT0RPIGZvciBzaW5nbGUgdHggcmVwb3J0aW5nIG1lY2hhbmlzbSBmb3IgYm90aCBFdGhlcm5l
dCBhbmQgODAyLjExIHR4IGZvcm1hdHMuIEFueSB0aG91Z2h0cz8NCg0KPj4gW01hbmlrYW50YV0g
WW91IGFyZSBjb3JyZWN0LiBJdCBpcyBnb29kIGlmIGRyaXZlciBhZHZlcnRpc2VzIHRoZSB2aWYN
Cj4+IHR5cGVzIGl0IHN1cHBvcnQgaW4gZW5jYXAgb2ZmbG9hZCBtb2RlLCBidXQgaG93IGNhbiB3
ZSBkZWNpZGUgdGhlDQo+PiBuZXRkZXZfb3BzIHRvIGJlIHVzZWQgd2hpbGUgY3JlYXRpbmcgdGhl
IHZpZj8gZHJ2X2FkZF9pbnRlcmZhY2Ugd2lsbA0KPj4gYmUgaW52b2tlZCBmcm9tIG5kb19vcGVu
IGFuZCBldmVuIGJlZm9yZSBpbnZva2luZyBkcml2ZXIgYWRkX2ludGVyZmFjZQ0KPj4gd2UgaGF2
ZSB0byBtYWtlIHRoZSBkZWNpc2lvbiBvZiB1c2luZyBFdGhlcm5ldCBtb2RlIG5ldGRldl9vcHMg
b3IgdGhlDQo+PiBkZWZhdWx0IG5ldGRldl9vcHMsIGlzbid0IGl0Pw0KPg0KPkl0IG1pZ2h0IG5v
dCBiZSBhIHByb2JsZW0gdG8gc3dhcCB0aGUgZGV2LT5uZXRkZXZfb3BzLCBjaGFuZ2luZyBvbmx5
IHRoZQ0KPnN0YXJ0X3htaXQsIHdoaWxlIHRoZSBpbnRlcmZhY2UgaXMgYmVpbmcgYnJvdWdodCB1
cC4gSSBhc3N1bWUgdGhlIGRyaXZlciBjYW4NCj5tYWtlIHRoaXMgZGVjaXNpb24gaW4gYWRkX2lu
dGVyZmFjZSgpLCBhbmQgSSB0aGluayBzd2FwcGluZyB0aGVyZSBzaG91bGQgYmUNCj5PSy4gSXQg
bWlnaHQgYmUgcHJvYmxlbWF0aWMgaWYgdGhpcyB2YWx1ZSBjaGFuZ2VzIGR1cmluZyBzdXNwZW5k
L3Jlc3VtZSBvcg0KPkhXIHJlc3RhcnQgdGhvdWdoLg0KPg0KW01hbmlrYW50YV0gQ29ycmVjdC4N
Cg0KPj4gQ2FuIHdlIGhhdmUgYSBzZXBhcmF0ZSBkcml2ZXIgaG9vayB3aGljaCBnaXZlcyB3aGV0
aGVyIDgwMjExIGVuY2FwDQo+PiBvZmZsb2FkIGlzIHN1cHBvcnRlZCBmb3IgdGhlIGdpdmVuIGlu
dGVyZmFjZSB0eXBlIGFuZCB0aGVuIGRlY2lkZSB0aGUNCj4+IG5ldGRldl9vcHMgdG8gYmUgYXR0
YWNoZWQgZm9yIHRoZSB2aWY/DQo+DQo+SSBkb24ndCB0aGluayB0aGF0IG1ha2VzIHNlbnNlLCBz
aW5jZSB5b3UgY2FuJ3Qga25vdyBpZiB0aGUgaW50ZXJmYWNlIHdpbGwgZXZlcg0KPmJlIGJyb3Vn
aHQgdXAsIHNvIHRoZSBkcml2ZXIgY2FuJ3QgbWFrZSBhIGdvb2QgZGVjaXNpb24gc2luY2UgaXQg
bm9ybWFsbHkNCj5kb2Vzbid0IGhhdmUgdG8gY2FyZSBhYm91dCBpbnRlcmZhY2VzIHRoYXQgYXJl
bid0IGJyb3VnaHQgdXAuDQo+DQpbTWFuaWthbnRhXSBIbW1tIG9rYXkuDQoNCj5UaGUgb25seSBy
ZWFsIGFsdGVybmF0aXZlIEkgc2VlLCB3aGljaCBtaWdodCBiZSBwcmVmZXJhYmxlLCBpcyBmb3Ig
dGhlIGRyaXZlciB0bw0KPmFkdmVydGlzZSBhIGJpdG1hcCBvZiBpbnRlcmZhY2UgdHlwZXMgdGhh
dCBpdCB3YW50cyB0byB1c2UgZXRoZXJuZXQgZnJhbWluZw0KPndpdGguDQo+DQpbTWFuaWthbnRh
XSBDb3JyZWN0LCB0aGlzIHdvdWxkIGJlIGEgb25ldGltZSByZWdpc3RyYXRpb24uIElzbid0IGl0
ID8NCkkgYW0ganVzdCBjdXJpb3VzIHRvIGtub3cgd2hldGhlciB0aGUgc3VwcG9ydGVkIHZpZiB0
eXBlcyBmb3IgZXRoZXJuZXQgZnJhbWluZyBjYW4gY2hhbmdlIGR5bmFtaWNhbGx5LCBpcyB0aGlz
IHBvc3NpYmxlPw0KDQotLQ0KTWFuaWthbnRhDQo=

Re: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Johannes Berg]

Hi,

[Manikanta] In that case I will keep this change, should we consider
a separate driver hook for legacy/mgmt tx like drv_tx_8023??
> How about having wake_tx_queue_8023 and ieee80211_tx_dequeue_8023 so
> that Ethernet transmit path is totally exclusive. Thoughts??

I'm not sure this will work well. The driver might have more space for
sending to a specific station, but doesn't really know which frames
should go first. So either it'd have to call both (dequeue_8023
followed by dequeue) with mac80211 sorting out what to do, or we should
keep it combined. I think mac80211 sorting out the priority here etc.
would be far more complex than this.

> [Manikanta] Hmmm, I would like to have ieee80211_tx_status_8023 for
> now and go with a TODO for single tx reporting mechanism for both
> Ethernet and 802.11 tx formats. Any thoughts?

There's an additional wrinkle btw - we currently report the 802.11
frame to the monitor interface, if active. Not sure we can keep that,
but it's something to think about.

> > The only real alternative I see, which might be preferable, is for
> > the driver to advertise a bitmap of interface types that it wants
> > to use ethernet framing with.
> > 
> 
> [Manikanta] Correct, this would be a onetime registration. Isn't it ?
> I am just curious to know whether the supported vif types for
> ethernet framing can change dynamically, is this possible?

I don't see why it would change. I guess there's a small chance that
you might design the HW in a way that it only has enough HW resources
to do header format conversion for a limited number of interfaces, but
if that ends up being a problem we can perhaps add more other
capabilities.

The way we're looking at it will be type/header format dependent,
nothing else.

johannes

RE: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Manikanta Pubbisetty]

SGksDQoNCj5bTWFuaWthbnRhXSBJbiB0aGF0IGNhc2UgSSB3aWxsIGtlZXAgdGhpcyBjaGFuZ2Us
IHNob3VsZCB3ZSBjb25zaWRlciBhIHNlcGFyYXRlDQo+ZHJpdmVyIGhvb2sgZm9yIGxlZ2FjeS9t
Z210IHR4IGxpa2UgZHJ2X3R4XzgwMjM/Pw0KPj4gSG93IGFib3V0IGhhdmluZyB3YWtlX3R4X3F1
ZXVlXzgwMjMgYW5kIGllZWU4MDIxMV90eF9kZXF1ZXVlXzgwMjMNCj5zbw0KPj4gdGhhdCBFdGhl
cm5ldCB0cmFuc21pdCBwYXRoIGlzIHRvdGFsbHkgZXhjbHVzaXZlLiBUaG91Z2h0cz8/DQo+DQo+
SSdtIG5vdCBzdXJlIHRoaXMgd2lsbCB3b3JrIHdlbGwuIFRoZSBkcml2ZXIgbWlnaHQgaGF2ZSBt
b3JlIHNwYWNlIGZvciBzZW5kaW5nDQo+dG8gYSBzcGVjaWZpYyBzdGF0aW9uLCBidXQgZG9lc24n
dCByZWFsbHkga25vdyB3aGljaCBmcmFtZXMgc2hvdWxkIGdvIGZpcnN0LiBTbw0KPmVpdGhlciBp
dCdkIGhhdmUgdG8gY2FsbCBib3RoIChkZXF1ZXVlXzgwMjMgZm9sbG93ZWQgYnkgZGVxdWV1ZSkg
d2l0aA0KPm1hYzgwMjExIHNvcnRpbmcgb3V0IHdoYXQgdG8gZG8sIG9yIHdlIHNob3VsZCBrZWVw
IGl0IGNvbWJpbmVkLiBJIHRoaW5rDQo+bWFjODAyMTEgc29ydGluZyBvdXQgdGhlIHByaW9yaXR5
IGhlcmUgZXRjLg0KPndvdWxkIGJlIGZhciBtb3JlIGNvbXBsZXggdGhhbiB0aGlzLg0KPg0KW01h
bmlrYW50YV0gSG1tbS4NCg0KPj4gW01hbmlrYW50YV0gSG1tbSwgSSB3b3VsZCBsaWtlIHRvIGhh
dmUgaWVlZTgwMjExX3R4X3N0YXR1c184MDIzIGZvcg0KPj4gbm93IGFuZCBnbyB3aXRoIGEgVE9E
TyBmb3Igc2luZ2xlIHR4IHJlcG9ydGluZyBtZWNoYW5pc20gZm9yIGJvdGgNCj4+IEV0aGVybmV0
IGFuZCA4MDIuMTEgdHggZm9ybWF0cy4gQW55IHRob3VnaHRzPw0KPg0KPlRoZXJlJ3MgYW4gYWRk
aXRpb25hbCB3cmlua2xlIGJ0dyAtIHdlIGN1cnJlbnRseSByZXBvcnQgdGhlIDgwMi4xMSBmcmFt
ZSB0bw0KPnRoZSBtb25pdG9yIGludGVyZmFjZSwgaWYgYWN0aXZlLiBOb3Qgc3VyZSB3ZSBjYW4g
a2VlcCB0aGF0LCBidXQgaXQncyBzb21ldGhpbmcNCj50byB0aGluayBhYm91dC4NCj4NCltNYW5p
a2FudGFdIEdvb2QgcG9pbnQsIHRoaXMgaXMgc29tZXRoaW5nIHdlIGhhdmUgdG8gdGhpbmsgYWJv
dXQuIEkgYmVsaWV2ZSB0aGlzIG9uZSBpcyB0cmlja3ksIGRvIHdlIG5lZWQgdG8gYWRkIHRoZSAu
MTEgaGVhZGVyIGp1c3QgYmVmb3JlIGdpdmluZyB0byBtb25pdG9yIGludGVyZmFjZXM/DQpIb3cg
aW1wb3J0YW50IHdpbGwgdGhpcyBiZSBmb3IgRXRoZXJuZXQgdHggY2hhbmdlcz8gSSBhbSBydW5u
aW5nIG91dCBvZiB0aG91Z2h0cy4NCg0KPj4gPiBUaGUgb25seSByZWFsIGFsdGVybmF0aXZlIEkg
c2VlLCB3aGljaCBtaWdodCBiZSBwcmVmZXJhYmxlLCBpcyBmb3INCj4+ID4gdGhlIGRyaXZlciB0
byBhZHZlcnRpc2UgYSBiaXRtYXAgb2YgaW50ZXJmYWNlIHR5cGVzIHRoYXQgaXQgd2FudHMgdG8N
Cj4+ID4gdXNlIGV0aGVybmV0IGZyYW1pbmcgd2l0aC4NCj4+ID4NCj4+DQo+PiBbTWFuaWthbnRh
XSBDb3JyZWN0LCB0aGlzIHdvdWxkIGJlIGEgb25ldGltZSByZWdpc3RyYXRpb24uIElzbid0IGl0
ID8NCj4+IEkgYW0ganVzdCBjdXJpb3VzIHRvIGtub3cgd2hldGhlciB0aGUgc3VwcG9ydGVkIHZp
ZiB0eXBlcyBmb3IgZXRoZXJuZXQNCj4+IGZyYW1pbmcgY2FuIGNoYW5nZSBkeW5hbWljYWxseSwg
aXMgdGhpcyBwb3NzaWJsZT8NCj4NCj5JIGRvbid0IHNlZSB3aHkgaXQgd291bGQgY2hhbmdlLiBJ
IGd1ZXNzIHRoZXJlJ3MgYSBzbWFsbCBjaGFuY2UgdGhhdCB5b3UgbWlnaHQNCj5kZXNpZ24gdGhl
IEhXIGluIGEgd2F5IHRoYXQgaXQgb25seSBoYXMgZW5vdWdoIEhXIHJlc291cmNlcyB0byBkbyBo
ZWFkZXINCj5mb3JtYXQgY29udmVyc2lvbiBmb3IgYSBsaW1pdGVkIG51bWJlciBvZiBpbnRlcmZh
Y2VzLCBidXQgaWYgdGhhdCBlbmRzIHVwIGJlaW5nDQo+YSBwcm9ibGVtIHdlIGNhbiBwZXJoYXBz
IGFkZCBtb3JlIG90aGVyIGNhcGFiaWxpdGllcy4NCj4NCj5UaGUgd2F5IHdlJ3JlIGxvb2tpbmcg
YXQgaXQgd2lsbCBiZSB0eXBlL2hlYWRlciBmb3JtYXQgZGVwZW5kZW50LCBub3RoaW5nDQo+ZWxz
ZS4NCj4NCltNYW5pa2FudGFdIEhtbW0gb2theS4NCg0KTWFuaWthbnRhDQo=

Re: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Johannes Berg]

Sorry, almost dropped this thread - my bad.

> > > [Manikanta] Hmmm, I would like to have ieee80211_tx_status_8023
> > > for
> > > now and go with a TODO for single tx reporting mechanism for both
> > > Ethernet and 802.11 tx formats. Any thoughts?
> > 
> > There's an additional wrinkle btw - we currently report the 802.11
> > frame to the monitor interface, if active. Not sure we can keep
> > that, but it's something to think about.
> > 
> 
> [Manikanta] Good point, this is something we have to think about. I
> believe this one is tricky, do we need to add the .11 header just
> before giving to monitor interfaces?

It's complicated. The interface has radiotap+802.11 type, so on the one
hand it should have 802.11 header. On the other hand, having what went
to the hardware can be helpful. However, I don't think we can get
around the radiotap+802.11 type in any way.

> How important will this be for Ethernet tx changes? I am running out
> of thoughts.

Well I think it's something we should consider when we look at this
path. Hopefully nobody who really cares about performance has the
monitor stuff active - although we're thinking of ways to push down
filters to make that less expensive.

johannes

RE: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Manikanta Pubbisetty]

PlNvcnJ5LCBhbG1vc3QgZHJvcHBlZCB0aGlzIHRocmVhZCAtIG15IGJhZC4NCj4NCj4+ID4gPiBb
TWFuaWthbnRhXSBIbW1tLCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBpZWVlODAyMTFfdHhfc3RhdHVz
XzgwMjMNCj4+ID4gPiBmb3Igbm93IGFuZCBnbyB3aXRoIGEgVE9ETyBmb3Igc2luZ2xlIHR4IHJl
cG9ydGluZyBtZWNoYW5pc20gZm9yDQo+PiA+ID4gYm90aCBFdGhlcm5ldCBhbmQgODAyLjExIHR4
IGZvcm1hdHMuIEFueSB0aG91Z2h0cz8NCj4+ID4NCj4+ID4gVGhlcmUncyBhbiBhZGRpdGlvbmFs
IHdyaW5rbGUgYnR3IC0gd2UgY3VycmVudGx5IHJlcG9ydCB0aGUgODAyLjExDQo+PiA+IGZyYW1l
IHRvIHRoZSBtb25pdG9yIGludGVyZmFjZSwgaWYgYWN0aXZlLiBOb3Qgc3VyZSB3ZSBjYW4ga2Vl
cA0KPj4gPiB0aGF0LCBidXQgaXQncyBzb21ldGhpbmcgdG8gdGhpbmsgYWJvdXQuDQo+PiA+DQo+
Pg0KPj4gW01hbmlrYW50YV0gR29vZCBwb2ludCwgdGhpcyBpcyBzb21ldGhpbmcgd2UgaGF2ZSB0
byB0aGluayBhYm91dC4gSQ0KPj4gYmVsaWV2ZSB0aGlzIG9uZSBpcyB0cmlja3ksIGRvIHdlIG5l
ZWQgdG8gYWRkIHRoZSAuMTEgaGVhZGVyIGp1c3QNCj4+IGJlZm9yZSBnaXZpbmcgdG8gbW9uaXRv
ciBpbnRlcmZhY2VzPw0KPg0KPkl0J3MgY29tcGxpY2F0ZWQuIFRoZSBpbnRlcmZhY2UgaGFzIHJh
ZGlvdGFwKzgwMi4xMSB0eXBlLCBzbyBvbiB0aGUgb25lIGhhbmQgaXQNCj5zaG91bGQgaGF2ZSA4
MDIuMTEgaGVhZGVyLiBPbiB0aGUgb3RoZXIgaGFuZCwgaGF2aW5nIHdoYXQgd2VudCB0byB0aGUN
Cj5oYXJkd2FyZSBjYW4gYmUgaGVscGZ1bC4gSG93ZXZlciwgSSBkb24ndCB0aGluayB3ZSBjYW4g
Z2V0IGFyb3VuZCB0aGUNCj5yYWRpb3RhcCs4MDIuMTEgdHlwZSBpbiBhbnkgd2F5Lg0KPg0KPj4g
SG93IGltcG9ydGFudCB3aWxsIHRoaXMgYmUgZm9yIEV0aGVybmV0IHR4IGNoYW5nZXM/IEkgYW0g
cnVubmluZyBvdXQNCj4+IG9mIHRob3VnaHRzLg0KPg0KPldlbGwgSSB0aGluayBpdCdzIHNvbWV0
aGluZyB3ZSBzaG91bGQgY29uc2lkZXIgd2hlbiB3ZSBsb29rIGF0IHRoaXMgcGF0aC4NCj5Ib3Bl
ZnVsbHkgbm9ib2R5IHdobyByZWFsbHkgY2FyZXMgYWJvdXQgcGVyZm9ybWFuY2UgaGFzIHRoZSBt
b25pdG9yIHN0dWZmDQo+YWN0aXZlIC0gYWx0aG91Z2ggd2UncmUgdGhpbmtpbmcgb2Ygd2F5cyB0
byBwdXNoIGRvd24gZmlsdGVycyB0byBtYWtlIHRoYXQgbGVzcw0KPmV4cGVuc2l2ZS4NCj4NCj5K
b2hhbm5lcw0KDQpbTWFuaWthbnRhXSBUaGFua3MgZm9yIHlvdXIgdGltZSBpbiByZXZpZXdpbmcg
dGhlIHBhdGNoIEpvaGFubmVzLCBJIHdpbGwgbWFrZSB0aGUgY2hhbmdlcyBhcyBkaXNjdXNzZWQg
YW5kIHNlbmQgb3V0IHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBwYXRjaC4NCg0KLS0NCk1hbmlr
YW50YQ0K