We should simply deprecate that flag and put expectation on device driver including dpdk-input to always set total_length_not_including_first_buffer in case when buffers are chained (VLIB_BUFER_NEXT_VALID is set).
— Damjan > On 23 May 2018, at 17:13, Yoann Desmouceaux <ydesm...@cisco.com> wrote: > > Hello, > > I noticed that dpdk devices set the VLIB_BUFFER_TOTAL_LENGTH_VALID flag when > receiving packets, regardless of the value of > total_length_not_including_first_buffer. Since dpdk only copies one cacheline > from its vlib_buffer template into the buffer upon receipt of a packet, > b->total_length_not_including_first_buffer is left unitialized (because it's > in the second cacheline). > > In most cases, this doesn't cause issues — for non-chained buffers the > vlib_buffer_length_in_chain() function will still return the correct value > because it only looks at b->current_length. > > However, if the buffer is later vlib_buffer_clone()d, the stale > total_length_not_including_first_buffer value will propagate to the new head > of the chain, for which vlib_buffer_length_in_chain() will now return a wrong > value. This can be observed for instance when using BIER, with which > replicated packets will sometimes have oversized lengths. > > An obvious fix for that is to remove the VLIB_BUFFER_TOTAL_LENGTH_VALID flag > from the buffer_flags_template in dpdk_init(). I'm concerned about the > performance of this approach though, because vlib_buffer_length_in_chain() > will then have to go through the slow path for all chained packets, causing > branches. The other solution would be to, in addition, add something along > the lines of the following in dpdk_process_rx_burst(): > b[0]->flags |= (!b[0]->total_length_not_including_first_buffer) << > VLIB_BUFFER_LOG2_TOTAL_LENGTH_VALID; > so as to set the flag in correct packets as early as possible. > This would be branchless code, but would cost a few cycles for every packet > received by dpdk. Any thoughts? > > Also, does anyone know if this can happen with other devices than dpdk? > > Best, > Yoann >
