Interpret b->current_data, b->current_length, the buffer freelist index, and the related vlib_buffer_free_list_t structure.
In most cases, b->packet_data is actually VLIB_BUFFER_DATA_SIZE (2048) bytes long. Look at the related vlib_buffer_free_list_t to know for sure. Current_data is a SIGNED offset into b->packet_data[0]. It can be negative by as much as VLIB_BUFFER_PRE_DATA_SIZE. Typically, device drivers write the first octet of packet data into b->packet_data[0], but devices / device driver writers may place data at arbitrary [positive] offsets into b->packet_data. HTH... Dave -----Original Message----- From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) Sent: Thursday, December 7, 2017 8:06 AM To: vpp-dev@lists.fd.io Subject: [vpp-dev] how to find vlib_buffer_t.data size(capacity) @ runtime? Hi, I discovered that the packet generator does not always respect the default vlib_buffer_t.data size as defined in buffer.h: #define VLIB_BUFFER_DATA_SIZE (2048) It derives the required buffer size from the individual packet sizes from the pcap file - at least that's what happens in 'make test'. In my case it's 256 bytes. My question is - what is the easiest way to determine the actual allocated vlib_buffer_t.data space at runtime? I want to be able to append some data to a buffer but first I would like to make sure that it fits... Thanks, Klement _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev