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: [email protected] <[email protected]> On Behalf Of ??? Sent: Thursday, November 19, 2020 4:23 AM To: Neale Ranns (nranns) <[email protected]>; [email protected] 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, "[email protected] on behalf of 叶东岗" > <[email protected] on behalf of [email protected]> 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: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
