[PATCH v4] ip_frag: add IPv4 options fragment and test data
Ananyev, Konstantin
konstantin.ananyev at intel.com
Mon Mar 21 15:24:38 CET 2022
Hi Huichao,
> 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 at 163.com>
> ---
> app/test/test_ipfrag.c | 319 ++++++++++++++++++++++++++++++++---
> lib/ip_frag/rte_ip_frag.h | 6 +
> lib/ip_frag/rte_ipv4_fragmentation.c | 70 +++++++-
> 3 files changed, 372 insertions(+), 23 deletions(-)
>
> diff --git a/app/test/test_ipfrag.c b/app/test/test_ipfrag.c
> index 1ced25a..f6ff2d0 100644
> --- a/app/test/test_ipfrag.c
> +++ b/app/test/test_ipfrag.c
> @@ -18,10 +18,109 @@
> #define NUM_MBUFS 128
> #define BURST 32
>
> +#define IPV4_IPOPT_MANUAL
> +
> +#ifdef IPV4_IPOPT_MANUAL
Could you explain why do we need that define at all?
As I can read the code, right now IPV4_IPOPT_MANUAL is always defined,
so all '#else' blocks are simply dead code.
Is there any reason to keep it?
If so, then the code probably need to be re-ordered somehow,
to make '#else' part to be enabled and executed:
let say a separate test-case(s), and/or separate function or extra parameter
for test_get_ipv4_opt().
Konstantin
More information about the dev
mailing list