I don't know if this is useful for anyone or not. I posted https://wiki.fd.io/images/a/a6/VPP_node_graph.svg
It is impossible to view at once, but you can search for a node and go from there. On Wed, Nov 18, 2020 at 11:05 AM Damjan Marion via lists.fd.io <dmarion= me....@lists.fd.io> wrote: > > 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 (#18086): https://lists.fd.io/g/vpp-dev/message/18086 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] -=-=-=-=-=-=-=-=-=-=-=-
