DPDK patches and discussions
 help / color / mirror / Atom feed
* Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
@ 2022-02-10 12:21 Ananyev, Konstantin
  2022-02-11  2:12 ` Huichao Cai
  2022-02-11  2:20 ` Huichao Cai
  0 siblings, 2 replies; 7+ messages in thread
From: Ananyev, Konstantin @ 2022-02-10 12:21 UTC (permalink / raw)
  To: chcchc88; +Cc: dev



> 
> 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>
> ---

....

> diff --git a/lib/ip_frag/rte_ipv4_fragmentation.c b/lib/ip_frag/rte_ipv4_fragmentation.c
> index 2e7739d..bcafa29 100644
> --- a/lib/ip_frag/rte_ipv4_fragmentation.c
> +++ b/lib/ip_frag/rte_ipv4_fragmentation.c
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: BSD-3-Clause
> +/* SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0)
>   * Copyright(c) 2010-2014 Intel Corporation
>   */
> 
> @@ -12,6 +12,13 @@
> 
>  #include "ip_frag_common.h"
> 
> +/* IP options */
> +#define RTE_IPOPT_COPY				0x80
> +#define RTE_IPOPT_CONTROL			0x00
> +#define RTE_IPOPT_END				(0 | RTE_IPOPT_CONTROL)
> +#define RTE_IPOPT_NOOP				(1 | RTE_IPOPT_CONTROL)
> +#define RTE_IPOPT_COPIED(o)			((o) & RTE_IPOPT_COPY)
> +
>  /* Fragment Offset */
>  #define	RTE_IPV4_HDR_DF_SHIFT			14
>  #define	RTE_IPV4_HDR_MF_SHIFT			13
> @@ -41,6 +48,38 @@ static inline void __free_fragments(struct rte_mbuf *mb[], uint32_t num)
>  		rte_pktmbuf_free(mb[i]);
>  }
> 
> +/*
> + *	Options "fragmenting", just fill options not
> + *	allowed in fragments with NOOPs.
> + *	Simple and stupid 8), but the most efficient way.
> + */
> +static inline void ip_options_fragment(struct rte_ipv4_hdr *iph)
> +{
> +	unsigned char *optptr = (unsigned char *)iph +
> +	    sizeof(struct rte_ipv4_hdr);

As a nit, why not 'uint8_t *', to keep style the same through all file? 

> +	int l = (iph->version_ihl & RTE_IPV4_HDR_IHL_MASK) *
> +	    RTE_IPV4_IHL_MULTIPLIER - sizeof(struct rte_ipv4_hdr);

We already done such calculation in rte_ipv4_fragment_packet(),
so can re-use header_len value here.

> +	int optlen;
> +
> +	while (l > 0) {
> +		switch (*optptr) {
> +		case RTE_IPOPT_END:
> +			return;
> +		case RTE_IPOPT_NOOP:
> +			l--;
> +			optptr++;
> +			continue;
> +		}
> +		optlen = optptr[1];
> +		if (optlen < 2 || optlen > l)

Why optlen==1 is not considered as valid one?

> +			return;
> +		if (!RTE_IPOPT_COPIED(*optptr))
> +			memset(optptr, RTE_IPOPT_NOOP, optlen);
> +		l -= optlen;
> +		optptr += optlen;
> +	}
> +}
> +
>  /**
>   * IPv4 fragmentation.
>   *
> @@ -188,6 +227,17 @@ static inline void __free_fragments(struct rte_mbuf *mb[], uint32_t num)
>  		    (uint16_t)out_pkt->pkt_len,
>  		    flag_offset, fragment_offset, more_in_segs);
> 
> +		/*
> +		 * ANK:

What means 'ANK' here? 

> dirty, but effective trick. Upgrade options only if
> +		 * the segment to be fragmented was THE FIRST (otherwise,
> +		 * options are already fixed) and make it ONCE
> +		 * on the initial mbuf, so that all the following fragments
> +		 * will inherit fixed options.
> +		 */
> +		if ((fragment_offset == 0) &&
> +			    ((flag_offset & RTE_IPV4_HDR_OFFSET_MASK) == 0))
> +			ip_options_fragment(in_hdr);
> +

