date:20190108

Re: [vpp-dev] wwan0 intarface - vpp

2019-01-08 Thread Dave Barach via Lists.Fd.Io

+1. You can put the [linux kernel] wireless interface into a Linux bridge with 
a vpp tap-v2 interface. Performance might not be much to write home about...

D.

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Tuesday, January 8, 2019 12:13 PM
To: amitmulay...@gmail.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] wwan0 intarface - vpp




On 7 Jan 2019, at 16:03, amitmulay...@gmail.com 
wrote:

Hello all , im new to vpp and just started to reseach about it

i was wandering regarding an issue , i want that the vpp will recognaize in his 
port list
a wwan0 intarface (wifi) that i have in the linux device.
it has its own pci address ,i can see it under sudo lshw -class network -businfo
pci@:01:00.0  wlan0  networkQCA986x/988x 
802.11ac Wireless Network A

but the vpp dosent "take it"

can i make it happen?

We don't support wireless NICs and AFAIK there is no user mode drivers 
available for wireless NICs.
--
Damjan

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

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

[vpp-dev] Reminder: VPP Release 19.01 F0 is ~18 hours away.

2019-01-08 Thread Andrew Yourtchenko

Hi all,

just a kind reminder - the F0 (the API freeze) is 9 January.

As discussed during today's community call, the time "T" for the
milestones is 18:00 UTC.

This means we have approximately 18 hours 40 minutes remaining until
this first milestone, at which we close the master branch for the new
feature/risky commits and API changes. Only low-risk changes will be
accepted on the main branch.

The schedule for the milestones is at
https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_19.01
- there is still very few features mentioned there - so please feel
free to update the page with your data.

Thanks a lot!

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

View/Reply Online (#11873): https://lists.fd.io/g/vpp-dev/message/11873
Mute This Topic: https://lists.fd.io/mt/28978425/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 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

2019-01-08 Thread Anthony Linz

Dear Dave,
Thank you very much for your great and exact response.
The program now works like a dream.
Best wishes,
--
Anthony
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11875): https://lists.fd.io/g/vpp-dev/message/11875
Mute This Topic: https://lists.fd.io/mt/28972181/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #binapi: https://lists.fd.io/mk?hashtag=binapi=1480452
Mute #vppcapi: https://lists.fd.io/mk?hashtag=vppcapi=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] wwan0 intarface - vpp

2019-01-08 Thread Jim Thompson


There is a DPDK driver for Atheros 10K NICs (the QCA986x/988x is Ath 10k). 

https://github.com/telematik-tu-ilmenau/DPDK-WiFi 
  (specifically 
/drivers/net/ath10k, written for DPDK 17.10)

I don’t know anything about the quality or performance of this driver.   VPP 
would also need to know how to configure and monitor this NIC.
Seems like a lot of work for minimal gains, so Dave’ suggestion of bridging 
into a tap-v2 interface is likely to provide more immediate results.

As for performance of same, anyone looking for > circa 600Mbps with wireless is 
smoking something interesting.  Pretty sure tap-v2 can pass that.

Jim



> On Jan 8, 2019, at 1:57 PM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> +1. You can put the [linux kernel] wireless interface into a Linux bridge 
> with a vpp tap-v2 interface. Performance might not be much to write home 
> about...
>  
> D. 
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of Damjan Marion via Lists.Fd.Io
> Sent: Tuesday, January 8, 2019 12:13 PM
> To: amitmulay...@gmail.com 
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] wwan0 intarface - vpp
>  
>  
> 
> 
> On 7 Jan 2019, at 16:03, amitmulay...@gmail.com 
>  wrote:
>  
> Hello all , im new to vpp and just started to reseach about it
> 
> i was wandering regarding an issue , i want that the vpp will recognaize in 
> his port list
> a wwan0 intarface (wifi) that i have in the linux device.
> it has its own pci address ,i can see it under sudo lshw -class network 
> -businfo
> pci@:01:00.0   wlan0  network
> QCA986x/988x 802.11ac Wireless Network A
> 
> but the vpp dosent "take it"
> 
> can i make it happen? 
>  
> We don't support wireless NICs and AFAIK there is no user mode drivers 
> available for wireless NICs.
> 
> -- 
> Damjan
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11872): https://lists.fd.io/g/vpp-dev/message/11872 
> 
> Mute This Topic: https://lists.fd.io/mt/28963384/675164 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [j...@netgate.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#11874): https://lists.fd.io/g/vpp-dev/message/11874
Mute This Topic: https://lists.fd.io/mt/28963384/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 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

