[ovs-dev] [PATCH v8 05/13] dp-packet: Fix data_len handling multi-seg mbufs.
Eelco Chaudron
echaudro at redhat.com
Tue Jun 26 09:24:27 UTC 2018
On 22 Jun 2018, at 21:04, Lam, Tiago wrote:
> On 18/06/2018 12:39, Eelco Chaudron wrote:
>>
>>
>> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>>
>>> When a dp_packet is from a DPDK source, and it contains multi-segment
>>> mbufs, the data_len is not equal to the packet size, pkt_len. Instead,
>>> the data_len of each mbuf in the chain should be considered while
>>> distributing the new (provided) size.
>>>
>>> To account for the above dp_packet_set_size() has been changed so
>>> that,
>>> in the multi-segment mbufs case, only the data_len on the last mbuf of
>>> the chain and the total size of the packet, pkt_len, are changed. The
>>> data_len on the intermediate mbufs preceeding the last mbuf is not
>>> changed by dp_packet_set_size(). Furthermore, in some cases
>>> dp_packet_set_size() may be used to set a smaller size than the
>>> current
>>> packet size, thus effectively trimming the end of the packet. In the
>>> multi-segment mbufs case this may lead to lingering mbufs that may
>>> need
>>> freeing.
>>>
>>> __dp_packet_set_data() now also updates an mbufs' data_len after
>>> setting
>>> the data offset. This is so that both fields are always in sync for
>>> each
>>> mbuf in a chain.
>>>
>>> Co-authored-by: Michael Qiu <qiudayu at chinac.com>
>>> Co-authored-by: Mark Kavanagh <mark.b.kavanagh at intel.com>
>>> Co-authored-by: Przemyslaw Lal <przemyslawx.lal at intel.com>
>>> Co-authored-by: Marcin Ksiadz <mksiadz at gmail.com>
>>> Co-authored-by: Yuanhan Liu <yliu at fridaylinux.org>
>>>
>>> Signed-off-by: Michael Qiu <qiudayu at chinac.com>
>>> Signed-off-by: Mark Kavanagh <mark.b.kavanagh at intel.com>
>>> Signed-off-by: Przemyslaw Lal <przemyslawx.lal at intel.com>
>>> Signed-off-by: Marcin Ksiadz <mksiadz at gmail.com>
>>> Signed-off-by: Yuanhan Liu <yliu at fridaylinux.org>
>>> Signed-off-by: Tiago Lam <tiago.lam at intel.com>
>>> ---
>>> lib/dp-packet.h | 56
>>> +++++++++++++++++++++++++++++++++++++++++++++-----------
>>> 1 file changed, 45 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/lib/dp-packet.h b/lib/dp-packet.h
>>> index 4c104b6..c301ed5 100644
>>> --- a/lib/dp-packet.h
>>> +++ b/lib/dp-packet.h
>>> @@ -429,17 +429,39 @@ dp_packet_size(const struct dp_packet *b)
>>> static inline void
>>> dp_packet_set_size(struct dp_packet *b, uint32_t v)
>>> {
>>> - /* netdev-dpdk does not currently support segmentation;
>>> consequently, for
>>> - * all intents and purposes, 'data_len' (16 bit) and 'pkt_len'
>>> (32 bit) may
>>> - * be used interchangably.
>>> - *
>>> - * On the datapath, it is expected that the size of packets
>>> - * (and thus 'v') will always be <= UINT16_MAX; this means that
>>> there is no
>>> - * loss of accuracy in assigning 'v' to 'data_len'.
>>> - */
>>> - b->mbuf.data_len = (uint16_t)v; /* Current seg length. */
>>> - b->mbuf.pkt_len = v; /* Total length of all segments
>>> linked to
>>> - * this segment. */
>>> + if (b->source == DPBUF_DPDK) {
>>
>> This function does not have any check to guarantee that the size set is
>> valid? i.e. is this not a trim only function? If we increase the size,
>> no additional mbufs get allocated (see below)
>
> Indeed, it should be used as a trim function. If the size is increased
> then the expectation is that enough space has been allocated. This is
> the current behavior when using `DPBUF_MALLOC` dp_packets as well, and
> is kept here for `DPBUF_DPDK` dp_packets.
I think a check is still needed as it’s not only used as a trim function.
For example: dp_packet_put_uninit()
>>
>>> + struct rte_mbuf *seg = &b->mbuf;
>>> + struct rte_mbuf *fmbuf = seg;
>>> + uint16_t pkt_len = v;
>>> + uint16_t seg_len;
>>> + uint16_t nb_segs = 0;
>>> +
>>> + /* Trim 'v' length bytes from the end of the chained buffers,
>>> freeing
>>> + any buffers that may be left floating */
>>> + while (seg) {
>>> + seg_len = MIN(pkt_len, seg->data_len);
>>> + seg->data_len = seg_len;
>>> +
>>> + pkt_len -= seg_len;
>>> + if (pkt_len <= 0) {
>>> + /* Free the rest of chained mbufs */
>>> + free_dpdk_buf((struct dp_packet *) seg->next);
>>> + seg->next = NULL;
>>> + } else if (!seg->next) {
>>> + seg->data_len = pkt_len;
>> Here we could potentially set the size of the segment larger than the
>> allocated/available buffer.
>>
>> Also if this is fine, we set it to the wrong value... Assume we have a
>> single buffer of 100 bytes and we call with v=400. This will result in
>> data_len being 300, and not 400, should probably be =pkt_len + seg_len
>>
>
> Thanks for pointing that out. I've overlooked this, which together with
> the leftover in patch 07/13 made it work correctly.
More information about the dev
mailing list