date:20181020

[vpp-dev] VPP/Using VPP In A Multi-thread Model

2018-10-20 Thread tianye@sina

Hello Everyone:

 

About the multi-thread mode of VPP, I have a question.

After read the following wiki page, I understand that user could allocation
1 or more worker thread

to 1 physical interface, and could also bind a worker thread or main thread
to a specific CPU core.

https://wiki.fd.io/view/VPP/Using_VPP_In_A_Multi-thread_Model

 

My question is:

The rule mentioned in this wiki page is look like only limited to the worker
thread and main thread in data plane.

What about the application level thread?

For example, as far as I know there is a thread named "http_server", right?
Obviously it is an application thread which work on the TCP session.

Can I specify the http_server thread to  a dedicate CPU core exclusively?

(I think this question might be a practical issue when someone want to
integrate any application to VPP, and it's look like

VPP is becoming more and more "application-friendly" , for example, the
appearance of POSIX style socket API etc.)

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10885): https://lists.fd.io/g/vpp-dev/message/10885
Mute This Topic: https://lists.fd.io/mt/27425156/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] one question IP checksum

2018-10-20 Thread Zhang Yuwei

Thanks a lot for your detail reply, John. My scenario is vxlan over l3 network, 
which means after decapsulation, vpp will use ip header to execute the forward 
function. I use this command to create the tunnel: "vppctl create vxlan tunnel 
src 10.0.0.1 dst 10.0.0.2 vni 24 encap-vrf-id 0 decap-next node 
ethernet-input". I found that vpp will calculate the inner ip header checksum 
and verify it. So I wonder if it is possible to skip the inner ip header 
calculation because the outer udp checksum can cover the inner packet. 
Expecting your reply, thanks a lot.

Regards,
Yuwei

From: John Lo (loj) [mailto:l...@cisco.com]
Sent: Friday, October 19, 2018 11:04 PM
To: Zhang, Yuwei1 ; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] one question IP checksum

The IP path after receiving a VXLAN packet is processing the outer IP header 
and not the inner one.  The payload of VXLAN packet is expected to be an 
ethernet packet.  After VXLAN decap, the payload ethernet packet will be 
processed in L2 forwarding path where no IP processing is involved.

If you want to speed up VXLAN decap processing, there is a vxlan-bypass feature 
you can enable on the underlay interface which will look for VXLAN packet and 
bypass IP lookup to speed up processing:

vpp# set interface ip vxlan-bypass ?
  set interface ip vxlan-bypassset interface ip vxlan-bypass 
 [del]

Enabling this feature on IP forwarding would add slight overhead for non-VXLAN 
IP packets but speed up VXLAN decap performance as IP lookup is not done.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Zhang Yuwei
Sent: Thursday, October 18, 2018 11:26 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] one question IP checksum

Hi Guys and VPP maintainers,
 When I run VPP in vxlan scenario, I found that when VPP receive a 
vxlan packets, after decapsulation, the packet will go into ip-input node 
instead of ip-input-nochecksum which means vpp will re-calculate the checksum 
and verify it. I think the outer UDP checksum has already include the inner 
packet as payload, so can we skip the ip header checksum calculation for inner 
ip header? This part is done by software which will cause some CPU cycles 
consumption and I tried if skip the checksum calculation it will have a obvious 
performance gain. Can anybody give me some instructions? Thanks a lot for your 
kindly help.

Regards,
Yuwei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10886): https://lists.fd.io/g/vpp-dev/message/10886
Mute This Topic: https://lists.fd.io/mt/27412224/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] one question IP checksum

2018-10-20 Thread John Lo (loj) via Lists.Fd.Io

Hi Yuwei,

I see that you are using VXLAN to carry L3 packets which seems to still have 
ethernet header.  This is not standard usage of VXLAN so I am not aware of a 
way to achieve what you desired via some kind of configuration of VPP.  A more 
optimal (also not standard) way may be to just send IP payload in VXLLAN tunnel 
without Ethernet header.  Then on decap, you can send the packet directly to 
ip-input-nochecksum node instead of (ethernet-input node).  The proper way to 
do this would be to use VXLAN-GPE which include a protocol header to specify 
payload type.

BTW, your claim of UDP checksum on the outer packet would've already cover the 
inner payload including its IP header is not necessarily correct.  For IPv4, 
the UDP checksum is optional and often left as 0 so not calculated.  VPP VXLAN 
encap would leave UDP checksum as 0 to save clocks, if the underlay is IPv4. If 
underlay is IPv6, then UDP checksum would be required and VPP would set it on 
VXLAN encap.

Regards,
John

