On 24 Jan 2019, at 14:45, Benoit Ganne (bganne) <bga...@cisco.com> wrote:

>>> 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)

With gigabytes of memory used for pools and other datastructs, node memory 
structure overhead is negligible imho. Plus, mind my point about 
address-family-specific optimizations. Check the acl plugin. I have 8 nodes and 
only one instance of actual “code”. Not to say that it works perfect but 
maintenance wise it is quite reasonable.

> - no need for helpers to register nodes to the 3 arcs

I just have difficulty to see how duplicating the packets is a workable idea.

> 
> 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 :)

#4. :)

The rationale behind the way i did it the way I did it was to harmonize the way 
the l2 and l3 nodes can work, as much as possible. 

—a

> 
> Ben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11994): https://lists.fd.io/g/vpp-dev/message/11994
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to