device-input feature arch is build for features which needs to deal with raw 
ethernet frames
before they are processed and before we know to which software interface packet 
belongs (including the information if interface is in l2 or l3 mode). So there 
is no many tunnelling protocols which will even be candidates for this arc. 
Tunnel encaps which doesn’t carry inner ethernet header will simply not work.
People should think twice before deciding to build any feature which hangs on 
that arc, as likely there is more appropriate one to use.
Pretty much the same applies to interface-output.


> On 18.11.2020., at 11:15, Neale Ranns via lists.fd.io 
> <nranns=cisco....@lists.fd.io> wrote:
> 
> 
> Hi Ye,
> 
> Some comments inline...
> 
> On 17/11/2020 02:34, "vpp-dev@lists.fd.io on behalf of 叶东岗" 
> <vpp-dev@lists.fd.io on behalf of y...@wangsu.com> wrote:
> 
>    Hi all:
> 
>    why tunnel interfaces do not support device-input feature?
> 
> No one has asked for/contributed such support.  If you're volunteering, 
> here's some advice.
> 
> Taking the feature arc always costs performance, but we accept that. What is 
> harder to accept is a performance degradation when there are no features 
> configured.
> 
> Devices are 'physical' interfaces, they represent an interface from VPP to 
> the external world. This means they are read by nodes in poll mode, one 
> device at a time. They therefore have the luxury of knowing that all packets 
> in the vector/frame come from the same device. Virtual interfaces don't have 
> that luxury, so the check for 'are there features on the arc' would be per 
> buffer, not per-packet, this would be a noticeable performance cost.
> 
>    why  esp packets  do not go through ipsec interface's "interface-output" 
>    node?
> 
> The actions for TX on a virtual interface are different. The equivalent node 
> is 'adj-midchain-tx'. Running the 'interface-output' arc here would be 
> possible, with a negligible performance cost because the adj can cache the 
> feature arc's state.
> 
> /neale
> 
>    I think it's no bad idea to keep some features consistency of all 
>    interface in spite of an little performance degradation?
> 
> 
>    Best regards,
>    Ye Donggang
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18084): https://lists.fd.io/g/vpp-dev/message/18084
Mute This Topic: https://lists.fd.io/mt/78307484/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