Re: [vpp-dev] How to actively close the client connections in http server? #vnet

[Florin Coras]

Ow, so the issue is the reset. Could you try to call stream_session_disconnect 
instead of stream_session_cleanup in the handle?

Florin

> On Nov 22, 2018, at 6:51 AM, Andreas Schultz  
> wrote:
> 
> Hi,
> 
> Florin Coras mailto:fcoras.li...@gmail.com>> schrieb 
> am Mi., 21. Nov. 2018 um 18:33 Uhr:
> 
>> On Nov 21, 2018, at 8:55 AM, Andreas Schultz > > wrote:
>> 
>> Florin Coras mailto:fcoras.li...@gmail.com>> 
>> schrieb am Mi., 21. Nov. 2018 um 17:18 Uhr:
>> Hi Andreas, 
>> 
>> The trace lower suggests your tcp connection was freed but you still got 
>> data for it. tcp-input and the checks in established should prevent that 
>> from happening and the session layer should not receive any events after the 
>> transport notifies it that the session will cleaned up. 
> 
> I've found a way to reproduce the problem with a mostly unmodified vpp (see 
> attached patch for the changes).
> It turns that the crash is triggered when a tcp client is aborting 
> (resetting) the connection the hard way with a RST.
> 
> A normal connection close looks like this:
> 
> Client  Server (VPP)
> - [FIN,ACK] >
> < [FIN,ACK] - 
> --- [ACK] -->
> 
> The crash occurs when the connection is aborted like this:
> 
> Client  Server (VPP)
> - [RST,ACK] >
> 
> For the unmodified VPP the crash looks like this:
> 
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> 0x776abda8 in tcp_handle_postponed_dequeues (wrk=0x7fffb7313b80) at 
> /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:530
> 530 tc->flags &= ~TCP_CONN_DEQ_PENDING;
> (gdb) bt
> #0  0x776abda8 in tcp_handle_postponed_dequeues (wrk=0x7fffb7313b80) 
> at /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:530
> #1  0x776b1a6c in tcp46_established_inline (vm=0x7708f340 
> , node=0x7fffb927a3c0, frame=0x7fffb7619800, is_ip4=1) at 
> /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:2160
> #2  0x776b1b01 in tcp4_established (vm=0x7708f340 
> , node=0x7fffb927a3c0, from_frame=0x7fffb7619800) at 
> /usr/src/components/vpp/src/vnet/tcp/tcp_input.c:2171
> #3  0x770043ec in dispatch_node (vm=0x7708f340 
> , node=0x7fffb927a3c0, type=VLIB_NODE_TYPE_INTERNAL, 
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb7619800, 
> last_time_stamp=67427903546971 )
> at /usr/src/components/vpp/src/vlib/main.c:1154
> #4  0x770049cc in dispatch_pending_node (vm=0x7708f340 
> , pending_frame_index=5, last_time_stamp=67427903546971 
> ) at /usr/src/components/vpp/src/vlib/main.c:1312
> #5  0x7700665f in vlib_main_or_worker_loop (vm=0x7708f340 
> , is_main=1) at /usr/src/components/vpp/src/vlib/main.c:1739
> #6  0x77006e38 in vlib_main_loop (vm=0x7708f340 
> ) at /usr/src/components/vpp/src/vlib/main.c:1813
> #7  0x77007be4 in vlib_main (vm=0x7708f340 , 
> input=0x7fffb6bfffb0) at /usr/src/components/vpp/src/vlib/main.c:2006
> #8  0x77062b90 in thread0 (arg=140737337946944) at 
> /usr/src/components/vpp/src/vlib/unix/main.c:606
> #9  0x76e73c98 in clib_calljmp () from 
> /usr/src/components/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01
> #10 0x7fffd230 in ?? ()
> #11 0x7706305d in vlib_unix_main (argc=34, argv=0x55694230) at 
> /usr/src/components/vpp/src/vlib/unix/main.c:675
> #12 0xd404 in main (argc=34, argv=0x55694230) at 
> /usr/src/components/vpp/src/vpp/vnet/main.c:272
> 
> The reason I discovered this is that my VPP HTTP server is sending a 302 
> redirect with a Location header. In this case wget is doing something with 
> the connection that leads to the RST instead of a normal FIN.
> 
> Regards
> Andreas
> 
> 
> -- 
> -- 
> Dipl.-Inform. Andreas Schultz
> 
> --- enabling your networks --
> Travelping GmbH Phone:  +49-391-81 90 99 0
> Roentgenstr. 13 Fax:+49-391-81 90 99 299
> 39108 Magdeburg Email:  i...@travelping.com 
> 
> GERMANY Web:http://www.travelping.com 
> 
> 
> Company Registration: Amtsgericht StendalReg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann  VAT ID No.: DE236673780
> -
> 

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

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

