Re: [vpp-dev] Graph Dispatch Pcap Trace HowTo video now on the fd.io YouTube channel

[Dave Wallace]

Most excellent!

Another fine tool in the VPP toolbox.

Thanks,
-daw-

On 02/06/2019 04:23 PM, Dave Barach via Lists.Fd.Io wrote:

See https://youtu.be/wmp3X8NipEM...

HTH... Dave



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

View/Reply Online (#12197): https://lists.fd.io/g/vpp-dev/message/12197
Mute This Topic: https://lists.fd.io/mt/29682831/675079
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dwallac...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-


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

View/Reply Online (#1): https://lists.fd.io/g/vpp-dev/message/1
Mute This Topic: https://lists.fd.io/mt/29682831/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 graph dispatch fine-grained event log capture and visualization

[Dave Barach via Lists.Fd.Io]

Folks,

Here is a short VoD which shows how to capture and visualize fine-grained event 
log data: https://youtu.be/KwHOgdm3_sY 

HTH... Dave

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

View/Reply Online (#12221): https://lists.fd.io/g/vpp-dev/message/12221
Mute This Topic: https://lists.fd.io/mt/29703228/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] Regarding clib_mem_alloc

[Dave Barach via Lists.Fd.Io]

Due to overhead, you won't be able to allocate 0x bytes (4gb-1), but in 
the size range you're describing there are no known first-order obvious problem 
with the memory allocator.

I don't blame you for asking, but I'm afraid it's likely that you have a 
dangling reference in your app code or some such to chase down...

D. 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Friday, February 8, 2019 8:21 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding clib_mem_alloc

Hi,

Assuming the heap is sufficiently dimensioned, can any size be requested from 
clib_mem_alloc which fits in u32 ? Are there any issues if higher sizes are 
requested eg. can clib_mem_alloc actually return a pointer but the allocated 
size is not as much as the requested size ?

Perhaps it is bizarre to ask the above, but one of my usecases works nicely 
when I request a size of around 216 MB, but runs into application level 
corruption when I request double of this i.e. around
432 MB. So thought of asking. It could by all means be and likely is an 
application level problem. This is with VPP 18.01

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

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

[vpp-dev] Regarding clib_mem_alloc

[Prashant Upadhyaya]

Hi,

Assuming the heap is sufficiently dimensioned, can any size be
requested from clib_mem_alloc which fits in u32 ? Are there any issues
if higher sizes are requested eg. can clib_mem_alloc actually return a
pointer but the allocated size is not as much as the requested size ?

Perhaps it is bizarre to ask the above, but one of my usecases works
nicely when I request a size of around 216 MB, but runs into
application level corruption when I request double of this i.e. around
432 MB. So thought of asking. It could by all means be and likely is
an application level problem. This is with VPP 18.01

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

View/Reply Online (#12219): https://lists.fd.io/g/vpp-dev/message/12219
Mute This Topic: https://lists.fd.io/mt/29701184/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] Understanding vlib_buffer_enqueue()

[Dave Barach via Lists.Fd.Io]

The discussion about feature arcs is a red herring with respect to the buffer 
enqueue dance. It's about node A enqueueing to its successor nodes B, C, D, 
etc. It's the same whether or not A (and friends) are part of a feature arc. 
The feature arc code manages the set of successor nodes, and has 
little-to-nothing to do with vector element enqueue mechanics.

The 1x/2x speculative enqueue scheme makes the observation that with high 
probability packets i and i+1 (and i+2 in the _x2 case) will be enqueued to the 
same successor node. Notice the PREDICT_FALSE in the macro. Next_index is the 
current arc index. In the PREDICT_FALSE case, the current packet isn't to 
follow the same arc that the last vector element followed. 

In that case, the macro unwinds the speculative enqueue done near the top of 
the loop, sends the packet along the correct arc, and changes the current arc 
index; next_index. 

HTH... Dave 


From: vpp-dev@lists.fd.io  On Behalf Of Nitin Saxena
Sent: Friday, February 8, 2019 6:36 AM
To: Gudimetla, Leela Sankar ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Understanding vlib_buffer_enqueue()

If yes, why the frame needs to traverse two directions?    Should it not 
traverse only feature-arc?
The flow is in one direction only.  

Every node has speculated "next_index" node. If the speculated "next_index" 
node is not same as actual "next0" node  (which is typically retrieved by 
either parsing data or vlib buffer). So if speculated "next_index" node is not 
same as actual "next0" node, release/put the frame of "next_index" node and get 
the frame corresponding to "next0" node. Also make "next0" as "next_index" node 
(considering further packets will come corresponding to this "next_index" 
node). 


Thanks,
Nitin

From: mailto:vpp-dev@lists.fd.io  on behalf of 
Gudimetla, Leela Sankar 
Sent: Friday, February 8, 2019 9:23 AM
To: mailto:vpp-dev@lists.fd.io
Subject: [vpp-dev] Understanding vlib_buffer_enqueue() 
 
External Email
Hello,
 
I am trying to understand a piece of code that enqueues a frame to next-node. 
But when a frame is traversing feature-nodes, I see the following boiler-plate 
code that seems to be sending the frames to two nodes at the same time.
Is my understanding correct?
 
218 #define 
vlib_validate_buffer_enqueue_x1(vm,node,next_index,to_next,n_left_to_next,bi0,next0)
 \
219 do {  \
220   if (PREDICT_FALSE (next0 != next_index))    \
221 { \
222   vlib_put_next_frame (vm, node, next_index, n_left_to_next + 1);   \
223   next_index = next0; \
224   vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next); \
225    \
226   to_next[0] = bi0;   \
227   to_next += 1;    \
228   n_left_to_next -= 1;    \
229 } \
230 } while (0)
 
If yes, why the frame needs to traverse two directions?    Should it not 
traverse only feature-arc?
 
Any pointers in understanding would really help.
 
Thanks,
Leela sankar
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12218): https://lists.fd.io/g/vpp-dev/message/12218
Mute This Topic: https://lists.fd.io/mt/29698182/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] Understanding vlib_buffer_enqueue()

[Nitin Saxena]

If yes, why the frame needs to traverse two directions?Should it not 
traverse only feature-arc?

The flow is in one direction only.

Every node has speculated "next_index" node. If the speculated "next_index" 
node is not same as actual "next0" node  (which is typically retrieved by 
either parsing data or vlib buffer). So if speculated "next_index" node is not 
same as actual "next0" node, release/put the frame of "next_index" node and get 
the frame corresponding to "next0" node. Also make "next0" as "next_index" node 
(considering further packets will come corresponding to this "next_index" node).


Thanks,
Nitin

From: vpp-dev@lists.fd.io  on behalf of Gudimetla, Leela 
Sankar 
Sent: Friday, February 8, 2019 9:23 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Understanding vlib_buffer_enqueue()


External Email

Hello,



I am trying to understand a piece of code that enqueues a frame to next-node.

But when a frame is traversing feature-nodes, I see the following boiler-plate 
code that seems to be sending the frames to two nodes at the same time.

Is my understanding correct?



218 #define 
vlib_validate_buffer_enqueue_x1(vm,node,next_index,to_next,n_left_to_next,bi0,next0)
 \

219 do {  \

220   if (PREDICT_FALSE (next0 != next_index))\

221 { \

222   vlib_put_next_frame (vm, node, next_index, n_left_to_next + 1);   \

223   next_index = next0; \

224   vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next); \

225\

226   to_next[0] = bi0;   \

227   to_next += 1;\

228   n_left_to_next -= 1;\

229 } \

230 } while (0)



If yes, why the frame needs to traverse two directions?Should it not 
traverse only feature-arc?



Any pointers in understanding would really help.



Thanks,

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

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

[vpp-dev] Hybrid ICN hicn - 19.01 release is out

[Luca Muscariello via Lists.Fd.Io]

Hi everyone,

 

I’m very happy to announce that the first hICN release is out.

 

hICN 19.01 release makes use of VPP 19.01 and artifacts are 

available on package cloud.

 

 

hICN (hybrid ICN) is composed of a server stack (network + transport) 

based on VPP and a client portable stack (macOS, Windows, GNU/Linux, iOS, 
Android).

hICN makes use of VPP through a new plugin and also by using libmemif 

as network/transport connector.

 

 

More information about the project can be found 

in the wiki page https://wiki.fd.io/view/HICN

 

 

The team is already engaging in several fd.io projects such as

VPP and sweetcomb and willing to engage with other projects

such as CSIT, GoVPP in the first place, for both testing and

network management.

 

hICN makes also use of CICN contributions such as libparc 

to support crypto APIs and OS portability. 

 

 

Many thanks to Ed and Vanessa for setting everything up in a 

very short time. Frankly, we cannot think about a better support.

 

Thanks and hope to working with you in the future.

 

Luca 

on behalf of the fd.io/hicn team.

 

 

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

View/Reply Online (#12216): https://lists.fd.io/g/vpp-dev/message/12216
Mute This Topic: https://lists.fd.io/mt/29700389/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] Question about crypto dev queue pairs #vpp

[Sergio G.M.]

Hi Manuel,

I forgot to mention that the test I performed does not validate the HW
crypto device case, ie. there could be a bug in the DMA addresses for the
crypto op. I do not have any crypto HW to test but afaik CSIT does run a
few different use cases using HW crypto.

HTH,
Sergio

On Fri, Feb 8, 2019 at 10:30 AM  wrote:

> Hi Sergio,
>
> thank you for your comment, I will try to debug the problem ASAP.
>
>
> BR,
> Manuel
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12213): https://lists.fd.io/g/vpp-dev/message/12213
> Mute This Topic: https://lists.fd.io/mt/29538345/682142
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1498673
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [
> sergio.gonzalez.mon...@outlook.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] llc_input question #vpp

[manuel . alonso]

Hi all,

reading a piece of code( *src/vnet/llc/node.c* ) I noticed that llc_input is 
almost the same as function snap_input( *src/vnet/snap/node.c* )...
but there is a different line and I would like to understand the reason, may be 
is the same having or not that line but I am not sure.
*src/vnet/llc/node.c :176*

case 3:

  /* A B B or A B C */

  to_next -= 2;

  n_left_to_next += 2;

  vlib_set_next_frame_buffer (vm, node, next0, bi0);

  vlib_set_next_frame_buffer (vm, node, next1, bi1);

src/vnet/snap/node.c:182
case 3:  /* A B B or A B C */  to_next -= 2;  to_next[-2] = bi0;  
n_left_to_next += 2;  vlib_set_next_frame_buffer (vm, node, next0, bi0);
BR,
Manuel
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12214): https://lists.fd.io/g/vpp-dev/message/12214
Mute This Topic: https://lists.fd.io/mt/29700012/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] Question about crypto dev queue pairs #vpp

