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 (Ref
>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
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
A small problem.Why is the content of the email just sent to you not visible at
Patchwork (this patch).
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 hea
>
> 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 s
Hi everyone,
This patch hasn't changed status for a long time, I want to know what the
current situation of this patch is?
Huichao Cai
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. :)
I didn't look at it in detail yet,
just wonder would be real gain in terms of space?
From: Huichao Cai
Sent: Thursday, December 2, 2021 11:39 AM
To: Dariusz Sosnowski
Cc: Ananyev, Konstantin ; dev@dpdk.org
Subject: Re:Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data
If op
If options with copied flag unset are not copied, then IPv4 headers in the
fragments (despite 1st fragment) will be shorter. This leaves more byte space
for the payload and in effect fragmentation might produce less fragments.
--Do I need to modify it this way?
Hi,
On Thu, 2 Dec 2021 10:24:40 +0800, Huichao Cai wrote:
> > Substituting options with NOOP might cause rte_ipv4_fragment_packet to
> > produce more fragments than necessary, since options with copied flag unset
> > will still occupy space in IPv4 header.
> --The "ip_options_fragment" just make
Hi Dariusz
Substituting options with NOOP might cause rte_ipv4_fragment_packet to produce
more fragments than necessary, since options with copied flag unset will still
occupy space in IPv4 header.
--The "ip_options_fragment" just make a replacement and doesn't change the
length of the IPv4
On Wed, 24 Nov 2021 16:47:06 +0800, Huichao Cai wrote:
> +/*
> + * 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)
> +{
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 fo
14 matches
Mail list logo
