History log of /dpdk/lib/ip_frag/rte_ipv4_fragmentation.c (Results 1 – 8 of 8)
Revision Date Author Comments
# 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 ...