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 (#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]
-=-=-=-=-=-=-=-=-=-=-=-