From: Zhang, Yuwei1 
Sent: Saturday, October 20, 2018 9:58 AM
To: John Lo (loj) ; vpp-dev@lists.fd.io
Cc: Yang, Zhiyong 
Subject: RE: [vpp-dev] one question IP checksum

Thanks a lot for your detail reply, John. My scenario is vxlan over l3 network, 
which means after decapsulation, vpp will use ip header to execute the forward 
function. I use this command to create the tunnel: "vppctl create vxlan tunnel 
src 10.0.0.1 dst 10.0.0.2 vni 24 encap-vrf-id 0 decap-next node 
ethernet-input". I found that vpp will calculate the inner ip header checksum 
and verify it. So I wonder if it is possible to skip the inner ip header 
calculation because the outer udp checksum can cover the inner packet. 
Expecting your reply, thanks a lot.

Regards,
Yuwei

From: John Lo (loj) [mailto:l...@cisco.com]
Sent: Friday, October 19, 2018 11:04 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] one question IP checksum

The IP path after receiving a VXLAN packet is processing the outer IP header 
and not the inner one.  The payload of VXLAN packet is expected to be an 
ethernet packet.  After VXLAN decap, the payload ethernet packet will be 
processed in L2 forwarding path where no IP processing is involved.

If you want to speed up VXLAN decap processing, there is a vxlan-bypass feature 
you can enable on the underlay interface which will look for VXLAN packet and 
bypass IP lookup to speed up processing:

vpp# set interface ip vxlan-bypass ?
  set interface ip vxlan-bypassset interface ip vxlan-bypass 
 [del]

Enabling this feature on IP forwarding would add slight overhead for non-VXLAN 
IP packets but speed up VXLAN decap performance as IP lookup is not done.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Zhang Yuwei
Sent: Thursday, October 18, 2018 11:26 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] one question IP checksum

Hi Guys and VPP maintainers,
 When I run VPP in vxlan scenario, I found that when VPP receive a 
vxlan packets, after decapsulation, the packet will go into ip-input node 
instead of ip-input-nochecksum which means vpp will re-calculate the checksum 
and verify it. I think the outer UDP checksum has already include the inner 
packet as payload, so can we skip the ip header checksum calculation for inner 
ip header? This part is done by software which will cause some CPU cycles 
consumption and I tried if skip the checksum calculation it will have a obvious 
performance gain. Can anybody give me some instructions? Thanks a lot for your 
kindly help.

Regards,
Yuwei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10887): https://lists.fd.io/g/vpp-dev/message/10887
Mute This Topic: https://lists.fd.io/mt/27412224/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] VPP/Using VPP In A Multi-thread Model

2018-10-20 Thread Damjan Marion via Lists.Fd.Io


Building generally that kind of pipelines is bad idea, as it will be as slow as 
slowest part of the pipeline.
It typically suffer of core-to-core transfer so our model is to keep packet on 
the same core as much as possible.
In some cases you need to handoff packet to different core (NAT plugin does 
that) but in such case
you likely want to continue processing packet on that core instead of paying 
cost of moving it back...

VPP have very simple to use packet handoff infra...

-- 
Damjan

> On 20 Oct 2018, at 04:18, tianye@sina  wrote:
> 
> Hello Everyone:
>  
> About the multi-thread mode of VPP, I have a question.
> After read the following wiki page, I understand that user could allocation 1 
> or more worker thread
> to 1 physical interface, and could also bind a worker thread or main thread 
> to a specific CPU core.
> https://wiki.fd.io/view/VPP/Using_VPP_In_A_Multi-thread_Model 
> 
>  
> My question is:
> The rule mentioned in this wiki page is look like only limited to the worker 
> thread and main thread in data plane.
> What about the application level thread?
> For example, as far as I know there is a thread named “http_server”, right? 
> Obviously it is an application thread which work on the TCP session.
> Can I specify the http_server thread to  a dedicate CPU core exclusively?
> (I think this question might be a practical issue when someone want to 
> integrate any application to VPP, and it’s look like
> VPP is becoming more and more “application-friendly” , for example, the 
> appearance of POSIX style socket API etc.)
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10885): https://lists.fd.io/g/vpp-dev/message/10885 
> 
> Mute This Topic: https://lists.fd.io/mt/27425156/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 (#10888): https://lists.fd.io/g/vpp-dev/message/10888
Mute This Topic: https://lists.fd.io/mt/27425156/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] vpp 18.07.1 hangs on intel x520-sr2

2018-10-20 Thread Damjan Marion via Lists.Fd.Io


Just try to run testpmd on that port, your traceback shows that
your problem happens inside DPDK code...

-- 
Damjan

