Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp82414rwb; Tue, 25 Jul 2023 12:16:18 -0700 (PDT) X-Google-Smtp-Source: APBJJlF9zMJePyT+UuAfoyXuvtIzNbs5GCottX914awTIzjJGodc9LSVyOB1ndHGwEJzQuY97aep X-Received: by 2002:a17:906:64d2:b0:993:d6a7:13b with SMTP id p18-20020a17090664d200b00993d6a7013bmr14151733ejn.22.1690312577993; Tue, 25 Jul 2023 12:16:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690312577; cv=none; d=google.com; s=arc-20160816; b=NjswDW82X0GgqVV2pksuVXh8VQpu9U+PGP0CstCi3om3tZujscdrpeXz7zI9ZxCf/C WBWOAts0EFoILWYKtJ410Mj7Wxj+618A3Ts0naT7xOiseW+aitfI6+Yoiih2CfPVED1R rjklCQRyJnBiXPz96Xg3wkEqGSzygXkjIjJq6NQnX6gA4Xn3js9rRDSWZ6UtpOxqMHQ1 cM9nS9Ijxf4grkq36ws2cFt+O/AQ7KU6+3lyzo4+NUVtGPDbHcj0tuoKx6zXa3wYvCMe Gxm1Z+H7NPzUwV9nKUyrkbN3kB1onTGhj5Vey8Ds+3MQoI9niE0/ZkB0NskjN1JwiJJa qNoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :to:content-language:subject:cc:user-agent:mime-version:date :message-id:from:dkim-signature; bh=xBbADqs+v1wKci/ZBXowdEAl6AvZzPcdCEegqxDdVtQ=; fh=wV/zvum37oOJBpfFbZgZbeuBz8iGcCuGEHEo2ONXRyI=; b=UZO2rR3oqoCqfbWFt/pXrdiqP+LGtt+gUIbbx2lNXb8i73tI+/NaZ0zBk62FffthkV 31aMD2r6G+ECwCuFaFmIEnFATyJc3kZnXbvTvZE5dUW81/0twZIgMzP1zuMIAWfnWU41 SY3uGbya0WRAc0nBjcG9jeWW4KfFH1L3JFUD+w0mTXucqCqC46RhtWb04dA3sQKY1DUz OjYKi1eC1I1RpX7d8WWXXpP3/W5YyMyn9bRRjQmbQhLLX/bducEJwaOBt0a2LmdOX5YG dLycyrfc/LGbkiEt1s3Kc07qrjXI54drXe5AxtaFWYJhbkGk8+srz/hLXWchgByWpkad 78HA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NanxW7bd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y11-20020a170906524b00b009784f00c5besi8098604ejm.263.2023.07.25.12.15.33; Tue, 25 Jul 2023 12:16:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NanxW7bd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232586AbjGYSCG (ORCPT + 99 others); Tue, 25 Jul 2023 14:02:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232592AbjGYSB4 (ORCPT ); Tue, 25 Jul 2023 14:01:56 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9722C1FE2 for ; Tue, 25 Jul 2023 11:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690308069; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xBbADqs+v1wKci/ZBXowdEAl6AvZzPcdCEegqxDdVtQ=; b=NanxW7bdoQ7RH08byXST3CQ8o4RYHSDTRCHFLiejabaqhsxV2+jj4kJxmqVGe5BJvYa4ZU cE0kswGRSLr7e9rnGHuLeC50JEIIm/MiN8WwpGHLfJeD/DctK8OqA9ubW+FoS2k2/yigWr ff8l1smO3THT1v93K7bgBep1lXuRCUU= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-347-c7kKavasN_SXSeQ0r3R7Rw-1; Tue, 25 Jul 2023 14:01:07 -0400 X-MC-Unique: c7kKavasN_SXSeQ0r3R7Rw-1 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-50daa85e940so4430200a12.0 for ; Tue, 25 Jul 2023 11:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690308065; x=1690912865; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xBbADqs+v1wKci/ZBXowdEAl6AvZzPcdCEegqxDdVtQ=; b=WZUQSBHYB2KiyGU28iSCUnCAAO5jMtqqu/EXKIv6BdWvcL50ks8IETGJpJBpuNgGOd acmkTkIpwAe1H00vl1aDQ5URoC4cs2axaAW/ECCHny+bHS2kAsNJB/4v1pMlwkR3JiGN ebn8+y37hG1PX51J0ft18YB2UYLLrFQUrM+8GW5RTl4jt50rzQwu/m9joLlbgxcY+k8d CB9OkpKY21crfEZKIAgEr8WyTddxJey9JNvyopMSjT6q8l7uJvFpJVGiXEa3HIopCoDv VXF/OvoZFaCAy2JgT0Z+TRy0icnNOB7XFrQuyjUzA8+xq69x53UeZWsoQkWL95lHQH7e vDgA== X-Gm-Message-State: ABy/qLYav7P/PHtAfaNWymbJUIg3wLWgkkVQ2908ZVA912/eLgh6QK4n QofMFLjKemkEiiKxCTpDP5QOvcC80BftR+iDkjhVI+SdfNkSoIOEMp7uPcwBTHKDf5O3cy4kQO6 YApPWD0GCnrAU0GPo6NO/mSNx X-Received: by 2002:aa7:c6da:0:b0:522:2aee:a2c9 with SMTP id b26-20020aa7c6da000000b005222aeea2c9mr6710251eds.5.1690308065633; Tue, 25 Jul 2023 11:01:05 -0700 (PDT) X-Received: by 2002:aa7:c6da:0:b0:522:2aee:a2c9 with SMTP id b26-20020aa7c6da000000b005222aeea2c9mr6710228eds.5.1690308065265; Tue, 25 Jul 2023 11:01:05 -0700 (PDT) Received: from [192.168.42.222] (194-45-78-10.static.kviknet.net. [194.45.78.10]) by smtp.gmail.com with ESMTPSA id l25-20020aa7c3d9000000b0051873c201a0sm7798293edr.26.2023.07.25.11.01.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jul 2023 11:01:04 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <729b360c-4d79-1025-f5be-384b17f132d3@redhat.com> Date: Tue, 25 Jul 2023 20:01:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: brouer@redhat.com, Dexuan Cui , KY Srinivasan , Paul Rosswurm , "olaf@aepfle.de" , "vkuznets@redhat.com" , "davem@davemloft.net" , "wei.liu@kernel.org" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "leon@kernel.org" , Long Li , "ssengar@linux.microsoft.com" , "linux-rdma@vger.kernel.org" , "daniel@iogearbox.net" , "john.fastabend@gmail.com" , "bpf@vger.kernel.org" , "ast@kernel.org" , Ajay Sharma , "hawk@kernel.org" , "tglx@linutronix.de" , "shradhagupta@linux.microsoft.com" , "linux-kernel@vger.kernel.org" , Ilias Apalodimas Subject: Re: [PATCH V3,net-next] net: mana: Add page pool for RX buffers Content-Language: en-US To: Haiyang Zhang , Jesper Dangaard Brouer , "linux-hyperv@vger.kernel.org" , "netdev@vger.kernel.org" References: <1689966321-17337-1-git-send-email-haiyangz@microsoft.com> <1af55bbb-7aff-e575-8dc1-8ba64b924580@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/07/2023 20.35, Haiyang Zhang wrote: > [...] >>> On 21/07/2023 21.05, Haiyang Zhang wrote: >>>> Add page pool for RX buffers for faster buffer cycle and reduce CPU >>>> usage. >>>> >>>> The standard page pool API is used. >>>> >>>> Signed-off-by: Haiyang Zhang >>>> --- >>>> V3: >>>> Update xdp mem model, pool param, alloc as suggested by Jakub Kicinski >>>> V2: >>>> Use the standard page pool API as suggested by Jesper Dangaard Brouer >>>> >>>> --- >>>> drivers/net/ethernet/microsoft/mana/mana_en.c | 91 +++++++++++++++-- >> -- >>>> include/net/mana/mana.h | 3 + >>>> 2 files changed, 78 insertions(+), 16 deletions(-) >>>> >>>> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c >>> b/drivers/net/ethernet/microsoft/mana/mana_en.c >>>> index a499e460594b..4307f25f8c7a 100644 >>>> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c >>>> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c >>> [...] >>>> @@ -1659,6 +1679,8 @@ static void mana_poll_rx_cq(struct mana_cq *cq) >>>> >>>> if (rxq->xdp_flush) >>>> xdp_do_flush(); >>>> + >>>> + page_pool_nid_changed(rxq->page_pool, numa_mem_id()); >>> >>> I don't think this page_pool_nid_changed() called is needed, if you do >>> as I suggest below (nid = NUMA_NO_NODE). >>> >>> >>>> } >>>> >>>> static int mana_cq_handler(void *context, struct gdma_queue >>> *gdma_queue) >>> [...] >>> >>>> @@ -2008,6 +2041,25 @@ static int mana_push_wqe(struct mana_rxq >> *rxq) >>>> return 0; >>>> } >>>> >>>> +static int mana_create_page_pool(struct mana_rxq *rxq) >>>> +{ >>>> + struct page_pool_params pprm = {}; >>> >>> You are implicitly assigning NUMA node id zero. >>> >>>> + int ret; >>>> + >>>> + pprm.pool_size = RX_BUFFERS_PER_QUEUE; >>>> + pprm.napi = &rxq->rx_cq.napi; >>> >>> You likely want to assign pprm.nid to NUMA_NO_NODE >>> >>> pprm.nid = NUMA_NO_NODE; >>> >>> For most drivers it is recommended to assign ``NUMA_NO_NODE`` (value -1) >>> as the NUMA ID to ``pp_params.nid``. When ``CONFIG_NUMA`` is enabled >>> this setting will automatically select the (preferred) NUMA node (via >>> ``numa_mem_id()``) based on where NAPI RX-processing is currently >>> running. The effect is that page_pool will only use recycled memory when >>> NUMA node match running CPU. This assumes CPU refilling driver RX-ring >>> will also run RX-NAPI. >>> >>> If a driver want more control over the NUMA node memory selection, >>> drivers can assign (``pp_params.nid``) something else than >>> `NUMA_NO_NODE`` and runtime adjust via function >>> ``page_pool_nid_changed()``. >> >> Our driver is using NUMA 0 by default, so I implicitly assign NUMA node id >> to zero during pool init. >> >> And, if the IRQ/CPU affinity is changed, the page_pool_nid_changed() >> will update the nid for the pool. Does this sound good? >> > > Also, since our driver is getting the default node from here: > gc->numa_node = dev_to_node(&pdev->dev); > I will update this patch to set the default node as above, instead of implicitly > assigning it to 0. > In that case, I agree that it make sense to use dev_to_node(&pdev->dev), like: pprm.nid = dev_to_node(&pdev->dev); Driver must have a reason for assigning gc->numa_node for this hardware, which is okay. That is why page_pool API allows driver to control this. But then I don't think you should call page_pool_nid_changed() like page_pool_nid_changed(rxq->page_pool, numa_mem_id()); Because then you will (at first packet processing event) revert the dev_to_node() setting to use numa_mem_id() of processing/running CPU. (In effect this will be the same as setting NUMA_NO_NODE). I know, mlx5 do call page_pool_nid_changed(), but they showed benchmark numbers that this was preferred action, even-when sysadm had "misconfigured" the default smp_affinity RX-processing to happen on a remote NUMA node. AFAIK mlx5 keeps the descriptor rings on the originally configured NUMA node that corresponds to the NIC PCIe slot. --Jesper