On Thu, Jul 02, 2020 at 05:36:38PM +0800, wenxu wrote: > > On 7/2/2020 1:33 AM, Cong Wang wrote: > > On Wed, Jul 1, 2020 at 1:21 AM wenxu <we...@ucloud.cn> wrote: > >> > >> On 7/1/2020 2:21 PM, wenxu wrote: > >>> On 7/1/2020 2:12 PM, Cong Wang wrote: > >>>> On Tue, Jun 30, 2020 at 11:03 PM wenxu <we...@ucloud.cn> wrote: > >>>>> Only forward packet case need do fragment again and there is no need do > >>>>> defrag explicit. > >>>> Same question: why act_mirred? You have to explain why act_mirred > >>>> has the responsibility to do this job. > >>> The fragment behavior only depends on the mtu of the device sent in > >>> act_mirred. Only in > >>> > >>> the act_mirred can decides whether do the fragment or not. > >> Hi cong, > >> > >> > >> I still think this should be resolved in the act_mirred. Maybe it is not > >> matter with a "responsibility" > >> > >> Did you have some other suggestion to solve this problem? > > Like I said, why not introduce a new action to handle fragment/defragment? > > > > With that, you can still pipe it to act_ct and act_mirred to achieve > > the same goal. > > Thanks. Consider about the act_fagment, There are two problem for this. > > > The frag action will put the ressemble skb to more than one packets. How > these packets > > go through the following tc filter or chain?
One idea is to listificate it, but I don't see how it can work. For example, it can be quite an issue when jumping chains, as the match would have to work on the list as well. > > > When should use the act_fragament the action, always before the act_mirred? Which can be messy if you consider chains like: "mirred, push vlan, mirred" or so. "frag, mirred, defrag, push vlan, frag, mirred".