> On 19 Oct 2018, at 22:28, Tomasz Płaza  wrote:
> 
> No I have not. Are there any special steps I should follow?
> 
> On 2018-10-19 22:11 Damjan Marion   
> wrote:
>> 
>> Have you tried with dpdk testpmd?
>> 
>> — 
>> Damjan
>> 
>> On 19 Oct 2018, at 20:51, Tomasz Płaza mailto:gla...@wp.pl>> 
>> wrote:
>> 
>>> Tested on two indetical computers and under kernel management nic works 
>>> just fine.
>>> 
>>> On 2018-10-19 09:56 Damjan Marion wrote:
 
 Looks like DPDK issue, might also be hardware problem.
 Have you tried different computer/nic?
 
 -- 
 Damjan
 
> On 17 Oct 2018, at 11:14, Glaza mailto:gla...@wp.pl>> 
> wrote:
> 
> Investigating it further I have build 18.10-rc1 and than master. In both 
> cases I got a crash dump in rte_eal_init. Bellow is BT from master:
> 
> #0  0x7ff377882277 in raise () from /lib64/libc.so.6
> #1  0x7ff377883968 in abort () from /lib64/libc.so.6
> #2  0x0040817c in os_exit (code=1) at 
> /var/vpp/vpp/src/vpp/vnet/main.c:349
> #3  0x7ff379021c9f in unix_signal_handler (signum=6, 
> si=0x7ff3369feeb0, uc=0x7ff3369fed80) at 
> /var/vpp/vpp/src/vlib/unix/main.c:157
> #4  
> #5  0x7ff377882277 in raise () from /lib64/libc.so.6
> #6  0x7ff377883968 in abort () from /lib64/libc.so.6
> #7  0x7ff334aba345 in __rte_panic () from 
> /usr/lib/vpp_plugins/dpdk_plugin.so
> #8  0x7ff334af3f90 in rte_eal_init () from 
> /usr/lib/vpp_plugins/dpdk_plugin.so
> #9  0x7ff335142df7 in dpdk_config (vm=0x7ff37924d240 
> , input=0x7ff33553e0a8 
> <_vlib_config_function_dpdk_config+8>) at 
> /var/vpp/vpp/src/plugins/dpdk/device/init.c:1427
> #10 0x7ff378fa854f in vlib_call_all_config_functions 
> (vm=0x7ff37924d240 , input=0x7ff3369fffb0, is_early=0) 
> at /var/vpp/vpp/src/vlib/init.c:146
> #11 0x7ff378fcc004 in vlib_main (vm=0x7ff37924d240 
> , input=0x7ff3369fffb0) at 
> /var/vpp/vpp/src/vlib/main.c:1809
> #12 0x7ff3790234b5 in thread0 (arg=140683686236736) at 
> /var/vpp/vpp/src/vlib/unix/main.c:607
> #13 0x7ff37864d88c in clib_calljmp () from /lib64/libvppinfra.so.19.01
> #14 0x7ffdbc134110 in ?? ()
> #15 0x7ff379023966 in vlib_unix_main (argc=29, argv=0x1315830) at 
> /var/vpp/vpp/src/vlib/unix/main.c:676
> #16 0x00407b45 in main (argc=29, argv=0x1315830) at 
> /var/vpp/vpp/src/vpp/vnet/main.c:264
> 
> # dpdk-devbind -s
> 
> Network devices using DPDK-compatible driver
> 
> :07:00.0 'I210 Gigabit Network Connection 1533' drv=vfio-pci 
> unused=igb_uio,uio_pci_generic
> :81:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' 
> drv=vfio-pci unused=igb_uio,uio_pci_generic
> :81:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' 
> drv=vfio-pci unused=igb_uio,uio_pci_generic
> 
> startup.conf is:
> 
> unix {
>   nodaemon
>   log /var/log/vpp/vpp.log
>   full-coredump
>   cli-listen /run/vpp/cli.sock
>   gid vpp
> }
> 
> api-trace {
>   on
> }
> 
> api-segment {
>   gid vpp
> }
> 
> cpu {
> 
> }
> 
> dpdk {
> uio-driver vfio-pci
> }
> On 15 10 2018  12:26 Glaza wrote:
> 
> Hi All,
> 
> On centos 7 after install vpp-18.07.1-release hangs after start when 
> x520-sr2 NIC is in use.
> 
> # dpdk-devbind -s | head
> 
> Network devices using DPDK-compatible driver
> 
> :81:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' 
> drv=uio_pci_generic unused=igb_uio
> :81:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' 
> drv=uio_pci_generic unused=igb_uio
> 
> # /usr/bin/vpp -c /etc/vpp/startup.conf
> vlib_plugin_early_init:361: plugin path 
> /usr/lib/vpp_plugins:/usr/lib64/vpp_plugins
> load_one_plugin:189: Loaded plugin: abf_plugin.so (ACL based Forwarding)
> load_one_plugin:189: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:189: Loaded plugin: avf_plugin.so (Intel Adaptive Virtual 
> Function (AVF) Device Plugin)
> load_one_plugin:191: Loaded plugin: cdp_plugin.so
> load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane 
> Development Kit (DPDK))
> load_one_plugin:189: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> load_one_plugin:189: Loaded plugin: gbp_plugin.so (Group Based Policy)
> load_one_plugin:189: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:189: Loaded plugin: igmp_plugin.so (IGMP messaging)
> load_one_plugin:189: Loaded plugin: ila_plugin

