From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751887AbdAYTb1 (ORCPT ); Wed, 25 Jan 2017 14:31:27 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:32818 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751491AbdAYTb0 (ORCPT ); Wed, 25 Jan 2017 14:31:26 -0500 Date: Wed, 25 Jan 2017 14:31:19 -0500 (EST) Message-Id: <20170125.143119.411717735878453521.davem@davemloft.net> To: hayeswang@realtek.com Cc: netdev@vger.kernel.org, nic_swsd@realtek.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH net v2 0/4] r8152: fix scheduling napi From: David Miller In-Reply-To: <1394712342-15778-242-Taiwan-albertk@realtek.com> References: <1394712342-15778-236-Taiwan-albertk@realtek.com> <1394712342-15778-242-Taiwan-albertk@realtek.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 25 Jan 2017 10:32:16 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Hayes Wang Date: Wed, 25 Jan 2017 16:13:17 +0800 > v2: > Add smp_mb__after_atomic() for patch #1. > > v1: > Scheduling the napi during the following periods would let it be ignored. > And the events wouldn't be handled until next napi_schedule() is called. > > 1. after napi_disable and before napi_enable(). > 2. after all actions of napi function is completed and before calling > napi_complete(). > > If no next napi_schedule() is called, tx or rx would stop working. > > In order to avoid these situations, the followings solutions are applied. > > 1. prevent start_xmit() from calling napi_schedule() during runtime suspend > or after napi_disable(). > 2. re-schedule the napi for tx if it is necessary. > 3. check if any rx is finished or not after napi_enable(). I think the fundamental issue is that since you can't stop URBs from queueing up, you cannot properly synchronize NAPI and schedule polling properly. >>From my perspective what happened here is you want GRO support, but it comes at the expense of this extremely racey NAPI support which does not at all achieve one of the main advantages of NAPI which is interrupt mitigation. It would have been so much better to implement a generic way for drivers to get GRO support without NAPI, especially if their packet feeding engine works the way that the USB networking drivers's do.