Re: [vpp-dev] vppcom: why __vcl_worker_index is thread local? #vpp

[Florin Coras]

It’s done on purpose in order to avoid constant locking. Applications should 
accept new session on the right thread. If you plan to distribute the load 
across multiple workers, then just have them all listen on the same ip:port 
tuple and vpp will load balance. 

Florin

> On Nov 22, 2018, at 6:54 AM, at.man...@gmail.com wrote:
> 
> Hello all,
> Having that index in the thread context is breaking run-time of 
> multi-threaded applications. Most of them accept connections in a main loop 
> and process data in a thread by passing the socket descriptor.
> I understand that there is no data protections across the interface 
> library..but, are there any other reasons, that I might be missing, for that?
> 
> Thanks in advance.
> Manuel -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11372): https://lists.fd.io/g/vpp-dev/message/11372
> Mute This Topic: https://lists.fd.io/mt/28286895/675152
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480544
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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

Re: [vpp-dev] Request: please add "real" pcap ability #vpp

[Jerome Tollet via Lists.Fd.Io]

Hi Brian,
I tried what I told you and I confirm that worked fine on my setup.

create packet-generator interface pg0
packet-generator capture pg0 pcap /tmp/mycap.pcap
set interface span SOURCE_INTF destination pg0
set interface state pg0 up

Jerome
De :  au nom de Brian Dickson 

Date : vendredi 23 novembre 2018 à 08:03
À : "d...@barachs.net" 
Cc : "vpp-dev@lists.fd.io" 
Objet : Re: [vpp-dev] Request: please add "real" pcap ability #vpp


On Thu, Nov 22, 2018 at 5:30 AM mailto:d...@barachs.net>> 
wrote:
Laying aside comments about folks who aren’t regular community contributors 
introducing themselves in random ways, here are a few thoughts:

We have a plan to unify pcap tracepoints when Damjan finishes reworking the 
ethernet input node.

That is very welcome news.

Is there a rough timeline for Damjan's reworking, and the unification? I just 
want to factor that into my own plans, if possible.


No matter what, pcap capture involves a bunch of data copying. The forwarding 
rate will clearly suffer. Full stop.

Yes, I fully understand that. There's no such thing as a free lunch.

In the environment in question, there's VPP hosts (doing BGP with the netlink 
and router sandbox plugins to get the routing table into VPP), and adjacent to 
them (physically upstream/downstream) we are using passive optical splitters.

Those optical splitters feed copies of traffic to capture hosts, specifically 
dedicated to packet capture and/or other integrated analysis code to be 
developed.

Our packet capture would only be using VPP without any packet forwarding, i.e. 
as a convenient way of integrating kernel offload with packet capture, and 
possibly chained with other added custom nodes.

(DPDK by itself is not really friendly for doing any kind of from-scratch 
integration, and I haven't found many/any other currently maintained open 
source packages/frameworks that offer pcap. E.g. netmap-libpcap seems 
abandoned.)

Having the ability to add other nodes in the graph, that do other stuff, 
possibly with zero copy, is another major reason we're looking at VPP.

So, pcap is the starting point, and future work might keep the pcap capability 
(assuming the ability to control whether capture is done, and the ability to 
specify pcap filter rules), and add other custom functionality.

To give you an idea, this is not consumer-grade stuff we are using; 12 or 24 
core Intel boxes (with HT, appears as 24 or 48 cores), and 128GB or 256GB of 
memory, just for packet capture, onto RAIDed SSDs.

Thanks for the info, and I'll definitely look at that extras/wireshark thing.

Brian


