[vpp-dev] Install libmemif in vpp 19.08.01

[Himanshu Rakshit]

Hi All,

As I understand libmemif is not a part of the vpp packages any more. What
is the way to install libmemif compatible with vpp 19.08.1

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

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

[vpp-dev] How to include my custom plugin in the rpm packages.

[Himanshu Rakshit]

Hi All,

We have developed a custom plugin (under the folder *src/plugin*). We are
able to compile it successfully and also able to run in the local setup
using *make run* or *make debug* command.

Our intention is not run in a different system(different for the build
system). So we make the rpm package using the *make pkg-rpm *command and
install the rpms in the remote system. But the custom plugin is not a part
of the rpm packages and not installed in the system.

Need your help on this.

What is best possible way to install the custom plugin in a remote
system(different form the build system.)

I followed the following steps

*make install-dep*
*make build*
*make pkg-rpm*

*rpm -ivh *

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

View/Reply Online (#15783): https://lists.fd.io/g/vpp-dev/message/15783
Mute This Topic: https://lists.fd.io/mt/71944155/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] VRRP Unit Tests failing on Master Ubuntu

[Paul Vinciguerra]

Hi Dave,

Please don't add broken tests to extended tests.

See https://gerrit.fd.io/r/c/vpp/+/24567/12/test/test_bfd.py

Thanks!

On Fri, Mar 13, 2020 at 1:33 PM Dave Wallace  wrote:

> Matt,
>
> I will keep an eye on this gerrit and merge it once the verify jobs have
> completed.
> If there are other tests which fail, are you ok if I add them to this
> patch and turn it into a generic 'disable failing tests' gerrit change?
>
> The other possibility is that this is due to the recent disabling of the
> Naginator retry plugin.
>
> I'm going to investigate if this issue may have been masked by Naginator...
>
> Thanks for your help on keeping the CI operational!
> -daw-
>
> On 3/12/2020 12:09 PM, Matthew Smith via Lists.Fd.Io wrote:
>
>
> Change submitted - https://gerrit.fd.io/r/c/vpp/+/25834. Verification
> jobs are running. Hopefully they won't fail :)
>
> -Matt
>
>
> On Thu, Mar 12, 2020 at 10:22 AM Matthew Smith via Lists.Fd.Io  netgate@lists.fd.io> wrote:
>
>>
>> I don't have a solution yet, but one observation has popped up quickly
>>
>> In the 2 failed jobs Ray sent links for, one of them had a test fail
>> which was not related to VRRP. There is a BFD6 test failure for the NAT
>> change https://gerrit.fd.io/r/c/vpp/+/25462:
>>
>>
>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/archives/
>>
>> Looking back through a couple of recent failed runs of that job, there is
>> also a DHCP6 PD test failure for rdma change
>> https://gerrit.fd.io/r/c/vpp/+/25823:
>>
>>
>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2682/archives/
>>
>> The most obvious common thread between BFD6, DHCP6 and VRRP to me seems
>> to be that they all maintain state which is dependent on timers. There
>> could be a more general issue with timing-sensitive tests. I am going to
>> submit a change which will prevent the VRRP tests from running temporarily
>> while I can figure out a proper solution. Based on the above, other tests
>> may need the same treatment.
>>
>> -Matt
>>
>>
>>
>>
>> On Thu, Mar 12, 2020 at 8:57 AM Matthew Smith 
>> wrote:
>>
>>> Hi Ray,
>>>
>>> Thanks for bringing it to my attention. I'll look into it.
>>>
>>> -Matt
>>>
>>>
>>> On Thu, Mar 12, 2020 at 8:24 AM Ray Kinsella  wrote:
>>>
 Anyone else noticing seeming spurious failures related to the VRRP
 plugin's unit tests.
 Some examples from un-related commits.

 Ray K

 nat: timed out session scavenging upgrade (
 https://gerrit.fd.io/r/c/vpp/+/25462)

 https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/console.log.gz


 ==
 TEST RESULTS:
  Scheduled tests: 1138
   Executed tests: 1138
 Passed tests: 1021
Skipped tests: 112
 Failures: 3
   Errors: 2
 FAILURES AND ERRORS IN TESTS:
   Testcase name: IPv4 VRRP Test Case
 FAILURE: IPv4 Master VR does not reply for VIP w/ accept mode off
 [test_vrrp.TestVRRP4.test_vrrp4_accept_mode_disabled]
 FAILURE: IPv4 Master VR preempted by higher priority backup
 [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
   Testcase name: IPv6 VRRP Test Case
 FAILURE: IPv6 Master VR preempted by higher priority backup
 [test_vrrp.TestVRRP6.test_vrrp6_master_preempted]
   ERROR: IPv6 Backup VR preempts lower priority master
 [test_vrrp.TestVRRP6.test_vrrp6_backup_preempts]
   Testcase name: Bidirectional Forwarding Detection (BFD) (IPv6)
   ERROR: echo function [test_bfd.BFD6TestCase.test_echo]

 ==

 vlib: startup multi-arch variant configuration (
 https://gerrit.fd.io/r/c/vpp/+/25798_

 https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2675/console.log.gz


 ==
 TEST RESULTS:
  Scheduled tests: 22
   Executed tests: 22
 Passed tests: 21
 Failures: 1
 FAILURES AND ERRORS IN TESTS:
   Testcase name: IPv4 VRRP Test Case
 FAILURE: IPv4 Master VR preempted by higher priority backup
 [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]

 ==




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

View/Reply Online (#15782): https://lists.fd.io/g/vpp-dev/message/15782
Mute This Topic: https://lists.fd.io/mt/71901798/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] Is there any Linux FD to poll for VCL message

[Florin Coras]

Hi Murthy, 

Glad it helps! By construction, when vcl is initialized (vppcom_app_create()) 
only one worker is initialized. As long as you don’t register other workers 
(vppcom_worker_register), you don’t really have to worry about anything else 
and there are no performance penalties.

It’s important to remember that vcl is not thread safe by itself, i.e., workers 
will never take any locks exactly because we want them to be as light weight as 
possible. If the application does not want to manage locking/forking, it should 
use vcl_locked (vls) but that’s an entirely different topic. 

Regards,
Florin

> On Mar 13, 2020, at 9:49 AM, Satya Murthy  wrote:
> 
> Hi Florin,
> 
> Thanks a lot for the detailed explanation. This kind of gives an overview of 
> this area, which really helps in our integration.
> 
> Just one more question:
> We are planning to remove the concept of vcl worker in our worker, as our app 
> is a single threaded app and will not be multi-threaded at any point of time 
> in future as well. Hope this is doable and does not pose any restrictions in 
> any of the VCL s/w layers.
>
> -- 
> Thanks & Regards,
> Murthy 

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

View/Reply Online (#15781): https://lists.fd.io/g/vpp-dev/message/15781
Mute This Topic: https://lists.fd.io/mt/71899986/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] Is there any Linux FD to poll for VCL message

[Satya Murthy]

Hi Florin,

Thanks a lot for the detailed explanation. This kind of gives an overview of 
this area, which really helps in our integration.

Just one more question:
We are planning to remove the concept of vcl worker in our worker, as our app 
is a single threaded app and will not be multi-threaded at any point of time in 
future as well. Hope this is doable and does not pose any restrictions in any 
of the VCL s/w layers.

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15780): https://lists.fd.io/g/vpp-dev/message/15780
Mute This Topic: https://lists.fd.io/mt/71899986/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] NAT bugix related to in2out/out2in handoff node index

[Dave Wallace]

I have cherry-picked this to stable/2001 [0] and will merge it once it 
has been verified.


Thanks,
-daw-

[0] https://gerrit.fd.io/r/c/vpp/+/25861

On 3/13/2020 10:25 AM, Dave Barach via Lists.Fd.Io wrote:

Merged, thanks for this one... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Filip Varga via 
Lists.Fd.Io
Sent: Friday, March 13, 2020 10:08 AM
To: Elias Rudberg ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] NAT bugix related to in2out/out2in handoff node index

Hello,

Thank you for your contribution Elias.

Best regards,
Filip

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Elias Rudberg
Sent: Friday, March 13, 2020 3:00 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] NAT bugix related to in2out/out2in handoff node index

Hello,

While working on moving from VPP 19.08 to 20.01 we found that NAT was no longer 
working and it seems to be due to a bug in src/plugins/nat/nat.c for the 
dynamic endpoint-independent case, here:

 sm->handoff_out2in_index = snat_in2out_node.index;
 sm->handoff_in2out_index = snat_out2in_node.index;

As I understand it, handoff_out2in_index is supposed to be the node index of 
the out2in node, but it is set to the in2out node index instead. And the other 
way around, in2out/in2out are mixed up in those two lines.

I pushed a fix to gerrit, it's just those two lines that are changed:
https://gerrit.fd.io/r/c/vpp/+/25856

If you agree, can this fix please be accepted into master and also into the 
stable/2001 branch?

Best regards,
Elias




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

View/Reply Online (#15779): https://lists.fd.io/g/vpp-dev/message/15779
Mute This Topic: https://lists.fd.io/mt/71926127/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] Query about internal apps

[Florin Coras]

Hi Vivek, 

Inline.

> On Mar 12, 2020, at 11:06 PM, Vivek Gupta  wrote:
> 
> Hi Florin,
> 
> Please see inline.
> 
> Regards,
> Vivek
> 
> -Original Message-
> From: Florin Coras  
> Sent: Thursday, March 12, 2020 8:09 PM
> To: Ole Troan 
> Cc: Vivek Gupta ; kusumanjal...@gmail.com; 
> vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Query about internal apps
> 
> Hi Ole, Vivek,
> 
> If I understand this right, you’re looking to intercept l2 packets in vpp 
> (supposedly only from certain hosts), process them and maybe generate some 
> return traffic. What is the payload of those l2 packets? 
> Vivek> We are trying to intercept the complete l2 packets, coming on certain 
> interfaces, and pass it on the user application and user application can then 
> process those and forward them to the actual destination. 
> Payload will be the regular ethernet packets.

FC: If you could deliver data directly to the builtin application, would you 
still need L2 framing? Do you plan to intercept just a subset of the L2 frames 
on an interface or all?

Also, can the source of those frames be changed to use vcl? If not, your only 
option is to intercept packets somewhere in vpp. 
 
> 
> You could write a feature that inspects all traffic on a certain interface 
> and intercepts the packets that you’re interested in. 
> Vivek> However, for these intercepted packets, what should be right way to 
> pass it to the VPP internal application? For the session layer, we would need 
> a transport_connection for L2_proto and pass traffic through the session 
> using the fake tuple lookup. 

FC: A transport is needed if the two peers must exchange data over network 
interfaces. Cut through connections have no transport protocol framing as 
they’re just shared memory buffers over which data can be exchanged with 
whatever framing the two peer apps decide (or no framing at all).

Regards,
Florin
 
> 
> Alternatively, session layer supports pure shared memory transports, i.e., 
> cut-through connections (see slide 16-18 here [1]). For instance, a vpp 
> builtin application could receive data directly over shared memory from an 
> external application. However, currently session layer only knows how to 
> lookup 5-tuples, so the two peers (external app and vpp builtin app) need to 
> agree on a shared “fake” 5-tuple.
> 
> 
> Regards,
> Florin
> 
> [1] https://wiki.fd.io/images/9/9c/Vpp-hoststack-kc-eu19.pdf
> 
>> On Mar 12, 2020, at 1:09 AM, Ole Troan  wrote:
>> 
>> Hi Vivek,
>> 
>>> We are trying to achieve the mechanism, something similar to TAP interface, 
>>> in VPP.
>>> 
>>> So, the packets coming out of the TAP interface, will be directed directly 
>>> to the application. The application will receive the packets, coming via 
>>> TAP interface, process them and send it down via the Host stack.
>>> 
>>> Possible options, we could think of are:-
>>> - Enhance the session layer to provide a L2 transport mechanism and add 
>>> nodes like tap-input and tap-out which would achieve the same.
>>> - Use the existing session layer by doing a IP/UDP encap and send it to the 
>>> APP, via session layer and use existing mechanism.
>>> This introduces an overhead of additional encap/decap.
>>> 
>>> We wanted to check if there is any alternate option to directly transfer 
>>> the packets from the plugin to the VPP App, without even involving the 
>>> session layer and have no additional overhead encap/decap,
>> 
>> Is this similar to the idea of routing directly to the application?
>> I.e. give each application an IP address (easier with IPv6), and the 
>> application itself links in whatever transport layer it needs. In a VPP 
>> context the application could sit behind a memif interface. The application 
>> would need some support for IP address assignment, ARP/ND etc.
>> Userland networking taken to the extreme. ;-)
>> 
>> Best regards,
>> Ole
> 

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

View/Reply Online (#15777): https://lists.fd.io/g/vpp-dev/message/15777
Mute This Topic: https://lists.fd.io/mt/71885250/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] Is there any Linux FD to poll for VCL message

[Florin Coras]

Hi Murthy, 

Inline. 

> On Mar 13, 2020, at 4:54 AM, Satya Murthy  wrote:
> 
> Hi Florin,
> 
> Thank you very much for the inputs.
> These are very difficult to understand unless we go through the code in 
> detail.
> Today, Whole day, I was trying to follow your instructions and get this 
> working by looking at the code as well.

I’d recommend starting here 
https://wiki.fd.io/images/9/9c/Vpp-hoststack-kc-eu19.pdf

> However, I am not fully successful. 
> Before going further, I would like to get my understanding clear, so that it 
> will form basis for my debugging.
> 
> Here are couple of questions:
> 1) 
> ==
> The message queue used between vpp and a vcl worker can do both mutex/condvar 
> and eventfd notifications. The former is the default but you can switch to 
> eventfds by adding to vcl.conf "use-mq-eventfd”. You can then use 
> vppcom_worker_mqs_epfd to retrieve a vcl worker's epoll fd (it’s an epoll fd 
> for historic reasons) which you should be able to nest into your own linux 
> epoll fd. 
> ==
> The message queues between VPP and VCL can be present either in "shared 
> memory" (or) "memfd segments".
> For eventfd to work, the queues need to be present in the "memfd segments".
> Is this correct understanding ?

FC: VCL workers and vpp use message queues to exchange io/ctrl messages and 
fifos to exchange data. Both are allocated in shared memory segments which can 
be of two flavors, POSIX shm segments (shm_open) or memfd based (memfd 
exchanged over a unix socket). For the latter to work, we use the binary api’s 
socket transport to exchange the fds.

If configured to use eventds for message queue signaling, vpp must exchange 
those eventfds with the vcl workers. For that, we also use the binary api’s 
socket. That should explain why the binary api’s socket transport is needed. 
Note also that this is just a configuration from vcl consumer perspective, it 
should not otherwise affect the app. 

> 
> 2) 
> ==
> Note that you’ll also need to force memfd segments for vpp’s message queues, 
> i.e., session { evt_qs_memfd_seg }, and use the socket transport for binary 
> api, i.e., in vpp’s startup.conf add "socksvr { /path/to/api.sock }" and in 
> vcl.conf "api-socket-name /path/to/api.sock”. 
> ==
> I didnt understand the reason for moving the binary api to sockets.
> Is this due to shm/memfd wont be used at the same time ? 

FC: I hope it’s clear now why you need to move to the binary api’s socket 
transport. 

> 
> 3) 
> In a nut shell:
> 
> VCL-APP   -> VPP
> VCL-APP  <---Binary Api via LinuxDomain 
> Sockets--> VPP
> 
> We will have two api clients with this model. One is shared memory client and 
> other is a socket client.

