— Damjan
> On 22 Sep 2018, at 16:10, Nitin Saxena <nitin.sax...@cavium.com> wrote: > > Thanks Dave for the detailed answers. > >> Patches which skip ANY of the work described above will not be merged. > Understood. Intention is not to break functionality/security at all. > >> 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). > Is it a confirmation that starting of "ip4/ip6 unicast/multicast" feature-arc > along with "device-input" feature arc in the “device_input” node itself is > acceptable by VPP? No, it is not, ip4 packet may also go to l2 path. You will end up with layering violation and bloatig driver code. Please dont go there. > > I am also assuming that ipv4-lookup can be device-input’s next node, provided > stack functionalities/performance remains intact. Ip4-input is also punt node, responsible for sending specific packets to the control plane. Iz should stay in the path... > > Thanks, > Nitin > >> On 22-Sep-2018, at 6:12 PM, Dave Barach via Lists.Fd.Io >> <dbarach=cisco....@lists.fd.io> wrote: >> >> External Email >> >> 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/675748 >> Group Owner: vpp-dev+ow...@lists.fd.io >> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub >> [nsax...@caviumnetworks.com] >> -=-=-=-=-=-=-=-=-=-=-=- > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#10609): https://lists.fd.io/g/vpp-dev/message/10609 > Mute This Topic: https://lists.fd.io/mt/25907990/675642 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10610): https://lists.fd.io/g/vpp-dev/message/10610 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] -=-=-=-=-=-=-=-=-=-=-=-