> > Current implementation of rte_ipv4_fragment_packet() doesn’t take
> > into account offset and flag values of the given packet, but blindly
> > assumes they are always zero (original packet is not fragmented).
> > According to RFC791, fragment and flag values for new fragment
> > should take int
Hi,Konstantin
Meanwhile, as I said before, it would be really good to add a new
test-case to cover that case. It could be a new separate patch on top
of current one.
--Ok,I will.
Kevin
Hi Kevin,
AFAIK, no other action from your side is needed at the moment.
Now it is up to other reviewers (if any) to have a look,
and then DPDK maintainers to bring your patch in.
If they will have more comments/questions about the patch -
they will email you.
Meanwhile, as I said before, it would
Hi,Konstantin
I'm glad to receive your ack！
Follow the documentation 《Contributing Code to DPDK》：
1.Update Patchwork to mark your previous patches as “Superseded”.
--Who is responsible for this update, I just tried, prompt no permission update(
You don't have permissions to edit patch 'ip_frag:
>
> Current implementation of rte_ipv4_fragment_packet() doesn’t take
> into account offset and flag values of the given packet, but blindly
> assumes they are always zero (original packet is not fragmented).
> According to RFC791, fragment and flag values for new fragment
> should take into acco
Current implementation of rte_ipv4_fragment_packet() doesn’t take
into account offset and flag values of the given packet, but blindly
assumes they are always zero (original packet is not fragmented).
According to RFC791, fragment and flag values for new fragment
should take into account values pro
6 matches
Mail list logo