In master/latest, I’ve added pcap tracing – and a wireshark dissector – to the 
graph dispatch engine. See .../extras/wireshark/readme.md for more detail. The 
wireshark dissector isn’t finished by any means, nor do we have a blessed encap 
type number from tcpdump-workers, nor is the work upstreamed into wireshark.

[cid:image001.png@01D4823D.97D176D0]



From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of 
brian.peter.dick...@gmail.com
Sent: Wednesday, November 21, 2018 6:59 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Request: please add "real" pcap ability #vpp

Hi, dev folks,

Apologies for my first message being kind of demanding.

However, I think this is a reasonable request.

What I am interested in, and I think this is likely to be a fairly universal 
desire, is the ability to properly integrate some kind of pcap packet capture 
to the full VPP graph.

The current available mechanisms (pcap drop trace and pcap tx trace) do not 
apply to packets that are only "handled" by the host in question, i.e. neither 
originate or terminate on the local host.

In particular, I'm interested in something that can run on a bare metal host 
and, presuming sufficient resources can be given to it (cores, memory, etc), do 
packet capture at line rate.

Thus, any restriction ("run it on a VM") is not adequate.

Given that there is already stuff for handling the pcap file already (in 
vnet/unix IIRC), this should not be a lot of work.

There are two use cases I have:
· debugging data plane stuff on a vpp-based router (i.e. using the vppsb 
netlink and router projects)
· packet capture at line rate (a vpp host that only listens/drops traffic, 
incidental to the packet capture, i.e. a single-purpose host, bypassing 
kernel/driver limitations, to take all ethernet traffic on a port and stuff it 
into a pcap file.)
oNB: for scaling purposes, it is reasonable to implement the pcap captures 
using RSS/RFS to multiple cores and having each core be a thread doing pcap 
file writing; how that would be put into the "vpp graph" might be a little less 
than trivial, but should be straightforward, IMHO)
Thanks in advance.

Brian Dickson

P.S. There is a SERIOUS lack of useful documentation on how to actually do 
this, as a potential ad-hoc contributor. Not sure if 

[vpp-dev] runing testpmd inside vm without installing guest OS

[Damjan Marion via Lists.Fd.Io]

In case anybody is interested, this is quick way to run testpmd inside vm, for 
vhost-user testing.

No guest userspace needed, no disk image, guest kernel just runs bash script 
which starts testpmd

https://gist.github.com/dmarion/161d83165d27af7c39ab807beae4746c


-- 
Damjan

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

