From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <users-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AE9C2A0032 for <public@inbox.dpdk.org>; Tue, 12 Jul 2022 13:22:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D83E41109; Tue, 12 Jul 2022 13:22:13 +0200 (CEST) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by mails.dpdk.org (Postfix) with ESMTP id BB2D6400D4 for <users@dpdk.org>; Tue, 12 Jul 2022 13:22:11 +0200 (CEST) Received: by mail-lf1-f42.google.com with SMTP id bp17so5546339lfb.3 for <users@dpdk.org>; Tue, 12 Jul 2022 04:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Pdn0T83Z7ki9hHMTBBhhkW2BmhA2l7Q54oiiVAF2Aus=; b=eMPcWd/qMOKSVYs1bzsbqqtYUbS3TnuZh/Exhi/ZB2C6aRse74kUhHR35DgVzjHGOR eHjomvR/sRqT0YVT2opR+eIIfmZ4wM4BbqkunIr9/9hqek3fE3aaCQzmTyF4Q4OlxdiN 79HpjLzhWGiAQp1IyMctECYFk0d5uH+SFVbG7KOBWJIHlvNt511aBK7rbFbyOzzuHVe/ e9DoA+AgCxwZuHQSpl0AukjhtaXs2PWtnZ8do+odxs3Ye7D4xvjPIeprgAu8UROuXXuG a3Xc7Erc8vUVQveP0/+XyJXQ7vJylcpvabXal8IickxmNObmp0uOsk8ynZZ3nuJBnAq1 5dEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Pdn0T83Z7ki9hHMTBBhhkW2BmhA2l7Q54oiiVAF2Aus=; b=DfkgUPNiOz73hPnNd9wkhgD+LpF19OAhp73Hqh/J9QT1TQ6yHCkCydZ2dsq0YgMx9C WEgVTSfpZGtENpi59vIopauy7pfniQIeVghaJjT4pesh+9JR1NRrjxUTqZZApp8A8UYB NIWcIVezQY6hUmI9XAcOeacJ//nDARwB4kZCumgM+b/HE3MXDrejaEkUpJEkbP7e+C+Y ARF2ciWhDdvshMmjxPaQXARkLY9ZRExxQeE5L8DsLmLKEyal2/Jvxgsoo/ef9yLEgn7f Co8zAbN2Qp4/pEBBhKN57LqdVa6rxktKYiaxk3Xt8sazERSnAKRdICEqSzoiFFFM+5Fw Z3Pw== X-Gm-Message-State: AJIora+ezTIF/wWQsQ4Ai0UeQqHbIIfkN48p7mMNbgK4Yp5/IkB/QETg yATfDmy7b1FzweiSJ0T0EW8KyA5gzp8= X-Google-Smtp-Source: AGRyM1vQEzEoRswEgzNHUOKTXWAxJdCpRZ+h/M8KmHmdzetCzkmxHnuG7zPNaOaZCJrfBF6wQnKxmQ== X-Received: by 2002:a05:6512:32c1:b0:489:e9de:2f0 with SMTP id f1-20020a05651232c100b00489e9de02f0mr2964393lfg.117.1657624931047; Tue, 12 Jul 2022 04:22:11 -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 t21-20020a056512209500b0047f84ecae2esm2114152lfr.236.2022.07.12.04.22.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 04:22:10 -0700 (PDT) Date: Tue, 12 Jul 2022 14:22:09 +0300 From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> To: Antonio Di Bacco <a.dibacco.ks@gmail.com> Cc: users@dpdk.org Subject: Re: Getting mbuf pointer from buf_addr pointer Message-ID: <20220712142209.4953c658@sovereign> In-Reply-To: <CAO8pfFmMdsX2k2AsFH5sk+ukY=QLO3EpDy+Y2U2r_DKdeEVLqg@mail.gmail.com> References: <CAO8pfFneeFnGZNxPeXTAMwe4cxXoACvWX7XhS-wGsG0RrNcgYA@mail.gmail.com> <20220712113234.1209dd36@sovereign> <CAO8pfFmMdsX2k2AsFH5sk+ukY=QLO3EpDy+Y2U2r_DKdeEVLqg@mail.gmail.com> 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: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions <users.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> Errors-To: users-bounces@dpdk.org 2022-07-12 12:30 (UTC+0200), Antonio Di Bacco: > I was asked to reproduce the exact same behaviour of a library that > used VMDQ queues without DPDK. > Now this library offered an API to allocate a buffer for a packet and > returned an address where the application could write its data. > > void* vmdqNew (vmdqUidPOOLt* p); > > I implemented the same API to allocate an MBUF from a pool and I also > return the right address as a void* but then to transmit the packet I > need the address of the MBUF for the tx_burst API and I don't have it. Since you create mbufs and send them, the approach I mentioned is viable. See rte_mbuf_buf_addr() and do the reverse to calculate the pointer to mbuf. There is no API because it cannot work for any mbuf, but you case is limited (there are chained mbufs, externally-attached mbufs, etc). BTW, in general you could save a back-reference to the mbuf just before the buffer you return from vmdqNew(), in pktmbuf private data. But direct calculation is more efficient.