#
4aee6110 |
| 08-Aug-2022 |
Huichao Cai <chcchc88@163.com> |
ip_frag: add IPv4 fragment copy
Some NIC drivers support MBUF_FAST_FREE (device supports optimization for fast release of mbufs. When set, application must guarantee that per-queue all mbufs comes f
ip_frag: add IPv4 fragment copy
Some NIC drivers support MBUF_FAST_FREE (device supports optimization for fast release of mbufs. When set, application must guarantee that per-queue all mbufs comes from the same mempool, has refcnt = 1, direct and non-segmented.) offload. In order to adapt to this offload function, add this API. Add some test data for this API.
Signed-off-by: Huichao Cai <chcchc88@163.com> Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
show more ...
|
#
e1522b32 |
| 18-Jun-2022 |
Huichao Cai <chcchc88@163.com> |
ip_frag: fix build with GCC 12
GCC 12 raises warnings on usage of rte_memcpy with IPv4 options handling in fragments for both the ip_frag library and unit tests.
For example in the library: In func
ip_frag: fix build with GCC 12
GCC 12 raises warnings on usage of rte_memcpy with IPv4 options handling in fragments for both the ip_frag library and unit tests.
For example in the library: In function ‘_mm256_storeu_si256’, inlined from ‘rte_mov32’ at ../lib/eal/x86/include/rte_memcpy.h:347:2, inlined from ‘rte_mov128’ at ../lib/eal/x86/include/rte_memcpy.h:369:2, inlined from ‘rte_memcpy_generic’ at ../lib/eal/x86/include/rte_memcpy.h:445:4, inlined from ‘rte_memcpy’ at ../lib/eal/x86/include/rte_memcpy.h:851:10, inlined from ‘__create_ipopt_frag_hdr’ at ../lib/ip_frag/rte_ipv4_fragmentation.c:68:4, inlined from ‘rte_ipv4_fragment_packet’ at ../lib/ip_frag/rte_ipv4_fragmentation.c:242:16: /usr/lib/gcc/x86_64-redhat-linux/12/include/avxintrin.h:935:8: error: array subscript ‘__m256i_u[1]’ is partly outside array bounds of ‘uint8_t[60]’ {aka ‘unsigned char[60]’} [-Werror=array-bounds] 935 | *__P = __A; | ~~~~~^~~~~ ../lib/ip_frag/rte_ipv4_fragmentation.c: In function ‘rte_ipv4_fragment_packet’: ../lib/ip_frag/rte_ipv4_fragmentation.c:122:17: note: at offset [52, 60] into object ‘ipopt_frag_hdr’ of size 60 122 | uint8_t ipopt_frag_hdr[IPV4_HDR_MAX_LEN]; | ^~~~~~~~~~~~~~
To resolve the compilation warning, replace the rte_memcpy with memcpy.
Fixes: b50a14a853aa ("ip_frag: add IPv4 options fragment")
Signed-off-by: Huichao Cai <chcchc88@163.com>
show more ...
|
#
b50a14a8 |
| 15-Apr-2022 |
Huichao Cai <chcchc88@163.com> |
ip_frag: add IPv4 options fragment
According to RFC791,the options may appear or not in datagrams. They must be implemented by all IP modules (host and gateways). What is optional is their transmiss
ip_frag: add IPv4 options fragment
According to RFC791,the options may appear or not in datagrams. They must be implemented by all IP modules (host and gateways). What is optional is their transmission in any particular datagram, not their implementation. So we have to deal with it during the fragmenting process. Add some test data for the IPv4 header optional field fragmenting.
Signed-off-by: Huichao Cai <chcchc88@163.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
show more ...
|
#
30a1de10 |
| 15-Feb-2022 |
Sean Morrissey <sean.morrissey@intel.com> |
lib: remove unneeded header includes
These header includes have been flagged by the iwyu_tool and removed.
Signed-off-by: Sean Morrissey <sean.morrissey@intel.com>
|
#
013bb504 |
| 25-Oct-2021 |
Huichao Cai <chcchc88@163.com> |
ip_frag: revert fix fragmenting IPv4 fragment
The patch ("ip_frag: fix fragmenting IPv4 fragment") introduces a bug and needs to be rolled back. This is because the patch and variables "flag_offset"
ip_frag: revert fix fragmenting IPv4 fragment
The patch ("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.
Bugzilla ID: 835 Fixes: 567473433b7e ("ip_frag: fix fragmenting IPv4 fragment") Cc: stable@dpdk.org
Signed-off-by: Huichao Cai <chcchc88@163.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
show more ...
|
#
56747343 |
| 09-Oct-2021 |
Huichao Cai <chcchc88@163.com> |
ip_frag: fix fragmenting IPv4 fragment
Current implementation of rte_ipv4_fragment_packet() doesn’t take into account offset and flag values of the given packet, but blindly assumes they are always
ip_frag: fix fragmenting IPv4 fragment
Current implementation of rte_ipv4_fragment_packet() doesn’t take into account offset and flag values of the given packet, but blindly assumes they are always zero (original packet is not fragmented). According to RFC791, fragment and flag values for new fragment should take into account values provided in the original IPv4 packet.
Fixes: 4c38e5532a07 ("ip_frag: refactor IPv4 fragmentation into a proper library") Cc: stable@dpdk.org
Signed-off-by: Huichao Cai <chcchc88@163.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
show more ...
|
#
1edf7a79 |
| 25-Mar-2021 |
Pu Xu <583493798@qq.com> |
ip_frag: fix fragmenting IPv4 packet with header option
When fragmenting IPv4 packet, the data offset should be calculated through the IHL field in IP header rather than using sizeof(struct rte_ipv4
ip_frag: fix fragmenting IPv4 packet with header option
When fragmenting IPv4 packet, the data offset should be calculated through the IHL field in IP header rather than using sizeof(struct rte_ipv4_hdr).
Fixes: 4c38e5532a07 ("ip_frag: refactor IPv4 fragmentation into a proper library") Cc: stable@dpdk.org
Signed-off-by: Pu Xu <583493798@qq.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
show more ...
|
#
99a2dd95 |
| 20-Apr-2021 |
Bruce Richardson <bruce.richardson@intel.com> |
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also m
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also makes it awkward to add features referring to individual libraries in the build - should the lib names be specified with or without the prefix. Therefore, we can just remove the library prefix and use the library's unique name as the directory name, i.e. 'eal' rather than 'librte_eal'
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
show more ...
|