View/Reply Online (#11388): https://lists.fd.io/g/vpp-dev/message/11388
Mute This Topic: https://lists.fd.io/mt/28293945/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] Performance test issues : Average cpu time cost changes as the tx speed changes.

[Dave Barach via Lists.Fd.Io]

You just demonstrated one of the basic properties of vector packet processing: 
as the offered load increases, the cost per vector element decreases. Although 
you didn’t explicitly report the vector sizes involved, the vector size 
necessarily increases as the offered load increases. Anyhow, it’s easy to fish 
that that statistic out of the node runtime stats:


“clear run”

“show run”


You might ask: OK, why should the cost per packet decrease as the number of 
packets in a vector increases? When you first enter a dispatch function, none 
of the code involved is likely to be in the i-cache. The first packet incurs a 
bunch of fixed overhead to drag code into the i-cache, and to warm up the 
branch predictor. All of the other packets in the vector profit. On a 
per-packet basis, cost decreases as the vector size increases.

There are a number of secondary effects with the same net result. Until the 
vector size reaches 2, none of the graph nodes bother about prefetching. When 
dealing with quad-looped nodes: ‘s/2/4/’.

This property gives rise to a second interesting property: given a specific 
offered load and configuration, the vector size reaches a stable equilibrium. 
Imagine the circuit time in equilibrium. Add a small delay [clock interrupt at 
kernel level?] which increases the graph dispatch circuit time (rx ... process 
... tx ... repeat).

The next rx vector size will be larger, but since it will be processed more 
efficiently, the vector size will eventually return to the equilibrium value.

HTH... Dave


From: vpp-dev@lists.fd.io  On Behalf Of Mikado
Sent: Thursday, November 22, 2018 10:22 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Performance test issues : Average cpu time cost changes as 
the tx speed changes.

Hi,
Recently I’m developing a plugin based on VPP 18.07 to decode specified 
packets. I added it between dpdk-input and interface-output  using the same 
method of adding sample plugin in VPP source code. To test its performance in 
theory , I used  clib_cpu_time_now() to calculate the average cpu time cost  
when packets  go through my pulgin.When I use differnet tx speed to send 
packets to the device using VPP and my plugin , it  turns out  that the average 
cpu time changes as the tx speed changes. At frist , I assume it is caused by 
the cpu time cost when VPP moves packets to the next node. So I calculate the 
average cpu time of each node but it appears  the same.Then, I use the sample 
plugin to operate  the same test. The result is similar although it does not 
fluctuate much.
Now I’m confused. Isn’t it that all packets go through the same code and cost 
the same cpu time ?

Here is my code and test result.

Code added in sample/node.c:
static uword
sample_node_fn (vlib_main_t * vm,
  vlib_node_runtime_t * node,
  vlib_frame_t * frame)
{
  from = vlib_frame_vector_args (frame);
  n_left_from = frame->n_vectors;
  next_index = node->cached_next_index;

  sample_main.last_cpu_time = clib_cpu_time_now ();

  sample_main.total_pkts += n_left_from;
   ………
  while (n_left_from > 0){
   ………
   }
   ………
  vlib_node_increment_counter (vm, sample_node.index,
   SAMPLE_ERROR_SWAPPED, pkts_swapped);

  sample_main.total_cpu_time += clib_cpu_time_now() - sample_main.last_cpu_time;

  return frame->n_vectors;
}


Test result:
Tx speed(Mb/s)  Average cpu time
19014
47512
6659
9507
1140  7
1900  6
2895  6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

答复: 答复: [vpp-dev] about sctp

[刘道林]

Hi Macro,

OK, I will try it when I have time.

I'm reading the sctp source code and found some issues. The most critical one 
is the checksum. The sctp checksum should not include the ip header, just only 
sctp data, and also it should use crc32c, not the current code shown. Another 
important issue is the max cookie length is 20 from the macro definition. 
Actually it should not be a fixed value (usually more than 200).


Best regards
刘道林 (Daolin Liu)
T大连市共进科技有限公司
DALIAN GONGJIN TECHNOLOGY CO.,LTD
中国大连市高新园区软件园路1A-4-24层
Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
直线(TEL)：(86-411)39996705   分机(EXT)：76824
手机(Mobile)：(86)13704090959

发件人: Marco Varlese [mailto:mvarl...@suse.de]
发送时间: 2018年11月22日 20:52
收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
主题: Re: 答复: [vpp-dev] about sctp

Dear Liu,

The reason why I asked you to take a look at the "test_sctp.py" is to see how 
things are setup and execute the exact steps in the CLI. You'll see things work.

You cannot remove the MTU code because that's used to initialize the PMTU and 
calculate initially the MSS to be sent to the other peer.


Cheers,
Marco

On Wed, 2018-11-21 at 01:50 +, Liu Daolin (刘道林) wrote:

Hi Marco,



Thanks for your reply.



Actually I'm trying to read the sctp code recently to want to know how it 
works. My requirement is very simply. I need to run sctp server based on vpp on 
one VM, and run sctp client without vpp (I have this now) on the other VM. As 
my below email, there will be aborted (core dumped), and I found the place 
yesterday, but I don’t know the root reason. You can see below picture:



[cid:image001.jpg@01D4830A.123FCDF0]



The sw_if_index is -1, so crashed when get mtu. Maybe I miss something? When I 
run actually is CLI command from echo_server.c. As you mentioned, if I run 
test_sctp.py, it will work fine? My requirement is only C language as it will 
merged some other code, so I don’t like to run it with python.



Yesterday, I also try to remove this mtu code, and the crash was disappeared 
although the sw_if_index is still -1, and then I start sctp client on the other 
VM to send INIT, but the server with vpp seemed be dead (no crash but cannot 
enter any command, seemed dead loop).



Anyway, I think it's better to try CLI "test echo server" in your side and find 
and fix all issues visually.











Best regards

刘道林 (Daolin Liu)

T大连市共进科技有限公司

DALIAN GONGJIN TECHNOLOGY CO.,LTD

中国大连市高新园区软件园路1A-4-24层

Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China

直线(TEL)：(86-411)39996705   分机(EXT)：76824

手机(Mobile)：(86)13704090959



-邮件原件-
发件人: Marco Varlese [mailto:mvarl...@suse.de]
发送时间: 2018年11月21日 1:06
收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
主题: Re: [vpp-dev] about sctp



Hi,



On Tue, 2018-11-20 at 02:50 +, Liu Daolin (刘道林) wrote:

> Hi,

>

> I encountered below Aborted (core dumped) issue:

>

>

>

> When I run "test echo server uri", it's ok for tcp, but crashed immediately

> for sctp.

>

> Please try this in your side and give me advice. I use 18.10. Thanks!

Can you please try to run "make test TEST=test_sctp"?

>

>

> Best regards

> 刘道林 (Daolin Liu)

> T大连市共进科技有限公司

> DALIAN GONGJIN TECHNOLOGY CO.,LTD

> 中国大连市高新园区软件园路1A-4-24层

> Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China

> 直线(TEL)：(86-411)39996705   分机(EXT)：76824

> 手机(Mobile)：(86)13704090959

>

> 发件人: Liu Daolin (刘道林)

> 发送时间: 2018年11月19日 19:23

> 收件人: 'vpp-dev@lists.fd.io'

> 主题: about sctp

>

> Hi,

>

> I'd like to know some information about sctp.

>

> Is this fully functional? Or just partly?

There are missing pieces to the SCTP implementations.



> Actually, I want to try simply with CLI to verify sctp basic functions now.

> But it seems that there is no CLI, and the binary APIs are also imperfect.

What do you actually mean by imperfect? Any input (e.g. patch submission) would

be greatly appreciated!

>

> Do you have any plan in the next release? Including the sample test.

I am planning to create some JIRA ticket(s) so that people can see what's

missing and contribute if they like. Would you be interested?



>

> Best regards

> 刘道林 (Daolin Liu)

> T大连市共进科技有限公司

> DALIAN GONGJIN TECHNOLOGY CO.,LTD

> 中国大连市高新园区软件园路1A-4-24层

> Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China

> 直线(TEL)：(86-411)39996705   分机(EXT)：76824

> 手机(Mobile)：(86)13704090959

>

> 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、

> 阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到

> 的文本。 This e-mail may contain confidential and/or privileged information. If

> you are not the intended recipient (or have received this e-mail in error)

> please notify the sender immediately and destroy this e-mail. Any unauthorized

> copying, disclosure or distribution of the material in this e-mail is strictly

> forbidden.

> -=-=-=-=-=-=-=-=-=-=-=-

> Links: You receive all 

[vpp-dev] DHCP relay issues

[Michal Cmarada via Lists.Fd.Io]

Hi vpp devs,

After this patch in VPP: https://gerrit.fd.io/r/#/c/15759/
our DHCP relay tests started to fail. The configuration seems to be written 
correctly (same as before, commands for VPP on DUT1 in attachment), but when 
actual packet is received the vpp seems to crash. Sometimes there are 
postmortem api files generated but I haven't  seen a core dump file. VPP is 
restarted for sure. It has different PID afterwards and configuration is lost. 
What I managed to figure out is that it happens after DHCP option 82 packet is 
sent from TG to DUT1 (attached).
Topology:
#+--+ +-+ port1
#|  | port1 port3 | +--+
#| DUT1 +-+ TG  |  |
#|  +-+ +--+
#|  | port2 port4 | | port2
#+-+-+--+ +-+-+-+

The packet is sent from port3 on TG, then it passes to DUT1 where vpp is 
running and has both ports enabled and IP assigned. The other port on TG is 
running a DHCP server. VPP is set as a DHCP relay to pass the requests sent 
from port3 on TG to port4 on TG where DHCP server is running. But as I said vpp 
crashes when the packet is received. I tried to run it with "dut1 vpp 
commands.txt" configuration on clean vpp. After the same packet is sent VPP 
crashes. So this is the only configuration needed to replicate this behavior on 
such setup.
I used the script provided by CSIT to generate the packet 
https://gerrit.fd.io/r/gitweb?p=csit.git;a=blob;f=resources/traffic_scripts/dhcp/send_and_check_proxy_discover.py;h=d8089713fd10643f92d178bbe024cf4b04ed7e94;hb=refs/heads/master
The command looks like this:
sudo -S sh -c "cd ~/openvpp-testing; virtualenv --system-site-packages 
--never-download env && export PYTHONPATH=\${PWD}; . \${PWD}/env/bin/activate; 
resources/traffic_scripts/dhcp/send_and_check_proxy_messages.py --tx_if enp0s17 
--rx_if enp0s16 --server_ip 192.168.0.100 --server_mac 08:00:27:20:b0:38 
--client_ip 172.16.0.2 --client_mac 08:00:27:62:73:6e --proxy_ip 172.16.0.1"

Can someone take a look?

Thanks
Michal

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/06_standard_graphic.png]