FC: If you mean to point out that there are two channels from vcl to vpp, 
that’s correct. The first is the one described above, but note that the message 
queues are not bidirectional. VPP has another set of message queues the apps 
use to enqueue notifications towards vpp.

As for the second channel, the binary api, it’s used to 1) attach vcl to the 
session layer, 2) its socket is used for exchanging fds (memfds and eventfds) 
3) sometimes for exchanging configuration. 

But again, apart from configuration changes, this should be completely 
transparent to vcl consumers. 

Regards,
Florin

> 
> Is my understanding correct ? 
> -- 
> Thanks & Regards,
> Murthy 

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

View/Reply Online (#15778): https://lists.fd.io/g/vpp-dev/message/15778
Mute This Topic: https://lists.fd.io/mt/71899986/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] Storing a struct as a value in BiHash

[Dave Barach via Lists.Fd.Io]

Sorry, I missed this message a couple of days ago. Answers inline...

From: Vishal1 Sharma
Sent: 11 March 2020 12:37
To: 'vpp-dev@lists.fd.io' mailto:vpp-dev@lists.fd.io>>
Subject: Storing a struct as a value in BiHash

Hello all,
I’m new to using vpp-infra and I’m currently trying to use hash table in order 
to store some structs as value. Thanks to Dave Barach, I’ve got a sample 
program for inserting a value and fetching that. However, I have some queries 
regarding the program. Given below is the program:

#include 
#include "vppinfra/bihash_8_8.h"
#include "vppinfra/bihash_template.c"

//This is my structure that I want to save as value.
typedef struct
{
  int a;
  char b[100];
  char c;
} design_t;

typedef struct
{
  /* Pool of designs */
  design_t *designs;
  /* design by key */
  uword *design_by_key;
} test_main_t;

test_main_t test_main;

int main (int argc, char **argv)
{
  test_main_t *tm = _main;
  design_t *elt;
  uword *p;

  /* Initialize the memory allocator */
  clib_mem_init (0, 128<<20);

  /* Create a 32-bit key hash table with a 32-bit value */
  tm->design_by_key = hash_create (0, sizeof (32));

  /*
   * Create an element
   * Remember that pools are vectors, which can/will MOVE
   * when resized. Always memorize pool indices, NOT pointers.
   */
  pool_get (tm->designs, elt);
  memset (elt, 0, sizeof (*elt)); /* pool_get doesn't zero memory */

  elt->a = 42;
  strncpy (elt->b, "Vishal Sharma", sizeof (elt->b));
  elt->c = 'v';

  /* Add the pool element INDEX to the hash table */
  hash_set (tm->design_by_key, 42, elt - tm->designs);

  /* For fun, look up the design_t we put into the hash table */

  p = hash_get (tm->design_by_key, 42);
  ASSERT (p);

  elt = pool_elt_at_index (tm->designs, p[0]);
  ASSERT (elt->a == 42);
  exit (0);
}

I’m compiling this above program by: gcc -o exe prog.c -lvppinfra -I ../ -ggdb3 
-I ./vpp/build-root/build-vpp_debug-native/vpp/
Given below are my queries:

  1.  I didn’t understand the purpose of “test_main_t”. Why is it required?

If you look at vlib/vnet/plugins, you’ll see this coding pattern all over the 
place. Typically, one ends up with faster object code as a result. It’s not 
“required,” but it is pretty effective.


  1.  By calling clib_mem_init(), some memory allocation is happening. What 
will happen if my usage exceeds that? Will it automatically resize?

Clib_mem_init(0, ) allocates  worth of virtual space, and sets the 
heap so that it will expand as needed. If you pass a chunk of memory (e.g. 
acquired by calling mmap) the heap will be fixed-size.


  1.  By looking at “pool_get (tm->designs, elt);” it seems that we’re getting 
some memory for ‘elt’ from ‘tm->designs’ which was described as ‘pool of 
desgins’. But when did we allocate the memory for this ‘pool of designs’? Do I 
have to call ‘pool_get()’ every time when I have to insert a key-value pair in 
the hash table?

Take a look at .../src/vppinfra/pool.h. Pools are dynamic arrays (vectors) with 
headers. The header has a free-element bitmap, and a freelist. All of the pool 
structures are dynamic, no need to manually allocate the pool. Fixed-size, 
preallocated pools are also supported; no need to go there in this case.

The only “gotcha” with pools: they ARE dynamic, so memorizing the address of a 
pool element is a bad mistake.

Call pool_get to acquire a new element from a pool. In most cases, the vector 
will not expand, so the operation is extremely fast.



  1.  When we are setting the key-value in the hash table by calling 
‘hash_set()’, I didn’t understand the 3rd argument being passed. Why is it ‘elt 
- tm->designs’ and not just ‘elt’? What’s being done by the subtraction here?

Always memorize pool indices. Never memorize a pointer to the ith element of a 
pool. Again, pools are dynamic. When a pool expands, we copy the current 
contents to a new, larger chunk of allocated memory. We free the old memory. 
Sticking pointers to pool elements into a hash table is a bad mistake, and 
leads to catastrophic failure when the old memory is reallocated.

I’ll be grateful if somebody can answer these queries.

Thanks and regards,
Vishal Sharma


"Confidentiality Warning: This message and any attachments are intended only 
for the use of the intended recipient(s), are confidential and may be 
privileged. If you are not the intended recipient, you are hereby notified that 
any review, re-transmission, conversion to hard copy, copying, circulation or 
other use of this message and any attachments is strictly prohibited. If you 
are not the intended recipient, please notify the sender immediately by return 
email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure 
no viruses are present in this email. The company cannot accept responsibility 
for any loss or damage arising from the use of this email or attachment."
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to 

Re: [vpp-dev] NAT bugix related to in2out/out2in handoff node index

[Filip Varga via Lists.Fd.Io]

Hello,

Thank you for your contribution Elias.

Best regards,
Filip

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Elias Rudberg
Sent: Friday, March 13, 2020 3:00 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] NAT bugix related to in2out/out2in handoff node index

