Hi Damjan/Dave. > You will end up with layering violation and bloatig driver code. Please dont > go there. Ok. My motivation is the error packet should be dropped at the earliest. i.e - In device-input node, if interface is not in L2 brdge or in L2XC config then drop all error packets in “device-input” node itself. Except TTL expiry, all ipv4-input checks drops the packet. - If interface is in L2 bridge or L2XC config, packet can take L2 path and ipv4-input stays in that path
> No, it is not, ip4 packet may also go to l2 path. Do you mean to say that in some cases L2 nodes are called after ip4-input? Could you please elaborate? “show vlib graph” output do not give any hint. > Ip4-input is also punt node, responsible for sending specific packets to the > control plane. Iz should stay in the path… I fail to find the punt code that call ip4-input. Could you please point me to the code? Thanks, Nitin > On 22-Sep-2018, at 8:01 PM, Damjan Marion <dmar...@me.com> wrote: > > > — > 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 (#10612): https://lists.fd.io/g/vpp-dev/message/10612 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] -=-=-=-=-=-=-=-=-=-=-=-
