> 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.
I tried something like this in the past: https://gerrit.fd.io/r/c/vpp/+/17168 However there were no real usecase for it apart 1 place (gbp) so it was not saving anything, but if the usecase for tunnels is common enough, we could do something similar I guess? Best ben > -----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- > d...@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 (#18104): https://lists.fd.io/g/vpp-dev/message/18104 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] -=-=-=-=-=-=-=-=-=-=-=-