Re: [vpp-dev] Question about VPP plugin/node's life cycle

2018-10-20 Thread Damjan Marion via Lists.Fd.Io


Yes, generally you want to put as less as possible into plugin init code and
simply initialise data structures at the moment when feature is 
configured/enabled.

If you have process node, it should be disabled and later enabled by using 
event message...

Please note that there is also a way to skip loading a plugin as result of 
failure in plugin early init code.
I.e. you can skip loading plugin if dlopen() of some library fails or some 
permissions are missing.

-- 
Damjan

> On 19 Oct 2018, at 21:41, Rui Cai via Lists.Fd.Io 
>  wrote:
> 
> Dear Dave:
>  
> Thanks a lot for the information! I have a follow up question with regard to 
> when a plugin should allocate its global resources.
>  
> Plugins doesn’t unload/reload during VPP process looks like the expectation 
> for a plugin to not allocate any resources during its plugin_init function 
> since it will not have an opportunity to free it. The plugin should rather 
> have some API to “enable feature” where it does the bulk of allocation and 
> free the resources in its “disable feature” API. With the sample plugin 
> example, what I see is that the plugin_init just hooks up APIs (init with the 
> VPP framework), but the actual “feature enable” API modifies the graph (init 
> sample plugin).
>  
> In general, what’s the responsibility of initialization for plugin init vs a 
> separate API to enable the feature? Should plugin init just do some 
> minimal/basic registration related work with VPP framework and leave plugin 
> specific work during “feature enable”?
>  
> Thanks,
> -Ray
>  
> From: Dave Barach (dbarach) mailto:dbar...@cisco.com>> 
> Sent: Friday, October 19, 2018 4:35 AM
> To: Ray Cai mailto:ru...@microsoft.com>>; 
> vpp-dev@lists.fd.io 
> Subject: RE: Question about VPP plugin/node's life cycle
>  
> Dear Ray,
>  
> As you probably suspect: plugins are neither unloaded nor reloaded.
>  
> HTH... Dave 
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of Rui Cai via Lists.Fd.Io
> Sent: Thursday, October 18, 2018 9:43 PM
> To: vpp-dev@lists.fd.io 
> Cc: vpp-dev@lists.fd.io 
> Subject: [SUSPICIOUS] [vpp-dev] Question about VPP plugin/node's life cycle
>  
> Hello vpp experts:
>  
> I’m trying to figure out a plugin/node’s life cycle with in VPP process. 
> There is very rich code/documentation talking about plugin 
> registration/initialization and node registration. I understand that nodes 
> are created during node graph build up and during plugin init function I can 
> further manipulate the edges of my nodes. However, I’m having trouble finding 
> the code that handles node tear down/plugin un-initialization. Does VPP have 
> a notion of plugin/node un-initialization? For example, if my plugin 
> allocated some object during init, I would expect to free it in un-init. If 
> there is such concept, what should I search to find them? Or pretty much the 
> node/plugin lives as long as the VPP process is running and the plugin/node 
> life cycle is never going to be shorter than VPP process?
>  
> Thanks a lot!
> -Ray
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10882): https://lists.fd.io/g/vpp-dev/message/10882 
> 
> Mute This Topic: https://lists.fd.io/mt/27411530/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 (#10890): https://lists.fd.io/g/vpp-dev/message/10890
Mute This Topic: https://lists.fd.io/mt/27411530/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP/Using VPP In A Multi-thread Model

Re: [vpp-dev] one question IP checksum

Re: [vpp-dev] one question IP checksum

Re: [vpp-dev] VPP/Using VPP In A Multi-thread Model

Re: [vpp-dev] vpp 18.07.1 hangs on intel x520-sr2

Re: [vpp-dev] Question about VPP plugin/node's life cycle

6 matches

Site Navigation

Mail list logo

Footer information