2019-01-08 Thread Dave Barach via Lists.Fd.Io

As usual, I’m off by a few characters. Sorry about that... See 
.../src/vppinfra/mem.h:

void *clib_mem_init (void *heap, uword size);
or
void *clib_mem_init_thread_safe (void *memory, uword memory_size);

From: vpp-dev@lists.fd.io  On Behalf Of Anthony Linz
Sent: Tuesday, January 8, 2019 8:08 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp 
#vppcapi

Dear Dave,
Thanks for you reply.
I could not find "clib_memory_init()" in vpp.
Did you mean "vlibmemory_init()"?
If yes where and how in my code I should use it?
Thanks
--
Anthony
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11870): https://lists.fd.io/g/vpp-dev/message/11870
Mute This Topic: https://lists.fd.io/mt/28972181/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #binapi: https://lists.fd.io/mk?hashtag=binapi=1480452
Mute #vppcapi: https://lists.fd.io/mk?hashtag=vppcapi=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] Seeing a VPP crash in timing wheel..

2019-01-08 Thread shawsunshow

I encountered the same problem on the VPP16.09 version. I also saw another 
question on the link: 
https://jira.fd.io/browse/VPP-153?jql=text%20~%20%22timing_wheel_insert%22%20ORDER%20BY%20lastViewed%20ASC
Someone gave the answer, but did not understand why it was done? And why is 
this happening? What is the nature of the problem? Has the problem been 
resolved in VPP19.01?
The implementation of VPP16.09 is as follows:
void clib_time_verify_frequency (clib_time_t * c)
{
  f64 now_reference = unix_time_now ();
  f64 dtr = now_reference - c->last_verify_reference_time;
  f64 dtr_max;
  u64 dtc = c->last_cpu_time - c->last_verify_cpu_time;
  f64 round_units = 100e5;
  c->last_verify_cpu_time = c->last_cpu_time;
  c->last_verify_reference_time = now_reference;
  /* 
   * Is the reported reference interval non-positive, 
   * or off by a factor of two - or 8 seconds - whichever is larger? 
   * Someone reset the clock behind our back.
   */
  dtr_max = (f64)(2ULL 8.0 ? dtr_max : 8.0;
  if (dtr <= 0.0 || dtr > dtr_max)
    {
  c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
  return;
    }
  c->clocks_per_second = flt_round_nearest ((f64) dtc / (dtr * round_units)) * 
round_units;
  c->seconds_per_clock = 1 / c->clocks_per_second;
  /* Double time between verifies; max at 64 secs ~ 1 minute. */
  if (c->log2_clocks_per_frequency_verify < c->log2_clocks_per_second + 6)
    c->log2_clocks_per_frequency_verify += 1;
}

The implementation of VPP18.01 is as follows:
clib_time_verify_frequency (clib_time_t * c)
{
  f64 now_reference = unix_time_now ();
  f64 dtr = now_reference - c->last_verify_reference_time;
  f64 dtr_max;
  u64 dtc = c->last_cpu_time - c->last_verify_cpu_time;
  f64 new_clocks_per_second, delta;
  c->last_verify_cpu_time = c->last_cpu_time;
  c->last_verify_reference_time = now_reference;
  /*
   * Is the reported reference interval non-positive,
   * or off by a factor of two - or 8 seconds - whichever is larger?
   * Someone reset the clock behind our back.
   */
  dtr_max = (f64) (2ULL << c->log2_clocks_per_frequency_verify) /
    (f64) (1ULL << c->log2_clocks_per_second);
  dtr_max = dtr_max > 8.0 ? dtr_max : 8.0;
  if (dtr <= 0.0 || dtr > dtr_max)
    {
  c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
  return;
    }
  if (PREDICT_FALSE (c->round_to_units == 0.0))
    {
  f64 next_pow10, est_round_to_units;
  /*
   * Compute the first power of ten which is greater than
   * 0.1% of the new clock rate. Save the result, and use it
   * to round future results, so we don't end up calculating
   * silly-looking clock rates.
   */
  est_round_to_units = ((f64) dtc / dtr) * 0.001;
  next_pow10 = ceil (log10 (est_round_to_units));
  c->round_to_units = pow (10.0, next_pow10);
    }
  /*
   * Reject large frequency changes, another consequence of
   * system clock changes particularly with old kernels.
   */
  new_clocks_per_second =
    flt_round_nearest ((f64) dtc / (dtr * c->round_to_units))
    * c->round_to_units;
  delta = new_clocks_per_second - c->clocks_per_second;
  if (delta < 0.0)
    delta = -delta;
  if (PREDICT_FALSE ((delta / c->clocks_per_second) > .01))
    {
  clib_warning ("Rejecting large frequency change of %.2f%%",
  (delta / c->clocks_per_second) * 100.0);
  c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
  return;
    }
  c->clocks_per_second =
    flt_round_nearest ((f64) dtc / (dtr * c->round_to_units))
    * c->round_to_units;
  c->seconds_per_clock = 1 / c->clocks_per_second;
  /* Double time between verifies; max at 64 secs ~ 1 minute. */
  if (c->log2_clocks_per_frequency_verify < c->log2_clocks_per_second + 6)
    c->log2_clocks_per_frequency_verify += 1;
}

Note:I don't understand the difference between the two, and whether such a 
change will solve this problem?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11862): https://lists.fd.io/g/vpp-dev/message/11862
Mute This Topic: https://lists.fd.io/mt/10640607/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] wwan0 intarface - vpp

