From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B37D9C76188 for ; Sun, 21 Jul 2019 14:53:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7865F20828 for ; Sun, 21 Jul 2019 14:53:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="R6+5PvMZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726462AbfGUOx2 (ORCPT ); Sun, 21 Jul 2019 10:53:28 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:54100 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726399AbfGUOx2 (ORCPT ); Sun, 21 Jul 2019 10:53:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uq/KuE4L/8X9xcpcAVbyOyvCVSdlgHWHWJ+hXa5I46s=; b=R6+5PvMZ6HPZqj04y1qoJH7CX6 wXEj3JIz+te0OdiHsZf+nI7HO4H3/A0WqK+KvO8SK3avLB+Ra616cXfGTmroU1mBY5ikGNm4wh0Au tmld3U9xFezOLjatf+eS2Ki/7C2sRL9F+yp6eVRqTAdRLNKyhhW51ue1Z7Y8sJE4Nh+I=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1hpDDJ-0006Ke-0B; Sun, 21 Jul 2019 16:53:25 +0200 Date: Sun, 21 Jul 2019 16:53:24 +0200 From: Andrew Lunn To: Zhu Yanjun Cc: davem@davemloft.net, netdev@vger.kernel.org Subject: Re: [PATCHv2 0/2] forcedeth: recv cache to make NIC work steadily Message-ID: <20190721145324.GD22996@lunn.ch> References: <1563713633-25528-1-git-send-email-yanjun.zhu@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1563713633-25528-1-git-send-email-yanjun.zhu@oracle.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Jul 21, 2019 at 08:53:51AM -0400, Zhu Yanjun wrote: > These patches are to this scenario: > > " > When the host run for long time, there are a lot of memory fragments in > the hosts. And it is possible that kernel will compact memory fragments. > But normally it is difficult for NIC driver to allocate a memory from > kernel. From this variable stat_rx_dropped, we can confirm that NIC driver > can not allocate skb very frequently. > " > > Since NIC driver can not allocate skb in time, this makes some important > tasks not be completed in time. > To avoid it, a recv cache is created to pre-allocate skb for NIC driver. > This can make the important tasks be completed in time. > >From Nan's tests in LAB, these patches can make NIC driver work steadily. > Now in production hosts, these patches are applied. > > With these patches, one NIC port needs 125MiB reserved. This 125MiB memory > can not be used by others. To a host on which the communications are not > mandatory, it is not necessary to reserve so much memory. So this recv cache > is disabled by default. > > V1->V2: > 1. ndelay is replaced with GFP_KERNEL function __netdev_alloc_skb. > 2. skb_queue_purge is used when recv cache is destroyed. > 3. RECV_LIST_ALLOCATE bit is removed. > 4. schedule_delayed_work is moved out of while loop. Hi Zhu You don't appear to of address David's comment that this is probably the wrong way to do this, it should be a generic solution. Also, that there should be enough atomic memory in the system anyway. Have you looked at what other drivers are using atomic memory? It could actually be you need to debug some other driver, rather than add hacks to forcedeth. Andrew