Michal Cmarada
Engineer - Software
mcmar...@cisco.com
Tel:










Cisco Systems, Inc.



Slovakia
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.







Sending packet out of ens7 of len 286
###[ Ethernet ]###
  dst   = ff:ff:ff:ff:ff:ff
  src   = fa:16:3e:2b:11:9e
  type  = 0x800
###[ IP ]###
 version   = 4L
 ihl   = 5L
 tos   = 0x0
 len   = 272
 id= 1
 flags = 
 frag  = 0L
 ttl   = 64
 proto = udp
 chksum= 0x79dd
 src   = 0.0.0.0
 dst   = 255.255.255.255
 \options   \
###[ UDP ]###
sport = bootpc
dport = bootps
len   = 252
chksum= 0x889
###[ BOOTP ]###
   op= BOOTREQUEST
   htype = 1
   hlen  = 6
   hops  = 0
   xid   = 0
   secs  = 0
   flags = 
   ciaddr= 0.0.0.0
   yiaddr= 0.0.0.0
   siaddr= 0.0.0.0
   giaddr= 0.0.0.0
   chaddr= 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
   sname = 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
   file  = 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
   options   = 'c\x82Sc'
###[ DHCP options ]###
  options   = [message-type=discover end]
dut1:~$ sudo vppctl set int ip address GigabitEthernet0/9/0 192.168.0.1/24
dut1:~$ sudo vppctl set int state 

