From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id D1E702C16; Fri, 23 Feb 2018 09:12:12 +0100 (CET) Received: by mail-wm0-f50.google.com with SMTP id q83so2993465wme.5; Fri, 23 Feb 2018 00:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=C78q7jpFpdphOvIj4ne/ONSdq6rFc9CeM/XYsxaVf7A=; b=s89tq5Bzcb6HLNDlNHMkNjvyeoKriJbx8sLZ2QOQgp2apzP2B+H4y8Mwp4PEHQ4Dff 4TcVl2Gbdl2JgoKGvWW66vUfqODfzbRwg2tp+DNi4S9e8NoeSfHtx1e/hKXmazPubV4h kQXNt/RD4WBpNl8Rhugxj74rSO0PnE+dEatrKE5n1zKNiMxptYOVWQkArrBwqCM1Gwsu nW1IvlyN75TsAD4cYJghW4rcqQZFCoHHAxg9pxFxW9+WPnI5tY2Z9BHrB4BPLKkDKwbc 93jelw6x8G8oWZBBvnfe547DhFaVNisPjme27iYEqeKvEaxwWKC1NWq2Ryg56vhayqeI 2N7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=C78q7jpFpdphOvIj4ne/ONSdq6rFc9CeM/XYsxaVf7A=; b=Kx2Amt80e57NgNEoioczfrSFRrByIVH///ZvyIkujlSPz5R43yVxaDVSSmznEYNPhT PhPfbb7NAXiYIieK+GEt68DDLHC47Wj9qGKp5D4O6L6OVdpjF4PoxWsae9N27IyUIfzE k5N7JMmoKyBKWHwUg/E82rlyU1U/CyUk6pOFO0QYcgJwKCWsV9ugNtP45UQ64E4CXWJN QVHq+FEO8wu7QuuA6+yLLeAVu73HLuYNh5BFiWuEALhbCnA+F2XYDOVQ2kwlqQsQrDZr Opd45ufKauLONaxOGIgSAf7Tj/5BV8XioQYpWluvhGCoyuxGgu6a7zKBZ27q1u8JD2KR Ws9g== X-Gm-Message-State: APf1xPAsNOFMnvWJVkYRTUdhb9DQYZbBJzKOQWBseuD+zf8kh16F6HzF uSY5IzEryM3a/MehD3LP4yWOKuzBATHJ81lKGsY= X-Google-Smtp-Source: AH8x227l6u6ScFUys4Q0z6b4CwvPzwbZSxLIB3qe3W2PCtGiIdi38wHkjEPfWd/48qiQhVBH50u4yuSzdpPnp9XZsGQ= X-Received: by 10.80.203.134 with SMTP id k6mr1700670edi.166.1519373532433; Fri, 23 Feb 2018 00:12:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.185.37 with HTTP; Fri, 23 Feb 2018 00:12:11 -0800 (PST) From: Victor Huertas Date: Fri, 23 Feb 2018 09:12:11 +0100 Message-ID: To: longtb5@viettel.com.vn Cc: 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 08:12:13 -0000 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 all 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 if I want that the content of this struct travels with the packet through 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, 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 stored. > > If I=E2=80=99m not mistaken, the headroom is not where metadata provided = 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 those > information are lost as soon as the packet leaves DPDK (the NIC will star= t > sending at offset 256). > > -BL. > --=20 Victor