Hello,

While working on moving from VPP 19.08 to 20.01 we found that NAT was no longer 
working and it seems to be due to a bug in src/plugins/nat/nat.c for the 
dynamic endpoint-independent case, here:

sm->handoff_out2in_index = snat_in2out_node.index;
sm->handoff_in2out_index = snat_out2in_node.index;

As I understand it, handoff_out2in_index is supposed to be the node index of 
the out2in node, but it is set to the in2out node index instead. And the other 
way around, in2out/in2out are mixed up in those two lines.

I pushed a fix to gerrit, it's just those two lines that are changed:
https://gerrit.fd.io/r/c/vpp/+/25856

If you agree, can this fix please be accepted into master and also into the 
stable/2001 branch?

Best regards,
Elias
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Coverity run FAILED as of 2020-03-13 14:00:36 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 6
Newly detected: 0
Eliminated: 0
More details can be found at  
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] NAT bugix related to in2out/out2in handoff node index

[Elias Rudberg]

Hello,

While working on moving from VPP 19.08 to 20.01 we found that NAT was
no longer working and it seems to be due to a bug in
src/plugins/nat/nat.c for the dynamic endpoint-independent case, here:

sm->handoff_out2in_index = snat_in2out_node.index;
sm->handoff_in2out_index = snat_out2in_node.index;