Re: [vpp-dev] Regarding page table address NULL in dpdk_pool_create

[Alok Makhariya]

Thanks Damjan. 

Regards
Alok

-Original Message-
From: Damjan Marion  
Sent: 23 November 2018 15:03
To: Alok Makhariya 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding page table address NULL in dpdk_pool_create

> 
> On 22 Nov 2018, at 10:55, Alok Makhariya  wrote:
> 
> Hi
>  
> I have a situation where in some scenarios when VPP is restarted after a 
> crash, the VPP which is coming up itself crashes with the following backtrace.
> This does not happen always. Any hints on what could cause this would be 
> appreciated.
>  
> Backtrace
>  
> (gdb) bt
> #0  0x2b688139c207 in raise () from /lib64/libc.so.6
> #1  0x2b688139d8f8 in abort () from /lib64/libc.so.6
> #2  0x00405f7e in os_exit (code=code@entry=1) at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:292
> #3  0x2b687f4b09d7 in unix_signal_handler (signum=, 
> si=, uc=)
> at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/vlib/unix/main.c:120
> #4  
> #5  rte_mempool_populate_iova_tab (mp=mp@entry=0x1098fbec0, 
> vaddr=0x2ac0 "", iova=0x0, pg_num=, 
> pg_shift=, free_cb=free_cb@entry=0x0, opaque=opaque@entry=0x0)
> at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-root/build-vpp-native/dpdk/dpdk-stable-17.
> 11.4/lib/librte_mempool/rte_mempool.c:486
> #6  0x2b6b0212a373 in dpdk_pool_create (vm=vm@entry=0x2b687f6cb260 
> , pool_name=pool_name@entry=0x2b6883a0d924 
> "dpdk_mbuf_pool_socket0", elt_size=elt_size@entry=2432, 
> num_elts=num_elts@entry=50, 
> pool_priv_size=pool_priv_size@entry=6, cache_size=cache_size@entry=512, 
> numa=numa@entry=0 '\000', _mp=_mp@entry=0x2b6884266c68, 
> pri=pri@entry=0x2b6884266c5f "")
> at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/plugins/dpdk/buffer.c:498
> #7  0x2b6b0212a470 in dpdk_buffer_pool_create (vm=vm@entry=0x2b687f6cb260 
> , num_mbufs=50, socket_id=0)
> at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/plugins/dpdk/buffer.c:537
> #8  0x2b6b02144861 in dpdk_config (vm=, input= out>)
> at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/plugins/dpdk/device/init.c:128
> 8
> #9  0x2b687f4715ad in vlib_call_all_config_functions (vm=, 
> input=input@entry=0x2b6884266fa0, is_early=is_early@entry=0)
> at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/vlib/init.c:146
> #10 0x2b687f479908 in vlib_main (vm=vm@entry=0x2b687f6cb260 
> , input=input@entry=0x2b6884266fa0)
> at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1772
> #11 0x2b687f4b0b23 in thread0 (arg=47727814423136) at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/vlib/unix/main.c:567
> #12 0x2b68807e38b8 in clib_calljmp () at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/vppinfra/longjmp.S:110
> #13 0x7ffe03c4a0e0 in ?? ()
> #14 0x2b687f4b187f in vlib_unix_main (argc=, 
> argv=) at 
> /bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/thi
> rd-party/vpp/vpp_1801/build-data/../src/vlib/unix/main.c:631
> #15 0x6f2d326c0028 in ?? ()
> #16 0x6c632d7475707475 in ?? ()
> #17 0x4c20796669737361 in ?? ()
> #18 0x697373616c432032 in ?? ()
> #19 0x73706f7244207966 in ?? ()
> #20 0x6425203a in ?? ()
> #21 0x in ?? ()
>  
>  
> VPP version: 18.01

