Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Tue, 28 Jul 2020 18:47:30 -0700
From:   Rajkumar Manoharan <rmanohar@codeaurora.org>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Felix Fietkau <nbd@nbd.name>, linux-wireless@vger.kernel.org,
        linux-wireless-owner@vger.kernel.org
Subject: Re: [RFC] mac80211: add a function for running rx without passing
 skbs to the stack
In-Reply-To: <c1b2a6583245560952db0cde3e3d6ff9db4cbd5a.camel@sipsolutions.net>
References: <20200725185554.17346-1-nbd@nbd.name>
 <c1b2a6583245560952db0cde3e3d6ff9db4cbd5a.camel@sipsolutions.net>
Message-ID: <801c3763d82b86268797fdc75040ce75@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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?

-Rajkumar