2019-01-08 Thread Damjan Marion via Lists.Fd.Io



> On 7 Jan 2019, at 16:03, amitmulay...@gmail.com wrote:
> 
> Hello all , im new to vpp and just started to reseach about it
> 
> i was wandering regarding an issue , i want that the vpp will recognaize in 
> his port list
> a wwan0 intarface (wifi) that i have in the linux device.
> it has its own pci address ,i can see it under sudo lshw -class network 
> -businfo
> pci@:01:00.0  wlan0  networkQCA986x/988x 802.11ac Wireless 
> Network A
> 
> but the vpp dosent "take it"
> 
> can i make it happen? 

We don't support wireless NICs and AFAIK there is no user mode drivers 
available for wireless NICs.

-- 
Damjan

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

View/Reply Online (#11871): https://lists.fd.io/g/vpp-dev/message/11871
Mute This Topic: https://lists.fd.io/mt/28963384/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] :: GRE tunnel dropping MPLS packets

2019-01-08 Thread Neale Ranns via Lists.Fd.Io


Hi Omer,

Your config looks OK. I would start debugging with a packet trace.

/neale


De :  au nom de Omer Majeed 
Date : lundi 7 janvier 2019 à 20:47
À : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] :: GRE tunnel dropping MPLS packets

Hi,

I'm running VPP on Centos 7 machine (say machine A), and running an application 
on other centos 7 machine (say machine B).
I've made a GRE tunnel between those 2 machines.

vpp# show gre tunnel
[0] instance 0 src 192.168.17.10 dst 192.168.17.6 fib-idx 0 sw-if-idx 8 payload 
L3

Made that gre0 interface mpls enabled.
I added outgoing mpls routes in VPP for IPs on machine B

vpp# show ip fib table 2
192.168.100.4/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:47 buckets:1 uRPF:49 to:[0:0]]
[0] [@10]: mpls-label[2]:[25:64:0:eos]
[@1]: mpls via 0.0.0.0 gre0: mtu:9000 
4500fe2f196ec0a8110ac0a811068847
  stacked-on:
[@3]: ipv4 via 192.168.17.6 loop9000: mtu:9000 
ac1f6b20498fdead00280800
192.168.100.5/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:46 buckets:1 uRPF:47 to:[0:0]]
[0] [@10]: mpls-label[0]:[30:64:0:eos]
[@1]: mpls via 0.0.0.0 gre0: mtu:9000 
4500fe2f196ec0a8110ac0a811068847
  stacked-on:
[@3]: ipv4 via 192.168.17.6 loop9000: mtu:9000 
ac1f6b20498fdead00280800

For reverse traffic I've added MPLS routes given below