I see two problems with that approach:
- you modify incoming packet's header - which is the change in behaviour,
  and doesn't look right at all.
- you remove not-copied options from all fragments.
  As I can read RFC 791 - first fragment should have a copy of all options present
  in original packet, while other fragments need to have only those that have to be
  copied.  

>  		fragment_offset = (uint16_t)(fragment_offset +
>  		    out_pkt->pkt_len - header_len);
> 
> --
> 1.8.3.1

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re:Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
  2022-02-10 12:21 [PATCH] ip_frag: add IPv4 options fragment and unit test data Ananyev, Konstantin
@ 2022-02-11  2:12 ` Huichao Cai
  2022-02-11  9:41   ` Ananyev, Konstantin
  2022-02-11  2:20 ` Huichao Cai
  1 sibling, 1 reply; 7+ messages in thread
From: Huichao Cai @ 2022-02-11  2:12 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: dev

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Hi,Konstantin


Thank you for your reply!


>As a nit, why not 'uint8_t *', to keep style the same through all file?
Yes,I can use 'uint8_t *.Thank you for your correction.


>We already done such calculation in rte_ipv4_fragment_packet(),
>so can re-use header_len value here.

Yes,I can re-use header_len.Thank you for your correction.


>Why optlen==1 is not considered as valid one?

RFC791:
        Case 2:  An option-type octet, an option-length octet, and the actual option-data octets.
        The option-length octet counts the option-type octet and the option-length octet as well as the option-data octets.

So for case 2, the value of optlen is at least 2.


>What means 'ANK' here?
Because this code comes from the Linux kernel and is licensed under the GPL, I kept the original comments, I looked up the Linux kernel code, and ‘ANK’ should be the name of a developer.


>I see two problems with that approach: >- you modify incoming packet's header - which is the change in behaviour,
> and doesn't look right at all.
Because the incoming packet is fragmented, the incoming packet IP header is no longer used, so this behavior does not cause problems.At the same time, in order to consider efficiency, modify the original IP header directly, rather than creating a separate IP header.Of course, if this method is not reasonable, I can create a separate IP header to modify.


>- you remove not-copied options from all fragments. > As I can read RFC 791 - first fragment should have a copy of all options present > in original packet, while other fragments need to have only those that have to be
> copied.
This function(ip_options_fragment) is called under that ‘__fill_ipv4hdr_frag’,so the first fragment have a copy of all options present in original packet.


Huichao Cai

[-- Attachment #2: Type: text/html, Size: 2480 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re:Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
  2022-02-10 12:21 [PATCH] ip_frag: add IPv4 options fragment and unit test data Ananyev, Konstantin
  2022-02-11  2:12 ` Huichao Cai
@ 2022-02-11  2:20 ` Huichao Cai
  2022-02-11 10:11   ` Ferruh Yigit
  1 sibling, 1 reply; 7+ messages in thread
From: Huichao Cai @ 2022-02-11  2:20 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: dev

