The only thing worth considering is to teach the ip4/6 input paths to skip work 
which the h/w and driver can do. As in: make a variant of ip4-input-no-checksum 
["ip4-input-no-checksum-no-ttl-no-fragment-no-<whatever>"] by adding additional 
compile-time-constant arguments to the ip4-input inline and instantiating it.

Beyond that, Damjan is right: it's not a good idea, please don't go there.

HTH... Dave

-----Original Message-----
From: Damjan Marion <dmar...@me.com> 
Sent: Saturday, September 22, 2018 10:31 AM
To: Nitin Saxena <nitin.sax...@cavium.com>
Cc: Dave Barach (dbarach) <dbar...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd



— 
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 (#10611): https://lists.fd.io/g/vpp-dev/message/10611
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to