Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd

[Nitin Saxena]

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  wrote:
> 
> 
> —
> Damjan
> 
>> On 22 Sep 2018, at 16:10, Nitin Saxena  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 
>>>  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  On Behalf Of Nitin Saxena
>>> Sent: Saturday, September 22, 2018 12:25 AM
>>> To: vpp-dev 
>>> 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: 

Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd

[Dave Barach via Lists.Fd.Io]

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-"] 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  
Sent: Saturday, September 22, 2018 10:31 AM
To: Nitin Saxena 
Cc: Dave Barach (dbarach) ; vpp-dev 
Subject: Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd



— 
Damjan

> On 22 Sep 2018, at 16:10, Nitin Saxena  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 
>>  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  On Behalf Of Nitin Saxena
>> Sent: Saturday, September 22, 2018 12:25 AM
>> To: vpp-dev 
>> 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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd

[Damjan Marion via Lists.Fd.Io]

— 
Damjan

> On 22 Sep 2018, at 16:10, Nitin Saxena  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 
>>  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  On Behalf Of Nitin Saxena
>> Sent: Saturday, September 22, 2018 12:25 AM
>> To: vpp-dev 
>> 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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd

[Nitin Saxena]

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 
>  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  On Behalf Of Nitin Saxena
> Sent: Saturday, September 22, 2018 12:25 AM
> To: vpp-dev 
> 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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Skipping ipv4-input processing in L3Fwd

[Dave Barach via Lists.Fd.Io]

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  On Behalf Of Nitin Saxena
Sent: Saturday, September 22, 2018 12:25 AM
To: vpp-dev 
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] setting speed and duplex in dpdk_update_link_state

[emma sdi]

Dear vpp

Patch 14848 is verified, Please review and give me some comments.

Cheers

On Mon, Sep 17, 2018 at 12:10 PM khers  wrote:

> Dear vpp
>
> we set speed and duplex In function dpdk_update_link_state, although
> When link_status is down, speed and duplex is unknown.
> So I commit my suggestion in gerrit id 14848
> .
>
> Cheers
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10607): https://lists.fd.io/g/vpp-dev/message/10607
Mute This Topic: https://lists.fd.io/mt/25721090/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-