On Wed 23 Oct 2019 at 17:21, Jamal Hadi Salim <j...@mojatatu.com> wrote: > On 2019-10-23 9:04 a.m., Vlad Buslov wrote: >> >> On Wed 23 Oct 2019 at 15:49, Jamal Hadi Salim <j...@mojatatu.com> wrote: >>> Hi Vlad, >>> > >>> I understand your use case being different since it is for h/w >>> offload. If you have time can you test with batching many actions >>> and seeing the before/after improvement? >> >> Will do. > > Thanks. > > I think you may have published number before, but would be interesting > to see the before and after of adding the action first and measuring the > filter improvement without caring about the allocator.
For filter with single gact drop action (first line in insertion rate table in the cover letter) I get insertion rate of 412k rules/sec with all of the actions preallocated in advance, which is 2x improvement. > >> >>> >>> Note: even for h/w offload it makes sense to first create the actions >>> then bind to filters (in my world thats what we end up doing). >>> If we can improve the first phase it is a win for both s/w and hw use >>> cases. >>> >>> Question: >>> Given TCA_ACT_FLAGS_FAST_INIT is common to all actions would it make >>> sense to use Could you have used a TLV in the namespace of TCA_ACT_MAX >>> (outer TLV)? You will have to pass a param to ->init(). >> >> It is not common for all actions. I omitted modifying actions that are >> not offloaded and some actions don't user percpu allocator at all >> (pedit, for example) and have no use for this flag at the moment. > > pedit just never got updated (its simple to update). There is > value in the software to have _all_ the actions use per cpu stats. > It improves fast path performance. > > Jiri complains constantly about all these new per-action TLVs > which are generic. He promised to "fix it all" someday. Jiri i notice > your ack here, what happened? ;-> > > cheers, > jamal