vpp# show mpls fib table 0
18:eos/21 fib:0 index:29 locks:2
  src:API refs:1 entry-flags:uRPF-exempt, src-flags:added,contributing,active,
path-list:[35] locks:20 flags:shared, uPRF-list:31 len:0 itfs:[]
  path:[35] pl-index:35 ip4 weight=1 pref=0 deag:  oper-flags:resolved,
[@0]: dst-address,unicast lookup in ipv4-VRF:2

 forwarding:   mpls-eos-chain
  [@0]: dpo-load-balance: [proto:mpls index:32 buckets:1 uRPF:32 to:[0:0]]
[0] [@6]: mpls-disposition:[0]:[ip4, pipe]
[@7]: dst-address,unicast lookup in ipv4-VRF:2
19:eos/21 fib:0 index:38 locks:2
  src:API refs:1 entry-flags:uRPF-exempt, src-flags:added,contributing,active,
path-list:[35] locks:20 flags:shared, uPRF-list:31 len:0 itfs:[]
  path:[35] pl-index:35 ip4 weight=1 pref=0 deag:  oper-flags:resolved,
[@0]: dst-address,unicast lookup in ipv4-VRF:2

 forwarding:   mpls-eos-chain
  [@0]: dpo-load-balance: [proto:mpls index:41 buckets:1 uRPF:41 to:[0:0]]
[0] [@6]: mpls-disposition:[9]:[ip4, pipe]
[@7]: dst-address,unicast lookup in ipv4-VRF:2

When I try to ping from machine B to an IP in machine B (VPP VRF 2) through 
that GRE tunnel, I receive packets but GRE tunnel drops the packets.
vpp# show int gre0
Name   Idx   State  Counter  Count
gre0  8 up   rx packets
66
 rx bytes   
   6996
 drops  
  66
 (nil)  
 66

Is there anything else that needs to be done to get MPLS over GRE working?
Any suggestions on how to debug the issue?

Thanks a lot.
Best Regards,
Omer
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11864): https://lists.fd.io/g/vpp-dev/message/11864
Mute This Topic: https://lists.fd.io/mt/28966281/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 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

2019-01-08 Thread Anthony Linz

Hi
Recently I tried to learn VPP's C API and I found a sample C program in 
https://www.marosmars.com/blog/managing-vpp-c-edition blog.
I have compiled the program like this:
gcc myprog.c -o myprog -lvppinfra -lvlibmemoryclient -lsvm
and it has been compiled successfully.
The problem is that when I try to run the program I will get segmentation fault 
like this:

program received signal SIGSEGV, Segmentation fault.
mspace_malloc (msp=0x0, bytes=bytes@entry=20) at 
/root/vpp/src/vppinfra/dlmalloc.c:4338
warning: Source file is more recent than executable.
4338  if (!PREACTION(ms)) {

And the back trace looks pretty like this:

#0  mspace_malloc (msp=0x0, bytes=bytes@entry=20) at 
/root/vpp/src/vppinfra/dlmalloc.c:4338
#1  0x77bb9308 in mspace_get_aligned (msp=0x0, n_user_data_bytes=20, 
n_user_data_bytes@entry=16, align=align@entry=8, 
    align_offset=align_offset@entry=8) at /root/vpp/src/vppinfra/dlmalloc.c:4177
#2  0x77bae5f8 in clib_mem_alloc_aligned_at_offset 
(os_out_of_memory_on_failure=1, align_offset=8, align=8, size=16)
    at /root/vpp/src/vppinfra/mem.h:118
#3  vec_resize_allocate_memory (v=v@entry=0x0, 
length_increment=length_increment@entry=8, data_bytes=16, 
header_bytes=, header_bytes@entry=0, 
    data_align=data_align@entry=8) at /root/vpp/src/vppinfra/vec.c:59
#4  0x77b549a6 in _vec_resize_inline (data_align=, 
header_bytes=, data_bytes=, 
    length_increment=, v=) at 
