From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 9B2F434F3; Fri, 23 Feb 2018 16:35:01 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id a20so7409976wmd.1; Fri, 23 Feb 2018 07:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UZDFqrwevJT7VBiIThU+hapPwEcfbDTxxfpgjL05vZU=; b=WgXyDmkWUQAyqz9+Y/MvZFw3Y6V/bp66sLt5+M+kvMZfzJbIMq3eDb3jB/JCEub41H 7tA741kliss0gTUPWr0CXzJBUMnXDyBRPmnq0KcTGITD8TYNc7VLbU6R7ygDy+gZPdfN 7fnnUcDkxsTzI7kYmu87xQ+gJ0Z+MPfl1rrmW3nPIZ7G9ERuxik4WFA2qYIceFqGglpj h4qkwxZIz2sakG0a6oz4xBRKPVzVw8F8PK8N4yugcu0zWmzUCKyNmB7jx/RKOuFYNKwB azKCPMX0x9wC9rR1LwpfMaF6vi53CDc4LCqxbPYtPchtO7sCn1t10s4M2W/OAQBHEo6k vW4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UZDFqrwevJT7VBiIThU+hapPwEcfbDTxxfpgjL05vZU=; b=niVqTSzX2kkYjJ5X46lm7gBOHM3K5i/2z+ij1v+4Al4Kp05KsdQmOtjgliCk3wGrib eWmnD3hLRcQTGUClRekEtbmZY5W1M/gLBSbfM98uw1NH56TxEW2EOHQVyfpOaygo6+Hi mhs7qCvQ3HR+snE0XqAFM4K4/F97oV1RIdi3eIQkB/fzV9RApwELQ6qFaeTbljuDCTGe Bptg2+pomA9kV2A2qNK27xed/ZQNNnxPwKoiBgBDqJYZpg9LypXSUUi2OPB3PJ2JUrEl 3L2DtCfws0YyjFZG2rtWtqabQTRYW6PtDYi6E7YLtkBoKa/rsCDksh5JIrApv1lL/pna hHTQ== X-Gm-Message-State: APf1xPAVafyBkFlJLfA9GLGhMDZZ33I7114K0GYB2EruU7qp3dWRfc9D 7E9HlmI3CIusHWOoXkeXQAXzRQi+1dulpJG9RtQ= X-Google-Smtp-Source: AH8x2263QG/2TKJfDOVo+ydhGPAwrtDBSgCk35gYNhqWzxB3OH4DttzX8qqAOzGOUT04XPRzt8yg8PvO46V7FWcuZIE= X-Received: by 10.80.224.72 with SMTP id g8mr3300182edl.218.1519400101224; Fri, 23 Feb 2018 07:35:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.15 with HTTP; Fri, 23 Feb 2018 07:35:00 -0800 (PST) In-Reply-To: <003501d3ac8e$99fdd8c0$cdf98a40$@viettel.com.vn> References: <003501d3ac8e$99fdd8c0$cdf98a40$@viettel.com.vn> From: Victor Huertas Date: Fri, 23 Feb 2018 16:35:00 +0100 Message-ID: To: longtb5@viettel.com.vn Cc: konstantin.ananyev@intel.com, dev@dpdk.org, users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Suggestions on how to customize the metadata fields of each packet X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:35:01 -0000 Thanks a lot for your suggestions, Taking them into account and having a look a this example on userdata field usage (http://dpdk.org/doc/api/examples_2bbdev_app_2main_8c-example.html#a1= 9), I have though the following plan. I think that the most elegant way to do it is to use "userdata" for metadata, leaving the headroom as it is for further and future header manipulation or encapsulation. Therefore, allow me to expose it and tell me if it is a good practice or not: 1. I create two independent mempools: "packet_pool" with N mbufs of capacity to store all captured packets and a second pool called "metadata_pool" with the same N positions of sizeof(struct additional-metadata). 2. On thread#1, I setup an rx queue on the eth port0 assigning it the "packet_pool". 3. The thread#1 captures a burst of 32 packets and store them in a struct *rte_mbuf packets[32]. At the same time I pick up 32 objects from the "metadata_pool" and store them in struct *additional-metadata custom_metadata[32]. The content of every struct vector item should be empty, but just in case I initialize every struct field to the default values. 4. For every packet vector position (32 in total) I perform the following assignment: packest[i].userdata =3D custom_metadata[i]; 5. I modify one field of the metadata for each packet this way: packets[i].userdata->field1=3DX 6. I send through a software ring (which I previously created) all the 32 elements of "packets" vector. I do NOT implement any parallel softwar= e ring to put the custom_metadata 32 objects as I assume that such userdat= a assignment prevails through the previous software ring. 7. Thread#2 reads 32 packets from the mentioned software ring and prints the content of packets[i].userdata->field1 to check that the content of metadata is maintained through the software ring. 8. Thread#2 sends the 32 packets through a tx queue in port 1. 9. Thread#2 frees the 32 packets ret_mbufs structs AND also frees the content in packets[i].userdata. 10. Go to point 1 and repeat in a loop all the time. Is this a valid procedure or do you think that there could be a better one? Thanks for your attention Regards, 2018-02-23 11:07 GMT+01:00 : > Hi all, > > Victor, I suggest taking a closer look at section 7.1. here: > http://dpdk.org/doc/guides/prog_guide/mbuf_lib.html > > The approach chosen by DPDK is to store everything, metadata and packet > data, in contiguous memory. That way, network packets will always have 1 = to > 1 relationship with DPDK mbufs, no extra pointer needed. Every task that > you need to perform, from allocating, freeing, to transferring mbufs to > another lcore via software rings, are handled by DPDK. You don't have to > worry about them. You can save your metadata either directly in the > userdata field of struct rte_mbuf or in the headroom area. > > I agree with Konstantin that in theory we should think of the userdata > field as space exclusively for metadata and reserve the headroom area for > packet header manipulation purposes only. However in practice I tend to > think that using headroom for metadata is more useful since you don't > really need to worry about any special configuration when creating mbuf > pool. The headroom is gonna be there by default and you can always adjust > its size after initialization. Please let me know if I missed something. > > -BL > > > -----Original Message----- > > From: konstantin.ananyev@intel.com [mailto:konstantin.ananyev@intel.com= ] > > Sent: Friday, February 23, 2018 4:27 PM > > To: Victor Huertas ; longtb5@viettel.com.vn > > Cc: dev@dpdk.org; users@dpdk.org > > Subject: RE: [dpdk-dev] Suggestions on how to customize the metadata > fields > > of each packet > > > > Hi Victor, > > > > > > > > Thanks for your quick answer, > > > > > > I have read so many documents and web pages on this issue that > > > probably I confounded the utility of the headroom. It is good to know > > > that this 128 bytes space is available to my disposal. The fact of > > > being lost once the NIC transmits the frame it is not a problem at al= l > for my > > application. > > > However, in case that this space is not enough, I have seen in the > > > rte_mbuf struct a (void *) pointer called userdata which is in theory > > > used for extra user-defined metadata. If I wanted to attach an > > > additional metadata struct, I guess that I just have to assign the > > > pointer to this struct to the userdata field. However, what happens i= f > > > I want that the content of this struct travels with the packet throug= h > > > a software ring in order to be processed by another thread? Should I > > > reserve more space in the ring to allocate such extra metadata? > > > > > > Thanks again, > > > > > > In theory headroom inside mbuf should be left for packet's data. > > To do things properly you'll need to create your mbuf mempools with > > priv_size >=3D your_extra_metadata_size. > > > > Konstantin > > > > > > > > PD: I have copied the message to users mailing list > > > > > > 2018-02-23 4:13 GMT+01:00 : > > > > > > > Hi, > > > > > > > > First, I think your question should be sent to the user mailing > > > > list, not the dev mailing list. > > > > > > > > > I have seen that each packet has a headroom memory space (128 > > > > > bytes > > > > long) > > > > > > > > > where RSS hashing and other metadata provided by the NIC is store= d. > > > > > > > > If I=E2=80=99m not mistaken, the headroom is not where metadata pro= vided by > > > > the NIC are stored. Those metadata are stored in the rte_mbuf > > > > struct, which is also 128 bytes long. > > > > > > > > The headroom area is located AFTER the end of rte_mbuf (at offset > 128). > > > > By default the headroom area is also 128 byte long, so the actual > > > > packet data is stored at offset 256. > > > > > > > > You can store whatever you want in this headroom area. However thos= e > > > > information are lost as soon as the packet leaves DPDK (the NIC wil= l > > > > start sending at offset 256). > > > > > > > > -BL. > > > > > > > > > > > > > > > > -- > > > Victor > > --=20 Victor