[dpdk-dev] [Bug 835] Previous patch introduced bugs in rte_ipv4_fragment_packet functions

[bugzilla@dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=835

            Bug ID: 835
           Summary: Previous patch introduced bugs in
                    rte_ipv4_fragment_packet functions
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: critical
          Priority: High
         Component: other
          Assignee: dev@dpdk.org
          Reporter: chcchc88@163.com
                CC: konstantin.ananyev@intel.com
  Target Milestone: ---

Overview:
The patch 567473433b7e("ip_frag: fix fragmenting IPv4 fragment") introduces
a bug and needs to be rolled back. This is because the patch
and variables "flag_offset" conflict with each other.

>> diff --git a/lib/ip_frag/rte_ipv4_fragmentation.c
>> b/lib/ip_frag/rte_ipv4_fragmentation.c
>> index 2e7739d..fead5a9 100644
>> --- a/lib/ip_frag/rte_ipv4_fragmentation.c
>> +++ b/lib/ip_frag/rte_ipv4_fragmentation.c
>> @@ -75,7 +75,7 @@ static inline void __free_fragments(struct rte_mbuf *mb[],
>> uint32_t num)
>>      uint32_t out_pkt_pos, in_seg_data_pos;
>>      uint32_t more_in_segs;
>>      uint16_t fragment_offset, flag_offset, frag_size, header_len;
>> -    uint16_t frag_bytes_remaining;
>> +    uint16_t frag_bytes_remaining, not_last_frag;
>> 
>>      /*
>>       * Formal parameter checking.
>> @@ -116,7 +116,9 @@ static inline void __free_fragments(struct rte_mbuf
>> *mb[], uint32_t num)
>>      in_seg = pkt_in;
>>      in_seg_data_pos = header_len;
>>      out_pkt_pos = 0;
>> -    fragment_offset = 0;
>> +    fragment_offset = (uint16_t)((flag_offset &
>> +        RTE_IPV4_HDR_OFFSET_MASK) << RTE_IPV4_HDR_FO_SHIFT);
>> +    not_last_frag = (uint16_t)(flag_offset & IPV4_HDR_MF_MASK);
>> 
>>      more_in_segs = 1;
>>      while (likely(more_in_segs)) {
>> @@ -186,7 +188,8 @@ static inline void __free_fragments(struct rte_mbuf
>> *mb[], uint32_t num)
>> 
>>              __fill_ipv4hdr_frag(out_hdr, in_hdr, header_len,
>>                  (uint16_t)out_pkt->pkt_len,
>> -                flag_offset, fragment_offset, more_in_segs);
>> +                flag_offset, fragment_offset,
>> +                not_last_frag || more_in_segs);
>> 
>>              fragment_offset = (uint16_t)(fragment_offset +
>>                  out_pkt->pkt_len - header_len);

"flag_offset" or “fofs” contains all the information about fragment,so this
patch is no longer needed.

flag_offset = rte_cpu_to_be_16(in_hdr->fragment_offset);

static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst,
                const struct rte_ipv4_hdr *src, uint16_t header_len,
                uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)
{
        rte_memcpy(dst, src, header_len);
        fofs = (uint16_t)(fofs + (dofs >> RTE_IPV4_HDR_FO_SHIFT));
        fofs = (uint16_t)(fofs | mf << RTE_IPV4_HDR_MF_SHIFT);
        dst->fragment_offset = rte_cpu_to_be_16(fofs);
        dst->total_length = rte_cpu_to_be_16(len);
        dst->hdr_checksum = 0;
}

Steps to Reproduce:
1) Use a fragment that is not the last fragment to test
rte_ipv4_fragment_packet function:MTU is 68,ip pkt_size is 104(not include ip
header len), MF is 1,fragment_offset is 13.
2) Start the test to see the fragmenting results: the values of fragment number
and fragment_offset.

Actual Results:
fragment number: 3
fragment_offset: 0x201A 0x2020 0x2026

Expected Results:
fragment number: 3
fragment_offset: 0x200D 0x2013 0x2019

Build Date & Hardware:
Build 2021-10-25 on Linux OS 3.10.0

-- 
You are receiving this mail because:
You are the assignee for the bug.