>> 4) keeps the 3 flavors as they are but add helper to register >> nodes to the 3 arcs - basically move helpers from GBP plugin to vnet/l2. >> Basically same up/downside as (3)
> This would be my favourite approach. The benefit of having per-arc nodes is > that we can get compiler optimizations by using constant propagation of > “is_ip6” parameter to a common inline node function... overhead in total is > about 20 LOC per node, and is a one-time thing. Note that (1) does not prevent that either and is simpler in my opinion: - (4) adds some overhead because node declaration must be duplicated (the feature node memory structure is duplicated for each arc) - no need for helpers to register nodes to the 3 arcs Finally, when moving from L2 feature bits to arcs, the fact that the nodes cannot be reordered between "all" and eg. "ip4" is no different that the current situation with L2 feature bits (that cannot be reordered dynamically AFAICT). Anyway, I do not have a strong opinion (apart that I do not like (5)), so I'll probably stop here and wait for your decision :) Ben
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11993): https://lists.fd.io/g/vpp-dev/message/11993 Mute This Topic: https://lists.fd.io/mt/29523811/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