As I understand it, handoff_out2in_index is supposed to be the node
index of the out2in node, but it is set to the in2out node index
instead. And the other way around, in2out/in2out are mixed up in those
two lines.

I pushed a fix to gerrit, it's just those two lines that are changed:
https://gerrit.fd.io/r/c/vpp/+/25856

If you agree, can this fix please be accepted into master and also into
the stable/2001 branch?

Best regards,
Elias
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15772): https://lists.fd.io/g/vpp-dev/message/15772
Mute This Topic: https://lists.fd.io/mt/71926127/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] Is there any Linux FD to poll for VCL message

[Satya Murthy]

Hi Florin,

Thank you very much for the inputs.
These are very difficult to understand unless we go through the code in detail.
Today, Whole day, I was trying to follow your instructions and get this working 
by looking at the code as well.
However, I am not fully successful.
Before going further, I would like to get my understanding clear, so that it 
will form basis for my debugging.

Here are couple of questions:
1)
==
The message queue used between vpp and a vcl worker can do both mutex/condvar 
and eventfd notifications. The former is the default but you can switch to 
eventfds by adding to vcl.conf "use-mq-eventfd”. You can then use 
vppcom_worker_mqs_epfd to retrieve a vcl worker's epoll fd (it’s an epoll fd 
for historic reasons) which you should be able to nest into your own linux 
epoll fd.
==
The message queues between VPP and VCL can be present either in "shared memory" 
(or) "memfd segments".
For eventfd to work, the queues need to be present in the "memfd segments".
Is this correct understanding ?