/root/vpp/src/vppinfra/vec.h:147
#5  va_format (s=0x0, fmt=, va=va@entry=0x7fffe228) at 
/root/vpp/src/vppinfra/format.c:403
#6  0x77b548f7 in format (s=s@entry=0x0, fmt=fmt@entry=0x77929a4c 
"/dev/shm%s%c") at /root/vpp/src/vppinfra/format.c:423
#7  0x7791e524 in vl_map_shmem (region_name=0xc7a2 "/vpe-api", 
is_vlib=is_vlib@entry=0) at /root/vpp/src/vlibmemory/memory_shared.c:544
#8  0x7791f8cb in vl_client_api_map (region_name=) at 
/root/vpp/src/vlibmemory/memory_client.c:389
#9  0x7791f90c in connect_to_vlib_internal (svm_name=, 
client_name=0xcae9 "test", rx_queue_size=32, want_pthread=1, 
    do_map=) at /root/vpp/src/vlibmemory/memory_client.c:416
#10 0x74c6 in connect_to_vpe ()
#11 0x9261 in main () 

My Operating System is Ubuntu 18.04.01 and I have tested this on Ubuntu 16.04 
as well with the same result.
I was wondering if anyone could help me with the problem.
Thanks in advance for your help,
Best regards
--
Anthony
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11863): https://lists.fd.io/g/vpp-dev/message/11863
Mute This Topic: https://lists.fd.io/mt/28972181/21656
Mute #binapi: https://lists.fd.io/mk?hashtag=binapi=1480452
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #vppcapi: https://lists.fd.io/mk?hashtag=vppcapi=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] An 'ip route' question

2019-01-08 Thread Neale Ranns via Lists.Fd.Io


Hi Jon.

In all cases it refers to the table related to the path (not the prefix). A 
path determines where to send the packet and is described by all keywords after 
the ‘via’ keyword.
The two use cases you mention would be:
   Ip route add table  10.1.1.0/24 via 20.20.20.20 next-hop-table  
out-labels 55
This is a typical MPLS VPN route. The prefix 10.1.1.0/24 is added to table 
 and the peer to which the traffic is forwarded is 20.20.20.20 known in 
the  table.
For the other case:
   mpls route add 55 eos ip4-lookup-in-table 
The returning MPLS packets with label 55 have the label popped and an IP lookup 
is performed on the exposed IP packet in table . In this case 
‘ip4-lookup-in-table’ specifies both that the exposed packet is IPv4 and the 
table to use (so that’s next_hop_table_id and next_hop_proto in the API 
message). There are IPv6 and MPLS equivalent keywords.

When it comes to API programming, these are different ways of setting the same 
next_hop_table_id field in the message.

Regards,
Neale



De :  au nom de Jon Loeliger 
Date : lundi 7 janvier 2019 à 18:43
À : vpp-dev 
Objet : [vpp-dev] An 'ip route' question

Neale,

I have a question about the API field 'next_hop_table_id' within the
API call ip_add_del_route.  (There isn't a doc string for this field in
the API file, so guessing a bit.)  Is this field the same field for both
the CLI options 'next-hop-table' and 'ip4-lookup-in-table'?  Is there
a conceptual difference between these two CLI options, or are they
just different words for setting the same API field?  Is this merely
a mechanism for specifying the IPv[46] proto when an IP address
is not available to specify the proto?  (Also, note, CLI keyword
'lookup-in-vrf' as well.)

Thanks,
jdl


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

