On 2020-07-28 18:47, Rajkumar Manoharan wrote:
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?
Also I was thinking of introducing threaded irq in athX driver. I was
concerned about
more threaded levels and intermediate lists might increase sojourn which
will impact latency. no?
-Rajkumar
