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? I am also assuming that ipv4-lookup can be device-input’s next node, provided stack functionalities/performance remains intact. 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/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