[-- Attachment #1: Type: text/plain, Size: 103 bytes --]

A small problem.Why is the content of the email just sent to you not visible at Patchwork (this patch).

[-- Attachment #2: Type: text/html, Size: 348 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Re:Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
  2022-02-11  2:12 ` Huichao Cai
@ 2022-02-11  9:41   ` Ananyev, Konstantin
  2022-02-11 10:00     ` Huichao Cai
  0 siblings, 1 reply; 7+ messages in thread
From: Ananyev, Konstantin @ 2022-02-11  9:41 UTC (permalink / raw)
  To: Huichao Cai; +Cc: dev


Hi Huichao

>>As a nit, why not 'uint8_t *', to keep style the same through all file?
>Yes,I can use 'uint8_t *.Thank you for your correction.
>
>>We already done such calculation in rte_ipv4_fragment_packet(),
>>so can re-use header_len value here.
>Yes,I can re-use header_len.Thank you for your correction.
>
>>Why optlen==1 is not considered as valid one?
>RFC791:
>        Case 2:  An option-type octet, an option-length octet, and the actual option-data octets.
>       The option-length octet counts the option-type octet and the option-length octet as well as the option-data octets.
>So for case 2, the value of optlen is at least 2.

Ok, thanks for explanation.

>>What means 'ANK' here? 
>Because this code comes from the Linux kernel and is licensed under the GPL, I kept the original comments, I looked up the Linux kernel code, and ‘ANK’ should be the name of a >developer.

AFAIK, we can't copy-paste code from Linux kernel.
As you noted it is under GPL, while DPDK is under BSD-3 license. 

>>I see two problems with that approach:
>>- you modify incoming packet's header - which is the change in behaviour,
>>  and doesn't look right at all.
>Because the incoming packet is fragmented, the incoming packet IP header is no longer used, so this behavior does not cause problems.At the same time, in order to consider >efficiency, modify the original IP header directly, rather than creating a separate IP header.Of course, if this method is not reasonable, I can create a separate IP header to modify.

Library routine has no idea would original IP packet will be used later or not.
In your particular case it might be not needed, but there might be other usages,
that do use it (logging, send un-fragmented via other port, etc.).
So I think we have to preserve original behaviour.

>>- you remove not-copied options from all fragments.
>>  As I can read RFC 791 - first fragment should have a copy of all options present
>>  in original packet, while other fragments need to have only those that have to be
>>  copied.  
>This function(ip_options_fragment) is called under that ‘__fill_ipv4hdr_frag’,so the first fragment have a copy of all options present in original packet.

Right, I missed the fact that you do modify original packet after making a first copy.
 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re:RE: Re:Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
  2022-02-11  9:41   ` Ananyev, Konstantin
@ 2022-02-11 10:00     ` Huichao Cai
  0 siblings, 0 replies; 7+ messages in thread
From: Huichao Cai @ 2022-02-11 10:00 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: dev

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

>AFAIK, we can't copy-paste code from Linux kernel.

>As you noted it is under GPL, while DPDK is under BSD-3 license.
Well, I'll rewrite the code.


>Library routine has no idea would original IP packet will be used later or not.
>In your particular case it might be not needed, but there might be other usages,
>that do use it (logging, send un-fragmented via other port, etc.).
>So I think we have to preserve original behaviour.
Ok,I will preserve original.

[-- Attachment #2: Type: text/html, Size: 965 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
  2022-02-11  2:20 ` Huichao Cai
@ 2022-02-11 10:11   ` Ferruh Yigit
  0 siblings, 0 replies; 7+ messages in thread
From: Ferruh Yigit @ 2022-02-11 10:11 UTC (permalink / raw)
  To: Huichao Cai, Ananyev, Konstantin; +Cc: dev

On 2/11/2022 2:20 AM, Huichao Cai wrote:
> A small problem.Why is the content of the email just sent to you not visible at Patchwork (this patch).
> 
> 

Hi Huichao,

The discussion is not in the same email thread, it looks like it spread
into multiple threads.
This is because some email headers (References:, In-Reply-To:) are dropped
by some emails (email clients?) causing reply seen as a new thread.

Because of this missing email header, I think patchwork can't relate
discussion to original patch/thread.

for record patchwork:
https://patches.dpdk.org/project/dpdk/patch/1637743626-70632-1-git-send-email-chcchc88@163.com/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re:RE: Re:Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
  2021-12-02 12:03   ` Ananyev, Konstantin
@ 2021-12-02 12:11     ` Huichao Cai
  0 siblings, 0 replies; 7+ messages in thread
From: Huichao Cai @ 2021-12-02 12:11 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: Dariusz Sosnowski, dev

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

Perhaps performance is more important.This code comes from the linux kernel(5.10.9 and so on). :)
It is more performance-focused based on comments. :)




[-- Attachment #2: Type: text/html, Size: 715 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-02-11 10:11 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-10 12:21 [PATCH] ip_frag: add IPv4 options fragment and unit test data Ananyev, Konstantin
2022-02-11  2:12 ` Huichao Cai
2022-02-11  9:41   ` Ananyev, Konstantin
2022-02-11 10:00     ` Huichao Cai
2022-02-11  2:20 ` Huichao Cai
2022-02-11 10:11   ` Ferruh Yigit
  -- strict thread matches above, loose matches on Subject: below --
2021-12-02  9:35 Dariusz Sosnowski
2021-12-02 11:38 ` Huichao Cai
2021-12-02 12:03   ` Ananyev, Konstantin
2021-12-02 12:11     ` Huichao Cai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).