[dpdk-users] locating the address of rte_mbuf payload

Sungho Hong shong59 at asu.edu
Sat Jul 14 22:09:46 CEST 2018


Thank you very much Rosen
Your reply gave me good ideas of how to solve the problem.
I've found out the solution by comparing the message size(that I am
sending)  with the actual data_length of the rte_mbuf. That way I was able
to allocate the location of my data.



Best
Sungho Hong

On Sat, Jul 14, 2018 at 9:24 AM, Rosen, Rami <rami.rosen at intel.com> wrote:

> Hi Sungho,
>
> I would suggest two or three things which may shed more light on your
> issue:
>
> 1) How to you print the rte_mbuf packets ? is it with rte_pktmbuf_dump()?
> In case it is, please post here also the rte_mbuf metadata that you get
> when calling rte_pktmbuf_dump() (for example, pkt_len, nb_segs, etc). You
> get this metadata as part of a regular rte_pktmbuf_dump() call. If you
> don’t use rte_pktmbuf_dump(), you can look in the following link for an
> example:
> http://git.dpdk.org/dpdk/tree/test/test/test_mbuf.c
>
> Regarding the eth header: you do print
> its length but not its DA/SA. can you also print the src address and the
> dest address and see if it makes sense ?
> You can use
> print_ethaddr() for this; for example, see: http://git.dpdk.org/dpdk/tree/
> examples/l3fwd/main.c
>
> Third thing is: if you will post here the snippet of code in which you
> craft the rte_mbuf it may clarify things. (if you do, please also let us
> know the size of PKT_SIZE that you use in your "message" struct.)
>
> Regards,
> Rami Rosen
>
>
> -----Original Message-----
> From: users [mailto:users-bounces at dpdk.org] On Behalf Of Sungho Hong
> Sent: Saturday, July 14, 2018 08:46
> To: users at dpdk.org
> Subject: [dpdk-users] locating the address of rte_mbuf payload
>
> Hello I have sent the packet with the data "hellohellohello*"
> in a message struct using DPDK
>
>     struct message{
>     data[PKT_SIZE]
>     }
>
> I am sending this data from a client to server, and the server receives
> this data. the data received in the server can be viewed from the packet
> dump provided by DPDK. You can see the data I am sending "hello"s right at
> the bottom of the log
>
>     00000000: A0 36 9F 83 AB BC 00 1B 21 A6 D4 D4 08 00 45 00 |
> .6......!.....E.
>     00000010: 01 49 7C 60 00 00 80 11 C9 37 0A DA 6E 59 0A DA |
> .I|`.....7..nY..
>     00000020: 6F FF 44 5C 44 5C 01 35 DF 27 7B 22 6E 61 6D 65 |
> o.D\D\.5.'{"name
>     00000030: 73 70 61 63 65 73 22 3A 20 5B 31 33 37 30 34 36 | spaces":
> [137046
>     00000040: 36 31 39 33 2C 20 32 39 33 31 32 37 36 38 39 36 | 6193,
> 2931276896
>     00000050: 2C 20 31 33 32 34 30 31 33 30 39 31 2C 20 31 33 | ,
> 1324013091, 13
>     00000060: 35 32 37 38 34 34 35 32 2C 20 31 34 33 33 32 37 | 52784452,
> 143327
>     00000070: 32 31 36 36 2C 20 32 32 30 31 36 38 30 30 31 36 | 2166,
> 2201680016
>     00000080: 2C 20 31 33 35 39 38 30 30 32 37 30 2C 20 31 34 | ,
> 1359800270, 14
>     00000090: 37 31 30 37 33 36 34 39 2C 20 31 39 37 34 38 36 | 71073649,
> 197486
>     000000A0: 31 33 39 32 2C 20 32 32 33 38 33 34 32 39 32 38 | 1392,
> 2238342928
>     000000B0: 2C 20 31 33 37 32 38 31 35 32 32 31 2C 20 33 30 | ,
> 1372815221, 30
>     000000C0: 37 33 32 34 31 37 36 30 2C 20 37 36 32 35 31 36 | 73241760,
> 762516
>     000000D0: 39 35 35 2C 20 31 32 39 34 33 35 36 37 36 34 2C | 955,
> 1294356764,
>     000000E0: 20 31 35 32 30 34 39 31 39 39 35 5D 2C 20 22 64 |
> 1520491995], "d
>     000000F0: 69 73 70 6C 61 79 6E 61 6D 65 22 3A 20 22 22 2C |
> isplayname": "",
>     00000100: 20 22 76 65 72 73 69 6F 6E 22 3A 20 5B 32 2C 20 |  "version":
> [2,
>     00000110: 30 5D 2C 20 22 68 6F 73 74 5F 69 6E 74 22 3A 20 | 0],
> "host_int":
>     00000120: 32 30 39 37 36 33 35 34 38 32 33 39 38 34 38 32 |
> 2097635482398482
>     00000130: 38 34 35 36 30 36 31 34 37 35 30 34 32 32 37 38 |
> 8456061475042278
>     00000140: 33 35 34 37 35 37 32 2C 20 22 70 6F 72 74 22 3A | 3547572,
> "port":
>     00000150: 20 31 37 35 30 30 7D 68 65 6C 6C 6F 68 65 6C 6C |
> 17500}hellohell
>     00000160: 6F 68 65 6C 6C 6F 68 65 6C 6C 6F 68 65 6C 6C 6F |
> ohellohellohello
>     00000170: 68 65 6C 6C 6F 68 65 6C 6C 6F 68 65 6C 6C 6F 00 |
> hellohellohello.
>
>
> The problem is I cannot locate the data offset by reading the rte_mbuf
> provided by dpdk. I need to extract the "hello"s using the correct method
> that is provided by DPDK, but I could not find a good way.
>
> I have tried the size headers and the buf_address pointers to locate the
> location of the struct message, but I have no idea how to pin point the
> exact address of the data-offset using DPDK structures.
>
>
> char *rtn = NULL;
> rtn = rte_pktmbuf_mtod(m, char *); // points to the start of the data
>
> struct ether_hdr *eth;
> eth = rte_pktmbuf_mtod(m, struct ether_hdr *); // rtn+=sizeof(eth);
>
> rtn = m->buf_addr;
>
>
> if(rtn!=NULL) {
> printf("length hdr: %ld\n", sizeof(struct ether_hdr)); printf("length eth:
> %ld\n", sizeof(eth)); printf("length m->buf_add: %ld\n",
> sizeof(m->buf_addr));
>
> printf("length message: %ld\n", sizeof(struct message));
>
> // 336
> printf("rte_pktmbuf_mtod: %s\n", rtn);  // lenght of the offset: 456
> rte_pktmbuf_dump(stdout, m, 1024); }
>
>
> Would anyone familiar with DPDK, have a good answer for this?
>
>
> Best
>


More information about the users mailing list