On 11/17/2020 3:01 AM, Cong Wang wrote: > On Sun, Nov 15, 2020 at 5:06 AM wenxu <we...@ucloud.cn> wrote: >> >> 在 2020/11/15 2:05, Cong Wang 写道: >>> On Wed, Nov 11, 2020 at 9:44 PM <we...@ucloud.cn> wrote: >>>> diff --git a/net/sched/act_frag.c b/net/sched/act_frag.c >>>> new file mode 100644 >>>> index 0000000..3a7ab92 >>>> --- /dev/null >>>> +++ b/net/sched/act_frag.c >>> It is kinda confusing to see this is a module. It provides some >>> wrappers and hooks the dev_xmit_queue(), it belongs more to >>> the core tc code than any modularized code. How about putting >>> this into net/sched/sch_generic.c? >>> >>> Thanks. >> All the operations in the act_frag are single L3 action. >> >> So we put in a single module. to keep it as isolated/contained as possible > Yeah, but you hook dev_queue_xmit() which is L2. > >> Maybe put this in a single file is better than a module? Buildin in the tc >> core code or not. >> >> Enable this feature in Kconifg with NET_ACT_FRAG? > Sort of... If this is not an optional feature, that is a must-have > feature for act_ct, > we should just get rid of this Kconfig. > > Also, you need to depend on CONFIG_INET somewhere to use the IP > fragment, no? > > Thanks.
Maybe the act_frag should rename to sch_frag and buildin kernel. This fcuntion can be used for all tc subsystem. There is no need for CONFIG_INET. The sched system depends on NET. >
