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