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