Ah indeed, I missed that, sorry! Thanks! :-)

--a

> On 18 Jul 2021, at 16:59, Damjan Marion <[email protected]> wrote:
> 
> 
> 
> That was already suggested to Jerome, see his first email in this thread.
> 
> — 
> Damjan
> 
> 
>>> On 18.07.2021., at 16:05, Andrew Yourtchenko <[email protected]> wrote:
>>> 
>> Naive question: if someone needs a lot of space to prepend in front of the 
>> buffer, would it make sense to allocate an entire new buffer and place it as 
>> the very first one in the chain ? That would save a recompile and also me 
>> more generic and extensible (you can get 2,3,4,… buffers in the same fashion 
>> then?) I don’t know if we have the easy facility to do this in VPP, though.
>> 
>> This would avoid a recompile and would work on the wider range of setups, if 
>> it were possible…
>> 
>> --a
>> 
>>>> On 17 Jul 2021, at 16:58, [email protected] wrote:
>>>> 
>>> 
>>> Hello Benoit,
>>> 
>>> Thank you for your answer about buffer allocation in batches, my solution 
>>> is way more efficient now.
>>> 
>>> However, I still want to try to change the value of the "PRE_DATA_SIZE" 
>>> cmake variable to see how it behaves with a greater value (i.e 256 instead 
>>> of 128). To do so, I followed the method given in the documentation at the 
>>> following url : 
>>> https://fd.io/docs/vpp/master/gettingstarted/developers/buildsystem/cmakeandninja.html#tinkering-with-build-options-ccmake.
>>> The issue is that once I've changed the value of the "PRE_DATA_SIZE" 
>>> variable, I press "c" to regenerate files that need to be regenerated and 
>>> then I get this error in cmake output :
>>> 
>>> CMake Error at cmake/misc.cmake:27 (_message):
>>>    [1;31mDPDK RTE_PKTMBUF_HEADROOM (128) ;must be equal to PRE_DATA_SIZE
>>>    (256)[m
>>>  Call Stack (most recent call first):
>>>    plugins/dpdk/CMakeLists.txt:65 (message)
>>> 
>>> I guess I should also modify the value of "DPDK RTE_PKTMBUF_HEADROOM" but I 
>>> don't know how I can do it ? Indeed, I can't find where this variable is 
>>> defined.
>>> 
>>> Jérôme
>>> 
>>> De: "Benoit Ganne (bganne)" <[email protected]>
>>> À: "jerome bayaux" <[email protected]>, [email protected]
>>> Cc: "Justin Iurman" <[email protected]>
>>> Envoyé: Jeudi 15 Juillet 2021 19:16:32
>>> Objet: RE: Buffer chains and pre-data area
>>> 
>>> Hi Jerome,
>>> 
>>> > However, when I tried to perform some performance tests I was quite
>>> > disappointed by the results : the buffer allocation for each packet is not
>>> > efficient at all. My question is then : Is there any way to increase the
>>> > performances ? To allocate buffers, I use the function "vlib_buffer_alloc"
>>> > defined in "buffer_funcs.h" but is it the right function to use ?
>>> 
>>> Do you allocate buffers in batch? Let's say you want to encapsulate a batch 
>>> of packets, instead of doing:
>>> 
>>>   while (n_left)
>>>     u32 bi
>>>     vlib_buffer_t *b
>>>     vlib_buffer_alloc(vm, &bi, 1)
>>>     b = vlib_get_buffer (vm, bi)
>>>     add b to the chain
>>>     ...
>>> 
>>> You should do something like (allocation error checking etc. is left as an 
>>> exercise):
>>> 
>>>   u32 bi[VLIB_FRAME_SIZE]
>>>   vlib_buffer_t *bufs[VLIB_FRAME_SIZE]
>>>   vlib_buffer_alloc (vm, bi, n_left)
>>>   vlib_get_buffers (vm, bi, bufs, n_left)
>>> 
>>>   while (n_left)
>>>     add bufs[i] to the chain
>>>     ...
>>> 
>>> > In my case, the best option would be to have more space available in the
>>> > buffer's pre-data area but VPP does not seem to be built in a way that
>>> > allows easy modifications of the "PRE_DATA_SIZE" value. Am I right or is
>>> > there any "clean" method to change this value ?
>>> 
>>> It is define as a cmake variable and can be customize through eg. cmake-gui.
>>> 
>>> ben
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19825): https://lists.fd.io/g/vpp-dev/message/19825
Mute This Topic: https://lists.fd.io/mt/84230132/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to