I agree with Ye, it's a pain to configure ip4, ip6 output, unicast and multicast. If my device is used with only physical interfaces and tunnel encap/decap of outer ip4/ip6 is used, interface-output is nice to have. I don't know enough about VPP to suggest what changes are needed, but I am open to helping if anyone embarks on a chance.
Hemant -----Original Message----- From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of ??? Sent: Thursday, November 19, 2020 4:23 AM To: Neale Ranns (nranns) <nra...@cisco.com>; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] why tunnel interfaces do not support device-input feature? thinks for your reply, I got it, but it is a little inconvenient if one want to add some features base on interface. Instead, he should add features on ip4-output/ip6-ouput arc or ip4-unicast/ip6-unicast twice, but still there are packets get through interface but ip4/6 nodes. 在 2020/11/18 下午6:15, Neale Ranns (nranns) 写道: > 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 > >
smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18103): https://lists.fd.io/g/vpp-dev/message/18103 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] -=-=-=-=-=-=-=-=-=-=-=-
