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.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 A4F56C7618B for ; Fri, 26 Jul 2019 09:41:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7889B216C8 for ; Fri, 26 Jul 2019 09:41:37 +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="gF9HjbvM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726413AbfGZJlg (ORCPT ); Fri, 26 Jul 2019 05:41:36 -0400 Received: from mail-vs1-f66.google.com ([209.85.217.66]:35790 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726173AbfGZJlg (ORCPT ); Fri, 26 Jul 2019 05:41:36 -0400 Received: by mail-vs1-f66.google.com with SMTP id u124so35691810vsu.2 for ; Fri, 26 Jul 2019 02:41:35 -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=zQAETFiPc0aFNIxeDXyiIDZA2xGxTwhcJMiDlxf4BIg=; b=gF9HjbvMjl5SVhv7yb2XcM5f/0R83Nt0MPGcMkb3JbW0PVLg8hJ1aDN8/yxAzHRJe8 h9bXjl+UIP7KZVZAq1hlOgwASM6/xlIuz5VAvWQ9gqSBIcvHOSWWHldRinLfZcpxh5Rr VrSzo56C0bQjWOrBiGcfS6/jjvR+Xnuj4oVSbD6ay+tKRmwQUR9Zq63KTw704nCRuR3M UpFbHnUlHD8pWZl/Wa2KTRmcV6gw6k48UOvAfQhYPVD3wnFnjv7obhES0C5gXSDvYFjU DQh0biEXrF3tyOZ+TJv1zPmIv/gUnZ5njhjYC/kyqTZEJp9caVQKRvrG7Vxf9uhQEWPk fzbQ== 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=zQAETFiPc0aFNIxeDXyiIDZA2xGxTwhcJMiDlxf4BIg=; b=aplUfGEmiha52RfASU2J67aqyhj0RzmjzgP2a4J5bShEzlKj0CEJkbp1Jrc00IYzEl bsQyKt0kzJSQOSBvaFIfDzgoU4Nh4wyxflH8cxJweL+PJmEFbI48QBOY0JKafDzOeEA2 WI3dCcK1iK5qGBdi23Q4IEnVpX4fkEKxm4HiMLH1HTVCenxKxzfQdHWRr18G35uro+En ua/URuf2KCF6QC6W1W3K/BxjmigvPPypYtInojfW2WfTA0RTyj9XlU0WJMDoeBO+D4Mp VmTVzmsVdn74IrJ0y0DhpsXxXk7Mf9wMTTMy7IRzur8wOQwsaj89YOK43mt7szm0ECg7 0wKQ== X-Gm-Message-State: APjAAAUHja/lwnN4GdOeEhO6k3/UhM/oQngk9XMba8AU7acb8IUGHSGt Xx1VjlBb7wO9QF1Sae8O5W9eKnTV3KGmT3SJjvNRYQ== X-Google-Smtp-Source: APXvYqxvp/2LfFvQ/EjoQDSHcBttZZk1A87AFf9gl9KRUa+fnZYFT1MDihIpFExEm6iD5Y9Rq6s1yOnrhkOaXjfB/uI= X-Received: by 2002:a67:d990:: with SMTP id u16mr59869159vsj.95.1564134094915; Fri, 26 Jul 2019 02:41:34 -0700 (PDT) MIME-Version: 1.0 References: <20190725080925.6575-1-jian-hong@endlessm.com> <06d713fff7434dfb9ccab32c2e2112e2@AcuMS.aculab.com> In-Reply-To: From: Jian-Hong Pan Date: Fri, 26 Jul 2019 17:40:58 +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=8826= =E6=97=A5 =E9=80=B1=E4=BA=94 =E4=B8=8B=E5=8D=885:23=E5=AF=AB=E9=81=93=EF=BC= =9A > > From: Jian-Hong Pan > > Sent: 26 July 2019 07:18 > ... > > > 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 ide= a. > > 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? > > If you malloc a buffer of size (8192+32) the allocator will either > round it up to a whole number of (often 4k) pages or to a power of > 2 of pages - so either 12k of 16k. > I think the Linux allocator does the latter. > Some of the allocators also 'steal' a bit from the front of the buffer > for 'red tape'. > > OTOH malloc the space 15 buffers and the allocator will round the > 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the > buffers. > > You then dma_map the large buffer and split into the actual rx buffers. > Repeat until you've filled the entire ring. > The only complication is remembering the base address (and size) for > the dma_unmap and free. > Although there is plenty of padding to extend the buffer structure > significantly without using more memory. > Allocate in 15's and you (probably) have 512 bytes per buffer. > Allocate in 31's and you have 256 bytes. > > The problem is that larger allocates are more likely to fail > (especially if the system has been running for some time). > So you almost certainly want to be able to fall back to smaller > allocates even though they use more memory. > > I also wonder if you actually need 512 8k rx buffers to cover > interrupt latency? > I've not done any measurements for 20 years! Thanks for the explanation. I am not sure the combination of 512 8k RX buffers. Maybe Realtek folks can give us some idea. Tony Chuang any comment? Jian-Hong Pan