Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
-Original Message- From: Damjan Marion Sent: Friday, November 20, 2020 2:16 PM To: hem...@mnkcg.com Cc: y...@wangsu.com; nra...@cisco.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] why tunnel interfaces do not support device-input feature? >What are the benefits compared to normal hash table lookup we do today. >Any perf numbers to share? My need was to hash a 6-tuple (src-ip, dst-ip, ip-tos, protocol/ip6-nextHdr, l4src-port, l4-dst-port) for ip4 and ip6 and this is why I just used the paper's hash tuple. I did look at VPP's N-tuple classify implementation but didn't find the exact algorithm the paper uses. Sorry, right now, I have only used the paper's hash, so I don't have any perf numbers to share. When I get a chance, I will use VPP API, run tests, and get back. Hemant smime.p7s Description: S/MIME cryptographic signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18114): https://lists.fd.io/g/vpp-dev/message/18114 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
> > On 20.11.2020., at 18:42, hemant via lists.fd.io > . > > I didn't look hard, but I don't see a tuple hash in VPP as described in this > paper: https://tinyurl.com/y5p5resg. The plugin I wrote uses the tuple hash > of the paper. What are the benefits compared to normal hash table lookup we do today. Any perf numbers to share? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18112): https://lists.fd.io/g/vpp-dev/message/18112 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
Appreciate the l2-input feature arch tip. Even when I use only device-input and interface-output, I still use VPP's vector processing. I wrote a 5G UPF VPP plugin (uses 6-tuple) this way and see packet performance comparable to stateful and deterministic NAT44 VPP plugin. A 5G UPF does lot more than the deterministic NAT44. Travelping has a UPF VPP plugin but I couldn't get their code to install and work to compare performance. I didn't look hard, but I don't see a tuple hash in VPP as described in this paper: https://tinyurl.com/y5p5resg. The plugin I wrote uses the tuple hash of the paper. Hemant -Original Message- From: Damjan Marion Sent: Friday, November 20, 2020 12:20 PM To: hem...@mnkcg.com Cc: 叶东岗 ; Neale Ranns ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] why tunnel interfaces do not support device-input feature? > On 20.11.2020., at 17:16, hemant via lists.fd.io > wrote: > > Please see in line below against "". > > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Damjan > Marion via lists.fd.io > Sent: Friday, November 20, 2020 3:45 AM > To: hem...@mnkcg.com > Cc: y...@wangsu.com; Neale Ranns ; > vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] why tunnel interfaces do not support > device-input feature? > > Is your encap L2 or L3 ? do you transport ethernet header or just ip4/ip6? > > L2 > > What is your criteria for selecting packets to be encapsulated? any > ethernet frame, particular VLAN, Q-in-Q, Ip4/6 address? > > layer-3 information + layer-4 ports (5-tuple). The 5-tuple is > looked up from packet and a tunnel id (teid) is returned. > > How do you want to assign L2 DMAC of the next hop device before > sending encapsulated packet out of the interface? > > An egress table consists of teid vs. dmac. This table lookup > provides dmac. Just use device-input arc for packet ingress and > interface-output for packet egress. > > Also, thanks to Ben for replying. Based on what you are explaining here, you don't need much from VPP. You can do int simpler and faster simply by writing small DPDK application. In VPP such thing can be achieved by using l2-input feature arch. You just need to switch interface to L2 mode and you wiill get all ethernet frames there, v4,v6 ucast and mcast…. — Damjan smime.p7s Description: S/MIME cryptographic signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18111): https://lists.fd.io/g/vpp-dev/message/18111 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
> On 20.11.2020., at 17:16, hemant via lists.fd.io > wrote: > > Please see in line below against "". > > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion > via > lists.fd.io > Sent: Friday, November 20, 2020 3:45 AM > To: hem...@mnkcg.com > Cc: y...@wangsu.com; Neale Ranns ; vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] why tunnel interfaces do not support device-input > feature? > > Is your encap L2 or L3 ? do you transport ethernet header or just ip4/ip6? > > L2 > > What is your criteria for selecting packets to be encapsulated? any ethernet > frame, particular VLAN, Q-in-Q, Ip4/6 address? > > layer-3 information + layer-4 ports (5-tuple). The 5-tuple is looked up > from packet and a tunnel id (teid) is returned. > > How do you want to assign L2 DMAC of the next hop device before sending > encapsulated packet out of the interface? > > An egress table consists of teid vs. dmac. This table lookup provides > dmac. Just use device-input arc for packet ingress and interface-output for > packet egress. > > Also, thanks to Ben for replying. Based on what you are explaining here, you don't need much from VPP. You can do int simpler and faster simply by writing small DPDK application. In VPP such thing can be achieved by using l2-input feature arch. You just need to switch interface to L2 mode and you wiill get all ethernet frames there, v4,v6 ucast and mcast…. — Damjan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18110): https://lists.fd.io/g/vpp-dev/message/18110 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
Please see in line below against "". -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via lists.fd.io Sent: Friday, November 20, 2020 3:45 AM To: hem...@mnkcg.com Cc: y...@wangsu.com; Neale Ranns ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] why tunnel interfaces do not support device-input feature? Is your encap L2 or L3 ? do you transport ethernet header or just ip4/ip6? L2 What is your criteria for selecting packets to be encapsulated? any ethernet frame, particular VLAN, Q-in-Q, Ip4/6 address? layer-3 information + layer-4 ports (5-tuple). The 5-tuple is looked up from packet and a tunnel id (teid) is returned. How do you want to assign L2 DMAC of the next hop device before sending encapsulated packet out of the interface? An egress table consists of teid vs. dmac. This table lookup provides dmac. Just use device-input arc for packet ingress and interface-output for packet egress. Also, thanks to Ben for replying. Hemant smime.p7s Description: S/MIME cryptographic signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18109): https://lists.fd.io/g/vpp-dev/message/18109 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
> On 20.11.2020., at 01:46, hemant via 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 On Behalf Of ??? > Sent: Thursday, November 19, 2020 4:23 AM > To: Neale Ranns (nranns) ; 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 叶东岗" >> 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
> 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 On Behalf Of ??? > Sent: Thursday, November 19, 2020 4:23 AM > To: Neale Ranns (nranns) ; 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 叶东岗" 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
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 On Behalf Of ??? Sent: Thursday, November 19, 2020 4:23 AM To: Neale Ranns (nranns) ; 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 叶东岗" > 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] -=-=-=-=-=-=-=-=-=-=-=-
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 叶东岗" 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 (#18091): https://lists.fd.io/g/vpp-dev/message/18091 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
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 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 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
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 > wrote: > > > Hi Ye, > > Some comments inline... > > On 17/11/2020 02:34, "vpp-dev@lists.fd.io on behalf of 叶东岗" > 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 (#18084): https://lists.fd.io/g/vpp-dev/message/18084 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] why tunnel interfaces do not support device-input feature?
Hi Ye, Some comments inline... On 17/11/2020 02:34, "vpp-dev@lists.fd.io on behalf of 叶东岗" 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 (#18080): https://lists.fd.io/g/vpp-dev/message/18080 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] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] why tunnel interfaces do not support device-input feature?
Hi all: why tunnel interfaces do not support device-input feature? why esp packets do not go through ipsec interface's "interface-output" node? 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 (#18046): https://lists.fd.io/g/vpp-dev/message/18046 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] -=-=-=-=-=-=-=-=-=-=-=-
