Re: [RFC] mac80211: add a function for running rx without passing skbs to the stack

[Rajkumar Manoharan <rmanohar@codeaurora.org>]

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