Am 29.07.2020 um 03:47 schrieb Rajkumar Manoharan:
On 2020-07-25 12:14, Johannes Berg wrote:
+void ieee80211_rx_napi(struct ieee80211_hw *hw, struct
ieee80211_sta *pubsta,
+ struct sk_buff *skb, struct napi_struct *napi)
+{
+ struct sk_buff_head list;
+
+ __skb_queue_head_init(&list);
+
+ /*
+ * key references and virtual interfaces are protected using RCU
+ * and this requires that we are in a read-side RCU section during
+ * receive processing
+ */
+ rcu_read_lock();
+ ieee80211_rx_list(hw, pubsta, skb, &list);
+ rcu_read_unlock();
+
+ while ((skb = __skb_dequeue(&list)) != NULL)
I'd drop the != NULL, but no strong feelings :)
+ if (napi)
+ napi_gro_receive(napi, skb);
+ else
+ netif_receive_skb(skb);
Nit: I'd prefer braces on the loop, just makes it nicer to read IMHO.
OTOH, the !napi case should use netif_receive_skb_list(), no?
Given the discussion, it also seems a bit odd to add more work for NAPI
poll where we process one by one ... But I see why you did that, and I
guess it's not actually that much more work.
IIUC Sebastian mentioned that threadable NAPI approach is helping in
load balancing
with minor check for dummy netdev for wireless drivers. Does this
change improve
the latency in both threaded and non-threaded modes?
check also for felix's last variant. he made a different patch based on
workq's
i'm testing this variant now on various platforms including a patched
ath10k driver
next step would be just to change other wifi drivers for the same
concept. just a few are using napi at all (mt76, ath10k and iwlwifi)
-Rajkumar
