[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