Thanks, Darrell I can try to test it
Other question, it seems that ipf is driven by input packet, no timer, if a packet has 40 fragment, first time, 32 fragments are received, next time, 8 fragment are received, reassemble is success, and send out 32 fragment. After that, if no new packets are received, the remaining 8 fragment will in complete list, and can not send out until expired to clean them, is it true? -RongQing 发件人: Darrell Ball [mailto:[email protected]] 发送时间: 2019年11月19日 10:22 收件人: Li,Rongqing <[email protected]> 抄送: ovs dev <[email protected]> 主题: Re: ipf question Thanks; I had a look and I noticed ipf does not keep all the context it needs to properly resume fragment processing in the general case; I have a potential fix, but won't get to it this week. On Sun, Nov 17, 2019 at 11:08 PM Darrell Ball <[email protected]<mailto:[email protected]>> wrote: On Fri, Nov 15, 2019 at 6:03 PM Li,Rongqing <[email protected]<mailto:[email protected]>> wrote: 发件人: Darrell Ball <[email protected]<mailto:[email protected]>> 发送时间: 2019年11月15日 22:58 收件人: Li,Rongqing 抄送: ovs dev 主题: Re: ipf question >Let me paraphrase, just to confirm we are on the same page. >IIUC, for example, in the case of a 33 fragment packet, in the first pass all >33 fragments enter ipf, then are >reassembled, pass thru conntrack >and then the frags sent out, while in the second pass, only 32 fragments enter >conntrack/ipf, while index 32 >fragment is being forwarded out without going >thru conntrack/ipf ? true. the second pass is recirculation and index 32 fragment is not into contrack/ipf, and send out to vm directly. can you check what rule is being hit by that fragment packet vs others and then compare the pkt metadata if I change NETDEV_MAX_BURST to 64, it works good test thanks -RongQing _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