View/Reply Online (#11865): https://lists.fd.io/g/vpp-dev/message/11865
Mute This Topic: https://lists.fd.io/mt/28965063/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] Seeing a VPP crash in timing wheel..

2019-01-08 Thread Dave Barach via Lists.Fd.Io

This bit of code works on the problem that either NTP or a privileged user can 
cause the kernel’s idea of “now” to change by a large amount, and we don’t want 
to break vpp’s idea of the cpu tick rate as a result.

As far as I know, folks haven’t seen problems in this area for a long time. The 
Jira ticket you mention should have been closed ages ago.

The code base is quite different than it was more than two years ago. As of 
this writing, we don’t support 16.09. I would hesitate to make any suggestions 
other than to rebase and see what happens.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of shawsuns...@163.com
Sent: Tuesday, January 8, 2019 3:17 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Seeing a VPP crash in timing wheel..

I encountered the same problem on the VPP16.09 version. I also saw another 
question on the link:
https://jira.fd.io/browse/VPP-153?jql=text%20~%20%22timing_wheel_insert%22%20ORDER%20BY%20lastViewed%20ASC
Someone gave the answer, but did not understand why it was done? And why is 
this happening? What is the nature of the problem? Has the problem been 
resolved in VPP19.01?
The implementation of VPP16.09 is as follows:
void clib_time_verify_frequency (clib_time_t * c)
{
  f64 now_reference = unix_time_now ();
  f64 dtr = now_reference - c->last_verify_reference_time;
  f64 dtr_max;
  u64 dtc = c->last_cpu_time - c->last_verify_cpu_time;
  f64 round_units = 100e5;
  c->last_verify_cpu_time = c->last_cpu_time;
  c->last_verify_reference_time = now_reference;
  /*
   * Is the reported reference interval non-positive,
   * or off by a factor of two - or 8 seconds - whichever is larger?
   * Someone reset the clock behind our back.
   */
  dtr_max = (f64)(2ULL 8.0 ? dtr_max : 8.0;
  if (dtr <= 0.0 || dtr > dtr_max)
{
  c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
  return;
}
  c->clocks_per_second = flt_round_nearest ((f64) dtc / (dtr * round_units)) * 
round_units;
  c->seconds_per_clock = 1 / c->clocks_per_second;
  /* Double time between verifies; max at 64 secs ~ 1 minute. */
  if (c->log2_clocks_per_frequency_verify < c->log2_clocks_per_second + 6)
c->log2_clocks_per_frequency_verify += 1;
}

The implementation of VPP18.01 is as follows:
clib_time_verify_frequency (clib_time_t * c)
{
  f64 now_reference = unix_time_now ();
  f64 dtr = now_reference - c->last_verify_reference_time;
  f64 dtr_max;
  u64 dtc = c->last_cpu_time - c->last_verify_cpu_time;
  f64 new_clocks_per_second, delta;
  c->last_verify_cpu_time = c->last_cpu_time;
  c->last_verify_reference_time = now_reference;
  /*
   * Is the reported reference interval non-positive,
   * or off by a factor of two - or 8 seconds - whichever is larger?
   * Someone reset the clock behind our back.
   */
  dtr_max = (f64) (2ULL << c->log2_clocks_per_frequency_verify) /
(f64) (1ULL << c->log2_clocks_per_second);
  dtr_max = dtr_max > 8.0 ? dtr_max : 8.0;
  if (dtr <= 0.0 || dtr > dtr_max)
{
  c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
  return;
}
  if (PREDICT_FALSE (c->round_to_units == 0.0))
{
  f64 next_pow10, est_round_to_units;
  /*
   * Compute the first power of ten which is greater than
   * 0.1% of the new clock rate. Save the result, and use it
   * to round future results, so we don't end up calculating
   * silly-looking clock rates.
   */
  est_round_to_units = ((f64) dtc / dtr) * 0.001;
  next_pow10 = ceil (log10 (est_round_to_units));
  c->round_to_units = pow (10.0, next_pow10);
}
  /*
   * Reject large frequency changes, another consequence of
   * system clock changes particularly with old kernels.
   */
  new_clocks_per_second =
flt_round_nearest ((f64) dtc / (dtr * c->round_to_units))
* c->round_to_units;
  delta = new_clocks_per_second - c->clocks_per_second;
  if (delta < 0.0)
delta = -delta;
  if (PREDICT_FALSE ((delta / c->clocks_per_second) > .01))
{
  clib_warning ("Rejecting large frequency change of %.2f%%",
  (delta / c->clocks_per_second) * 100.0);
  c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
  return;
}
  c->clocks_per_second =
flt_round_nearest ((f64) dtc / (dtr * c->round_to_units))
* c->round_to_units;
  c->seconds_per_clock = 1 / c->clocks_per_second;
  /* Double time between verifies; max at 64 secs ~ 1 minute. */
  if (c->log2_clocks_per_frequency_verify < c->log2_clocks_per_second + 6)
c->log2_clocks_per_frequency_verify += 1;
}

Note:I don't understand the difference between the two, and whether such a 
change will solve this problem?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11866): https://lists.fd.io/g/vpp-dev/message/11866
Mute This Topic: https://lists.fd.io/mt/10640607/21656
Group Owner: vpp-dev+ow...@lists.fd.io

Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

2019-01-08 Thread Dave Barach via Lists.Fd.Io

Looks like a missing call to clib_memory_init(...). Note mspace=0...

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Anthony Linz
Sent: Tuesday, January 8, 2019 4:44 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

Hi
Recently I tried to learn VPP's C API and I found a sample C program in 
https://www.marosmars.com/blog/managing-vpp-c-edition blog.
I have compiled the program like this:
gcc myprog.c -o myprog -lvppinfra -lvlibmemoryclient -lsvm
and it has been compiled successfully.
The problem is that when I try to run the program I will get segmentation fault 
like this:
program received signal SIGSEGV, Segmentation fault.
mspace_malloc (msp=0x0, bytes=bytes@entry=20) at 
/root/vpp/src/vppinfra/dlmalloc.c:4338
warning: Source file is more recent than executable.
4338   if (!PREACTION(ms)) {

And the back trace looks pretty like this:
#0  mspace_malloc (msp=0x0, bytes=bytes@entry=20) at 
/root/vpp/src/vppinfra/dlmalloc.c:4338
#1  0x77bb9308 in mspace_get_aligned (msp=0x0, n_user_data_bytes=20, 
n_user_data_bytes@entry=16, align=align@entry=8,
align_offset=align_offset@entry=8) at /root/vpp/src/vppinfra/dlmalloc.c:4177
#2  0x77bae5f8 in clib_mem_alloc_aligned_at_offset 
(os_out_of_memory_on_failure=1, align_offset=8, align=8, size=16)
at /root/vpp/src/vppinfra/mem.h:118
#3  vec_resize_allocate_memory (v=v@entry=0x0, 
length_increment=length_increment@entry=8, data_bytes=16, 
header_bytes=, header_bytes@entry=0,
data_align=data_align@entry=8) at /root/vpp/src/vppinfra/vec.c:59
#4  0x77b549a6 in _vec_resize_inline (data_align=, 
header_bytes=, data_bytes=,
length_increment=, v=) at 
/root/vpp/src/vppinfra/vec.h:147
#5  va_format (s=0x0, fmt=, va=va@entry=0x7fffe228) at 
/root/vpp/src/vppinfra/format.c:403
#6  0x77b548f7 in format (s=s@entry=0x0, fmt=fmt@entry=0x77929a4c 
"/dev/shm%s%c") at /root/vpp/src/vppinfra/format.c:423
#7  0x7791e524 in vl_map_shmem (region_name=0xc7a2 "/vpe-api", 
is_vlib=is_vlib@entry=0) at /root/vpp/src/vlibmemory/memory_shared.c:544
#8  0x7791f8cb in vl_client_api_map (region_name=) at 
/root/vpp/src/vlibmemory/memory_client.c:389
#9  0x7791f90c in connect_to_vlib_internal (svm_name=, 
client_name=0xcae9 "test", rx_queue_size=32, want_pthread=1,
do_map=) at /root/vpp/src/vlibmemory/memory_client.c:416
#10 0x74c6 in connect_to_vpe ()
#11 0x9261 in main ()

