> On 20.11.2020., at 01:46, hemant via lists.fd.io > <hemant=mnkcg....@lists.fd.io> wrote: > > 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.
Is your encap L2 or L3 ? do you transport ethernet header or just ip4/ip6? What is your criteria for selecting packets to be encapsulated? any ethernet frame, particular VLAN, Q-in-Q, Ip4/6 address? How do you want to assign L2 DMAC of the next hop device before sending encapsulated packet out of the interface? > 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 >> >> > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18105): https://lists.fd.io/g/vpp-dev/message/18105 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] -=-=-=-=-=-=-=-=-=-=-=-