Please move to recent version of vpp 18.01 is not supported anymore.


>  
> After analysing back-trace, it is observed that in 
> rte_mempool_populate_iova_tab iova address is NULL which is called by 
> dpdk_pool_create passing pr->page_table addr as iova address.
> pr : vlib_physmem_region_t *pr;
> Before calling rte_mempool_populate_iova_tab, vlib_physmem_region_alloc is 
> called which internally calls vm->os_physmem_region_alloc.
>  
> vm->os_physmem_region_alloc  is mapped to unix_physmem_region_alloc.
> So in unix_physmem_region_alloc,
> pr->page_table = clib_mem_vm_get_paddr (pr->mem, pr->log2_page_size, 
> pr->pr->n_pages);
> Looks like clib_mem_vm_get_paddr is returning NULL to page table address.
>  
> Code for clib_mem_vm_get_paddr function
> u64 *
> clib_mem_vm_get_paddr (void *mem, int log2_page_size, int n_pages) {
>   int pagesize = sysconf (_SC_PAGESIZE);
>   int fd;
>   int i;
>   u64 *r = 0;
>  
>   if ((fd = open ((char *) "/proc/self/pagemap", O_RDONLY)) == -1)
> return 0;
>  
>   for (i = 0; i < n_pages; i++)
> {
>   u64 seek, 

Re: 答复: 答复: [vpp-dev] about sctp

[Marco Varlese]

On Fri, 2018-11-23 at 00:57 +, Liu Daolin (刘道林) wrote:
> Hi Macro,
>  
> OK, I will try it when I have time.
Well, as you wish.

> 
> I'm reading the sctp source code and found some issues. The most critical one
> is the checksum. The sctp checksum should not include the ip header, just only
> sctp data, and also it should use crc32c, not the current code shown. 
I am not sure what you refer to with "code shown". 
However the crc calculated is indeed the one you mention and it's using SSE4
instructions which are exactly using the polynomial depicted by RFC 4960.

> Another important issue is the max cookie length is 20 from the macro
> definition. Actually it should not be a fixed value (usually more than 200).
So I cannot find a definition for the actual length of the cookie.
It would help if you could point to the actual filename / definition when
reporting issues.

>  
>  
> Best regards
> 刘道林 (Daolin Liu)
> T大连市共进科技有限公司
> DALIAN GONGJIN TECHNOLOGY CO.,LTD
> 中国大连市高新园区软件园路1A-4-24层
> Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> 直线(TEL)：(86-411)39996705   分机(EXT)：76824
> 手机(Mobile)：(86)13704090959
>  
> 发件人: Marco Varlese [mailto:mvarl...@suse.de] 
> 发送时间: 2018年11月22日 20:52
> 收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
> 主题: Re: 答复: [vpp-dev] about sctp
>  
> Dear Liu,
>  
> The reason why I asked you to take a look at the "test_sctp.py" is to see how
> things are setup and execute the exact steps in the CLI. You'll see things
> work.
>  
> You cannot remove the MTU code because that's used to initialize the PMTU and
> calculate initially the MSS to be sent to the other peer.
>  
>  
> Cheers,
> Marco
>  
> On Wed, 2018-11-21 at 01:50 +, Liu Daolin (刘道林) wrote:
> > Hi Marco,
> >  
> > Thanks for your reply.
> >  
> > Actually I'm trying to read the sctp code recently to want to know how it
> > works. My requirement is very simply. I need to run sctp server based on vpp
> > on one VM, and run sctp client without vpp (I have this now) on the other
> > VM. As my below email, there will be aborted (core dumped), and I found the
> > place yesterday, but I don’t know the root reason. You can see below
> > picture:
> >  
> > 
> >  
> > The sw_if_index is -1, so crashed when get mtu. Maybe I miss something? When
> > I run actually is CLI command from echo_server.c. As you mentioned, if I run
> > test_sctp.py, it will work fine? My requirement is only C language as it
> > will merged some other code, so I don’t like to run it with python.
> >  
> > Yesterday, I also try to remove this mtu code, and the crash was disappeared
> > although the sw_if_index is still -1, and then I start sctp client on the
> > other VM to send INIT, but the server with vpp seemed be dead (no crash but
> > cannot enter any command, seemed dead loop).
> >  
> > Anyway, I think it's better to try CLI "test echo server" in your side and
> > find and fix all issues visually.
> >  
> >  
> >  
> >  
> >  
> > Best regards
> > 刘道林 (Daolin Liu)
> > T大连市共进科技有限公司
> > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > 中国大连市高新园区软件园路1A-4-24层
> > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> > 直线(TEL)：(86-411)39996705   分机(EXT)：76824
> > 手机(Mobile)：(86)13704090959
> >  
> > -邮件原件-
> > 发件人: Marco Varlese [mailto:mvarl...@suse.de] 
> > 发送时间: 2018年11月21日 1:06
> > 收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
> > 主题: Re: [vpp-dev] about sctp
> >  
> > Hi,
> >  
> > On Tue, 2018-11-20 at 02:50 +, Liu Daolin (刘道林) wrote:
> > > Hi,
> > > 
> > > I encountered below Aborted (core dumped) issue:
> > > 
> > >
> > > 
> > > When I run "test echo server uri", it's ok for tcp, but crashed
> > immediately
> > > for sctp.
> > > 
> > > Please try this in your side and give me advice. I use 18.10. Thanks!
> > Can you please try to run "make test TEST=test_sctp"?
> > > 
> > > 
> > > Best regards
> > > 刘道林 (Daolin Liu)
> > > T大连市共进科技有限公司
> > > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > > 中国大连市高新园区软件园路1A-4-24层
> > > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> > > 直线(TEL)：(86-411)39996705   分机(EXT)：76824
> > > 手机(Mobile)：(86)13704090959
> > > 
> > > 发件人: Liu Daolin (刘道林)
> > > 发送时间: 2018年11月19日 19:23
> > > 收件人: 'vpp-dev@lists.fd.io'
> > > 主题: about sctp
> > > 
> > > Hi,
> > > 
> > > I'd like to know some information about sctp.
> > > 
> > > Is this fully functional? Or just partly?
> > There are missing pieces to the SCTP implementations.
> >  
> > > Actually, I want to try simply with CLI to verify sctp basic functions
> > now.
> > > But it seems that there is no CLI, and the binary APIs are also imperfect.
> > What do you actually mean by imperfect? Any input (e.g. patch submission)
> > would
> > be greatly appreciated!
> > > 
> > > Do you have any plan in the next release? Including the sample test.
> > I am planning to create some JIRA ticket(s) so that people can see what's
> > missing and contribute if they like. Would you be interested?
> >  
> > > 
> > > Best