Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
From:   Justin Lai <justinlai0215@realtek.com>
To:     Jakub Kicinski <kuba@kernel.org>
CC:     "davem@davemloft.net" <davem@davemloft.net>,
        "edumazet@google.com" <edumazet@google.com>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "andrew@lunn.ch" <andrew@lunn.ch>,
        Ping-Ke Shih <pkshih@realtek.com>,
        Larry Chiu <larry.chiu@realtek.com>
Subject: RE: [PATCH net-next v13 01/13] rtase: Add pci table supported in this module
Thread-Topic: [PATCH net-next v13 01/13] rtase: Add pci table supported in
 this module
Thread-Index: AQHaI4J1hYqre02tzkGBvHQzDpC7MLCU5PoAgAV9LKCAALy7AIAECGwQ
Date:   Fri, 8 Dec 2023 09:27:44 +0000
Message-ID: <e5281291c4c04630ab818fdc8394841b@realtek.com>
References: <20231130114327.1530225-1-justinlai0215@realtek.com>
        <20231130114327.1530225-2-justinlai0215@realtek.com>
        <20231201203602.7e380716@kernel.org>
        <ae4807e31b53452ebf176098d95cf1fb@realtek.com>
 <20231205194050.7033cc2b@kernel.org>
In-Reply-To: <20231205194050.7033cc2b@kernel.org>
Accept-Language: zh-TW, en-US
Content-Language: zh-TW
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Precedence: bulk

> 
> On Wed, 6 Dec 2023 03:28:32 +0000 Justin Lai wrote:
> > > > +static void rtase_remove_one(struct pci_dev *pdev) {
> > > > +     struct net_device *dev = pci_get_drvdata(pdev);
> > > > +     struct rtase_private *tp = netdev_priv(dev);
> > > > +     struct rtase_int_vector *ivec;
> > > > +     u32 i;
> > > > +
> > > > +     for (i = 0; i < tp->int_nums; i++) {
> > > > +             ivec = &tp->int_vector[i];
> > > > +             netif_napi_del(&ivec->napi);
> > >
> > > NAPI instances should be added on ndo_open()
> >
> > Do you want me to call netif_napi_add() in the .ndo_open function, and
> > netif_napi_del() in the .ndo_stop function? However, I saw that many
> > drivers do it in probe and remove. What is the purpose of doing this
> > in .ndo_open and .ndo_stop?
> 
> They will sit in a fixed-size hash table used for NAPI lookup in the core. Not a
> big deal, but not the best way either.
> 
> I think the main thing that prompted me to ask was that I couldn't find
> napi_disable() in the first few patches. You should probably call it on close,
> otherwise making sure NAPI is not running when you start freeing rings is hard.
> synchronize_irq() will not help you at all if you're using NAPI.

Thanks, I will call napi_disable() on close to fix this issue.