You would have to pull a bunch of work back into the device driver: counting IP packet errors, head of ip4/6 unicast/multicast input feature arcs, and mandatory input checks (expired TTL, ip header length, fragment).
Hardware offload will NOT accomplish all of these tasks. If by chance you can convince it and/or the device driver to do SOME of these things - perhaps the ip header length, fragment, and expired TTL checks - variant ip4/6 input nodes can be constructed by working on ip4_input_inline(...) and ip6_input(...). The rest of the forwarding graph - and by implication anyone running vpp - depend on these checks having been performed. These checks are important for three reasons: functional correctness, security, and observability. Patches which skip ANY of the work described above will not be merged. Thanks... Dave -----Original Message----- From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Nitin Saxena Sent: Saturday, September 22, 2018 12:25 AM To: vpp-dev <vpp-dev@lists.fd.io> Subject: [vpp-dev] Skipping ipv4-input processing in L3Fwd Hi, In case of L3Fwd, there is a possibility of handing of vlib_buffer from device-input to ipv4-lookup and thereby skipping ipv4-input/ipv4-input-no-chksum completely. All ipv4-input/ipv4-input-nochksum functionalities can be offloaded to hardware and hence the node can be skipped. Questions: - If ipv4-input will be skipped is it fair to enable feature-arc in device-input node? - Is it fair to add ipv4-lookup next node to device-input node? Any other approach to be think about to leverage hardware offload functionalities? Thanks, Nitin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10608): https://lists.fd.io/g/vpp-dev/message/10608 Mute This Topic: https://lists.fd.io/mt/25907990/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