2)
==
Note that you’ll also need to force memfd segments for vpp’s message queues, 
i.e., session { evt_qs_memfd_seg }, and use the socket transport for binary 
api, i.e., in vpp’s startup.conf add "socksvr { /path/to/api.sock }" and in 
vcl.conf "api-socket-name /path/to/api.sock”.
==
I didnt understand the reason for moving the binary api to sockets.
Is this due to shm/memfd wont be used at the same time ?

3)
In a nut shell:

VCL-APP   VPP
VCL-APP  <---Binary Api via LinuxDomain 
Sockets--> VPP

We will have two api clients with this model. One is shared memory client and 
other is a socket client.

Is my understanding correct ?
--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15771): https://lists.fd.io/g/vpp-dev/message/15771
Mute This Topic: https://lists.fd.io/mt/71899986/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] Tap connect CLI

[Jerome Tollet via Lists.Fd.Io]

Hello,
You can create tap interface using “create tap” CLI command.
Jerome

De :  au nom de "Gudimetla, Leela Sankar via Lists.Fd.Io" 

Répondre à : "lgudi...@ciena.com" 
Date : vendredi 13 mars 2020 à 00:13
À : "vpp-dev@lists.fd.io" 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] Tap connect CLI

Hi,

I see that the tap connect CLI has been deprecated which was used for creating 
a pair of interfaces between container and host.
Is there any other CLI/mechanism available in VPP-1908 to achieve the same?

