On Mon, May 20, 2024 at 2:56 AM laixiangwu <[email protected]> wrote: > > Description: > > when 1) The fragment timeout is between 15 seconds and 25 seconds; 2) The > ipf_list currently has received more than 32 fragments, and there are other > fragments of same big packet that have not been received. > > When the above two scenario conditions are met, due to exceeding the capacity > of the packet batch(here is 32), ipf_dp_packet_batch_add returns false, and > ipf_list will not be cleared. However, the 32 fragments packets added to the > packet batch will be processed normally. When receiving the subsequent > fragments of the ipf_list, because the first 32 fragments have been > processed, when processing subsequent fragment packets, relevant information > about the processed fragment packets will be read，therefore will occur carsh. > One solution is do not forward timeout fragment packets from the above > scenarios, that is, do not add them to the packet batch, and handle other > scenarios according to the original logic.
Hello laixaingwu, I happen to have a patch on the list right now for a similar sounding issue: https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ Do you happen to have a stack trace available for this crash? That could help determine if the crash is triggered at the same location. I'm not sure I like the approach of not adding any fragments to the batch during expiration, as this changes how packets are processed currently and may be an unexpected behaviour for end users. Would it be better to only add a few to the current batch and add the remaining to later batches? Thanks, M _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