[manuel . alonso]

Hi Sergio,

thank you for your comment, I will try to debug the problem ASAP.

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

View/Reply Online (#12213): https://lists.fd.io/g/vpp-dev/message/12213
Mute This Topic: https://lists.fd.io/mt/29538345/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] Question about crypto dev queue pairs #vpp

[Sergio G.M.]

So I have tried both IPsec ESP in transport mode with aes-gcm and aes-cbc
and it does encrypt properly.
In the test I'm using VPP 19.01 release with software cryptodevs and the
built-in packet-generator:

00:00:07:563578: ipsec4-output-feature
  spd 1
00:00:07:563595: dpdk-esp4-encrypt
  cipher aes-cbc-128 auth sha1-96
  IPSEC_ESP: 192.168.100.1 -> 192.168.200.1
tos 0x00, ttl 63, length 168, checksum 0xcdd0
fragment id 0x
  ESP: spi 1001, seq 1

Packet 2

00:00:07:563658: dpdk-crypto-input
  status: success
00:00:07:563701: pg0-output
  pg0
  IP4: 02:fe:1e:3a:8f:6a -> de:ad:be:ef:ca:fe
  IPSEC_ESP: 192.168.100.1 -> 192.168.200.1
tos 0x00, ttl 63, length 168, checksum 0xcdd0
fragment id 0x
00:00:07:563707: pg0-tx
buffer 0x4e9f: current data -38, length 182, free-list 0, clone-count
0, totlen-nifb 0, trace 0x1
  IP4: 02:fe:1e:3a:8f:6a -> de:ad:be:ef:ca:fe
  IPSEC_ESP: 192.168.100.1 -> 192.168.200.1
tos 0x00, ttl 63, length 168, checksum 0xcdd0
fragment id 0x

As you can observe, in the interface -output and -tx the trace shows the
proper Ethernet and IPv4 layers, where as in your trace the ethertype is
already wrong:

00:03:07:167310: dpdk-crypto-input
  status: success
00:03:07:167371: VirtualFunctionEthernet1/0/2-output
  VirtualFunctionEthernet1/0/2
  0x: 02:0f:b7:00:00:00 -> 02:0f:b7:00:00:01
00:03:07:167392: VirtualFunctionEthernet1/0/2-tx
  VirtualFunctionEthernet1/0/2 tx queue 1
  buffer 0x2a02: current data -24, length 102, buffer-pool 0,
clone-count 0, totlen-nifb 0, trace 0x0
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
  PKT MBUF: port 0, nb_segs 1, pkt_len 102
buf_len 2176, data_len 102, ol_flags 0x180, data_off 104,
phys_addr 0x40150200
packet_type 0x210 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
  RTE_PTYPE_L4_UDP (0x0200) UDP packet
  0x: 02:0f:b7:00:00:00 -> 02:0f:b7:00:00:01


It looks like the crypto device is writing at the wrong offset, so you
probably need to gdb and look at the packet before encrypt
(esp-encrypt node) and after being read from the cryptodev
(dpdk-crypto-input node).



On Thu, Feb 7, 2019 at 2:22 PM  wrote:

> Yes I did, OpenSSL backend is working.
> I can see the esp4-encrypt and esp4-decrypt counters incrementing and
> there are no errors. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12206): https://lists.fd.io/g/vpp-dev/message/12206
> Mute This Topic: https://lists.fd.io/mt/29538345/682142
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1498673
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [
> sergio.gonzalez.mon...@outlook.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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