Thanks,
Leela sankar Gudimetla
Embedded Software Engineer 3 |  Ciena
San Jose, CA, USA
M | +1.408.904.2160
[Ciena Logo]

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

View/Reply Online (#15770): https://lists.fd.io/g/vpp-dev/message/15770
Mute This Topic: https://lists.fd.io/mt/71914759/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] Query about internal apps

[Vivek Gupta]

Hi Florin,

Please see inline.

Regards,
Vivek

-Original Message-
From: Florin Coras  
Sent: Thursday, March 12, 2020 8:09 PM
To: Ole Troan 
Cc: Vivek Gupta ; kusumanjal...@gmail.com; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Query about internal apps

Hi Ole, Vivek,

If I understand this right, you’re looking to intercept l2 packets in vpp 
(supposedly only from certain hosts), process them and maybe generate some 
return traffic. What is the payload of those l2 packets? 
Vivek> We are trying to intercept the complete l2 packets, coming on certain 
interfaces, and pass it on the user application and user application can then 
process those and forward them to the actual destination. 
Payload will be the regular ethernet packets.

You could write a feature that inspects all traffic on a certain interface and 
intercepts the packets that you’re interested in. 
Vivek> However, for these intercepted packets, what should be right way to pass 
it to the VPP internal application? For the session layer, we would need a 
transport_connection for L2_proto and pass traffic through the session using 
the fake tuple lookup. 

Alternatively, session layer supports pure shared memory transports, i.e., 
cut-through connections (see slide 16-18 here [1]). For instance, a vpp builtin 
application could receive data directly over shared memory from an external 
application. However, currently session layer only knows how to lookup 
5-tuples, so the two peers (external app and vpp builtin app) need to agree on 
a shared “fake” 5-tuple.  


Regards,
Florin

[1] https://wiki.fd.io/images/9/9c/Vpp-hoststack-kc-eu19.pdf

> On Mar 12, 2020, at 1:09 AM, Ole Troan  wrote:
> 
> Hi Vivek,
> 
>> We are trying to achieve the mechanism, something similar to TAP interface, 
>> in VPP.
>> 
>> So, the packets coming out of the TAP interface, will be directed directly 
>> to the application. The application will receive the packets, coming via TAP 
>> interface, process them and send it down via the Host stack.
>> 
>> Possible options, we could think of are:-
>> - Enhance the session layer to provide a L2 transport mechanism and add 
>> nodes like tap-input and tap-out which would achieve the same.
>> - Use the existing session layer by doing a IP/UDP encap and send it to the 
>> APP, via session layer and use existing mechanism.
>>  This introduces an overhead of additional encap/decap.
>> 
>> We wanted to check if there is any alternate option to directly transfer the 
>> packets from the plugin to the VPP App, without even involving the session 
>> layer and have no additional overhead encap/decap,
> 
> Is this similar to the idea of routing directly to the application?
> I.e. give each application an IP address (easier with IPv6), and the 
> application itself links in whatever transport layer it needs. In a VPP 
> context the application could sit behind a memif interface. The application 
> would need some support for IP address assignment, ARP/ND etc.
> Userland networking taken to the extreme. ;-)
> 
> Best regards,
> Ole

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

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