Age | Commit message (Collapse) | Author | Files | Lines |
|
New startup config command:
unix {
runtime-dir /run/vpp
}
Also, adds recursive mkdir funtion for use in deifferent places
like cli-config socket path and dpdk hugepage directory path.
Change-Id: I1446ceab9c220c25804e73a743a3ebb383450124
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ib4de018a84e9c94df26a8870bf1b04e26204ace1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I902f54618c4e1f649af11497c1cb10922e43755a
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ief02eb1109a1bc463665d9747e9fa4e0c0e3d7e0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
- removed memif details message from memif API
Change-Id: I21185e7678f375cc10639cdbc3ad2fd84bc95459
Signed-off-by: Jakub Grajciar <grajciar.jakub@gmail.com>
|
|
The standard behaviour for binary API is that zeroed arguments are
treated as if the default values were set. This way the configurator
does not need to know what default values are.
This, however, wasn't the case for rx_queues and tx_queues in
memif_create binary API message.
Change-Id: Ib588b472823f6bbb5ef12a798d68b0dda6dd2139
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
|
|
If interface is down and queues are not configured then we are not able
to change rx-mode. This change introducess default mode which is stored
per interface and applied if driver wants.
Change-Id: I70149c21c1530eafc148d5e4aa03fbee53dec62f
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Iff550fd65f6e559b9fdfbbd53ef92d287c18166c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
In IP mode memif interface is L3 point-to-point interfaces and
we don't pass l2 header. There is no l2 header rewrite operation and
received packets are sent straight to ip4-input / ip6-input nodes.
Change-Id: I4177f3fce3004da7ecf14d235006ae053fcf3f09
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Add optional keywords to show memif to allow display a particular
interface and option to display the descriptor tables. The new syntax for
the show memif command is now
show memif [<interface>] [descriptors]
Change-Id: I20696bbea1142bdc152b6e351c6ece24b1cf5500
Signed-off-by: Steven <sluong@cisco.com>
|
|
Current memif interface supports frame size up to 2048. This patch is to
enhance memif to support jumbo frames.
On tx (writing buffers to the ring), keep reading the next buffer in vlib
when the flag VLIB_BUFFER_NEXT_PRESENT and merge it to the same ring entry.
Use descriptor chaining if the buffer is not big enough.
On rx (reading buffers from the ring), if the packet is greater than 2048,
create multiple vlib buffers, chained with the VLIB_BUFFER_NEXT_PRESENT.
Testing:
Because the ping command provided by VPP does not support jumbo frames,
I have to use linux ping. Here is the set up that I use for testing.
VM1 --- vhost ---- VPP1 --- memif --- VPP2 --- vhost --- VM2
Create vhost-user interfaces between VM1 and VPP1 and between VPP2 and VM2
VM configuration:
Set the interface mtu on the VM, e.g 9216 to support jumbo frames.
create static route and static arp on VM1 to VM2 and vice versa.
Use iperf3 or ping -s 8000 from VM1 to VM2 or vice versa.
Sample run
sluong@ubuntu:~$ ping 131.1.1.1 -c1 -s 8000
ping 131.1.1.1 -c1 -s 8000
PING 131.1.1.1 (131.1.1.1) 8000(8028) bytes of data.
8008 bytes from 131.1.1.1: icmp_seq=1 ttl=62 time=0.835 ms
--- 131.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.835/0.835/0.835/0.000 ms
sluong@ubuntu:~$
DBGvpp# sh interface memif0
Name Idx State Counter Count
memif0 1 up rx packets 1
rx bytes 8042
tx packets 1
tx bytes 8042
ip4 1
DBGvpp#
Change-Id: I469bece3d45a790dceaee1d6a8e976bd018feee2
Signed-off-by: Steven <sluong@cisco.com>
|
|
Change-Id: Ide6d26d6fcc81be6f26ac0abe2cd0d6a0838cfe6
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I4d41def83a23f13701f1ddcea722d481e4c85cbc
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I01dc439fc84f9213e55ba56982eff34474637115
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
|
|
Check -1 for return from read prior to using the data
Change-Id: Ibab7309244de488737ea7938b334fab495bf855d
Signed-off-by: Steven <sluong@cisco.com>
|
|
- Add rx-queues and tx-queues option to the create memif CLI
- Add vlib_worker_thread_barrier_sync () to memif_conn_fd_read_ready () as
the latter function may disconnect the ring and clean up the shared memory.
- On transmit, write the rid (queue number) to the socket.
- On receive, read the rid and trigger the interrupt for the corresponding
thread.
Change-Id: If1c7e26c7124174678f047909cbc33e931eaac8c
Signed-off-by: Steven <sluong@cisco.com>
|
|
When I type in 'quit' on the slave instance, the master instance crashes
on this line.
0: /home/sluong/vpp-master/vpp/build-data/../src/vlib/unix/input.c:200 (linux_epoll_input) assertion `! pool_is_free (um->file_pool, _e)' fails
Aborted (core dumped)
Below is the decode from gdb
line_number=0, fmt=0x7f57af6cc9a0 "%s:%d (%s) assertion `%s' fails")
at /home/sluong/vpp-master/vpp/build-data/../src/vppinfra/error.c:143
vm=0x7f57af8e2400 <vlib_global_main>, node=0x7f576d40ad80, frame=0x0)
at /home/sluong/vpp-master/vpp/build-data/../src/vlib/unix/input.c:200
vm=0x7f57af8e2400 <vlib_global_main>, node=0x7f576d40ad80,
type=VLIB_NODE_TYPE_PRE_INPUT, dispatch_state=VLIB_NODE_STATE_POLLING,
frame=0x0, last_time_stamp=1525665215050617)
at /home/sluong/vpp-master/vpp/build-data/../src/vlib/main.c:1016
vm=0x7f57af8e2400 <vlib_global_main>, is_main=1)
at /home/sluong/vpp-master/vpp/build-data/../src/vlib/main.c:1500
I am able to reproduce the problem consistently with the below procedure.
1. Create 3 memif interfaces between slave and master instances.
2. Type 'quit' on the slave. Neither crashes the first time.
3. Bring back the slave. Type 'quit' on the master. Neither crashes.
4. Bring back the master. Type 'quit' on the slave. The master crashes.
There are two places the interrupt line is disconnected and the unix file is
removed via the call unix_file_del ()
1. memif_int_fd_read_ready ()
2. memif_disconnect () which is called via multiple places in memif.
When the crash happens, the unix file was removed from memif_disconnect ()
via memif_conn_fd_read_ready () with size of the message == 0 in recvmsg ().
It is noted when the unix file was removed from memif_int_fd_read_ready (),
it never crashes. It is a race condition. However, if I follow the
aformentioned procedure, the crash always happens.
The reason the crash happens when memif_disconnect () removes the unix file
is because there may still be pending input in linux_epoll_input (). When
linux_epoll_input () tries to access the unix file via the line 200
unix_file_t *f = pool_elt_at_index (um->file_pool, i);
it crashes.
We could add code in linux_epoll_input () to avoid the crash if the index
for the particular file_pool is already free. Or we could fix memif to not
remove the unix file in memif_conn_fd_read_ready () when recvmsg () got 0
byte and just postpone the unix file deletion in memif_int_fd_read_ready ()
later after linux_epoll_input () got a chance to run to empty the input
stream.
I choose to fix the problem in the latter approach. I split the function
memif_disconnect () into two parts. For the code path which
memif_conn_fd_read_ready () calls memif_disconnect (), it does not remove the
unix file. All other calls to memif_disconnect () will continue to do what
it uses to do to avoid regression.
Please let me know if I should fix the problem other way.
Change-Id: I8efe2a3d24c6581609bc7b6fe82c2b59c22d8e4b
Signed-off-by: Steven <sluong@cisco.com>
|
|
Migrate memif to use vnet device infra APIs. No new function is added.
Change-Id: I70e440d2ae1e673876365041f31fe78997aceecf
Signed-off-by: Steven <sluong@cisco.com>
|
|
Change-Id: I72298aaae7d172082ece3a8edea4217c11b28d79
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I220b0b95449f24cc547206e38ab8e10019115ec0
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
|
|
This patch deprecates stack-based thread identification,
Also removes requirement that thread stacks are adjacent.
Finally, possibly annoying for some folks, it renames
all occurences of cpu_index and cpu_number with thread
index. Using word "cpu" is misleading here as thread can
be migrated ti different CPU, and also it is not related
to linux cpu index.
Change-Id: I68cdaf661e701d2336fc953dcb9978d10a70f7c1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I935620798d6fe82b99b6bd564749e20a189b4ae3
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
|
|
Change-Id: I844ec53b55ceaa1e00996f5cf8a018537ea8b481
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
|
|
Change-Id: I86089e9bb604adfc260a111685001be1c897ce53
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I94c06b07a39f07ceba87bf3e7fcfc70e43231e8a
Signed-off-by: Damjan Marion <damarion@cisco.com>
Co-Authored-By: Milan Lenco <Milan.Lenco@pantheon.tech>
|