My Operating System is Ubuntu 18.04.01 and I have tested this on Ubuntu 16.04 
as well with the same result.
I was wondering if anyone could help me with the problem.
Thanks in advance for your help,
Best regards
--
Anthony
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11867): https://lists.fd.io/g/vpp-dev/message/11867
Mute This Topic: https://lists.fd.io/mt/28972181/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #binapi: https://lists.fd.io/mk?hashtag=binapi=1480452
Mute #vppcapi: https://lists.fd.io/mk?hashtag=vppcapi=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] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

2019-01-08 Thread Dave Barach via Lists.Fd.Io

Oh, oops, I meant “msp=0”. Anyhow, results will almost certainly improve if you 
call clib_memory_init(...)... ()...

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Tuesday, January 8, 2019 7:38 AM
To: Anthony Linz ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp 
#vppcapi

Looks like a missing call to clib_memory_init(...). Note mspace=0...

HTH... Dave

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Anthony Linz
Sent: Tuesday, January 8, 2019 4:44 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

Hi
Recently I tried to learn VPP's C API and I found a sample C program in 
https://www.marosmars.com/blog/managing-vpp-c-edition blog.
I have compiled the program like this:
gcc myprog.c -o myprog -lvppinfra -lvlibmemoryclient -lsvm
and it has been compiled successfully.
The problem is that when I try to run the program I will get segmentation fault 
like this:
program received signal SIGSEGV, Segmentation fault.
mspace_malloc (msp=0x0, bytes=bytes@entry=20) at 
/root/vpp/src/vppinfra/dlmalloc.c:4338
warning: Source file is more recent than executable.
4338   if (!PREACTION(ms)) {

And the back trace looks pretty like this:
#0  mspace_malloc (msp=0x0, bytes=bytes@entry=20) at 
/root/vpp/src/vppinfra/dlmalloc.c:4338
#1  0x77bb9308 in mspace_get_aligned (msp=0x0, n_user_data_bytes=20, 
n_user_data_bytes@entry=16, align=align@entry=8,
align_offset=align_offset@entry=8) at /root/vpp/src/vppinfra/dlmalloc.c:4177
#2  0x77bae5f8 in clib_mem_alloc_aligned_at_offset 
(os_out_of_memory_on_failure=1, align_offset=8, align=8, size=16)
at /root/vpp/src/vppinfra/mem.h:118
#3  vec_resize_allocate_memory (v=v@entry=0x0, 
length_increment=length_increment@entry=8, data_bytes=16, 
header_bytes=, header_bytes@entry=0,
data_align=data_align@entry=8) at /root/vpp/src/vppinfra/vec.c:59
#4  0x77b549a6 in _vec_resize_inline (data_align=, 
header_bytes=, data_bytes=,
length_increment=, v=) at 
/root/vpp/src/vppinfra/vec.h:147
#5  va_format (s=0x0, fmt=, va=va@entry=0x7fffe228) at 
/root/vpp/src/vppinfra/format.c:403
#6  0x77b548f7 in format (s=s@entry=0x0, fmt=fmt@entry=0x77929a4c 
"/dev/shm%s%c") at /root/vpp/src/vppinfra/format.c:423
#7  0x7791e524 in vl_map_shmem (region_name=0xc7a2 "/vpe-api", 
is_vlib=is_vlib@entry=0) at /root/vpp/src/vlibmemory/memory_shared.c:544
#8  0x7791f8cb in vl_client_api_map (region_name=) at 
/root/vpp/src/vlibmemory/memory_client.c:389
#9  0x7791f90c in connect_to_vlib_internal (svm_name=, 
client_name=0xcae9 "test", rx_queue_size=32, want_pthread=1,
do_map=) at /root/vpp/src/vlibmemory/memory_client.c:416
#10 0x74c6 in connect_to_vpe ()
#11 0x9261 in main ()

