From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7FEB5A0032; Fri, 21 Oct 2022 22:07:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C7F4400D6; Fri, 21 Oct 2022 22:07:56 +0200 (CEST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by mails.dpdk.org (Postfix) with ESMTP id 18C5340042 for ; Fri, 21 Oct 2022 22:07:54 +0200 (CEST) Received: by mail-lj1-f177.google.com with SMTP id n23so2373118ljc.3 for ; Fri, 21 Oct 2022 13:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=qgnUo5byqjZOE6Bc+mQBN2tZu9W9xwh77/udwmSJoIo=; b=qJRJ384zz37LhRJw1q559LVer1vdYVIL76eKDckqe8p5rcwhHXwax9mc3zZY+EfAjQ YUmJBcV88TPAkK9nfPFLoGfk/DjcGD0PkUXuExbioKZE+9JGh9mzWKECCgfR4Bm1qnRh qGY9FQyATSXB5jy3Wt5dvyKg83tV1dZswQ7RspNm6ajPZdwebp8EaiVHMHE0ACr7OTlh TmSAz1dxsGqrRt4O3D5yeuddRbUTuaHn5iGNUJQ8/0v1R7jEu8M/b+fJN5oWuCRbbTxu Tk9SbyJ++Ii/fNKb0HKCC4AOYSXuN23QUXJ99MCnRo1Vh1SrxjXspqWRqg69c5PU/J3R ybww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qgnUo5byqjZOE6Bc+mQBN2tZu9W9xwh77/udwmSJoIo=; b=Tlnf0hiGwEhp3Ug7vySiPhtvvc+MgSVj28IvgaAlgilgirSzsIG82HXQyTVyXuutM7 swqy2M70KqcISscaTlQ8zvYl0/FI//NSncLB3q9W9cuDRPhJZFV5q+QgJ+TT2XV1rg45 /CnEzUXskYxvhArOhEEDznhIirQfhtXweM1u+QwJnRoQb1Fr2R/h6hhGuCYIEmZZ+Wvp uMGvNZXyWjj1bhESQ+UhXOu8YXhC5oCTJKYtGGDhj5qVsYBan5OpgbAxJfIcc258p6nt pAGlHZwPHH2JjXXJFNVS0I6lrO2RuSHOSLfxf603A84NrbRTltk6yOGbP0Vt+fTD2WqD KHwA== X-Gm-Message-State: ACrzQf0JDVuPSCCC1xF+xnhNkhW1/vQtUkqwSzHkwDprpmimNh6oq76T XPxQiJKLiL0SuYODeEi2l9Q= X-Google-Smtp-Source: AMsMyM5dqE/2rAGfK2ENPfc+XMv3nEr8SAdPWG47hM2+2b4exU7s6+sZcwxrexnRiRJ08jlTS8BxIA== X-Received: by 2002:a05:651c:b0d:b0:26f:d3ce:8ce0 with SMTP id b13-20020a05651c0b0d00b0026fd3ce8ce0mr7217542ljr.428.1666382873343; Fri, 21 Oct 2022 13:07:53 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id w8-20020a05651c118800b0026e03e61a70sm382076ljo.84.2022.10.21.13.07.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Oct 2022 13:07:52 -0700 (PDT) Date: Fri, 21 Oct 2022 23:07:51 +0300 From: Dmitry Kozlyuk To: Amit Prakash Shukla Cc: Anatoly Burakov , "dev@dpdk.org" , Jerin Jacob Kollanukkaran , "david.marchand@redhat.com" , "bruce.richardson@intel.com" , "ciara.power@intel.com" Subject: Re: [EXT] Re: [PATCH v5 1/2] mem: telemetry support for memseg and element information Message-ID: <20221021230751.0b5cbb38@sovereign> In-Reply-To: References: <20220525103352.1806937-1-amitprakashs@marvell.com> <20220929114313.1346972-1-amitprakashs@marvell.com> <20221020144046.13b98d76@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Amit, 2022-10-21 19:26 (UTC+0000), Amit Prakash Shukla: [...] > > How does the user learn heap_id? > > There probably should be /eal/heap_id returning a list of heap IDs. > > Request for list of active heap Id's is already present. > " /eal/heap_list" My bad! > > > --> /eal/element_list,0,1,15 > > > {"/eal/element_list": {"Element_count": 52}} > > > > > > 5. /eal/element_info,,,, \ > > > , > > > The command outputs element information like element start address, > > > end address, to which memseg it belongs, element state, element size. > > > User can give a range of elements to be printed. > > > Example: > > > --> /eal/element_info,0,1,15,1,2 > > > {"/eal/element_info": {"element.1": {"msl_id": 1, \ > > > "ms_id": 15, "memseg_start_addr": "0xb20000000", \ > > > "memseg_end_addr": "0xb40000000", \ > > > "element_start_addr": "0xb201fe680", \ > > > "element_end_addr": "0xb20bfe700", \ > > > "element_size": 10485888, "element_state": "Busy"}, \ > > > "element.2": {"msl_id": 1, "ms_id": 15, \ > > > "memseg_start_addr": "0xb20000000", \ > > > "memseg_end_addr": "0xb40000000", \ > > > "element_start_addr": "0xb20bfe700", \ > > > "element_end_addr": "0xb215fe780", "element_size": 10485888, \ > > > "element_state": "Busy"}, "Element_count": 2}} > > > > How this request is going to be used? > > Elements don't have permanent IDs like MSL/memseg index or heap ID. > > Heap layout may change between /eal/element_list and this request. > > Idea here was to print information related to memory element. This information > Can be printed for a single element or for a range of elements. I understand what this request does, the question is: what info the user has initially, what they want to learn, and whether the request helps them. For example, if the user wants to understand which elements hold the known hugepage from being freed, then your request is good as it is. On the other hand, if the user initially has an address from some debug print and wants to know if it's free, and if not, what's there, then my suggestion about query by address is more suitable. Or maybe both are good to have eventually. > > Maybe instead there should be a filter by address with maybe a context > > parameter (like "grep -C")? > > You mean that the user shall be able to grep for a memory address to check > which element it belongs to ? If my understanding is correct, can I implement > it as new request post rc2 and keep this request as-is? Yes, this is what I mean. AFAIU, rc1 is API freeze, and telemetry is API, so the new request must wait. If the current request helps solving actual issues, of course let's have it.