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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 86AFFC76191 for ; Fri, 26 Jul 2019 06:19:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 60E0A218DA for ; Fri, 26 Jul 2019 06:19:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=endlessm-com.20150623.gappssmtp.com header.i=@endlessm-com.20150623.gappssmtp.com header.b="WmFtrFSw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726349AbfGZGTF (ORCPT ); Fri, 26 Jul 2019 02:19:05 -0400 Received: from mail-vs1-f68.google.com ([209.85.217.68]:38783 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725925AbfGZGTF (ORCPT ); Fri, 26 Jul 2019 02:19:05 -0400 Received: by mail-vs1-f68.google.com with SMTP id k9so35350047vso.5 for ; Thu, 25 Jul 2019 23:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endlessm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Bl7fI4eVZWffKAOz4zhIOA0eJ2D0U0DNka5Gld+y0is=; b=WmFtrFSw/R5Cz8UuWt8tiEoXLxFQ6BCS/F4MD7pwFOpPfJiwxzoJexVjGGjwbsbDM2 8kGywwqi+EOUNqcAN2+vSIAEsSl/yhZDMdDmQonSWX1pUYtAwsGuFx3miJ2JcVGBs7na bOUfRzSLSYvBUWvbRSdvjTY1ct55yl0Iqn5yJ5tjdfz6zPsgOdAnc8TuJC4Fxt7PuTiq 6AM60l/Fdw/kt2HG/LbYjxx1ftu9FTGK4yV8DVY1xA3Da9zgQcDfENwhQDx1YstruteQ q/r7kniw5cWXc/F3AtJTiR2+eVsb/myAm9vO7XDIP/hpQUaUdZ+mg1Nva++4iPrL65v/ E2tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Bl7fI4eVZWffKAOz4zhIOA0eJ2D0U0DNka5Gld+y0is=; b=TjEpzpjA26y2Fs0XJNMpTm9qtgAoiZ2/ZxWVERFIXldtjdNt0DOHo5uSS4LMO711fR U8GSQxCzX70rsOLd9dEP3Vr3dcOx0TxZWmj/pRRHRWCTEpNdgRXmthC2YoE0mmeNTTwV 9JmBr9YebcZwI43khT72vvspHx3PYPgYqc+Kqd76EwSwZhxhflp5vxQDy25pJFVBtp0g ubjEkjiNLZPUGqhFtRzJkfER84wI05FDc0pLW18OtqoIS/LeAUPbUFb7hEnuaBvGuQau j7g3cjgXn2C066Ej9t1wkl9+Nq+Wdd/2JlmmocurVmUryFZPbd+eDmUZCwjJAKJjAjSN z5gA== X-Gm-Message-State: APjAAAXvTyvBnc8YmTEtSXbk/BUWbSFqnvJXbMeWp6bZEj+nabIHpjhN sfF3M8uEQiVBAHfS/+cxbBd19mKsDQLOEaQSVAP94A== X-Google-Smtp-Source: APXvYqy5de4RdPtgj97TOfRHiUta7VD2dn3FWaYfsVQWQZRVK/s1bYmGEqsu1oqBvlo5cD2KF02tErIDgh9uivkIFbI= X-Received: by 2002:a67:eb19:: with SMTP id a25mr58320351vso.109.1564121943796; Thu, 25 Jul 2019 23:19:03 -0700 (PDT) MIME-Version: 1.0 References: <20190725080925.6575-1-jian-hong@endlessm.com> <06d713fff7434dfb9ccab32c2e2112e2@AcuMS.aculab.com> In-Reply-To: <06d713fff7434dfb9ccab32c2e2112e2@AcuMS.aculab.com> From: Jian-Hong Pan Date: Fri, 26 Jul 2019 14:18:26 +0800 Message-ID: Subject: Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring To: David Laight Cc: Yan-Hsuan Chuang , Kalle Valo , "David S . Miller" , "linux-wireless@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux@endlessm.com" , "stable@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Laight =E6=96=BC 2019=E5=B9=B47=E6=9C=8825= =E6=97=A5 =E9=80=B1=E5=9B=9B =E4=B8=8B=E5=8D=885:21=E5=AF=AB=E9=81=93=EF=BC= =9A > > From: Jian-Hong Pan > > Sent: 25 July 2019 09:09 > > Each skb as the element in RX ring was expected with sized buffer 8216 > > (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is > > 16640 bytes for alignment after allocated, x86_64 for example. And, the > > difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM). > > To prevent that much wasted memory, this patch follows David's > > suggestion [1] and uses general buffer arrays, instead of skbs as the > > elements in RX ring. > ... > > for (i =3D 0; i < len; i++) { > > - skb =3D dev_alloc_skb(buf_sz); > > - if (!skb) { > > + buf =3D devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC); > > You should do this allocation somewhere than can sleep. > So you don't need GFP_ATOMIC, making the allocate (and dma map) > much less likely to fail. > If they do fail using a smaller ring might be better than failing > completely. Ok, I can tweak and try it. > I suspect that buf_sz gets rounded up somewhat. > Also you almost certainly want 'buf' to be cache-line aligned. > I don't think devm_kzalloc() guarantees that at all. Sure > While allocating all 512 buffers in one block (just over 4MB) > is probably not a good idea, you may need to allocated (and dma map) > then in groups. Thanks for reviewing. But got questions here to double confirm the idea. According to original code, it allocates 512 skbs for RX ring and dma mapping one by one. So, the new code allocates memory buffer 512 times to get 512 buffer arrays. Will the 512 buffers arrays be in one block? Do you mean aggregate the buffers as a scatterlist and use dma_map_sg? Thank you, Jain-Hong Pan