My Operating System is Ubuntu 18.04.01 and I have tested this on Ubuntu 16.04 
as well with the same result.
I was wondering if anyone could help me with the problem.
Thanks in advance for your help,
Best regards
--
Anthony
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11868): https://lists.fd.io/g/vpp-dev/message/11868
Mute This Topic: https://lists.fd.io/mt/28972181/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #binapi: https://lists.fd.io/mk?hashtag=binapi=1480452
Mute #vppcapi: https://lists.fd.io/mk?hashtag=vppcapi=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] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

2019-01-08 Thread Anthony Linz

Dear Dave,
Thanks for you reply.
I could not find " clib_memory_init()" in vpp.
Did you mean "vlibmemory_init()"?
If yes where and how in my code I should use it?
Thanks
--
Anthony
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11869): https://lists.fd.io/g/vpp-dev/message/11869
Mute This Topic: https://lists.fd.io/mt/28972181/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #binapi: https://lists.fd.io/mk?hashtag=binapi=1480452
Mute #vppcapi: https://lists.fd.io/mk?hashtag=vppcapi=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] wwan0 intarface - vpp

[vpp-dev] Reminder: VPP Release 19.01 F0 is ~18 hours away.

Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

Re: [vpp-dev] wwan0 intarface - vpp

Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

Re: [vpp-dev] Seeing a VPP crash in timing wheel..

Re: [vpp-dev] wwan0 intarface - vpp

Re: [vpp-dev] :: GRE tunnel dropping MPLS packets

[vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

Re: [vpp-dev] An 'ip route' question

Re: [vpp-dev] Seeing a VPP crash in timing wheel..

Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

Re: [vpp-dev] VPP 19.01 C API gets segmentation fault #binapi #vpp #vppcapi

14 matches

Site Navigation

Mail list logo

Footer information