[vpp-dev] pppoe plugin + vlan
Hello folks, I'm trying to figure out how to make PPPoE plugin work with dot1q subinterfaces (and maybe with qinq interfaces). I've made a prototype with the following things: 1) I enabled arc "device-input" with the next node "pppoe-input" on the pppoe cp interface: to get rid of L3_MAC_MISMATCH error (it's a bit controversial thing, but I didn't find any other proper way to get it working). 2) Because of the previous point - I rewrite parsing in the "pppoe-input" node to parse all headers from the scratch. 3) I get rid of "local mac" because it's more obvious to get mac address directly from encap interface when you filling up DPO adjacency. Anyway, in the case of the dot1q subinterface, we need to get vlan tags to fill the DPO adjacency. I'm new to VPP, so maybe some of these things are not good from some points of view. So it would be great if someone will look at it (and maybe propose something). Also, there are some open questions: - Should we strip the vlan tag before we sent pppoe packets to the cp interface? (I keep it, but my cp is ok with parsing vlan tags). - Is there any sense in pointing local mac address when we creating a pppoe session? We can get it from the encap interface. https://gerrit.fd.io/r/c/vpp/+/26964 -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16293): https://lists.fd.io/g/vpp-dev/message/16293 Mute This Topic: https://lists.fd.io/mt/74099572/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] pppoe plugin + vlan
Hello again, Are there any users of pppoe-plugins? Or maybe any maintainers of this plugin? On Sat, 9 May 2020 at 20:16, Stanislav Zaikin wrote: > Hello folks, > > I'm trying to figure out how to make PPPoE plugin work with dot1q > subinterfaces (and maybe with qinq interfaces). > > I've made a prototype with the following things: > 1) I enabled arc "device-input" with the next node "pppoe-input" on the > pppoe cp interface: to get rid of L3_MAC_MISMATCH error (it's a bit > controversial thing, but I didn't find any other proper way to get it > working). > 2) Because of the previous point - I rewrite parsing in the "pppoe-input" > node to parse all headers from the scratch. > 3) I get rid of "local mac" because it's more obvious to get mac address > directly from encap interface when you filling up DPO adjacency. Anyway, in > the case of the dot1q subinterface, we need to get vlan tags to fill the > DPO adjacency. > > I'm new to VPP, so maybe some of these things are not good from some > points of view. So it would be great if someone will look at it (and maybe > propose something). > > Also, there are some open questions: > - Should we strip the vlan tag before we sent pppoe packets to the cp > interface? (I keep it, but my cp is ok with parsing vlan tags). > - Is there any sense in pointing local mac address when we creating a > pppoe session? We can get it from the encap interface. > > https://gerrit.fd.io/r/c/vpp/+/26964 > > -- > Best regards > Stanislav Zaikin > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16348): https://lists.fd.io/g/vpp-dev/message/16348 Mute This Topic: https://lists.fd.io/mt/74099572/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Best way to punt packets to the control plane
Hello, What's the best way to punt L2 packets to the control plane? If I'm correct, now we have these ways: - VPP communication library (it works only for TCP and UDP packets) - a punt through Unix socket (it's only one-way punt) - also, we can redirect IP packets (but it's not flexible and not working for L2 packets) I am wondering because PPPoE plugin punts control packets with just redirecting it on another interface. But when VPP gets packets back from the control plane interface - it's just not working (because of mac l3 mismatch). And to make it worked I had to do some ugly hacks (such as turning on "device-input" for pppoe-input node on control plane interface [1]). May be there any other ways to do it? [1] https://gerrit.fd.io/r/c/vpp/+/26964 -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16660): https://lists.fd.io/g/vpp-dev/message/16660 Mute This Topic: https://lists.fd.io/mt/74692556/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] Best way to punt packets to the control plane
You could write a plugin to redirect these packets to some interface as the pppoe plugin does. But in this case, you would need to keep some kind of state (because these packets could arrive from any interface and you would redirect it just to one interface. you need some state to send packets back). On the other hand, you could adopt (by this I mean rewrite) the "router" plugin to make it work with the current vpp release. With this plugin, you can process packets in the Linux network stack. However both these ways seem to me ugly, that's why I've asked is there any other way to make a dp-cp channel for exchanging the packets. On Mon, 8 Jun 2020 at 22:09, wrote: > I am also searching best way to receive the packets from Device_Input > node? I want to receive raw packets to my application. how can I achieve > that? is there any way to receive complete L2 Packet receive at > application? When I check the documentation I can find few ways to > communicate the application with VPP but is there any way to communicate > directly with any particular node? > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16708): https://lists.fd.io/g/vpp-dev/message/16708 Mute This Topic: https://lists.fd.io/mt/74692556/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] p2p interfaces and clib_bihash_init (and oom)
Hello folks,
I've tried to set up vpp to handle many pppoe connections. But I faced OOM
issue:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x767b3899 in __GI_abort () at abort.c:79
#2 0xcef2 in os_panic () at
/home/zstas/vpp_gerrit/src/vpp/vnet/main.c:366
#3 0x76a51183 in os_out_of_memory () at
/home/zstas/vpp_gerrit/src/vppinfra/unix-misc.c:222
#4 0x77994f1e in alloc_aligned_24_8 (h=0x7fffb85880c0, nbytes=64)
at /home/zstas/vpp_gerrit/src/vppinfra/bihash_template.c:60
#5 0x77994fe0 in clib_bihash_instantiate_24_8 (h=0x7fffb85880c0)
at /home/zstas/vpp_gerrit/src/vppinfra/bihash_template.c:86
...
#9 0x77a02fa5 in adj_nbr_insert (nh_proto=FIB_PROTOCOL_IP4,
link_type=VNET_LINK_IP4, nh_addr=0x77c3da60 ,
sw_if_index=1365, adj_index=1351) at
/home/zstas/vpp_gerrit/src/vnet/adj/adj_nbr.c:83
#10 0x77a0345b in adj_nbr_alloc (nh_proto=FIB_PROTOCOL_IP4,
link_type=VNET_LINK_IP4, nh_addr=0x77c3da60 ,
sw_if_index=1365) at /home/zstas/vpp_gerrit/src/vnet/adj/adj_nbr.c:200
...
#22 0x7fffb018033d in vnet_pppoe_add_del_session (a=0x7fffb7420d10,
sw_if_indexp=0x7fffb7420cdc) at
/home/zstas/vpp_gerrit/src/plugins/pppoe/pppoe.c:418
Despite the fact PPPoE interface is P2P interface, there is the logic in
vpp which create a pretty big adj table:
BV(clib_bihash_init) (adj_nbr_tables[nh_proto][sw_if_index],
"Adjacency Neighbour table",
ADJ_NBR_DEFAULT_HASH_NUM_BUCKETS,
ADJ_NBR_DEFAULT_HASH_MEMORY_SIZE);
At first, I've tried to to fix it with allocating a smaller table:
int numbuckets = ADJ_NBR_DEFAULT_HASH_NUM_BUCKETS;
int memsize = ADJ_NBR_DEFAULT_HASH_MEMORY_SIZE;
if( vnet_sw_interface_is_p2p( vnet_get_main(), sw_if_index ) == 1 ) {
numbuckets = 4;
memsize = 32 << 8;
}
BV(clib_bihash_init) (adj_nbr_tables[nh_proto][sw_if_index],
"Adjacency Neighbour table",
numbuckets,
memsize);
But I saw that hugetable pages still consumed every time pppoe connection
is coming up. I've looked into the code of alloc_aligned function, and it
seems to me that a new memory page will be allocated in any case (when you
are initializing new hash table). But how we can deal with situations when
we have hundreds of thousands of interfaces. Is there a way to prevent
this behavior? Can we allocate an adj table in some kind of memory pool, or
keep one adj table for all p2p interfaces?
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16872): https://lists.fd.io/g/vpp-dev/message/16872
Mute This Topic: https://lists.fd.io/mt/75261778/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] queue drain warning on calling vapi_disconnect()
Hi Chinmaya,
If you are using C++ headers (as I do), you can deal with it by adding
periodic control pings to VPP.
As far as I understand, vapi deals automatically with these control packets
from VPP. But if your code doesn't interact with VPP some time, these
control packets will be stored in a queue. And adding periodic control
pings would solve the problem.
On Fri, 31 Jul 2020 at 15:19, Dave Barach via lists.fd.io wrote:
> For whatever reason, your application didn’t process 3x memclnt_keepalive
> messages. Vpp sends one of these messages every 10 seconds.
>
>
>
> vpp# sh api messsage table
>
> ID Name
>
>
>
> 21 memclnt_keepalive
>
>
>
>
>
> The code in question runs after the client sends a MEMCLNT_DELETE message.
> Purpose: make sure that we don’t leak message buffers...
>
>
>
> /* drain the queue */
>
> if (ntohs (rp->_vl_msg_id) != VL_API_MEMCLNT_DELETE_REPLY)
>
> {
>
> clib_warning ("queue drain: %d", ntohs (rp->_vl_msg_id));
>
> vl_msg_api_handler ((void *) rp);
>
> continue;
>
> }
>
>
>
> HTH... Dave
>
>
>
> *From:* vpp-dev@lists.fd.io *On Behalf Of *Chinmaya
> Aggarwal
> *Sent:* Friday, July 31, 2020 12:42 AM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] queue drain warning on calling vapi_disconnect()
>
>
>
> Hi,
> We are integrating VAPI in our application. We created connection to vapi
> using vapi_connect() and everything works fine for us. But during
> termination, when we call vapi_disconnect() we get the following warning in
> our logs multiple times :-
>
> vl_client_disconnect:323: queue drain: 21
>
> vl_client_disconnect:323: queue drain: 21
>
> vl_client_disconnect:323: queue drain: 21
>
> Can anyone suggest why this is happening?
>
> Thanks and Regards,
> Chinmaya Agarwal.
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17122): https://lists.fd.io/g/vpp-dev/message/17122
Mute This Topic: https://lists.fd.io/mt/75901691/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vapi and counters for interfaces
Hello folks, I want to get counters for interfaces through the VAPI. Is it possible? I can't find any methods to do it. I am using C++ VAPI headers, but any references with C would be helpful too. Or I would be glad if anyone would tell me the proper way to collect counters for all interfaces in VPP. -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17243): https://lists.fd.io/g/vpp-dev/message/17243 Mute This Topic: https://lists.fd.io/mt/76205779/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 allocate new buffer correctly
at /home/zstas/vpp/src/vppinfra/error.c:143 #5 0x76c644fc in vlib_buffer_validate_alloc_free (vm=0x76d67bc0 , buffers=0x7fffafc725f0, n_buffers=1, expected_state=VLIB_BUFFER_KNOWN_ALLOCATED) at /home/zstas/vpp/src/vlib/buffer.c:366 #6 0x76c4a08c in vlib_buffer_pool_put (vm=0x76d67bc0 , buffer_pool_index=0 '\000', buffers=0x7fffafc725f0, n_buffers=1) at /home/zstas/vpp/src/vlib/buffer_funcs.h:754 /* omit */ (gdb) select 6 (gdb) print buffers[0] $6 = 653093 Maybe I need to set some flags on the allocated buffer? Or what else am I missing? -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18518): https://lists.fd.io/g/vpp-dev/message/18518 Mute This Topic: https://lists.fd.io/mt/79705076/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] how to allocate new buffer correctly
Hello Damjan, Thanks for the response. Nothing special happens, I just want to send this packet to another interface. Interface TX is just a regular VPP node (TX for tapv2/virtio). This packet went to error-node because the interface was down. But if I set interface up, everything looks just the same (error on freeing this buffer): (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x76936859 in __GI_abort () at abort.c:79 #2 0x76bd73bf in os_panic () at /home/zstas/vpp/src/vppinfra/unix-misc.c:177 #3 0x76b37ea4 in debugger () at /home/zstas/vpp/src/vppinfra/error.c:84 #4 0x76b38295 in _clib_error (how_to_die=2, function_name=0x76d39c40 <__FUNCTION__.16> "vlib_buffer_validate_alloc_free", line_number=366, fmt=0x76d3974a "%s %U buffer 0x%x") at /home/zstas/vpp/src/vppinfra/error.c:143 #5 0x76c644fc in vlib_buffer_validate_alloc_free (vm=0x76d67bc0 , buffers=0x7fffafc730b0, n_buffers=1, expected_state=VLIB_BUFFER_KNOWN_ALLOCATED) at /home/zstas/vpp/src/vlib/buffer.c:366 #6 0x76f753ec in vlib_buffer_pool_put (vm=0x76d67bc0 , buffer_pool_index=0 '\000', buffers=0x7fffafc730b0, n_buffers=1) at /home/zstas/vpp/src/vlib/buffer_funcs.h:754 #7 0x76f75c29 in vlib_buffer_free_inline (vm=0x76d67bc0 , buffers=0x7fffb74f0044, n_buffers=0, maybe_next=1) at /home/zstas/vpp/src/vlib/buffer_funcs.h:924 #8 0x76f75c79 in vlib_buffer_free (vm=0x76d67bc0 , buffers=0x7fffb74f0040, n_buffers=1) at /home/zstas/vpp/src/vlib/buffer_funcs.h:943 #9 0x76f75d1a in vlib_buffer_free_from_ring (vm=0x76d67bc0 , ring=0x7fffb74f0040, start=0, ring_size=256, n_buffers=1) at /home/zstas/vpp/src/vlib/buffer_funcs.h:991 #10 0x76f79af4 in virtio_free_used_device_desc_split (vm=0x76d67bc0 , vring=0x7fffb75ab540, node_index=679) at /home/zstas/vpp/src/vnet/devices/virtio/device.c:200 #11 0x76f79dc2 in virtio_free_used_device_desc (vm=0x76d67bc0 , vring=0x7fffb75ab540, node_index=679, packed=0) at /home/zstas/vpp/src/vnet/devices/virtio/device.c:277 #12 0x76f7baed in virtio_device_class_tx_fn_hsw (vm=0x76d67bc0 , node=0x7fffb6b73800, frame=0x7fffb96ff8c0) at /home/zstas/vpp/src/vnet/devices/virtio/device.c:1017 #13 0x76cba2e2 in dispatch_node (vm=0x76d67bc0 , node=0x7fffb6b73800, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb96ff8c0, last_time_stamp=1108992938029) at /home/zstas/vpp/src/vlib/main.c:1223 #14 0x76cbaa19 in dispatch_pending_node (vm=0x76d67bc0 , pending_frame_index=1, last_time_stamp=1108992938029) at /home/zstas/vpp/src/vlib/main.c:1384 #15 0x76cbcdd3 in vlib_main_or_worker_loop (vm=0x76d67bc0 , is_main=1) at /home/zstas/vpp/src/vlib/main.c:1912 #16 0x76cbd848 in vlib_main_loop (vm=0x76d67bc0 ) at /home/zstas/vpp/src/vlib/main.c:2040 #17 0x76cbe66b in vlib_main (vm=0x76d67bc0 , input=0x7fffafc73fb0) at /home/zstas/vpp/src/vlib/main.c:2286 #18 0x76d29ac5 in thread0 (arg=140737334639552) at /home/zstas/vpp/src/vlib/unix/main.c:670 #19 0x76b56f10 in clib_calljmp () at /home/zstas/vpp/src/vppinfra/longjmp.S:123 #20 0x7fffd150 in ?? () #21 0x76d2a095 in vlib_unix_main (argc=28, argv=0x55631e50) at /home/zstas/vpp/src/vlib/unix/main.c:747 #22 0xcd8b in main (argc=28, argv=0x55631e50) at /home/zstas/vpp/src/vpp/vnet/main.c:338 On Fri, 15 Jan 2021 at 19:57, Damjan Marion wrote: > > This looks right (except the wrong assumption that vlib_get_frame_to_node > will give you empty frame). > > > What happens between this code and error-drop node? Is interface TX also > your custom code? > > — > Damjan > > > On 15.01.2021., at 17:03, Stanislav Zaikin wrote: > > Hello, > > I'm trying to reincarnate router plugin. But I stuck with a pretty simple > thing, when I need to allocate a buffer to store a packet from a tap > device, everything is going well. But when the next node decides to free > this buffer I get a clib_error. > > Basically, code is pretty simple and straightforward: > u32 bi = ~0; > vlib_buffer_t * b; > > if( vlib_buffer_alloc (vm, &bi, 1) != 1 ) > //err handling > > b = vlib_get_buffer (vm, bi); > VLIB_BUFFER_TRACE_TRAJECTORY_INIT(b); > > n_bytes = read (fd, b->data, vlib_buffer_get_default_data_size (vm)); > // err handling > > b->current_length = n_bytes; > vnet_buffer (b)->sw_if_index[VLIB_RX] = sw_if_index; > vnet_buffer (b)->sw_if_index[VLIB_TX] = sw_if_index; > > vnet_hw_interface_t * hw; > vlib_frame_t * new_frame; > u32 * to_next; > > hw = vnet_get_hw_interface (vnet_get_main (), sw_if_index); > > new_frame = vlib_get_frame_to_node (vm, hw->output_node_index); > to_next = vlib_frame_vector_a
Re: [vpp-dev] how to allocate new buffer correctly
I've dug more into this issue. And I noticed strange thing:
187 {
(gdb) next
188 tap_inject_main_t * im = tap_inject_get_main ();
(gdb)
190 u32 bi = ~0;
(gdb)
194 sw_if_index = tap_inject_lookup_sw_if_index_from_tap_fd (fd);
(gdb)
195 if (sw_if_index == ~0)
(gdb)
199 if( vlib_buffer_alloc (vm, &bi, 1) != 1 )
(gdb)
202 b = vlib_get_buffer (vm, bi);
(gdb)
207 n_bytes = read (fd, b->data, vlib_buffer_get_default_data_size (vm));
(gdb)
208 if (n_bytes < 0)
(gdb) print b
$31 = (vlib_buffer_t *) 0x10027db5c0
(gdb) print *b
$32 = {{cacheline0 = 0x10027db5c0 "", current_data = 0, current_length
= 0, flags = 0, flow_id = 0, ref_count = 1 '\001', buffer_pool_index =
0 '\000', error = 0, next_buffer = 0, {current_config_index = 0,
punt_reason = 0}, opaque = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
template_end = 0x10027db600 "", second_half = 0x10027db600 "",
trace_handle = 0, total_length_not_including_first_buffer = 0, opaque2
= {
0 }, headroom = 0x10027db640 "", pre_data =
'\000' , "\001", data = 0x10027db6c0 "33"}}
(gdb) print bi
$33 = 653015
(gdb) call vlib_buffer_is_known (vm, bi)
$34 = VLIB_BUFFER_KNOWN_FREE
For some reason the allocated buffer was marked as free. The only
function that could change its state is
vlib_buffer_validate_alloc_free.
always_inline __clib_warn_unused_result u32
vlib_buffer_alloc_from_pool (vlib_main_t * vm, u32 * buffers, u32 n_buffers,
u8 buffer_pool_index)
{
/* omit */
if (CLIB_DEBUG > 0)
vlib_buffer_validate_alloc_free (vm, buffers, n_buffers,
VLIB_BUFFER_KNOWN_FREE);
return n_buffers;
But there's another strange issue. I've tried to debug it with gdb and
sometimes vlib_buffer_validate_alloc_free isn't calling for some reason:
Thread 1 "vpp_main" hit Breakpoint 1, vlib_buffer_alloc_from_pool
(buffer_pool_index=0 '\000', n_buffers=1, buffers=0x7fffafc727e0,
vm=0x76d67bc0 )
at /usr/include/vlib/buffer_funcs.h:569
569 vlib_buffer_main_t *bm = vm->buffer_main;
(gdb) next
585 bp = vec_elt_at_index (bm->buffer_pools, buffer_pool_index);
(gdb)
586 bpt = vec_elt_at_index (bp->threads, vm->thread_index);
(gdb)
588 dst = buffers;
(gdb)
589 n_left = n_buffers;
(gdb)
590 len = bpt->n_cached;
(gdb)
593 if (len >= n_buffers)
(gdb)
595 src = bpt->cached_buffers + len - n_buffers;
(gdb)
596 vlib_buffer_copy_indices (dst, src, n_buffers);
(gdb)
597 bpt->n_cached -= n_buffers;
(gdb)
602 return n_buffers;
(gdb) nextvlib_buffer_alloc_on_numa (numa_node=0, n_buffers=1,
buffers=0x7fffafc727e0, vm=0x76d67bc0 ) at
/usr/include/vlib/buffer_funcs.h:664
664 return vlib_buffer_alloc_from_pool (vm, buffers, n_buffers, index);
(gdb) cont
Continuing.
[New Thread 0x7fffacc9b700 (LWP 127836)]
[Thread 0x7fffacc9b700 (LWP 127836) exited]
Thread 1 "vpp_main" hit Breakpoint 1, vlib_buffer_alloc_from_pool
(vm=0x76d67bc0 , buffers=0x7fffb74e4dfc,
n_buffers=64, buffer_pool_index=0 '\000')
at /home/zstas/vpp/src/vlib/buffer_funcs.h:569
569 vlib_buffer_main_t *bm = vm->buffer_main;
(gdb) next
585 bp = vec_elt_at_index (bm->buffer_pools, buffer_pool_index);
(gdb)
586 bpt = vec_elt_at_index (bp->threads, vm->thread_index);
(gdb)
588 dst = buffers;
(gdb)
589 n_left = n_buffers;
(gdb)
590 len = bpt->n_cached;
(gdb)
593 if (len >= n_buffers)
(gdb)
595 src = bpt->cached_buffers + len - n_buffers;
(gdb)
596 vlib_buffer_copy_indices (dst, src, n_buffers);
(gdb)
597 bpt->n_cached -= n_buffers;
(gdb) *600 vlib_buffer_validate_alloc_free (vm, buffers, n_buffers,
*(gdb)
602 return n_buffers;
(gdb)
648 }
(gdb) cont
I have no idea why in the first run vlib_buffer_validate_alloc_free
hadn't been called (second run was ok). Because there is the same code
according to debug info in gdb.
I hope you'll point me where I'm wrong.
On Sat, 16 Jan 2021 at 12:07, Stanislav Zaikin via lists.fd.io wrote:
> Hello Damjan,
> Thanks for the response.
>
> Nothing special happens, I just want to send this packet to another
> interface.
> Interface TX is just a regular VPP node (TX for tapv2/virtio). This packet
> went to error-node because the interface was down. But if I set interface
> up, everything looks just the same (error on freeing this buffer):
>
> (gdb) bt
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1 0x76936859 in __GI_abort () at abort.c:79
> #2 0x76bd73bf in os_panic () at
> /home/zstas/vpp/src/vppinfra/unix-misc.c:177
> #3 0x76b37ea4 in debugger () at
> /home/zstas/vpp/src/vppinfra/error.c:84
> #4 0x76b38295 in _clib_error
Re: [vpp-dev] how to allocate new buffer correctly
Hi Matthew,
Many thanks for opening my eyes. Now everything is perfectly clear for me.
On Mon, 18 Jan 2021 at 18:10, Matthew Smith wrote:
>
> Hi Stanislav,
>
> As you noted, vlib_buffer_validate_alloc_free() is the only place that
> would change the "known state" of a buffer. All of the calls to that
> function are in vlib/buffer_funcs.h in inline functions in conditional
> blocks with a condition like 'if (CLIB_DEBUG > 0)'. One of those calls is
> made when vlib_buffer_alloc() is called - it
> calls vlib_buffer_alloc_on_numa() which calls vlib_buffer_alloc_from_pool()
> which has several invocations of vlib_buffer_validate_alloc_free() which
> all look like this:
>
> if (CLIB_DEBUG > 0)
> vlib_buffer_validate_alloc_free (vm, buffers, n_buffers,
> VLIB_BUFFER_KNOWN_FREE);
>
> Since these calls occur in inline functions and are only made when
> CLIB_DEBUG is defined as a value greater than 0, it seems like the issue is
> probably that VPP and the router plugin are being built with CLIB_DEBUG
> defined to different values - one of them is being built with CLIB_DEBUG ==
> 0 and one of them is built with CLIB_DEBUG > 0. Since your backtrace
> shows vlib_buffer_validate_alloc_free() being called from one of the VPP
> virtio nodes, that suggests that VPP was built with CLIB_DEBUG > 0. You are
> probably building the router plugin without explicitly defining a value for
> CLIB_DEBUG so it is ending up defined to 0. To remedy the issue, you could
> either build VPP with CLIB_DEBUG set to 0 (run 'make build-release' instead
> of 'make build') or explicitly define CLIB_DEBUG when you build the router
> plugin.
>
> -Matt
>
>
> On Sat, Jan 16, 2021 at 5:50 AM Stanislav Zaikin
> wrote:
>
>> I've dug more into this issue. And I noticed strange thing:
>>
>> 187 {
>> (gdb) next
>> 188tap_inject_main_t * im = tap_inject_get_main ();
>> (gdb)
>> 190u32 bi = ~0;
>> (gdb)
>> 194sw_if_index = tap_inject_lookup_sw_if_index_from_tap_fd (fd);
>> (gdb)
>> 195if (sw_if_index == ~0)
>> (gdb)
>> 199if( vlib_buffer_alloc (vm, &bi, 1) != 1 )
>> (gdb)
>> 202b = vlib_get_buffer (vm, bi);
>> (gdb)
>> 207n_bytes = read (fd, b->data, vlib_buffer_get_default_data_size (vm));
>> (gdb)
>> 208if (n_bytes < 0)
>> (gdb) print b
>> $31 = (vlib_buffer_t *) 0x10027db5c0
>> (gdb) print *b
>> $32 = {{cacheline0 = 0x10027db5c0 "", current_data = 0, current_length = 0,
>> flags = 0, flow_id = 0, ref_count = 1 '\001', buffer_pool_index = 0 '\000',
>> error = 0, next_buffer = 0, {current_config_index = 0,
>> punt_reason = 0}, opaque = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
>> template_end = 0x10027db600 "", second_half = 0x10027db600 "", trace_handle
>> = 0, total_length_not_including_first_buffer = 0, opaque2 = {
>> 0 }, headroom = 0x10027db640 "", pre_data = '\000'
>> , "\001", data = 0x10027db6c0 "33"}}
>> (gdb) print bi
>> $33 = 653015
>> (gdb) call vlib_buffer_is_known (vm, bi)
>> $34 = VLIB_BUFFER_KNOWN_FREE
>>
>> For some reason the allocated buffer was marked as free. The only function
>> that could change its state is vlib_buffer_validate_alloc_free.
>>
>> always_inline __clib_warn_unused_result u32
>> vlib_buffer_alloc_from_pool (vlib_main_t * vm, u32 * buffers, u32
>> n_buffers,
>> u8 buffer_pool_index)
>> {
>> /* omit */
>> if (CLIB_DEBUG > 0)
>> vlib_buffer_validate_alloc_free (vm, buffers, n_buffers,
>> VLIB_BUFFER_KNOWN_FREE);
>> return n_buffers;
>>
>> But there's another strange issue. I've tried to debug it with gdb and
>> sometimes vlib_buffer_validate_alloc_free isn't calling for some reason:
>>
>> Thread 1 "vpp_main" hit Breakpoint 1, vlib_buffer_alloc_from_pool
>> (buffer_pool_index=0 '\000', n_buffers=1, buffers=0x7fffafc727e0,
>> vm=0x76d67bc0 )
>> at /usr/include/vlib/buffer_funcs.h:569
>> 569vlib_buffer_main_t *bm = vm->buffer_main;
>> (gdb) next
>> 585bp = vec_elt_at_index (bm->buffer_pools, buffer_pool_index);
>> (gdb)
>> 586bpt = vec_elt_at_index (bp->threads, vm->thread_index);
>> (gdb)
>> 588dst = buffers;
>> (gdb)
>> 589n_left = n_buffers;
>> (gdb)
>> 590len = bpt->n_cached;
>> (gdb)
>> 593if (len >= n_buffers)
>> (gdb)
>> 595src = bpt->ca
Re: [vpp-dev] git push to gerrit fails?
Hi Hemant, You should use "git review" to send the patch. Please see [1]. [1] https://fd.io/docs/vpp/master/gettingstarted/developers/gitreview.html On Tue, 19 Jan 2021 at 21:02, hemant via lists.fd.io wrote: > I cloned the gerrit VPP repo, created a new classify-val branch using git, > made code changes, and used commit. Then, trying “git push”, I fail. Does > any VPP gerrit repo admin need to give me create permissions? Log is > included below. > > > > > > $*git push -u origin classify-val* > > Username for 'https://gerrit.fd.io': hemants > > Password for 'https://hema...@gerrit.fd.io': > > Counting objects: 88, done. > > Delta compression using up to 8 threads. > > Compressing objects: 100% (85/85), done. > > Writing objects: 100% (88/88), 27.77 KiB | 1.98 MiB/s, done. > > Total 88 (delta 79), reused 11 (delta 3) > > remote: Resolving deltas: 100% (79/79) > > remote: error: branch refs/heads/classify-val: > > *remote: You need 'Create' rights to create new references.* > > remote: User: hemants > > remote: Contact an administrator to fix the permissions > > remote: Processing changes: refs: 1, done > > To https://gerrit.fd.io/r/vpp > > ! [remote rejected] classify-val -> classify-val (prohibited by > Gerrit: not permitted: create) > > error: failed to push some refs to 'https://gerrit.fd.io/r/vpp' > > hemant@upper:/tmp/vpp$ > > > > Thanks, > > > > Hemant > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18551): https://lists.fd.io/g/vpp-dev/message/18551 Mute This Topic: https://lists.fd.io/mt/79958182/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] local lookup and tx sw_if_index
Hello, I have a custom node which registered certain protocols (it's basically an old good "router" plugin). After "ip4-local" node VPP sends the packet to this node. But there is no information about TX interface, and I need TX sw_if_index to push my packet to the corresponding tap device. If I've understood correctly vnet_buffer(b0)->sw_if_index[VLIB_TX] is set to fib index. How can I get TX sw_if_index of the destination address after the lookup? 00:00:39:579495: memif-input memif: hw_if_index 1 next-index 4 slot: ring 0 00:00:39:587518: ethernet-input frame: flags 0x1, hw-if-index 1, sw-if-index 1 MPLS: 02:fe:13:14:0e:36 -> 02:fe:4c:84:cc:01 00:00:39:587526: mpls-input MPLS: next mpls-lookup[1] label ttl 64 exp 0 00:00:39:587530: mpls-lookup MPLS: next [6], lookup fib index 0, LB index 33 hash 0 label eos 1 00:00:39:587534: ip4-mpls-label-disposition-pipe rpf-id:-1 ip4, pipe 00:00:39:587539: lookup-ip4-dst fib-index:1 addr:1.1.1.1 load-balance:28 00:00:39:587543: ip4-local TCP: 100.0.0.2 -> 1.1.1.1 tos 0x00, ttl 63, length 60, checksum 0x1f25 dscp CS0 ecn NON_ECN fragment id 0xb693, flags DONT_FRAGMENT TCP: 40740 -> 169 seq. 0x9613 ack 0x flags 0x02 SYN, tcp header: 40 bytes window 64240, checksum 0x0939 00:00:39:587552: tap-inject-tx tap_inject_tx rx_sw_if 1 tx_sw_if 1 tap fd 23 -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18581): https://lists.fd.io/g/vpp-dev/message/18581 Mute This Topic: https://lists.fd.io/mt/80032473/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] local lookup and tx sw_if_index
Hi Neale, I've patched the router plugin a bit to make it work with several VRF tables. For every VRF table it will create a netns inside the host. And for every interface it will create a corresponding tap device. But I need to get TX sw_if_index somehow to properly choose the tx fd of tap interface. I've tried to use VLIB_RX sw_if_index, but it doesn't fit in case with several VRF tables (because RX sw_if_index always will be the interface in the global table). Seems like there should be a way to extract sw_if_index, because there is information about interface in FIB: 1.1.1.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:28 buckets:1 uRPF:29 to:[1339:144612]] [0] [@2]: dpo-receive: 1.1.1.1 on *loop0* But I can't find the right way. Any suggestions are appreciated. BTW your Linux Control Plane Mirror plugin seems very interesting to me. Maybe I'll find my answer there. On Fri, 22 Jan 2021 at 18:52, Neale Ranns wrote: > > > Hi Stanislav, > > > > There is no TX interface information if the packet is for-us. There is > only valid TX interface information if the routing decision was to TX on an > interface. How do you choose the egress Tap? > > > > /neale > > > > > > *From: *vpp-dev@lists.fd.io on behalf of Stanislav > Zaikin via lists.fd.io > *Date: *Friday, 22 January 2021 at 16:29 > *To: *vpp-dev > *Subject: *[vpp-dev] local lookup and tx sw_if_index > > Hello, > > > > I have a custom node which registered certain protocols (it's basically an > old good "router" plugin). > > After "ip4-local" node VPP sends the packet to this node. But there is no > information about TX interface, and I need TX sw_if_index to push my packet > to the corresponding tap device. > > > > If I've understood correctly vnet_buffer(b0)->sw_if_index[VLIB_TX] is set > to fib index. > > How can I get TX sw_if_index of the destination address after the lookup? > > > > 00:00:39:579495: memif-input > > memif: hw_if_index 1 next-index 4 > > slot: ring 0 > > 00:00:39:587518: ethernet-input > > frame: flags 0x1, hw-if-index 1, sw-if-index 1 > > MPLS: 02:fe:13:14:0e:36 -> 02:fe:4c:84:cc:01 > > 00:00:39:587526: mpls-input > > MPLS: next mpls-lookup[1] label ttl 64 exp 0 > > 00:00:39:587530: mpls-lookup > > MPLS: next [6], lookup fib index 0, LB index 33 hash 0 label eos 1 > > 00:00:39:587534: ip4-mpls-label-disposition-pipe > > rpf-id:-1 ip4, pipe > > 00:00:39:587539: lookup-ip4-dst > > fib-index:1 addr:1.1.1.1 load-balance:28 > > 00:00:39:587543: ip4-local > > TCP: 100.0.0.2 -> 1.1.1.1 > > tos 0x00, ttl 63, length 60, checksum 0x1f25 dscp CS0 ecn NON_ECN > > fragment id 0xb693, flags DONT_FRAGMENT > > TCP: 40740 -> 169 > > seq. 0x9613 ack 0x > > flags 0x02 SYN, tcp header: 40 bytes > > window 64240, checksum 0x0939 > > 00:00:39:587552: tap-inject-tx > > tap_inject_tx rx_sw_if 1 tx_sw_if 1 tap fd 23 > > > -- > > Best regards > Stanislav Zaikin > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18584): https://lists.fd.io/g/vpp-dev/message/18584 Mute This Topic: https://lists.fd.io/mt/80032473/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] RFC: Interface Mirroring for Linux Network Stackintegration
Hi Neale, This is exactly what many people waited for! Thank you. If you need any help with this plugin I want to help. On Fri, 22 Jan 2021 at 18:55, Neale Ranns wrote: > > > Dear All, > > > > I’d like to solicit comments for this proposed patch: > > https://gerrit.fd.io/r/c/vpp/+/30759 > > > > this is a scheme that aids with the integration of VPP with the Linux > network stack by mirroring a [user defined] set of interfaces that VPP owns > with tap/tun interfaces in the kernel. More details are in the .rst file. > > > > Thanks, > > /neale > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18585): https://lists.fd.io/g/vpp-dev/message/18585 Mute This Topic: https://lists.fd.io/mt/80033164/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] set IPv6 add fails?
Hi Hemant, I don't think you can add addresses to local0.Try another interface. And you can use "set interface ip address " as well. On Fri, 26 Feb 2021 at 21:11, hemant via lists.fd.io wrote: > vpp# set ip6 address local0 2001::1 > > set ip6 address: unexpected input `2001::1' > > vpp# > > > > A quick search online does not show me any example for how to configure an > IPv6 address using VPP CLI. > > > > Hemant > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18812): https://lists.fd.io/g/vpp-dev/message/18812 Mute This Topic: https://lists.fd.io/mt/80933945/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] plugin tracing?
Hi Hemant, Try something like this: trace filter include upf6 100 trace add dpdk-input 100 dpdk-input for regular dpdk interfaces, virtio-input for tap/virtio interfaces, memif-input for memif interfaces. On Tue, 2 Mar 2021 at 19:58, hemant via lists.fd.io wrote: > Is this how a plugin enables tracing? > > > > vpp# trace filter include upf6 5 > > > > I don’t see any packets with this trace yet. > > > > Is it possible to add trace code to a plugin to support per-node trace? > > > > vpp# trace add upf6 5 > > trace add: node 'upf6' doesn't support per-node tracing. There may be > another way to initiate trace on this node. > > vpp# > > > > Thanks, > > > > Hemant > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18833): https://lists.fd.io/g/vpp-dev/message/18833 Mute This Topic: https://lists.fd.io/mt/81030282/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] VRF does not seem to working for us
Hi Venumadhav, You should specify an ip table for the nexthop with "next-hop-table XX". By default it'd be nexthop in default fib. On Thu, 8 Apr 2021 at 10:40, Venumadhav Josyula wrote: > Hi All, > For VRF configuration does not seem to work for us, we using vpp-20.09. > vpp# show version > vpp v20.09.0-1~0-g94f29f6 built by root on devdocker2.parallelwireless.net > at 2021-04-05T21:52:02 > vpp# > > We are trying to following configuration > > ip table add 100 > set interface ip table vpp-intf19/0/1 100 > set interface ip address vpp-intf19/0/1 10.53.1.189/23 > ip route add 10.43.0.170/32 table 100 via 10.53.0.1 > > here is dump > vpp# show ip fib table 100 > ipv4-VRF:100, fib_index:1, flow hash:[src dst sport dport proto ] epoch:0 > flags:none locks:[CLI:2, ] > 0.0.0.0/0 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:17 to:[0:0]] > [0] [@0]: dpo-drop ip4 > 0.0.0.0/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:17 buckets:1 uRPF:20 to:[0:0]] > [0] [@0]: dpo-drop ip4 > 10.43.0.170/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:27 buckets:1 uRPF:29 to:[0:0]] > [0] [@0]: dpo-drop ip4 > 10.53.0.0/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:14 to:[0:0]] > [0] [@0]: dpo-drop ip4 > 10.53.0.0/23 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:20 buckets:1 uRPF:12 to:[0:0]] > [0] [@4]: ipv4-glean: vpp-intf19/0/1: mtu:9000 next:2 > 3cecef1f59df0806 > 10.53.1.189/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:25 buckets:1 uRPF:30 to:[0:0]] > [0] [@2]: dpo-receive: 10.53.1.189 on vpp-intf19/0/1 > 10.53.1.255/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:28 to:[3:234]] > [0] [@0]: dpo-drop ip4 > 224.0.0.0/4 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:18 to:[0:0]] > [0] [@0]: dpo-drop ip4 > 240.0.0.0/4 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:19 to:[0:0]] > [0] [@0]: dpo-drop ip4 > 255.255.255.255/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:16 > to:[214:19084]] > [0] [@0]: dpo-drop ip4 > vpp# > > Can anyone pinpoint what could be the problem ? > > Thanks, > Regards, > Venu > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19139): https://lists.fd.io/g/vpp-dev/message/19139 Mute This Topic: https://lists.fd.io/mt/81936718/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] VRF does not seem to working for us
Hi Venumadhav, By those commands: set interface ip table vpp-intf19/0/1 100 set interface ip address vpp-intf19/0/1 10.53.1.189/23 you set interface vpp-intf19/0/1 into the ip table 100, and that's why 10.53.0.1 (which is inside net 10.53.0.0/23) is also reachable from ip table 100. That means you need to specify an ip table for the nexthop as well. In you case it'd be: ip route add 10.43.0.170/32 table 100 via 10.53.0.1 next-hop-table 100 But make sure you've deleted the previous "wrong" route. On Thu, 8 Apr 2021 at 10:54, Venumadhav Josyula wrote: > Hi Stanislav, > > > By default it'd be nexthop in default fib. > i) by default meaning table id 0 ? > i) So we want it to be default fib, what should be in the default fib ? > meaning default route ? > ii) But we want to only for dest ip ( 10.43.0.170/32) > > What needs to be done? > > Thanks, > Regards, > Venu > > > On Thu, 8 Apr 2021 at 13:18, Stanislav Zaikin wrote: > >> Hi Venumadhav, >> >> You should specify an ip table for the nexthop with "next-hop-table XX". >> By default it'd be nexthop in default fib. >> >> On Thu, 8 Apr 2021 at 10:40, Venumadhav Josyula >> wrote: >> >>> Hi All, >>> For VRF configuration does not seem to work for us, we using vpp-20.09. >>> vpp# show version >>> vpp v20.09.0-1~0-g94f29f6 built by root on >>> devdocker2.parallelwireless.net at 2021-04-05T21:52:02 >>> vpp# >>> >>> We are trying to following configuration >>> >>> ip table add 100 >>> set interface ip table vpp-intf19/0/1 100 >>> set interface ip address vpp-intf19/0/1 10.53.1.189/23 >>> ip route add 10.43.0.170/32 table 100 via 10.53.0.1 >>> >>> here is dump >>> vpp# show ip fib table 100 >>> ipv4-VRF:100, fib_index:1, flow hash:[src dst sport dport proto ] >>> epoch:0 flags:none locks:[CLI:2, ] >>> 0.0.0.0/0 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:17 to:[0:0]] >>> [0] [@0]: dpo-drop ip4 >>> 0.0.0.0/32 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:17 buckets:1 uRPF:20 to:[0:0]] >>> [0] [@0]: dpo-drop ip4 >>> 10.43.0.170/32 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:27 buckets:1 uRPF:29 to:[0:0]] >>> [0] [@0]: dpo-drop ip4 >>> 10.53.0.0/32 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:14 to:[0:0]] >>> [0] [@0]: dpo-drop ip4 >>> 10.53.0.0/23 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:20 buckets:1 uRPF:12 to:[0:0]] >>> [0] [@4]: ipv4-glean: vpp-intf19/0/1: mtu:9000 next:2 >>> 3cecef1f59df0806 >>> 10.53.1.189/32 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:25 buckets:1 uRPF:30 to:[0:0]] >>> [0] [@2]: dpo-receive: 10.53.1.189 on vpp-intf19/0/1 >>> 10.53.1.255/32 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:28 >>> to:[3:234]] >>> [0] [@0]: dpo-drop ip4 >>> 224.0.0.0/4 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:18 to:[0:0]] >>> [0] [@0]: dpo-drop ip4 >>> 240.0.0.0/4 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:19 to:[0:0]] >>> [0] [@0]: dpo-drop ip4 >>> 255.255.255.255/32 >>> unicast-ip4-chain >>> [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:16 >>> to:[214:19084]] >>> [0] [@0]: dpo-drop ip4 >>> vpp# >>> >>> Can anyone pinpoint what could be the problem ? >>> >>> Thanks, >>> Regards, >>> Venu >>> >>> >>> >>> >> >> -- >> Best regards >> Stanislav Zaikin >> > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19143): https://lists.fd.io/g/vpp-dev/message/19143 Mute This Topic: https://lists.fd.io/mt/81936718/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] Adding new route via ipv6 link-local
Hello Artem, Looks like we need (at least) to add a check for nullptr. DBGvpp# create tap tap0 DBGvpp# set interface state tap0 up DBGvpp# ip route add fa::1/120 via fe80::1 tap0 Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. 0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at /home/zstas/vpp/src/vnet/ip/ip6_packet.h:129 129 dst->as_u64[0] = src->as_u64[0]; (gdb) bt #0 0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at /home/zstas/vpp/src/vnet/ip/ip6_packet.h:129 #1 0x7774b892 in fib_sas6_get (sw_if_index=1, dst=0x7fffb91b4e50, src=0x7fffaf487aa0) at /home/zstas/vpp/src/vnet/fib/fib_sas.c:105 On Fri, 20 Aug 2021 at 15:20, Artem Glazychev wrote: > Hello, > > Found a crash: if we add the route via fe80:: *after* the interface > upping - vpp crashes. > > For example: > > DBGvpp# create tap > > tap0 > > DBGvpp# set int state tap0 up > > DBGvpp# ip route add fa::1/120 via fe80::1 tap0 > > make: *** [Makefile:537: run] Aborted > > > > If we swap *set ... up* and *ip route ...* - no crashes. > > Could you please explain me if such a situation is possible at all? > In any case, I believe that vpp should not crash. > > Thanks. > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19995): https://lists.fd.io/g/vpp-dev/message/19995 Mute This Topic: https://lists.fd.io/mt/85020362/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] Adding new route via ipv6 link-local
Hi Neale, If there are no volunteers, there's the patch: https://gerrit.fd.io/r/c/vpp/+/33558 On Fri, 20 Aug 2021 at 16:20, Neale Ranns wrote: > Hi Artem, Stanislav, > > > > I agree graceful handling is needed, return false if there is no link > local. > > > > If you enabled ip6 on the link first, this wouldn’t be a problem. The link > will need to be ip6 enabled if you want something to reply. > > > > /neale > > > > > > *From: *vpp-dev@lists.fd.io on behalf of Stanislav > Zaikin via lists.fd.io > *Date: *Friday, 20 August 2021 at 16:10 > *To: *Artem Glazychev > *Cc: *vpp-dev > *Subject: *Re: [vpp-dev] Adding new route via ipv6 link-local > > Hello Artem, > > > > Looks like we need (at least) to add a check for nullptr. > > > > DBGvpp# create tap > tap0 > DBGvpp# set interface state tap0 up > DBGvpp# ip route add fa::1/120 via fe80::1 tap0 > > Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. > 0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at > /home/zstas/vpp/src/vnet/ip/ip6_packet.h:129 > 129 dst->as_u64[0] = src->as_u64[0]; > (gdb) bt > #0 0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) > at /home/zstas/vpp/src/vnet/ip/ip6_packet.h:129 > #1 0x7774b892 in fib_sas6_get (sw_if_index=1, dst=0x7fffb91b4e50, > src=0x7fffaf487aa0) at /home/zstas/vpp/src/vnet/fib/fib_sas.c:105 > > > > On Fri, 20 Aug 2021 at 15:20, Artem Glazychev > wrote: > > Hello, > > Found a crash: if we add the route via fe80:: *after* the interface > upping - vpp crashes. > > For example: > > DBGvpp# create tap > > tap0 > > DBGvpp# set int state tap0 up > > DBGvpp# ip route add fa::1/120 via fe80::1 tap0 > > make: *** [Makefile:537: run] Aborted > > > > If we swap *set ... up* and *ip route ...* - no crashes. > > Could you please explain me if such a situation is possible at all? > In any case, I believe that vpp should not crash. > > Thanks. > > > > > > -- > > Best regards > Stanislav Zaikin > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19997): https://lists.fd.io/g/vpp-dev/message/19997 Mute This Topic: https://lists.fd.io/mt/85020362/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] Getting Dpdk-input : no error
What does "show ip fib 48.0.0.1" say? On Sat, 18 Sept 2021 at 12:44, Mohsen Meamarian wrote: > Hi, > > Did anyone know why i get this error? > For every 10 packet that i send, 1 packet drop because of this. > > Thank you > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20160): https://lists.fd.io/g/vpp-dev/message/20160 Mute This Topic: https://lists.fd.io/mt/85696233/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] Getting Dpdk-input : no error
Hi Mohsen, The adjacency is unresolved, so vpp will try to resolve it as soon as it gets the first packet. After that you shouldn't observe such drops. On Sat, 18 Sept 2021 at 13:07, Mohsen Meamarian wrote: > Hi, > It says : > > vpp# show ip fib 48.0.0.1 > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] > locks:[src:plugin-hi:2, src:recursive-resolution:2, src:default-route:1, ] > 48.0.0.0/8 fib:0 index:30 locks:2 > src:CLI refs:1 src-flags:added,contributing,active, > path-list:[35] locks:2 flags:shared, uPRF-list:36 len:1 itfs:[3, ] > path:[39] pl-index:35 ip4 weight=1 pref=0 recursive: > oper-flags:resolved, > via 10.10.30.2 in fib:0 via-fib:31 via-dpo:[dpo-load-balance:33] > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:34 buckets:1 uRPF:36 to:[0:0]] > [0] [@12]: dpo-load-balance: [proto:ip4 index:33 buckets:1 uRPF:35 > to:[0:0]] > [0] [@3]: arp-ipv4: via 10.10.30.2 GigabitEthernet2/0/3 > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20162): https://lists.fd.io/g/vpp-dev/message/20162 Mute This Topic: https://lists.fd.io/mt/85696233/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 Socket API how to use from the application #socket-api #vpp #sock-api
from
>> /usr/include/vlibapi/api.h:24,
>> > > from vpp_api_client_test3.c:3:
>> > > /usr/include/vppinfra/clib.h:43:18: error:
>> missing
>> > binary operator before
>> > > token "("
>> > > #if __has_include()
>> > > ^
>> > > In file included from
>> > /usr/include/vppinfra/mem.h:49:0,
>> > > from
>> /usr/include/vppinfra/vec.h:42,
>> > > from
>> > /usr/include/vppinfra/error.h:53,
>> > > from
>> /usr/include/vlibapi/api.h:24,
>> > > from vpp_api_client_test3.c:3:
>> > > /usr/include/vppinfra/string.h:92:34: error:
>> expected
>> > ';', ',' or ')'
>> > > before 'dst'
>> > > clib_memcpy_fast (void *restrict dst, const
>> void
>> > *restrict src, size_t n)
>> > > ^
>> > > [root@8f57181df3a1 vpp_c_api_examples]# vim
>> > /usr/include/vppinfra/clib.h
>> > > +43
>> > > [root@8f57181df3a1 vpp_c_api_examples]# vim
>> > /usr/include/vppinfra/clib.h
>> > > +43
>> > > [root@8f57181df3a1 vpp_c_api_examples]# gcc
>> --version
>> > > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
>> > > Copyright (C) 2015 Free Software Foundation,
>> Inc.
>> > > This is free software; see the source for
>> copying
>> > conditions. There is NO
>> > > warranty; not even for MERCHANTABILITY or
>> FITNESS FOR
>> > A PARTICULAR
>> > > PURPOSE.
>> > >
>> > > [root@8f57181df3a1 vpp_c_api_examples]#
>> > >
>> > >
>> > > -
>> > >
>> > > c -code
>> > >
>> > >
>> > >
>> > > #include
>> > > #include
>> > > #include
>> > > #include
>> > > #include
>> > >
>> > > #define vl_typedefs
>> > > #define vl_endianfun
>> > > #include
>> > > #undef vl_typedefs
>> > > #undef vl_endianfun
>> > >
>> > > int main()
>> > > {
>> > >char *name = "vpp-test-app";
>> > >
>> > >clib_mem_init_thread_safe (0, 64ULL << 20);
>> > >
>> > >if (vl_client_api_map("/vpe-api"))
>> > >{
>> > > printf("unable to map\n");
>> > > goto quit;
>> > >}
>> > >if (vl_client_connect("vpp-test-app", 0, 32)
>> < 0)
>> > >{
>> > > printf("unable to connect \n");
>> > > vl_client_api_unmap();
>> > > goto quit;
>> > >}
>> > >printf("successfully connected... \n");
>> > > quit:
>> > > return 0;
>> > > }
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Can you please suggest what can i be doing
>> worng ?
>> > >
>> > >
>> > > Thanks,
>> > > Regards,
>> > > Venu
>> > >
>> > >
>> > > On Thu, 30 Sept 2021 at 13:21, <
>> otr...@employees.org
>> > <mailto:otr...@employees.org>
>> > > <mailto:otr...@employees.org
>> > <mailto:otr...@employees.org> > > wrote:
>> > >
>> > >
>> > > Hi Venu,
>> > >
>> > > > Any examples for VAPI shared to use
>> binary
>> > APIs ?
>> > >
>> > > Try this for a start:
>> > > https://git.fd.io/vpp/tree/src/vpp-
>> > api/vapi/vapi_c_test.c
>> > >
>> > > Cheers,
>> > > Ole
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20265): https://lists.fd.io/g/vpp-dev/message/20265
Mute This Topic: https://lists.fd.io/mt/85796959/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #socket-api:https://lists.fd.io/g/vpp-dev/mutehashtag/socket-api
Mute #sock-api:https://lists.fd.io/g/vpp-dev/mutehashtag/sock-api
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev]: ASSERT in load_balance_get()
n.c:492 >>> > #33 0x7f994f98b2af in bds_deferred_plugin_cb >>> > (table_handle=0x5576fdc0b13c, obj_handle=0x55770102780c, >>> > obj_deleted=0x7f98d8bb5de2 "") >>> > at >>> /development/librtbrickinfra/libbds/code/bds/src/bds_plugin.c:656 >>> > #34 0x7f994f97fed9 in bds_object_handle_plugin_publish >>> > (table_handle=0x5576fdc0b13c, obj_handle=0x55770102780c, >>> > old_obj_handle=0x55770212be6c) >>> > at >>> /development/librtbrickinfra/libbds/code/bds/src/bds_object.c:3403 >>> > #35 0x7f994f9801b9 in bds_object_handle_features >>> > (table=0x5576fdc0b13c, index=0x55770102780c, old_index=0x55770212be6c, >>> > add_vector=3, is_diff_index=0 '\000') >>> > at >>> /development/librtbrickinfra/libbds/code/bds/src/bds_object.c:3515 >>> > #36 0x7f994f980dc5 in bds_build_index (table=0x5576fdc0b13c, >>> > obj_map=0x557702d6fefc, cp_offset=0x7f98d8bb5f80, >>> cp_len=0x7f98d8bb6180, >>> > data_offset=38, >>> > add_bitmap=65535, is_diff_index=0 '\000') at >>> > /development/librtbrickinfra/libbds/code/bds/src/bds_object.c:3832 >>> > >>> > #37 0x7f994f9816bd in bds_create_object_index_map >>> > (obj_template=0x5576f8083e5c, use_seq=0 '\000', skip_index=0 '\000') >>> > at >>> /development/librtbrickinfra/libbds/code/bds/src/bds_object.c:4024 >>> > #38 0x7f994f98206c in bds_object_add >>> (object_template=0x5576f8083e5c) >>> > at /development/librtbrickinfra/libbds/code/bds/src/bds_object.c:4267 >>> > #39 0x7f9945acfd12 in fib_adjacency_api_out_obj_add_del >>> > (fib_adjacency=0x7f98d8bb6820, action=0 '\000') >>> > at >>> > /development/libforwarding/pi/fib/code/src/fib_adjacency_api_out.c:342 >>> > #40 0x7f9945acec9a in fib_adjacency_local_obj_process >>> > (table=0x5576fdc0512c, obj_handle=0x5577018317fc, action=0 '\000') >>> > at /development/libforwarding/pi/fib/code/src/fib_adjacency.c:90 >>> > #41 0x7f9945aced39 in fib_adjacency_local_obj_chng_cb >>> > (tblHndl=0x5576fdc0512c, newObjHndl=0x5577018317fc, >>> > oldObjHndl=0x5577016fed0c) >>> > at /development/libforwarding/pi/fib/code/src/fib_adjacency.c:111 >>> > #42 0x7f994f98bd9a in bds_handle_object_plugin >>> > (table_handle=0x5576fdc0512c, index=0x5577018317fc, >>> > old_index=0x5577016fed0c, type=BDS_PC_CHANGE) >>> > at >>> /development/librtbrickinfra/libbds/code/bds/src/bds_plugin.c:992 >>> > #43 0x7f994f98ad7f in bds_deferred_object_plugins >>> > (table_handle=0x5576fdc0512c, obj_handle=0x5577018317fc, >>> > obj_deleted=0x7f98d8bb6d8f "") >>> > at >>> /development/librtbrickinfra/libbds/code/bds/src/bds_plugin.c:492 >>> > #44 0x7f994f98b2af in bds_deferred_plugin_cb >>> > (table_handle=0x5576fdc0512c, obj_handle=0x5577018317fc, >>> > obj_deleted=0x7f98d8bb6d8f "") >>> > at >>> /development/librtbrickinfra/libbds/code/bds/src/bds_plugin.c:656 >>> > #45 0x7f994f98b390 in bds_deferred_plugin_cb_expiry >>> > (table_handle=0x5576fdc0512c) at >>> > /development/librtbrickinfra/libbds/code/bds/src/bds_plugin.c:696 >>> > #46 0x7f995270a070 in timer_dispatch (item=0x557701811cb0, >>> > p=QB_LOOP_HIGH) at >>> > /development/librtbrickinfra/libqb/lib/loop_timerlist.c:56 >>> > #47 0x7f9952706006 in qb_loop_run_level (level=0x5576f78f5830) at >>> > /development/librtbrickinfra/libqb/lib/loop.c:43 >>> > #48 0x7f9952707038 in qb_loop_run_vpp_wrapper (lp=0x5576f78f57c0) >>> at >>> > /development/librtbrickinfra/libqb/lib/loop.c:350 >>> > #49 0x7f9952717cd8 in lib_qb_service_start_event_wrapper_loop () at >>> > /development/librtbrickinfra/libqb/lib/wrapper/lib_qb_service.c:290 >>> > #50 0x7f98cfb8386c in rtb_vpp_epoll_process (vm=0x7f9946776e40 >>> > , rt=0x7f98d8ba6000, f=0x0) >>> > ---Type to continue, or q to quit--- >>> > at /development/libvpp/src/plugins/rtbrick/rtb_node.c:81 >>> > #51 0x7f99464d571b in vlib_process_bootstrap (_a=140294421412800) >>> at >>> > /development/libvpp/src/vlib/main.c:1468 >>> > #52 0x7f9946197600 in clib_calljmp () from >>> > /usr/local/lib/libvppinfra.so.1.0.1 >>> > #53 0x7f98d726fb90 in ?? () >>> > #54 0x7f99464d5820 in vlib_process_startup (vm=0x7f99464d588a >>> > , p=0x8, f=0x7f9946776e40 ) >>> > at /development/libvpp/src/vlib/main.c:1490 >>> > Backtrace stopped: previous frame inner to this frame (corrupt stack?) >>> > >>> > >>> > Thanks, >>> > Rajith >>> >> >> > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20317): https://lists.fd.io/g/vpp-dev/message/20317 Mute This Topic: https://lists.fd.io/mt/75353568/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] assert in pool_elt_at_index
epoll_wait.c:30 * 3Thread 0x7fb4f2e22700 (LWP 3244) "vpp_wk_0" __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 4Thread 0x7fb4f2621700 (LWP 3246) "vpp_wk_1" 0x7fb594ebf897 in vlib_worker_thread_barrier_check () at /home/vpp/vpp/src/vlib/threads.h:439 -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20319): https://lists.fd.io/g/vpp-dev/message/20319 Mute This Topic: https://lists.fd.io/mt/86295132/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] assert in pool_elt_at_index
Hi Florin, I wasn't aware of those helper functions, thanks! But yeah, it also returns 0 (sorry, but there's the trace of another crash) Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted. [Switching to Thread 0x7f9cc0f6a700 (LWP 3546)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x7f9d61542921 in __GI_abort () at abort.c:79 #2 0x7f9d624da799 in os_panic () at /home/vpp/vpp/src/vppinfra/unix-misc.c:177 #3 0x7f9d62420f49 in debugger () at /home/vpp/vpp/src/vppinfra/error.c:84 #4 0x7f9d62420cc7 in _clib_error (how_to_die=2, function_name=0x0, line_number=0, fmt=0x7f9d644348d0 "%s:%d (%s) assertion `%s' fails") at /home/vpp/vpp/src/vppinfra/error.c:143 #5 0x7f9d636695b4 in load_balance_get (lbi=4569) at /home/vpp/vpp/src/vnet/dpo/load_balance.h:222 #6 0x7f9d63668247 in mpls_lookup_node_fn_hsw (vm=0x7f9ceb0138c0, node=0x7f9ceee6f700, from_frame=0x7f9cef9c9240) at /home/vpp/vpp/src/vnet/mpls/mpls_lookup.c:229 #7 0x7f9d63008076 in dispatch_node (vm=0x7f9ceb0138c0, node=0x7f9ceee6f700, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f9cef9c9240, last_time_stamp=1837178878370487) at /home/vpp/vpp/src/vlib/main.c:1217 #8 0x7f9d630089e7 in dispatch_pending_node (vm=0x7f9ceb0138c0, pending_frame_index=2, last_time_stamp=1837178878370487) at /home/vpp/vpp/src/vlib/main.c:1376 #9 0x7f9d63002441 in vlib_main_or_worker_loop (vm=0x7f9ceb0138c0, is_main=0) at /home/vpp/vpp/src/vlib/main.c:1904 #10 0x7f9d630012e7 in vlib_worker_loop (vm=0x7f9ceb0138c0) at /home/vpp/vpp/src/vlib/main.c:2038 #11 0x7f9d6305995d in vlib_worker_thread_fn (arg=0x7f9ce1b88540) at /home/vpp/vpp/src/vlib/threads.c:1868 #12 0x7f9d62445214 in clib_calljmp () at /home/vpp/vpp/src/vppinfra/longjmp.S:123 #13 0x7f9cc0f69c90 in ?? () #14 0x7f9d63051b83 in vlib_worker_thread_bootstrap_fn (arg=0x7f9ce1b88540) at /home/vpp/vpp/src/vlib/threads.c:585 #15 0x7f9cda360355 in eal_thread_loop (arg=0x0) at ../src-dpdk/lib/librte_eal/linux/eal_thread.c:127 #16 0x7f9d629246db in start_thread (arg=0x7f9cc0f6a700) at pthread_create.c:463 #17 0x7f9d6162371f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) select 5 (gdb) *print pifi( load_balance_pool, 4569 )$1 = 0* (gdb) source ~/vpp/extras/gdb/gdbinit Loading vpp functions... Load vlLoad pe Load pifi Load node_name_from_index Load vnet_buffer_opaque Load vnet_buffer_opaque2 Load bitmap_get Done loading vpp functions... (gdb) pifi load_balance_pool 4569 pool_is_free_index (load_balance_pool, 4569)$2 = 0 On Wed, 13 Oct 2021 at 21:55, Florin Coras wrote: > Hi Stanislav, > > Just to make sure the gdb macro is okay, could you run from gdb: > pifi(pool, index)? The function is defined in gdb_funcs.c. > > Regards, > Florin > > On Oct 13, 2021, at 11:30 AM, Stanislav Zaikin wrote: > > Hello folks, > > I'm facing a strange issue with 2 worker threads. Sometimes I get a crash > either in "ip6-lookup" or "mpls-lookup" nodes. They happen with assert in > the *pool_elt_at_index* macro and always inside the "*load_balance_get*" > function. But the load_balance dpo looks perfectly good, I mean it still > has a lock and on regular deletion (in the case when the load_balance dpo > is deleted) it should be erased properly (with dpo_reset). It happens > usually when the main core is executing > vlib_worker_thread_barrier_sync_int(), and the other worker is executing > vlib_worker_thread_barrier_check(). > And the strangest thing is, when I run the vpp's gdb helper for checking > "pool_index_is_free" or pifi, it shows me that the index isn't free (and > the macro in that case shouldn't fire). > > Any thoughts and inputs are appreciated. > > Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted. > [Switching to Thread 0x7fb4f2e22700 (LWP 3244)] > __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) bt > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x7fb5933fa921 in __GI_abort () at abort.c:79 > #2 0x7fb594392799 in os_panic () at > /home/vpp/vpp/src/vppinfra/unix-misc.c:177 > #3 0x7fb5942d8f49 in debugger () at > /home/vpp/vpp/src/vppinfra/error.c:84 > #4 0x7fb5942d8cc7 in _clib_error (how_to_die=2, function_name=0x0, > line_number=0, fmt=0x7fb5962ec8d0 "%s:%d (%s) assertion `%s' fails") at > /home/vpp/vpp/src/vppinfra/error.c:143 > #5 0x7fb5954bd694 in load_balance_get (lbi=3604) at > /home/vpp/vpp/src/vnet/dpo/load_balance.h:222 > #6 0
Re: [vpp-dev] assert in pool_elt_at_index
Hi Florin, Hi Rajith, It shouldn't be the pool expansion case, I have 8341f76fd1cd4351961cd8161cfed2814fc55103. Moreover, in this case _e would be different from &load_balance_pool[3604]. I've found some of those expansions (in other places), in those cases a pointer to the element has a different address. On Thu, 14 Oct 2021 at 06:45, Rajith PR wrote: > HI Stanislav, > > My guess is you don't have the commit below. > > commit 8341f76fd1cd4351961cd8161cfed2814fc55103 > Author: Dave Barach > Date: Wed Jun 3 08:05:15 2020 -0400 > > fib: add barrier sync, pool/vector expand cases > > load_balance_alloc_i(...) is not thread safe when the > load_balance_pool or combined counter vectors expand. > > Type: fix > > Signed-off-by: Dave Barach > Change-Id: I7f295ed77350d1df0434d5ff461eedafe79131de > > Thanks, > Rajith > > On Thu, Oct 14, 2021 at 3:57 AM Florin Coras > wrote: > >> Hi Stanislav, >> >> The only thing I can think of is that main thread grows the pool, or the >> pool’s bitmap, without a worker barrier while the worker that asserts is >> trying to access it. Is main thread busy doing something (e.g., adding >> routes/interfaces) when the assert happens? >> >> Regards, >> Florin >> >> On Oct 13, 2021, at 2:52 PM, Stanislav Zaikin wrote: >> >> Hi Florin, >> >> I wasn't aware of those helper functions, thanks! But yeah, it also >> returns 0 (sorry, but there's the trace of another crash) >> >> Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted. >> [Switching to Thread 0x7f9cc0f6a700 (LWP 3546)] >> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 >> 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. >> (gdb) bt >> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 >> #1 0x7f9d61542921 in __GI_abort () at abort.c:79 >> #2 0x7f9d624da799 in os_panic () at >> /home/vpp/vpp/src/vppinfra/unix-misc.c:177 >> #3 0x7f9d62420f49 in debugger () at >> /home/vpp/vpp/src/vppinfra/error.c:84 >> #4 0x7f9d62420cc7 in _clib_error (how_to_die=2, function_name=0x0, >> line_number=0, fmt=0x7f9d644348d0 "%s:%d (%s) assertion `%s' fails") at >> /home/vpp/vpp/src/vppinfra/error.c:143 >> #5 0x7f9d636695b4 in load_balance_get (lbi=4569) at >> /home/vpp/vpp/src/vnet/dpo/load_balance.h:222 >> #6 0x7f9d63668247 in mpls_lookup_node_fn_hsw (vm=0x7f9ceb0138c0, >> node=0x7f9ceee6f700, from_frame=0x7f9cef9c9240) at >> /home/vpp/vpp/src/vnet/mpls/mpls_lookup.c:229 >> #7 0x7f9d63008076 in dispatch_node (vm=0x7f9ceb0138c0, >> node=0x7f9ceee6f700, type=VLIB_NODE_TYPE_INTERNAL, >> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f9cef9c9240, >> last_time_stamp=1837178878370487) at /home/vpp/vpp/src/vlib/main.c:1217 >> #8 0x7f9d630089e7 in dispatch_pending_node (vm=0x7f9ceb0138c0, >> pending_frame_index=2, last_time_stamp=1837178878370487) at >> /home/vpp/vpp/src/vlib/main.c:1376 >> #9 0x7f9d63002441 in vlib_main_or_worker_loop (vm=0x7f9ceb0138c0, >> is_main=0) at /home/vpp/vpp/src/vlib/main.c:1904 >> #10 0x7f9d630012e7 in vlib_worker_loop (vm=0x7f9ceb0138c0) at >> /home/vpp/vpp/src/vlib/main.c:2038 >> #11 0x7f9d6305995d in vlib_worker_thread_fn (arg=0x7f9ce1b88540) at >> /home/vpp/vpp/src/vlib/threads.c:1868 >> #12 0x7f9d62445214 in clib_calljmp () at >> /home/vpp/vpp/src/vppinfra/longjmp.S:123 >> #13 0x7f9cc0f69c90 in ?? () >> #14 0x7f9d63051b83 in vlib_worker_thread_bootstrap_fn >> (arg=0x7f9ce1b88540) at /home/vpp/vpp/src/vlib/threads.c:585 >> #15 0x7f9cda360355 in eal_thread_loop (arg=0x0) at >> ../src-dpdk/lib/librte_eal/linux/eal_thread.c:127 >> #16 0x7f9d629246db in start_thread (arg=0x7f9cc0f6a700) at >> pthread_create.c:463 >> #17 0x7f9d6162371f in clone () at >> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 >> (gdb) select 5 >> (gdb) >> *print pifi( load_balance_pool, 4569 )$1 = 0* >> (gdb) source ~/vpp/extras/gdb/gdbinit >> Loading vpp functions... >> Load vlLoad pe >> Load pifi >> Load node_name_from_index >> Load vnet_buffer_opaque >> Load vnet_buffer_opaque2 >> Load bitmap_get >> Done loading vpp functions... >> (gdb) pifi load_balance_pool 4569 >> pool_is_free_index (load_balance_pool, 4569)$2 = 0 >> >> On Wed, 13 Oct 2021 at 21:55, Florin Coras >> wrote: >> >>> Hi Stanislav, >>> >>> Just to make sure the gdb macro is okay, could you run from gdb: &
Re: [vpp-dev] assert in pool_elt_at_index
Any thoughts will be much appreciated. This bug is quite reproducible in my environment, but I don't know what else to check. On Thu, 14 Oct 2021 at 08:51, Stanislav Zaikin via lists.fd.io wrote: > Hi Florin, > Hi Rajith, > > It shouldn't be the pool expansion case, I have > 8341f76fd1cd4351961cd8161cfed2814fc55103. > Moreover, in this case _e would be different from &load_balance_pool[3604]. > I've found some of those expansions (in other places), in those cases a > pointer to the element has a different address. > > > On Thu, 14 Oct 2021 at 06:45, Rajith PR wrote: > >> HI Stanislav, >> >> My guess is you don't have the commit below. >> >> commit 8341f76fd1cd4351961cd8161cfed2814fc55103 >> Author: Dave Barach >> Date: Wed Jun 3 08:05:15 2020 -0400 >> >> fib: add barrier sync, pool/vector expand cases >> >> load_balance_alloc_i(...) is not thread safe when the >> load_balance_pool or combined counter vectors expand. >> >> Type: fix >> >> Signed-off-by: Dave Barach >> Change-Id: I7f295ed77350d1df0434d5ff461eedafe79131de >> >> Thanks, >> Rajith >> >> On Thu, Oct 14, 2021 at 3:57 AM Florin Coras >> wrote: >> >>> Hi Stanislav, >>> >>> The only thing I can think of is that main thread grows the pool, or the >>> pool’s bitmap, without a worker barrier while the worker that asserts is >>> trying to access it. Is main thread busy doing something (e.g., adding >>> routes/interfaces) when the assert happens? >>> >>> Regards, >>> Florin >>> >>> On Oct 13, 2021, at 2:52 PM, Stanislav Zaikin wrote: >>> >>> Hi Florin, >>> >>> I wasn't aware of those helper functions, thanks! But yeah, it also >>> returns 0 (sorry, but there's the trace of another crash) >>> >>> Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted. >>> [Switching to Thread 0x7f9cc0f6a700 (LWP 3546)] >>> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 >>> 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. >>> (gdb) bt >>> #0 __GI_raise (sig=sig@entry=6) at >>> ../sysdeps/unix/sysv/linux/raise.c:51 >>> #1 0x7f9d61542921 in __GI_abort () at abort.c:79 >>> #2 0x7f9d624da799 in os_panic () at >>> /home/vpp/vpp/src/vppinfra/unix-misc.c:177 >>> #3 0x7f9d62420f49 in debugger () at >>> /home/vpp/vpp/src/vppinfra/error.c:84 >>> #4 0x7f9d62420cc7 in _clib_error (how_to_die=2, function_name=0x0, >>> line_number=0, fmt=0x7f9d644348d0 "%s:%d (%s) assertion `%s' fails") at >>> /home/vpp/vpp/src/vppinfra/error.c:143 >>> #5 0x7f9d636695b4 in load_balance_get (lbi=4569) at >>> /home/vpp/vpp/src/vnet/dpo/load_balance.h:222 >>> #6 0x7f9d63668247 in mpls_lookup_node_fn_hsw (vm=0x7f9ceb0138c0, >>> node=0x7f9ceee6f700, from_frame=0x7f9cef9c9240) at >>> /home/vpp/vpp/src/vnet/mpls/mpls_lookup.c:229 >>> #7 0x7f9d63008076 in dispatch_node (vm=0x7f9ceb0138c0, >>> node=0x7f9ceee6f700, type=VLIB_NODE_TYPE_INTERNAL, >>> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f9cef9c9240, >>> last_time_stamp=1837178878370487) at /home/vpp/vpp/src/vlib/main.c:1217 >>> #8 0x7f9d630089e7 in dispatch_pending_node (vm=0x7f9ceb0138c0, >>> pending_frame_index=2, last_time_stamp=1837178878370487) at >>> /home/vpp/vpp/src/vlib/main.c:1376 >>> #9 0x7f9d63002441 in vlib_main_or_worker_loop (vm=0x7f9ceb0138c0, >>> is_main=0) at /home/vpp/vpp/src/vlib/main.c:1904 >>> #10 0x7f9d630012e7 in vlib_worker_loop (vm=0x7f9ceb0138c0) at >>> /home/vpp/vpp/src/vlib/main.c:2038 >>> #11 0x7f9d6305995d in vlib_worker_thread_fn (arg=0x7f9ce1b88540) at >>> /home/vpp/vpp/src/vlib/threads.c:1868 >>> #12 0x7f9d62445214 in clib_calljmp () at >>> /home/vpp/vpp/src/vppinfra/longjmp.S:123 >>> #13 0x7f9cc0f69c90 in ?? () >>> #14 0x7f9d63051b83 in vlib_worker_thread_bootstrap_fn >>> (arg=0x7f9ce1b88540) at /home/vpp/vpp/src/vlib/threads.c:585 >>> #15 0x7f9cda360355 in eal_thread_loop (arg=0x0) at >>> ../src-dpdk/lib/librte_eal/linux/eal_thread.c:127 >>> #16 0x7f9d629246db in start_thread (arg=0x7f9cc0f6a700) at >>> pthread_create.c:463 >>> #17 0x7f9d6162371f in clone () at >>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 >>> (gdb) select 5 >>> (gdb) >>> *print pifi( load_balance_po
Re: [vpp-dev]: SIGSEV in mpls_tunnel_collect_forwarding
0::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1062 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1063 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1064 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1065 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1066 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1067 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1068 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1069 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1070 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1071 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1072 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1073 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1074 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1075 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1076 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1077 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1078 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1079 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1080 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1081 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1082 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1083 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1084 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1085 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1086 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1087 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1088 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1089 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1090 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1091 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1092 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1093 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1094 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1095 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1096 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1097 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1098 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1099 > mpls tunnel l2-only via fe80::e:903c:b3ff:fe15:f119 ifp-0/0/0.13 > out-labels 1100 > > Thanks, > Rajith > > NOTICE TO RECIPIENT This e-mail message and any attachments are > confidential and may be privileged. If you received this e-mail in error, > any review, use, dissemination, distribution, or copying of this e-mail is > strictly prohibited. Please notify us immediately of the error by return > e-mail and please delete this message from your system. For more > information about Rtbrick, please visit us at www.rtbrick.com > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20351): https://lists.fd.io/g/vpp-dev/message/20351 Mute This Topic: https://lists.fd.io/mt/86484036/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] assert in pool_elt_at_index
Hi Benoit, I've tried but got this crash. Maybe some fixes were merged to handle this issue? (I'm using 21.01 + additional patches from the master) Program received signal SIGSEGV, Segmentation fault. 0x0042c037 in __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*, unsigned long*) () (gdb) bt #0 0x0042c037 in __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*, unsigned long*) () #1 0x004a31b4 in __asan::ThreadStackContainsAddress(__sanitizer::ThreadContextBase*, void*) () #2 0x004b2f4a in __sanitizer::ThreadRegistry::FindThreadContextLocked(bool (*)(__sanitizer::ThreadContextBase*, void*), void*) () #3 0x004a30eb in __asan::FindThreadByStackAddress(unsigned long) () #4 0x00429265 in __asan::AddressDescription::AddressDescription(unsigned long, unsigned long, bool) () #5 0x0042adb3 in __asan::ErrorGeneric::ErrorGeneric(unsigned int, unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long) () #6 0x0049cd81 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) () #7 0x0049d5e8 in __asan_report_load4 () #8 0x74fc18e8 in clib_march_select_fn_ptr_by_name (r=0x77858740 , name=0x76fd5980 <.str> "hsw") at /home/vpp/vpp/src/vppinfra/cpu.h:94 #9 0x74fc17a1 in vnet_interface_output_node_get (vm=0x73a2d340 ) at /home/vpp/vpp/src/vnet/interface_output.c:538 #10 0x74f152cd in vnet_register_interface (vnm=0x77a6b320 , dev_class_index=34, dev_instance=0, hw_class_index=31, hw_instance=0) at /home/vpp/vpp/src/vnet/interface.c:810 #11 0x74ff34ca in vnet_main_init (vm=0x73a2d340 ) at /home/vpp/vpp/src/vnet/misc.c:81 #12 0x7353d476 in call_init_exit_functions_internal (vm=0x73a2d340 , headp=0x73a2d998 , call_once=1, do_sort=1) at /home/vpp/vpp/src/vlib/init.c:350 #13 0x7353d258 in vlib_call_init_exit_functions (vm=0x73a2d340 , headp=0x73a2d998 , call_once=1) at /home/vpp/vpp/src/vlib/init.c:364 #14 0x7353d561 in vlib_call_all_init_functions (vm=0x73a2d340 ) at /home/vpp/vpp/src/vlib/init.c:386 #15 0x735c8711 in vlib_main (vm=0x73a2d340 , input=0x7fff9cb4bec0) at /home/vpp/vpp/src/vlib/main.c:2213 #16 0x7376b808 in thread0 (arg=140737280922432) at /home/vpp/vpp/src/vlib/unix/main.c:670 #17 0x7269204c in clib_calljmp () at /home/vpp/vpp/src/vppinfra/longjmp.S:123 #18 0x7fffc980 in ?? () #19 0x7376ad55 in vlib_unix_main (argc=2, argv=0x7fffe498) at /home/vpp/vpp/src/vlib/unix/main.c:747 #20 0x004c8fa8 in main (argc=2, argv=0x7fffe498) at /home/vpp/vpp/src/vpp/vnet/main.c:338 (gdb) On Mon, 18 Oct 2021 at 14:29, Benoit Ganne (bganne) wrote: > You can try running with AddressSanitizer: > https://fd.io/docs/vpp/master/troubleshooting/sanitizer.html#id2 > That could catch the corruption earlier with more clues. > > Best > ben > > > -Original Message- > > From: vpp-dev@lists.fd.io On Behalf Of Stanislav > > Zaikin > > Sent: vendredi 15 octobre 2021 14:54 > > To: vpp-dev > > Subject: Re: [vpp-dev] assert in pool_elt_at_index > > > > Any thoughts will be much appreciated. This bug is quite reproducible in > > my environment, but I don't know what else to check. > > > > > > On Thu, 14 Oct 2021 at 08:51, Stanislav Zaikin via lists.fd.io > > <http://lists.fd.io> > <mailto:gmail@lists.fd.io> > wrote: > > > > > > Hi Florin, > > Hi Rajith, > > > > It shouldn't be the pool expansion case, I have > > 8341f76fd1cd4351961cd8161cfed2814fc55103. > > Moreover, in this case _e would be different from > > &load_balance_pool[3604]. I've found some of those expansions (in other > > places), in those cases a pointer to the element has a different address. > > > > > > > > > > On Thu, 14 Oct 2021 at 06:45, Rajith PR > <mailto:raj...@rtbrick.com> > wrote: > > > > > > HI Stanislav, > > > > My guess is you don't have the commit below. > > > > commit 8341f76fd1cd4351961cd8161cfed2814fc55103 > > Author: Dave Barach > <mailto:d...@barachs.net> > > > Date: Wed Jun 3 08:05:15 2020 -0400 > > > > fib: add barrier sync, pool/vector expand cases > > > > load_balance_alloc_i(...) is not thread safe when the > > load_balance_pool or combined counter vectors expand. > > > > Type: fix > > > > Signed-off-by: Dave B
Re: [vpp-dev] assert in pool_elt_at_index
Hi Neale,
Sure, here it is:
https://gist.github.com/zstas/c2316d4e95a84fa28f0e0be00eb6fb19
Thanks in advance.
On Fri, 22 Oct 2021 at 09:55, Neale Ranns wrote:
> Hi Stanislav,
>
>
>
> Can you do:
>
> thread apply all bt
>
> I’d like to see what the other threads are doing.
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io on behalf of Stanislav
> Zaikin via lists.fd.io
> *Date: *Wednesday, 13 October 2021 at 20:30
> *To: *vpp-dev
> *Subject: *[vpp-dev] assert in pool_elt_at_index
>
> Hello folks,
>
>
>
> I'm facing a strange issue with 2 worker threads. Sometimes I get a crash
> either in "ip6-lookup" or "mpls-lookup" nodes. They happen with assert in
> the *pool_elt_at_index* macro and always inside the "*load_balance_get*"
> function. But the load_balance dpo looks perfectly good, I mean it still
> has a lock and on regular deletion (in the case when the load_balance dpo
> is deleted) it should be erased properly (with dpo_reset). It happens
> usually when the main core is executing
> vlib_worker_thread_barrier_sync_int(), and the other worker is executing
> vlib_worker_thread_barrier_check().
>
> And the strangest thing is, when I run the vpp's gdb helper for checking
> "pool_index_is_free" or pifi, it shows me that the index isn't free (and
> the macro in that case shouldn't fire).
>
>
>
> Any thoughts and inputs are appreciated.
>
>
>
> Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fb4f2e22700 (LWP 3244)]
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1 0x7fb5933fa921 in __GI_abort () at abort.c:79
> #2 0x7fb594392799 in os_panic () at
> /home/vpp/vpp/src/vppinfra/unix-misc.c:177
> #3 0x7fb5942d8f49 in debugger () at
> /home/vpp/vpp/src/vppinfra/error.c:84
> #4 0x7fb5942d8cc7 in _clib_error (how_to_die=2, function_name=0x0,
> line_number=0, fmt=0x7fb5962ec8d0 "%s:%d (%s) assertion `%s' fails") at
> /home/vpp/vpp/src/vppinfra/error.c:143
> #5 0x7fb5954bd694 in load_balance_get (lbi=3604) at
> /home/vpp/vpp/src/vnet/dpo/load_balance.h:222
> #6 0x7fb5954bc070 in ip6_lookup_inline (vm=0x7fb51ceccd00,
> node=0x7fb520f6b700, frame=0x7fb52128e4c0) at
> /home/vpp/vpp/src/vnet/ip/ip6_forward.h:117
> #7 0x7fb5954bbdd5 in ip6_lookup_node_fn_hsw (vm=0x7fb51ceccd00,
> node=0x7fb520f6b700, frame=0x7fb52128e4c0) at
> /home/vpp/vpp/src/vnet/ip/ip6_forward.c:736
> #8 0x7fb594ec0076 in dispatch_node (vm=0x7fb51ceccd00,
> node=0x7fb520f6b700, type=VLIB_NODE_TYPE_INTERNAL,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fb52128e4c0,
> last_time_stamp=1808528151240447) at /home/vpp/vpp/src/vlib/main.c:1217
> #9 0x7fb594ec09e7 in dispatch_pending_node (vm=0x7fb51ceccd00,
> pending_frame_index=5, last_time_stamp=1808528151240447) at
> /home/vpp/vpp/src/vlib/main.c:1376
> #10 0x7fb594eba441 in vlib_main_or_worker_loop (vm=0x7fb51ceccd00,
> is_main=0) at /home/vpp/vpp/src/vlib/main.c:1904
> #11 0x7fb594eb92e7 in vlib_worker_loop (vm=0x7fb51ceccd00) at
> /home/vpp/vpp/src/vlib/main.c:2038
> #12 0x7fb594f1195d in vlib_worker_thread_fn (arg=0x7fb513a48100) at
> /home/vpp/vpp/src/vlib/threads.c:1868
> #13 0x7fb5942fd214 in clib_calljmp () at
> /home/vpp/vpp/src/vppinfra/longjmp.S:123
> #14 0x7fb4f2e21c90 in ?? ()
> #15 0x7fb594f09b83 in vlib_worker_thread_bootstrap_fn
> (arg=0x7fb513a48100) at /home/vpp/vpp/src/vlib/threads.c:585
> #16 0x7fb50c218355 in eal_thread_loop (arg=0x0) at
> ../src-dpdk/lib/librte_eal/linux/eal_thread.c:127
> #17 0x7fb5947dc6db in start_thread (arg=0x7fb4f2e22700) at
> pthread_create.c:463
> #18 0x7fb5934db71f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb) select 5
> (gdb) print _e
> $1 = (load_balance_t *) 0x7fb52651e580
> (gdb) print load_balance_pool[3604]
> $2 = {cacheline0 = 0x7fb52651e580 "\001", lb_n_buckets = 1,
> lb_n_buckets_minus_1 = 0, lb_proto = DPO_PROTO_IP6, lb_flags =
> LOAD_BALANCE_FLAG_NONE, lb_fib_entry_flags = (FIB_ENTRY_FLAG_CONNECTED |
> FIB_ENTRY_FLAG_LOCAL), lb_locks = 1, lb_map = 4294967295, lb_urpf = 4094,
> lb_hash_config = 31, lb_buckets = 0x0,
> lb_buckets_inline = dpoi_type = DPO_RECEIVE, dpoi_proto =
> DPO_PROTO_IP6, dpoi_next_node = 2, dpoi_index = 2094}, as_u64 =
> 8993661649164}}, {{{dpoi_type = DPO_FIRST, dpoi_proto = DPO_PROTO_IP4,
> dpoi_next_node = 0, dpoi_index = 0}, as_u64 = 0}}, {{{dpoi_type =
> DPO_FIRST, dpoi_proto = DPO_
Re: [vpp-dev] Classify Session Crash after 32K Creations (IMPORTANT)
) at > /home/Immaculate/Oct12/vpp/src/vppinfra/mem.h:217 > > #22 0x77f14d87 in clib_mem_size (p=0x7ffe74a1e1a8) at > /home/Immaculate/Oct12/vpp/src/vppinfra/mem.h:346 > > #23 0x77f14f37 in _vec_resize_inline (v=0x0, length_increment=1, > data_bytes=0, header_bytes=0, data_align=4, numa_id=255) > > at /home/Immaculate/Oct12/vpp/src/vppinfra/vec.h:157 > > #24 0x77f17bbb in vlib_process_signal_event_helper > (nm=0x7ffe73ab77f0, n=0x7ffe74a1da30, p=0x7ffe74a4eb80, t=0, n_data_elts=1, > n_data_elt_bytes=8) > > at /home/Immaculate/Oct12/vpp/src/vlib/node_funcs.h:903 > > #25 0x000a in ?? () > > #26 0x7ffe6c473958 in ?? () > > #27 0x7604c1c7 in vec_aligned_header (v= Cannot access memory at address 0xfff8>, > > header_bytes= 0xfff0>, > > align= 0xffe8>) at > /home/Immaculate/Oct12/vpp/src/vppinfra/vec_bootstrap.h:118 > > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > > Regards, > > Akash > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20377): https://lists.fd.io/g/vpp-dev/message/20377 Mute This Topic: https://lists.fd.io/mt/86572564/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] assert in pool_elt_at_index
Hi Neale,
I've tried with simplified version first (I know there's a
_vec_resize_will_expand macro), something like:
always_inline u8
clib_bitmap_will_expand(uword * ai, uword i)
{
uword i0 = i / BITS (ai[0]);
return vec_len(ai) < i0;
}
I've put a check in load_balance_destroy just before pool_put.
And there's no abort anymore. So, the prize comes to you :)
In my case, there's a lot of control traffic and data traffic. Control
traffic creates some routes and tunnels, and because the rate is high, not
all the control traffic reaches the control plane. And some tunnels\routes
are getting deleted.
I can prepare the patch, but one thing is concerning me: deleting an
element from the pool looks like something almost free while setting a
worker barrier is quite expensive. Also, that affects only debug mode (on
the other hand, it might have other side effects, I don't know). In your
opinion, does it make sense to put a barrier in that case?
On Fri, 22 Oct 2021 at 20:37, Neale Ranns wrote:
>
>
> Hi Stanislav,
>
>
>
> I see no smoking guns :(
>
>
>
> The only cause I can think of is that when a load-balance is returned to
> the pool, the pool’s bitmap of free indicies may expand, which would
> confuse readers/workers. But I don’t see any of your threads having just
> pool_put a load-balance. Since you have a reliable reproduction
> environment, could you cook your own pool_put_would_expand macro to test
> this theory?
>
>
>
> /neale
>
>
>
>
>
> *From: *Stanislav Zaikin
> *Date: *Friday, 22 October 2021 at 15:06
> *To: *Neale Ranns
> *Cc: *vpp-dev
> *Subject: *Re: [vpp-dev] assert in pool_elt_at_index
>
> Hi Neale,
>
>
>
> Sure, here it is:
>
> https://gist.github.com/zstas/c2316d4e95a84fa28f0e0be00eb6fb19
>
>
>
> Thanks in advance.
>
>
>
> On Fri, 22 Oct 2021 at 09:55, Neale Ranns wrote:
>
> Hi Stanislav,
>
>
>
> Can you do:
>
> thread apply all bt
>
> I’d like to see what the other threads are doing.
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io on behalf of Stanislav
> Zaikin via lists.fd.io
> *Date: *Wednesday, 13 October 2021 at 20:30
> *To: *vpp-dev
> *Subject: *[vpp-dev] assert in pool_elt_at_index
>
> Hello folks,
>
>
>
> I'm facing a strange issue with 2 worker threads. Sometimes I get a crash
> either in "ip6-lookup" or "mpls-lookup" nodes. They happen with assert in
> the *pool_elt_at_index* macro and always inside the "*load_balance_get*"
> function. But the load_balance dpo looks perfectly good, I mean it still
> has a lock and on regular deletion (in the case when the load_balance dpo
> is deleted) it should be erased properly (with dpo_reset). It happens
> usually when the main core is executing
> vlib_worker_thread_barrier_sync_int(), and the other worker is executing
> vlib_worker_thread_barrier_check().
>
> And the strangest thing is, when I run the vpp's gdb helper for checking
> "pool_index_is_free" or pifi, it shows me that the index isn't free (and
> the macro in that case shouldn't fire).
>
>
>
> Any thoughts and inputs are appreciated.
>
>
>
> Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fb4f2e22700 (LWP 3244)]
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1 0x7fb5933fa921 in __GI_abort () at abort.c:79
> #2 0x7fb594392799 in os_panic () at
> /home/vpp/vpp/src/vppinfra/unix-misc.c:177
> #3 0x7fb5942d8f49 in debugger () at
> /home/vpp/vpp/src/vppinfra/error.c:84
> #4 0x7fb5942d8cc7 in _clib_error (how_to_die=2, function_name=0x0,
> line_number=0, fmt=0x7fb5962ec8d0 "%s:%d (%s) assertion `%s' fails") at
> /home/vpp/vpp/src/vppinfra/error.c:143
> #5 0x7fb5954bd694 in load_balance_get (lbi=3604) at
> /home/vpp/vpp/src/vnet/dpo/load_balance.h:222
> #6 0x7fb5954bc070 in ip6_lookup_inline (vm=0x7fb51ceccd00,
> node=0x7fb520f6b700, frame=0x7fb52128e4c0) at
> /home/vpp/vpp/src/vnet/ip/ip6_forward.h:117
> #7 0x7fb5954bbdd5 in ip6_lookup_node_fn_hsw (vm=0x7fb51ceccd00,
> node=0x7fb520f6b700, frame=0x7fb52128e4c0) at
> /home/vpp/vpp/src/vnet/ip/ip6_forward.c:736
> #8 0x7fb594ec0076 in dispatch_node (vm=0x7fb51ceccd00,
> node=0x7fb520f6b700, type=VLIB_NODE_TYPE_INTERNAL,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fb52128e4c0,
> last_time_stamp=1808528151240447) at /home/vpp/vpp/src/vlib/main.c:1217
> #9 0x7fb594ec09e7 in dispatch_pe
[vpp-dev] a free_bitmap may expand while pool_put
Hello folks, In a multi-threaded environment (in my case I have 2 workers) I observed a crash, and thanks to Neale, it turned out that free_bitmap may expand while doing pool_put. Let's say one thread is doing pool_put, while another thread is calling "pool_elt_at_index". I observed different addresses before and after checking "ASSERT (! pool_is_free (p, _e))" in that macro. I prepared a patch [0], but it's kind of ugly. We don't have asserts in release mode, so why should we care about it? On the other hand, 2 different threads can do 2 pool_puts simultaneously and we can lose one free element in the pool (and also additionally allocated bitmap). For me, it's a place where it would be nice to have an mt-safe vec. What do you think? [0] - https://gerrit.fd.io/r/c/vpp/+/34332 -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20421): https://lists.fd.io/g/vpp-dev/message/20421 Mute This Topic: https://lists.fd.io/mt/86821639/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] a free_bitmap may expand while pool_put
Hi Damjan, Hi Florin, I may have given the wrong example, even though the IP API's marked as mt-safe (VL_API_IP_ROUTE_ADD_DEL/VL_API_IP_ROUTE_ADD_DEL_V2), they'd be called only from the main thread, right? So, only one pool_put will be called and it looks like the patch actually fixes the problem (I still don't like it). I liked the idea with a vec of freed elements, but we still need to put a worker barrier to perform such an operation. I thought about something more lightweight, like CAS for a newly allocated bitmap/vector. But I find myself extremely incompetent to write any lock-free solutions. On Thu, 4 Nov 2021 at 20:01, Florin Coras wrote: > Agreed! Since pools are not thread safe, the whole load balance destroy > scheme should probably be refactored. > > Maybe add, with locks, the indices to be freed to a vector and once enough > accumulate, or if a new element is needed, grab the worker barrier and > actually free them all. > > Regards, > Florin > > On Nov 4, 2021, at 11:50 AM, Damjan Marion via lists.fd.io < > dmarion=me@lists.fd.io> wrote: > > > Dear Stanislav, > > It doesn’t look to me as a thread safe solution. > > i.e imagine 2 threads call pool_put_will expand on the same time, and > there is just one free slot. Both will get negative answer, but 2nd put > operation will actually expand. > > — > Damjan > > On 04.11.2021., at 18:24, Stanislav Zaikin wrote: > > > Hello folks, > > In a multi-threaded environment (in my case I have 2 workers) I observed a > crash, and thanks to Neale, it turned out that free_bitmap may expand while > doing pool_put. > Let's say one thread is doing pool_put, while another thread is calling > "pool_elt_at_index". I observed different addresses before and after > checking "ASSERT (! pool_is_free (p, _e))" in that macro. > > I prepared a patch [0], but it's kind of ugly. We don't have asserts in > release mode, so why should we care about it? > > On the other hand, 2 different threads can do 2 pool_puts simultaneously > and we can lose one free element in the pool (and also additionally > allocated bitmap). > > For me, it's a place where it would be nice to have an mt-safe vec. What > do you think? > > [0] - https://gerrit.fd.io/r/c/vpp/+/34332 > > -- > Best regards > Stanislav Zaikin > > > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20428): https://lists.fd.io/g/vpp-dev/message/20428 Mute This Topic: https://lists.fd.io/mt/86821639/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] [csit-dev] FD.io CSIT-2110 Release Report is published
Thanks for the report! Out of curiosity, what happened to AF_XDP? PPS rate was much bigger on r21.06. [0] - https://s3-docs.fd.io/csit/rls2110/report/vpp_performance_tests/packet_throughput_graphs/ip4-2n-skx-x710.html [1] - https://docs.fd.io/csit/rls2106/report/vpp_performance_tests/packet_throughput_graphs/ip4-2n-skx-x710.html On Thu, 11 Nov 2021 at 15:19, Maciek Konstantynowicz (mkonstan) via lists.fd.io wrote: > Big thanks to FD.io community contributors and supporters that enabled > this data-rich publication. > Great job everyone! > > Cheers, > Maciek > > On 10 Nov 2021, at 18:12, Tibor Frank via lists.fd.io < > tifrank=cisco@lists.fd.io> wrote: > > Hi All, > > FD.io <http://fd.io/> CSIT-2110 report is now available on FD.io > <http://fd.io/> docs site: > > https://s3-docs.fd.io/csit/rls2110/report/ > > Another successful release! Many thanks to all contributors in CSIT and > VPP communities for making it happen. > > See below for CSIT-2110 release summary and pointers to specific > sections in the report. > > Welcome all comments, best by email to csit-...@lists.fd.io. > > Tibor > > > CSIT-2110 Release Summary > - > > BENCHMARK TESTS > > - Intel Xeon Ice Lake: Added test data for these platforms. Current > CSIT-2110 > report data for Intel Xeon Ice Lake comes from an external source (Intel > labs running CSIT code on “8360Y D Stepping” and “6338N” processors). > > - MLRsearch improvements: Added support for multiple packet throughput > rates > in a single search, each rate is associated with a distinct Packet Loss > Ratio > (PLR) criterion. Previously only Non Drop Rate (NDR) (PLR=0) and single > Partial Drop Rate (PDR) (PLR<0.5%) were supported. Implemented number of > optimizations improving rate discovery efficiency. > > - TREX performance tests: Added initial tests for testing latency between 2 > ports on nic on the TRex. Added tests: IP4Base, IP4scale2m, IP6Base, > IP6scale2m, L2bscale1mmaclrn. > > TEST FRAMEWORK > > - CSIT test environment version has been updated to ver. 8: Intel NIC > 700/800 > series firmware upgrade based on DPDK compatibility matrix. > > - CSIT in AWS environment: Added CSIT support for AWS c5n instances > environment. > > Pointers to CSIT-2110 Report sections > - > > 1. FD.io <http://fd.io/> CSIT test methodology [1] > 2. VPP release notes[2] > 3. VPP 64B/IMIX throughput graphs [3] > 4. VPP throughput speedup multi-core[4] > 5. VPP latency under load [5] > 6. VPP comparisons v21.10 vs. v21.06[6] > 7. VPP performance all pkt sizes & NICs [7] > 8. DPDK 21.08 apps release notes[8] > 9. DPDK 64B throughput graphs [9] > 10. DPDK latency under load [10] > 11. DPDK comparisons 21.08 vs. 21.02[11] > 12. TRex 2.88 apps release notes[12] > 13. TRex 64B throughput graphs [13] > 14. TRex latency under load [14] > > Functional device tests (VPP_Device) are also included in the report. > > [1] > https://s3-docs.fd.io/csit/rls2110/report/introduction/methodology.html > [2] > https://s3-docs.fd.io/csit/rls2110/report/vpp_performance_tests/csit_release_notes.html > [3] > https://s3-docs.fd.io/csit/rls2110/report/vpp_performance_tests/packet_throughput_graphs/index.html > [4] > https://s3-docs.fd.io/csit/rls2110/report/vpp_performance_tests/throughput_speedup_multi_core/index.html > [5] > https://s3-docs.fd.io/csit/rls2110/report/vpp_performance_tests/packet_latency/index.html > [6] > https://s3-docs.fd.io/csit/rls2110/report/vpp_performance_tests/comparisons/current_vs_previous_release.html > [7] > https://s3-docs.fd.io/csit/rls2110/report/detailed_test_results/vpp_performance_results/index.html > [8] > https://s3-docs.fd.io/csit/rls2110/report/dpdk_performance_tests/csit_release_notes.html > [9] > https://s3-docs.fd.io/csit/rls2110/report/dpdk_performance_tests/packet_throughput_graphs/index.html > [10] > https://s3-docs.fd.io/csit/rls2110/report/dpdk_performance_tests/packet_latency/index.html > [11] > https://s3-docs.fd.io/csit/rls2110/report/dpdk_performance_tests/comparisons/current_vs_previous_release.html > [12] > https://s3-docs.fd.io/csit/rls2110/report/trex_performance_tests/csit_release_notes.html > [13] > https://s3-docs.fd.io/csit/rls2110/report/trex_performance_tests/packet_throughput_graphs/index.html > [14] > https://s3-docs.fd.io/csit/rls2110/report/trex_performance_tests/packet_latency/index.html > > > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20481): https://lists.fd.io/g/vpp-dev/message/20481 Mute This Topic: https://lists.fd.io/mt/86982560/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] Recursive routing issue
Hi Wei, Interesting finding! Only the first resolved path was added when creating the rr entry (as you can see in the first output of "show ip fib 192.168.200.0/24"). I've prepared (probably) a fix [0] and tested it with the same setup (2 ipip tunnels). At least from cli perspective - it works now, I didn't test it with any traffic though. Can you give it a try? [0] - https://gerrit.fd.io/r/c/vpp/+/34621 On Tue, 30 Nov 2021 at 17:54, Wei Huang wrote: > I have an issue with recursive routing and like to get some advice on how > to fix this. > > On my vpp node, I have two interfaces ipip0, ipip1, both can reach > 192.168.21.0/24 > > I added two routes like this > vppctl ip route add 192.168.21.0/24 via ipip0 > vppctl ip route add 192.168.21.0/24 via ipip1 > > Then I added a route like this: > vppctl ip route add 192.168.200.0/24 via 192.168.21.2 > > I try to ping 192.168.21.2, 192.168.200.20, both works fine, traffic goes > through ipip0. > > vpp#show ip fib 192.168.21.0/24 > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, > default-route:1, ] > 192.168.21.0/24 fib:0 index:29 locks:2 > CLI refs:1 entry-flags:attached, src-flags:added,contributing,active, > path-list:[39] locks:2 flags:shared, uPRF-list:38 len:2 itfs:[4, 5, ] > path:[48] pl-index:39 ip4 weight=1 pref=0 attached: > oper-flags:resolved, > ipip0 > path:[49] pl-index:39 ip4 weight=1 pref=0 attached: > oper-flags:resolved, > ipip1 > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:32 buckets:2 uRPF:38 to:[5:443]] > [0] [@6]: ipv4 via 0.0.0.0 ipip0: mtu:9000 next:10 flags:[fixup-ip4o4 > ] 45004004f69dc0a80106c0a80206 > stacked-on entry:30: > [@2]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 > to:[0:0] via:[4965:724564]] > [0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:6 > flags:[] fa163fdd32d9fa163f30992d0800 > [1] [@6]: ipv4 via 0.0.0.0 ipip1: mtu:9000 next:10 flags:[fixup-ip4o4 > ] 45004004db9dc0a80a06c0a81406 > stacked-on entry:31: > [@2]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:20 > to:[0:0] via:[292:31108]] > [0] [@5]: ipv4 via 192.168.10.1 tn-eth1: mtu:9000 next:7 > flags:[] fa163f3186d0fa163f93d4ea0800 > vpp# show ip fib 192.168.200.0/24 > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, > default-route:1, ] > 192.168.200.0/24 fib:0 index:33 locks:2 > API refs:1 src-flags:added,contributing,active, > path-list:[40] locks:4 flags:shared, uPRF-list:40 len:1 itfs:[4, ] > path:[50] pl-index:40 ip4 weight=1 pref=0 recursive: > oper-flags:resolved, > via 192.168.21.2 in fib:0 via-fib:34 via-dpo:[dpo-load-balance:35] > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:36 buckets:1 uRPF:40 > to:[4250:357000]] > [0] [@12]: dpo-load-balance: [proto:ip4 index:35 buckets:1 uRPF:39 > to:[142:8733] via:[4250:357000]] > [0] [@6]: ipv4 via 0.0.0.0 ipip0: mtu:9000 next:10 > flags:[fixup-ip4o4 ] 45004004f69dc0a80106c0a80206 > stacked-on entry:30: > [@2]: dpo-load-balance: [proto:ip4 index:13 buckets:1 > uRPF:12 to:[0:0] via:[4975:726084]] > [0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:6 > flags:[] fa163fdd32d9fa163f30992d0800 > > Then I take down ipip0, if I ping 192.168.21.2, it works, traffic goes > through ipip1, but for 192.168.200.20, it doesn't. > > vpp# show ip fib 192.168.200.0/24 > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, > default-route:1, ] > 192.168.200.0/24 fib:0 index:33 locks:2 > API refs:1 src-flags:added,contributing,active, > path-list:[40] locks:4 flags:shared, uPRF-list:39 len:1 itfs:[4, ] > path:[50] pl-index:40 ip4 weight=1 pref=0 recursive: > via 192.168.21.2 in fib:0 via-fib:34 via-dpo:[dpo-load-balance:35] > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:36 buckets:1 uRPF:39 > to:[4336:364224]] > [0] [@0]: dpo-drop ip4 > > Is there anyway to let the recursive route knows to use the ipip1 when > ipip0 is down? > > Thanks in advance, > > Wei > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20565): https://lists.fd.io/g/vpp-dev/message/20565 Mute This Topic: https://lists.fd.io/mt/87406938/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] searching for all routes that point to an attached next-hop neighbor #routing
Hi David, I'll answer from my perspective (maybe not 100% correct). Both your commands will create 2 paths with attached nexthop. It will source the fib path for 10.0.0.2/32 based on the "connected" path for 10.0.0.0/24 (which is a glean path on the interface GigabitEthernet2/0/1). You'd see it as "arp-ipv4: via 10.0.0.2 GigabitEthernet2/0/1". So, when the first packet would come to dst in the 100.64.10.0/23, the arp request will be sent automatically. After the arp response is processed, an adj-fib path for 10.0.0.2/32 (with l2 headers) will be added. And there's no need to iterate over all the routes with such nexthop. I didn't get your use case, but I can assume one thing. In case your control plane is responsible for adding such routes, you need only to subscribe to neighbours events (want_ip_neighbor_events for the specific ip address and/or interface). Then you can lookup routes in CP with such nexthop and do whatever you want with those routes. In case your CP isn't responsible for that, you need to dump all the routes from time to time and do the same thing. If you can tell more about your use-case there might be more bright ideas. On Thu, 23 Dec 2021 at 14:13, David Gohberg wrote: > Hello, > > From reading the routing data model: > > https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/fib20/routes.html#id2 > I understand that when I add a static route (using the "ip route add" > command) to an attached next hop, VPP will resolve that > route, which is triggered (in my case of plain ol' routing) by a > successful ARP learning event. What I want is to perform > some logic on each of the routes that their attached next-hop is a > recently learned neighbor. > > Taking the example from the doc: if I use > ip route add table 1 64.10.1.0/24 10.0.0.2 GigabitEthernet2/0/1 > ip route add table 1 64.10.2.0/24 10.0.0.2 GigabitEthernet2/0/1 > then upon learning the MAC of 10.0.0.2 neighbor, > I want to be able to programmatically fetch the 64.10.1.0/24 and > 64.10.2.0/24 prefixes in that context of neighbor resolution. > > I've traced down the neighbor learning logic to `ip_neighbor_add` function > in `vnet/ip-neighbor/` but I couldn't figure out > where VPP performs the route resolution following a neighbor learning > event. > > If I understand the model correctly, a new neighbor IP and MAC triggers a > change to the adjacency table. > In order to fetch the matching prefixes, I need to be able to iterate over > entries of fib_entry_t , for each entry checking the fib_path_t it has, and > whether the path's ip_adjancency_t is matching the IP and MAC of the > recently learned neighbor. > > Is my perception correct? > > Thanks, > David > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20661): https://lists.fd.io/g/vpp-dev/message/20661 Mute This Topic: https://lists.fd.io/mt/87917518/21656 Mute #routing:https://lists.fd.io/g/vpp-dev/mutehashtag/routing Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Failed to create wireguard tunnel using CLI
length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > 12:51:33.945859 52:54:00:02:10:01 > 52:54:00:01:10:02, ethertype IPv4 > (0x0800), length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > 12:51:39.216163 52:54:00:02:10:01 > 52:54:00:01:10:02, ethertype IPv4 > (0x0800), length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > 12:51:44.357225 52:54:00:02:10:01 > 52:54:00:01:10:02, ethertype IPv4 > (0x0800), length 190: (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto > UDP (17), length 176) > > 192.168.10.3.50869 > 192.168.10.0.50869: UDP, length 148 > > But vpp1 is not receiving them. Show errors and show logging gives me no > reasonable leads. Can somebody help me figure this out ? > > groet, > Pim > -- > Pim van Pelt > PBVP1-RIPE - http://www.ipng.nl/ > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20698): https://lists.fd.io/g/vpp-dev/message/20698 Mute This Topic: https://lists.fd.io/mt/88321357/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] L2/L3 cross-connect allows pinging an interface located in a deleted netns
Hi Artem, As far as I know, netns in the host is just a binding (mounting point) to the netns. If you delete the file (in /var/run/netns/ or something), you just lose the way to connect to it. But the netns will be still in the kernel until you delete all the interfaces from it (maybe except lo). On Thu, 13 Jan 2022 at 08:35, Artem Glazychev wrote: > Hello all, > > I ran into a problem when working with l2/l3 cross connect. > > For example, I create two *tap* interfaces in different network > namespaces and L2 cross-connect inside a vpp instance. Set up addresses - > ping works. > But, if i delete the target namespace from the host - ping continues to > work. > I've tested it with *l2xc/l3xc + tap/tun* - the result is the same. > Moreover, I see the same behavior with *l2xc + **af-packet* if I > configure it via *vpp api*. But unfortunately I can't reproduce it using > *vppctl*... > Does anyone have any idea? > > I've created a JIRA issue with steps to reproduce - > https://jira.fd.io/browse/VPP-2006 > > Thanks > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20705): https://lists.fd.io/g/vpp-dev/message/20705 Mute This Topic: https://lists.fd.io/mt/88392642/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] Failed to create wireguard tunnel using CLI
alive:0 *flags: > 2, *api-clients count: 0 > > adj: > > key:qZz6XPwtrrEJw2rnzFHXYCm5KGm7+Cc9clpoP+B6kQc= > a99cfa5cfc2daeb109c36ae7cc51d76029b92869bbf8273d725a683fe07a9107 > > allowed-ips: 10.0.123.0/24 > > > But I can't ping the neighbor (or, as a matter of fact, myself): > > vpp1# ping 10.0.123.1 > > > Statistics: 5 sent, 0 received, 100% packet loss > > vpp1# ping 10.0.123.2 > > > Statistics: 5 sent, 0 received, 100% packet loss > > > vpp1# show ip fib 10.0.123.1 > > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, default-route:1, lcp-rt:1, ] > > 10.0.123.1/32 fib:0 index:122 locks:2 > > interface refs:1 entry-flags:connected,local, > src-flags:added,contributing,active, cover:119 > > path-list:[58] locks:2 flags:local, uPRF-list:48 len:0 itfs:[] > > path:[84] pl-index:58 ip4 weight=1 pref=0 receive: oper-flags:resolved, > cfg-flags:local, > > [@0]: dpo-receive: 10.0.123.1 on wg0 > > > forwarding: unicast-ip4-chain > > [@0]: dpo-load-balance: [proto:ip4 index:124 buckets:1 uRPF:48 to:[0:0]] > > [0] [@13]: dpo-receive: 10.0.123.1 on wg0 > > > vpp1# show ip fib 10.0.123.2 > > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, default-route:1, lcp-rt:1, ] > > 10.0.123.0/24 fib:0 index:119 locks:2 > > interface refs:1 entry-flags:connected,attached, > src-flags:added,contributing,active, cover:-1 > > path-list:[55] locks:2 uPRF-list:43 len:1 itfs:[11, ] > > path:[81] pl-index:55 ip4 weight=1 pref=0 attached: > oper-flags:resolved, > cfg-flags:glean, > > wg0 > > > forwarding: unicast-ip4-chain > > [@0]: dpo-load-balance: [proto:ip4 index:121 buckets:1 uRPF:43 > to:[5:480]] > > [0] [@0]: dpo-drop ip4 > > > I was not sure how neighbor discovery works on the wireguard, so I set a > static to the peer on both machines: > > *vpp2# ip route add 10.0.123.1/32 <http://10.0.123.1/32> via wg0* > > *vpp1# ip route add 10.0.123.2/32 <http://10.0.123.2/32> via wg0* > > vpp1# ping 10.0.123.2 > > 116 bytes from 10.0.123.2: icmp_seq=1 ttl=64 time=4.5987 ms > > 116 bytes from 10.0.123.2: icmp_seq=2 ttl=64 time=5.6347 ms > > 116 bytes from 10.0.123.2: icmp_seq=3 ttl=64 time=5.6518 ms > > 116 bytes from 10.0.123.2: icmp_seq=4 ttl=64 time=5.6929 ms > > 116 bytes from 10.0.123.2: icmp_seq=5 ttl=64 time=5.6257 ms > > > Statistics: 5 sent, 5 received, 0% packet loss > > Stanislav, if you have the dynamic endpoint behavior, I'd be very > interested. As the remote might be behind NAT or DHCP, and the central > wireguard concentrator is the only machine with a known IPv4/IPv6 address, > it'd be very useful to be able to omit the 'endpoint' argument to the peer. > > groet, > Pim > > On Tue, Jan 11, 2022 at 5:02 PM Stanislav Zaikin > wrote: > >> Hi Pim, >> >> IIRC you should specify the endpoint on vpp1. At least it was true about >> a year ago. >> I even prepared a patch to enable this dynamic endpoint updating, but I >> don't remember what went wrong (there should be a reason why I didn't send >> it upstream). >> >> Could you give it a try by specifying the endpoint on vpp1 while I'm >> trying to find that patch? >> >> On Mon, 10 Jan 2022 at 13:01, Pim van Pelt wrote: >> >>> Hoi folks, >>> >>> On a reasonably recent VPP, I'm trying to create a Wireguard tunnel, >>> it's not working for me and I have a few questions (and found a few small >>> bugs along the way) - I'm hoping you can help me further :) >>> This is on two instances of VPP running on a hypervisor (KVM so >>> interfaces are virtio) and the version is *vpp >>> v22.02-rc0~347-gb28df767d built by pim on hippo at 2021-11-30T15:22:48* >>> >>> After bringing up basic connectivity, machine vpp1 has a >>> loopback 192.168.10.0 and vpp2 has a loopback 192.168.10.3 -- they can >>> reach each other fine, and there is no additional configuration (like ACLs >>> and such) -- >>> >>> vpp1# ping 192.168.10.3 >>> >>> 116 bytes from 192.168.10.3: icmp_seq=1 ttl=62 time=5.7011 ms >>> >>> 116 bytes from 192.168.10.3: icmp_seq=2 ttl=62 time=4.4814 ms >>> >>> 116 bytes from 192.168.10.3: icmp_seq=3 ttl=62 time=4.4962 ms >>> >>> 116 bytes from 192.168.10.3: icmp_seq=4 ttl=62 time=23.2758 ms >>> >
Re: [vpp-dev] ip4 getting disabled when using worker threads
Hi Scott, That means that you got 2 ipv4 packets on the interface without an IP address If you want to see what happens exactly you can execute: trace filter include ip4-not-enabled 10 trace add virtio-input 10 and then see the trace. It will show on what interface without an IP you're getting those packets. On Tue, 25 Jan 2022 at 23:16, Scott McMillan wrote: > Hi all, > > > > I’m having an issue with virtio devices in a VM on OCI when setting up > multiple workers with VPP (21.06). I’m looking for some suggestions on > where to start the debugging. Here is what I’m seeing: > > > >- With the startup configuration commenting out “corelist-workers 2” >(so that there are no workers), everything works correctly. > >- Same setup with one change, uncomment “corelist-workers 2”, ip4 gets >disabled. I get the following dispatch traces in the event-logger: > > > 000:00:00:002:662 workers 1 dpdk-input-return: 2 > > 000:00:00:002:667 workers 1 ethernet-input-call: 2 > > 000:00:00:002:690 workers 1 ethernet-input-return: 2 > > 000:00:00:002:692 workers 1 ip4-input-call:2 > > 000:00:00:002:698 workers 1 ip4-input-return: 2 > > 000:00:00:002:699 workers 1 ip4-not-enabled-call: 2 > > 000:00:00:002:705 workers 1 ip4-not-enabled-return:2 > > 000:00:00:002:705 workers 1 error-drop-call: 2 > > 000:00:00:002:707 workers 1 error-drop-return: 2 > > > > When using a VM on openstack, I don’t have this problem. Something > specific about the OCI setup seems to be causing issues. > > > > I also don’t have issues on OCI when using the Broadcom and Mellanox > virtual functions with multiple workers. Only with virtio > (PARAVIRTUALIZED). > > > > Any suggestions on what is resulting in the ip4 disablement? Any > suggestions on where to start the debug? I can get GDB out and step > through it, but was hoping for someone to zero me on something if possible. > > > > Thanks, > > Scott McMillan > > > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20787): https://lists.fd.io/g/vpp-dev/message/20787 Mute This Topic: https://lists.fd.io/mt/88683738/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [External] : Re: [vpp-dev] ip4 getting disabled when using worker threads
4fa0e40 > > packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > > IP4: 02:00:17:05:9f:bd -> 02:00:17:05:b7:59 > > ICMP: 192.168.100.5 -> 192.168.100.20 > > tos 0x00, ttl 64, length 84, checksum 0xd1fe dscp CS0 ecn NON_ECN > > fragment id 0x1f40, flags DONT_FRAGMENT > > ICMP echo_reply checksum 0x6f77 id 21172 > > > > Packet 9 > > > > 00:00:06:253485: dpdk-input > > tn-eth2 rx queue 0 > > buffer 0x96810: current data 0, length 98, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x8 > > ext-hdr-valid > > l4-cksum-computed l4-cksum-correct > > PKT MBUF: port 2, nb_segs 1, pkt_len 98 > > buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr > 0x64fa0480 > > packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > > IP4: 02:00:17:05:b7:59 -> 02:00:17:05:9f:bd > > ICMP: 192.168.100.20 -> 192.168.100.5 > > tos 0x00, ttl 64, length 84, checksum 0x959f dscp CS0 ecn NON_ECN > > fragment id 0x5b9f, flags DONT_FRAGMENT > > ICMP echo_request checksum 0x8918 id 21172 > > 00:00:06:253494: ethernet-input > > frame: flags 0x1, hw-if-index 3, sw-if-index 3 > > IP4: 02:00:17:05:b7:59 -> 02:00:17:05:9f:bd > > 00:00:06:253501: ip4-input > > ICMP: 192.168.100.20 -> 192.168.100.5 > > tos 0x00, ttl 64, length 84, checksum 0x959f dscp CS0 ecn NON_ECN > > fragment id 0x5b9f, flags DONT_FRAGMENT > > ICMP echo_request checksum 0x8918 id 21172 > > 00:00:06:253503: ip4-lookup > > fib 0 dpo-idx 9 flow hash: 0x > > ICMP: 192.168.100.20 -> 192.168.100.5 > > tos 0x00, ttl 64, length 84, checksum 0x959f dscp CS0 ecn NON_ECN > > fragment id 0x5b9f, flags DONT_FRAGMENT > > ICMP echo_request checksum 0x8918 id 21172 > > 00:00:06:253506: ip4-local > > ICMP: 192.168.100.20 -> 192.168.100.5 > > tos 0x00, ttl 64, length 84, checksum 0x959f dscp CS0 ecn NON_ECN > > fragment id 0x5b9f, flags DONT_FRAGMENT > > ICMP echo_request checksum 0x8918 id 21172 > > 00:00:06:253508: ip4-icmp-input > > ICMP: 192.168.100.20 -> 192.168.100.5 > > tos 0x00, ttl 64, length 84, checksum 0x959f dscp CS0 ecn NON_ECN > > fragment id 0x5b9f, flags DONT_FRAGMENT > > ICMP echo_request checksum 0x8918 id 21172 > > 00:00:06:253509: ip4-icmp-echo-request > > ICMP: 192.168.100.20 -> 192.168.100.5 > > tos 0x00, ttl 64, length 84, checksum 0x959f dscp CS0 ecn NON_ECN > > fragment id 0x5b9f, flags DONT_FRAGMENT > > ICMP echo_request checksum 0x8918 id 21172 > > 00:00:06:253511: ip4-load-balance > > fib 0 dpo-idx 8 flow hash: 0x > > ICMP: 192.168.100.5 -> 192.168.100.20 > > tos 0x00, ttl 64, length 84, checksum 0x38c5 dscp CS0 ecn NON_ECN > > fragment id 0xb879, flags DONT_FRAGMENT > > ICMP echo_reply checksum 0x9118 id 21172 > > 00:00:06:253513: ip4-rewrite > > tx_sw_if_index 3 dpo-idx 8 : ipv4 via 192.168.100.20 tn-eth2: mtu:9000 > next:5 flags:[] 02001705b759020017059fbd0800 flow hash: 0x > > : > 02001705b759020017059fbd08004554b8794000400138c5c0a86405c0a8 > > 0020: 6414911852b409b40d45f1614f0506001011 > > 00:00:06:253514: tn-eth2-output > > tn-eth2 > > IP4: 02:00:17:05:9f:bd -> 02:00:17:05:b7:59 > > ICMP: 192.168.100.5 -> 192.168.100.20 > > tos 0x00, ttl 64, length 84, checksum 0x38c5 dscp CS0 ecn NON_ECN > > fragment id 0xb879, flags DONT_FRAGMENT > > ICMP echo_reply checksum 0x9118 id 21172 > > 00:00:06:253516: tn-eth2-tx > > tn-eth2 tx queue 0 > > buffer 0x96810: current data 0, length 98, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x8 > > ext-hdr-valid > > l4-cksum-computed l4-cksum-correct local l2-hdr-offset 0 > l3-hdr-offset 14 > > PKT MBUF: port 2, nb_segs 1, pkt_len 98 > > buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr > 0x64fa0480 > > packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > > IP4: 02:00:17:05:9f:bd -> 02:00:17:05:b7:59 > > ICMP: 192.168.100.5 -> 192.168.100.20 > > tos 0x00, ttl 64, length 84, checksum 0x38c5 dscp CS0 ecn NON_ECN > > fragment id 0xb879, flags DONT_FRAGMENT > > ICMP echo_reply checksum 0x9118 id 21172 > > > > Packet 10 > > > > 00:00:07:277392:
Re: [vpp-dev] Out of tree plugins ergonomics
Hi guys, I use the same approach as Pim does. I have the following structure in my repo: * directory with the plugin sources * vpp which is added as a git submodule * directory for vpp patches which are not merged to upstream yet * makefile that applies the patches, creates a symbolic link inside ./vpp/src/plugins/ On Tue, 15 Mar 2022 at 14:17, Pim van Pelt wrote: > Hoi Andrew, > > I don't know if mine qualifies as "truly", but github.com/pimvanpelt/lcpng > certainly qualifies as "out-of-tree" in the sense that it's meant to be > linked in, not standalone compilable as a module (that would be ... > cumbersome). > > cd ~/src > git clone https://github.com/pimvanpelt/lcpng.git > ln -s ~/src/lcpng ~/src/vpp/src/plugins/lcpng > cd ~/src/vpp > make build > make build-release > > > > On Tue, Mar 15, 2022 at 1:36 PM Andrew Yourtchenko > wrote: > >> hi all, >> >> Is there anyone doing the truly “out of tree“ plugins ? I would like to >> take a look a bit at the ergonomics of this process, and having another >> brain(s) to discuss with would be useful. >> >> --a >> >> >> > > -- > Pim van Pelt > PBVP1-RIPE - http://www.ipng.nl/ > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21022): https://lists.fd.io/g/vpp-dev/message/21022 Mute This Topic: https://lists.fd.io/mt/89796445/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] Crash in BVI and Loopback interaction
) > at /home/pim/src/vpp/src/vlib/node_funcs.h:1025 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > *2) Create bvi after loop:* > DBGvpp# show version > vpp v22.06-rc0~268-g4859d8d8e built by pim on hippo at 2022-03-23T19:23:53 > DBGvpp# create loopback > loop0 > DBGvpp# delete loopback interface intfc loop0 > DBGvpp# bvi create > *0: /home/pim/src/vpp/src/vlib/node.c:194 (vlib_node_add_next_with_slot) > assertion `slot == p[0]' fails > * > > > Thread 1 "vpp_main" received signal SIGABRT, Aborted. > > __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > > 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. > > (gdb) bt > > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > > #1 0x769de859 in __GI_abort () at abort.c:79 > > #2 0x004072f3 in os_panic () at > /home/pim/src/vpp/src/vpp/vnet/main.c:413 > > #3 0x76d2ebc9 in debugger () at > /home/pim/src/vpp/src/vppinfra/error.c:84 > > #4 0x76d2e92d in _clib_error (how_to_die=2, function_name=0x0, > line_number=0, fmt=0x76f3b19c "%s:%d (%s) assertion `%s' fails") > > at /home/pim/src/vpp/src/vppinfra/error.c:143 > > #5 0x76ea462b in vlib_node_add_next_with_slot (vm=0x7fff96800740, > node_index=696, next_node_index=648, slot=0) > at /home/pim/src/vpp/src/vlib/node.c:194 > > #6 0x76ea61d8 in vlib_node_add_named_next_with_slot > (vm=0x7fff96800740, node=696, name=0x77cc7c86 "l2-input", slot=0) > > at /home/pim/src/vpp/src/vlib/node.c:267 > > #7 0x77123f69 in l2_bvi_create (user_instance=4294967295, > mac_in=0x7fff515424e8, sw_if_indexp=0x7fff515424f8) > > at /home/pim/src/vpp/src/vnet/l2/l2_bvi.c:186 > > #8 0x771266b9 in l2_bvi_create_cli (vm=0x7fff96800740, > input=0x7fff51542e40, cmd=0x7fff99b87868) > > at /home/pim/src/vpp/src/vnet/l2/l2_bvi.c:256 > > #9 0x76e681d4 in vlib_cli_dispatch_sub_commands > (vm=0x7fff96800740, cm=0x4312e0 , > input=0x7fff51542e40, > parent_command_index=1124) at /home/pim/src/vpp/src/vlib/cli.c:592 > > #10 0x76e67f4e in vlib_cli_dispatch_sub_commands > (vm=0x7fff96800740, cm=0x4312e0 , > input=0x7fff51542e40, > parent_command_index=0) at /home/pim/src/vpp/src/vlib/cli.c:549 > > #11 0x76e66e98 in vlib_cli_input (vm=0x7fff96800740, > input=0x7fff51542e40, function=0x76ef2c40 , > function_arg=0) > at /home/pim/src/vpp/src/vlib/cli.c:695 > > #12 0x76ef48dd in unix_cli_process_input (cm=0x76f69748 > , cli_file_index=0) at > /home/pim/src/vpp/src/vlib/unix/cli.c:2617 > #13 0x76ef1cb1 in unix_cli_process (vm=0x7fff96800740, > rt=0x7fff9bc4ea80, f=0x0) at /home/pim/src/vpp/src/vlib/unix/cli.c:2746 > > #14 0x76e9f26d in vlib_process_bootstrap (_a=140735646532920) at > /home/pim/src/vpp/src/vlib/main.c:1220 > #15 0x76d47e08 in clib_calljmp () at > /home/pim/src/vpp/src/vppinfra/longjmp.S:123 > > #16 0x7fff92380530 in ?? () > > #17 0x76e9eb3f in vlib_process_startup (vm=0x1, p=0x8, > f=0x7fff968008b0) at /home/pim/src/vpp/src/vlib/main.c:1245 > > #18 0x7fff96800740 in ?? () > #19 0x7fff923805c0 in ?? () > #20 0x76eff104 in vlib_process_signal_event (vm= variable: Cannot access memory at address 0x2a7>, > node_index= 0x29f>, > type_opaque= 0x297>, > data=) > at /home/pim/src/vpp/src/vlib/node_funcs.h:1025 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > -- > Pim van Pelt > PBVP1-RIPE - http://www.ipng.nl/ > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21117): https://lists.fd.io/g/vpp-dev/message/21117 Mute This Topic: https://lists.fd.io/mt/90053941/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] trace in gdb
Hello folks, Is there a way to print out the trace for the packet buffer in gdb? For me VPP crashes when a packet goes wrongly to l2-input with RX interface without any l2 configuration. I'm using linux-cp and it looks like the packet doesn't hit the "linux-cp-xc-ip4" node for some reason. And what's strange is that it works for some time and only then crashes (so tracin the packet before crash doesn't help me at all). I want to see what node was before l2-input. -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21121): https://lists.fd.io/g/vpp-dev/message/21121 Mute This Topic: https://lists.fd.io/mt/90087736/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] trace in gdb
Thank you Benoit, It was exactly what I needed. On Mon, 28 Mar 2022 at 17:49, Benoit Ganne (bganne) wrote: > Yes, you can call 'gdb_show_traces()' from gdb - but you'll need to have > tracing enable beforehand of course. > If that's not enough, you can enable trajectory tracing: > https://git.fd.io/vpp/tree/src/vlib/buffer.h#n101 and inspect them via > 'gdb_dump_trajectory_trace()'. > > ben > > > -Original Message- > > From: vpp-dev@lists.fd.io On Behalf Of Stanislav > > Zaikin > > Sent: Monday, March 28, 2022 17:44 > > To: vpp-dev > > Subject: [vpp-dev] trace in gdb > > > > Hello folks, > > > > Is there a way to print out the trace for the packet buffer in gdb? > > For me VPP crashes when a packet goes wrongly to l2-input with RX > > interface without any l2 configuration. I'm using linux-cp and it looks > > like the packet doesn't hit the "linux-cp-xc-ip4" node for some reason. > > And what's strange is that it works for some time and only then crashes > > (so tracin the packet before crash doesn't help me at all). > > > > I want to see what node was before l2-input. > > > > > > -- > > > > Best regards > > Stanislav Zaikin > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21126): https://lists.fd.io/g/vpp-dev/message/21126 Mute This Topic: https://lists.fd.io/mt/90087736/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] issue with ethernet-input (or not)
Hello folks, I'm experiencing a weird issue. I'm running a current master with linux-cp plugin enabled. I create a loopback interface, set it as BVI for a bridge, and create a lcp for the loop. Almost everywhere it's working just fine. Usually, the trace looks like this: virtio-input -> ethernet-input -> ip4-input -> linux-cp-xc-ip4 -> loop20-output -> l2-input -> etc But on 2 machines I observe a crash almost immediately as some traffic comes from the tap interface (which is lcp interface for the loop). It happens in the "l2-input" node. But the tap interface isn't a part of any bridge (and obviously it doesn't have any l2 config, and that's why vpp crashes). I even enabled VLIB_BUFFER_TRACE_TRAJECTORY to check how the trace looks like. I can see that the packet goes directly from "ethernet-input" to "l2-input" (which obviously shouldn't happen). I double-checked the sources of ethernet-input and the only reason could be if in ethernet_main.main_intfs[sw_if_index] there's a flag SUBINT_CONFIG_L2 for an untagged subinterface. I checked that in gdb and I don't have such a flag for my tap interface. Since I run out of ideas on what to check I'm asking for the help of the community. So, any ideas/inputs are much appreciated. -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21140): https://lists.fd.io/g/vpp-dev/message/21140 Mute This Topic: https://lists.fd.io/mt/90117260/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] issue with ethernet-input (or not)
Looks like I found the issue:
it happens when ethernet-node gets a frame with flag
ETH_INPUT_FRAME_F_SINGLE_SW_IF_IDX but they're actually packets from
different interfaces (from virtio-node but some of them are l2 and some of
them are l3). virtio-input doesn't set this flag, but I thought maybe it
just wasn't cleared.
After I've added a piece of code which clears the flag in frames - the
issue was gone:
diff --git a/src/vlib/main.c b/src/vlib/main.c
index fd0c1fc5f..e88a0724a 100644
--- a/src/vlib/main.c
+++ b/src/vlib/main.c
@@ -208,6 +208,7 @@ vlib_frame_free (vlib_main_t * vm, vlib_node_runtime_t
* r, vlib_frame_t * f)
}
f->frame_flags &= ~(VLIB_FRAME_IS_ALLOCATED | VLIB_FRAME_NO_APPEND);
+ f->flags = 0;
vec_add1 (fs->free_frames, f);
ASSERT (fs->n_alloc_frames > 0);
@@ -1163,6 +1164,7 @@ dispatch_pending_node (vlib_main_t * vm, uword
pending_frame_index,
/* no new frame has been assigned to this node, use the saved one
*/
nf->frame = restore_frame;
f->n_vectors = 0;
+ f->flags = 0;
}
else
{
If I'm correct, I'd like to send 2 patches, this one and another which
allocates a new frame per interface with the
ETH_INPUT_FRAME_F_SINGLE_SW_IF_IDX flag in virtio-input node.
Any feedback is appreciated.
On Tue, 29 Mar 2022 at 22:09, Stanislav Zaikin wrote:
> Hello folks,
>
> I'm experiencing a weird issue. I'm running a current master with linux-cp
> plugin enabled.
> I create a loopback interface, set it as BVI for a bridge, and create a
> lcp for the loop. Almost everywhere it's working just fine. Usually, the
> trace looks like this:
>
> virtio-input -> ethernet-input -> ip4-input -> linux-cp-xc-ip4 ->
> loop20-output -> l2-input -> etc
>
> But on 2 machines I observe a crash almost immediately as some traffic
> comes from the tap interface (which is lcp interface for the loop). It
> happens in the "l2-input" node. But the tap interface isn't a part of any
> bridge (and obviously it doesn't have any l2 config, and that's why vpp
> crashes).
>
> I even enabled VLIB_BUFFER_TRACE_TRAJECTORY to check how the trace looks
> like. I can see that the packet goes directly from "ethernet-input" to
> "l2-input" (which obviously shouldn't happen).
>
> I double-checked the sources of ethernet-input and the only reason could
> be if in ethernet_main.main_intfs[sw_if_index] there's a flag
> SUBINT_CONFIG_L2 for an untagged subinterface. I checked that in gdb and I
> don't have such a flag for my tap interface.
>
> Since I run out of ideas on what to check I'm asking for the help of the
> community. So, any ideas/inputs are much appreciated.
>
> --
> Best regards
> Stanislav Zaikin
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21150): https://lists.fd.io/g/vpp-dev/message/21150
Mute This Topic: https://lists.fd.io/mt/90117260/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] issue with ethernet-input (or not)
I put an assert just to be sure that virtio-input got a frame with the
ETH_INPUT_FRAME_F_SINGLE_SW_IF_IDX
flag.
Attaching to process 324596
[New LWP 324612]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fc5c21cf1dc in virtio_device_input_inline (vm=0x7fc580e0b740,
node=0x7fc581491f40, frame=0x0, vif=0x7fc58175f900,
qid=0, type=VIRTIO_IF_TYPE_TAP) at
/home/zstas/vpp/src/vnet/devices/virtio/node.c:447
447 /home/zstas/vpp/src/vnet/devices/virtio/node.c: No such file or
directory.
Continuing.
Thread 1 "vpp_main" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7fc5c0f33859 in __GI_abort () at abort.c:79
#2 0x004072f3 in os_panic () at
/home/zstas/vpp/src/vpp/vnet/main.c:413
#3 0x7fc5c1283bc9 in debugger () at
/home/zstas/vpp/src/vppinfra/error.c:84
#4 0x7fc5c128392d in _clib_error (how_to_die=2, function_name=0x0,
line_number=0,
fmt=0x7fc5c22051a7 "%s:%d (%s) assertion `%s' fails") at
/home/zstas/vpp/src/vppinfra/error.c:143
#5 0x7fc5c21cf4ae in virtio_device_input_gso_inline
(vm=0x7fc580e0b740, node=0x7fc581491f40, frame=0x0,
vif=0x7fc58175ef00, vring=0x7fc5866aedc0, type=VIRTIO_IF_TYPE_TAP,
gso_enabled=0, checksum_offload_enabled=0, packed=0)
at /home/zstas/vpp/src/vnet/devices/virtio/node.c:266
#6 0x7fc5c21cf1e4 in virtio_device_input_inline (vm=0x7fc580e0b740,
node=0x7fc581491f40, frame=0x0, vif=0x7fc58175ef00,
qid=0, type=VIRTIO_IF_TYPE_TAP) at
/home/zstas/vpp/src/vnet/devices/virtio/node.c:447
#7 0x7fc5c21cedb1 in virtio_input_node_fn_icl (vm=0x7fc580e0b740,
node=0x7fc581491f40, frame=0x0)
at /home/zstas/vpp/src/vnet/devices/virtio/node.c:472
#8 0x7fc5c13f3f48 in dispatch_node (vm=0x7fc580e0b740,
node=0x7fc581491f40, type=VLIB_NODE_TYPE_INPUT,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0,
last_time_stamp=388854079070548) at /home/zstas/vpp/src/vlib/main.c:961
#9 0x7fc5c13ef276 in vlib_main_or_worker_loop (vm=0x7fc580e0b740,
is_main=1) at /home/zstas/vpp/src/vlib/main.c:1556
#10 0x7fc5c13f14ba in vlib_main_loop (vm=0x7fc580e0b740) at
/home/zstas/vpp/src/vlib/main.c:1715
#11 0x7fc5c13f129e in vlib_main (vm=0x7fc580e0b740,
input=0x7fc57c8b9fa8) at /home/zstas/vpp/src/vlib/main.c:2009
#12 0x7fc5c145cd5e in thread0 (arg=140486247495488) at
/home/zstas/vpp/src/vlib/unix/main.c:656
#13 0x7fc5c129cb48 in clib_calljmp () at
/home/zstas/vpp/src/vppinfra/longjmp.S:123
#14 0x7ffcb8196770 in ?? ()
#15 0x7fc5c145c94c in vlib_unix_main (argc=82, argv=0x1873450) at
/home/zstas/vpp/src/vlib/unix/main.c:736
#16 0x004066bf in main (argc=82, argv=0x1873450) at
/home/zstas/vpp/src/vpp/vnet/main.c:342
(gdb) select 5
(gdb) info locals
_f = 0x7fc5867ad040
_n = 25
n_left_to_next = 0
next0 = 4
vnm = 0x7fc5c24a06e0
thread_index = 0
n_trace = 0
next_index = 4
hdr_sz = 12
to_next = 0x0
n_rx_packets = 0
n_rx_bytes = 0
mask = 255
last = 27
n_left = 2
bt = {{cacheline0 = 0x7fc57c8b96c0 "", current_data = 0, current_length =
0, flags = 0, flow_id = 0, ref_count = 0 '\000',
buffer_pool_index = 0 '\000', error = 0, next_buffer = 0,
{current_config_index = 0, punt_reason = 0}, opaque = {0, 0, 0,
0, 0, 0, 0, 0, 0, 0}, template_end = 0x7fc57c8b9700 "", second_half =
0x7fc57c8b9700 "", trace_handle = 0,
total_length_not_including_first_buffer = 0, opaque2 = {0 }, headroom = 0x7fc57c8b9740 "",
pre_data = '\000' , data = 0x7fc57c8b97c0
"`\230\213|\305\177"}, as_u8x16 = {'\000' ,
'\000' , '\000' , '\000' }, as_u8x32 = {'\000' ,
'\000' }, as_u8x64 = {'\000' }}
(gdb) p *_f
$1 = {frame_flags = 6, flags = 1, scalar_offset = 16, vector_offset = 32,
aux_offset = 0, n_vectors = 25,
arguments = 0x7fc5867ad04c "\376\376\376\376\003"}
(gdb)
On Wed, 30 Mar 2022 at 19:35, Stanislav Zaikin via lists.fd.io wrote:
> Looks like I found the issue:
>
> it happens when ethernet-node gets a frame with flag
> ETH_INPUT_FRAME_F_SINGLE_SW_IF_IDX but they're actually packets from
> different interfaces (from virtio-node but some of them are l2 and some of
> them are l3). virtio-input doesn't set this flag, but I thought maybe it
> just wasn't cleared.
>
> After I've added a piece of code which clears the flag in frames - the
> issue was gone:
> diff --git a/src/vlib/main.c b/src/vlib/main.c
> index fd0c1fc5f..e88a0724a 100644
> --- a/src/vlib/main.c
> +++ b/src/vlib/main.c
> @@ -208,6 +208,7 @@ vlib_frame_free (vlib_main_t * vm, vlib_node_runtime_t
> * r, vlib_
Re: [vpp-dev] How to check how many packets per vector is VPP processing ? #vpp
Hi David, The last column is actually packets per call. On Wed, 13 Apr 2022 at 10:35, wrote: > Hi Pim, > > Thanks for your answer. I tried the command "show runtime" but I cannot > see those information. That's what I see from vppctl : > > vpp# show runtime > Time 488589.1, 10 sec internal node vector rate 1.00 loops/sec 6214808.56 > vector rates in 2.3584e1, out 2.2146e1, drop 1.4381e0, punt 0.e0 > Name State Calls > VectorsSuspends Clocks Vectors/Call > GigabitEthernet0/6/0-output active 137187 > 191343 0 4.18e21.39 > > > Am I missing something ? Are those information displayed with a different > name ? Thanks again. > > David > > > > > > > > > > > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21255): https://lists.fd.io/g/vpp-dev/message/21255 Mute This Topic: https://lists.fd.io/mt/90421955/21656 Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vapi and rpc stream notation
Hello folks,
Does vapi for C support code generation for the following notation (took it
from lcp.api)?
service {
rpc lcp_itf_pair_get returns lcp_itf_pair_get_reply
stream lcp_itf_pair_details;
};
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21371): https://lists.fd.io/g/vpp-dev/message/21371
Mute This Topic: https://lists.fd.io/mt/90908018/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] ikev2 and nat-t
Hello folks, I have an issue with ikev2 and the host over the nat. IKE_AUTH packet goes to ikev2-ip4 node instead of ikev2-ip4-natt and it causes IKEV2_ERROR_BAD_LENGTH. I'm not an expert in ike, but are there the right nodes specified below? udp_register_dst_port (vm, IKEV2_PORT, ikev2_node_ip4.index, 1); udp_register_dst_port (vm, IKEV2_PORT, ikev2_node_ip6.index, 0); udp_register_dst_port (vm, IKEV2_PORT_NATT, ikev2_node_ip4.index, 1); udp_register_dst_port (vm, IKEV2_PORT_NATT, ikev2_node_ip6.index, 0); Shouldn't it be ikev2_node_ip4_natt instead of ikev2_node_ip4 for IKEV2_PORT_NATT? Errors: 12 ikev2-ip4 packets processed info 6 ikev2-ip4 Bad packet length error 6 ikev2-ip4 IKE EXCHANGE SA requests receivedinfo The trace 06:19:16:980290: dpdk-input GigabitEthernet5/0/0 rx queue 0 buffer 0x84923: current data 0, length 290, buffer-pool 0, ref-count 1, trace handle 0x1 ext-hdr-valid PKT MBUF: port 0, nb_segs 1, pkt_len 290 buf_len 2176, data_len 290, ol_flags 0x180, data_off 128, phys_addr 0x59124940 packet_type 0x211 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_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt. PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt. Packet Types RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers RTE_PTYPE_L4_UDP (0x0200) UDP packet IP4: 10:0e:7e:bb:78:40 -> 38:ea:a7:37:59:90 802.1q vlan 1191 UDP: X.X.X.X -> Y.Y.Y.Y tos 0x28, ttl 216, length 272, checksum 0xe170 dscp AF11 ecn NON_ECN fragment id 0x UDP: 23911 -> 4500 length 252, checksum 0x 06:19:16:980294: bond-input src 10:0e:7e:bb:78:40, dst 38:ea:a7:37:59:90, GigabitEthernet5/0/0 -> BondEthernet10 06:19:16:980294: ethernet-input IP4: 10:0e:7e:bb:78:40 -> 38:ea:a7:37:59:90 802.1q vlan 1191 06:19:16:980295: ip4-input UDP: X.X.X.X -> Y.Y.Y.Y tos 0x28, ttl 216, length 272, checksum 0xe170 dscp AF11 ecn NON_ECN fragment id 0x UDP: 23911 -> 4500 length 252, checksum 0x 06:19:16:980296: ip4-lookup fib 0 dpo-idx 6 flow hash: 0x UDP: X.X.X.X -> Y.Y.Y.Y tos 0x28, ttl 216, length 272, checksum 0xe170 dscp AF11 ecn NON_ECN fragment id 0x UDP: 23911 -> 4500 length 252, checksum 0x 06:19:16:980296: ip4-receive UDP: X.X.X.X -> Y.Y.Y.Y tos 0x28, ttl 216, length 272, checksum 0xe170 dscp AF11 ecn NON_ECN fragment id 0x UDP: 23911 -> 4500 length 252, checksum 0x 06:19:16:980297: ip4-udp-lookup UDP: src-port 23911 dst-port 4500 06:19:16:980300: ikev2-ip4 ikev2: sw_if_index 10, next index 1 06:19:16:980301: error-drop rx:BondEthernet10.1191 06:19:16:980301: drop ip4-udp-lookup: none -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21407): https://lists.fd.io/g/vpp-dev/message/21407 Mute This Topic: https://lists.fd.io/mt/91061656/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] ikev2 and nat-t
Hi Filip, In my case an initiator is behind NAT while a responder has a public IP. What node should check for SPI=0? I also have LCP enabled on some interfaces, maybe it breaks the default punt behaviour. On Fri, 13 May 2022 at 10:54, Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco) wrote: > I'm not entirely sure that's the case - the reason being that default port > 4500 is used for both nat traversal and encrypted dataplane traffic. The > way to distinguish between those two is having SPI=0 in case of NATT. For > this there is punt mechanism in vpp, which forwards 4500 IKE packets to > natt-node. Since this isn't happening judging from your packet trace I > wonder if you maybe have responder behind nat? Such case isn't supported > > Filip > -- > *From:* vpp-dev@lists.fd.io on behalf of Benoit > Ganne (bganne) via lists.fd.io > *Sent:* Friday, May 13, 2022 10:26 AM > *To:* Stanislav Zaikin ; vpp-dev > *Subject:* Re: [vpp-dev] ikev2 and nat-t > > Hmm good catch, I wonder why we did not catch it - maybe the unit tests > use only non-standard port... > Can you try to patch it accordingly and if it solves the issue, push it on > gerrit for review? > If you can update the unit tests to reproduce the issue and verify the fix > fixes it it would be ideal of course. > > Best > Ben > > > -Original Message- > > From: vpp-dev@lists.fd.io On Behalf Of Stanislav > > Zaikin > > Sent: Thursday, May 12, 2022 18:11 > > To: vpp-dev > > Subject: [vpp-dev] ikev2 and nat-t > > > > Hello folks, > > > > I have an issue with ikev2 and the host over the nat. IKE_AUTH packet > goes > > to ikev2-ip4 node instead of ikev2-ip4-natt and it causes > > IKEV2_ERROR_BAD_LENGTH. > > > > > > I'm not an expert in ike, but are there the right nodes specified below? > > > > udp_register_dst_port (vm, IKEV2_PORT, ikev2_node_ip4.index, 1); > > udp_register_dst_port (vm, IKEV2_PORT, ikev2_node_ip6.index, 0); > > udp_register_dst_port (vm, IKEV2_PORT_NATT, ikev2_node_ip4.index, > > 1); > > udp_register_dst_port (vm, IKEV2_PORT_NATT, ikev2_node_ip6.index, > > 0); > > > > Shouldn't it be ikev2_node_ip4_natt instead of ikev2_node_ip4 for > > IKEV2_PORT_NATT? > > > > Errors: > > > > 12 ikev2-ip4 packets processed > > info > > 6 ikev2-ip4 Bad packet length > > error > > 6 ikev2-ip4 IKE EXCHANGE SA requests > > receivedinfo > > > > > > The trace > > 06:19:16:980290: dpdk-input > > GigabitEthernet5/0/0 rx queue 0 > > buffer 0x84923: current data 0, length 290, buffer-pool 0, ref-count 1, > > trace handle 0x1 > > ext-hdr-valid > > PKT MBUF: port 0, nb_segs 1, pkt_len 290 > > buf_len 2176, data_len 290, ol_flags 0x180, data_off 128, phys_addr > > 0x59124940 > > packet_type 0x211 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_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt. > > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid > > PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt. > > Packet Types > > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > > RTE_PTYPE_L4_UDP (0x0200) UDP packet > > IP4: 10:0e:7e:bb:78:40 -> 38:ea:a7:37:59:90 802.1q vlan 1191 > > UDP: X.X.X.X -> Y.Y.Y.Y > > tos 0x28, ttl 216, length 272, checksum 0xe170 dscp AF11 ecn NON_ECN > > fragment id 0x > > UDP: 23911 -> 4500 > > length 252, checksum 0x > > 06:19:16:980294: bond-input > > src 10:0e:7e:bb:78:40, dst 38:ea:a7:37:59:90, GigabitEthernet5/0/0 -> > > BondEthernet10 > > 06:19:16:980294: ethernet-input > > IP4: 10:0e:7e:bb:78:40 -> 38:ea:a7:37:59:90 802.1q vlan 1191 > > 06:19:16:980295: ip4-input > > UDP: X.X.X.X -> Y.Y.Y.Y > > tos 0x28, ttl 216, length 272, checksum 0xe170 dscp AF11 ecn NON_ECN > > fragment id 0x > > UDP: 23911 -> 4500 > > length 252, checksum 0x > > 06:19:16:980296: ip4-lookup > > fib 0 dpo-idx 6 flow hash: 0x > > UDP: X.X.X.X -> Y.Y.Y.Y > > tos 0x28, ttl 216, length 272, checksum 0xe170 dscp AF11 ecn NON_ECN > > fragme
Re: [vpp-dev] ikev2 and nat-t
Hi Filip, Hi Benoit, The issue was in linux-cp plugin (which punt ipsec to the host). But it looks like there's reversed ip addresses in IPSec SA. Could you please review the patch[0]? Also, I wanted to add a unit test, but can't figure out how to test it with the current test case logic. Any input would be appreciated. [0] https://gerrit.fd.io/r/c/vpp/+/36157 On Fri, 13 May 2022 at 12:53, Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco) wrote: > Hi Stanislav, > > punt-dispatch should be doing it; below is an example of packet trace from > my test env: > > ... > 00:00:11:655232: ip4-receive > UDP: 192.168.10.1 -> 10.0.0.2 > tos 0x00, ttl 63, length 280, checksum 0xc2c9 dscp CS0 ecn NON_ECN > fragment id 0xa360, flags DONT_FRAGMENT > UDP: 4500 -> 4500 > length 260, checksum 0x209f > 00:00:11:655236: ip4-udp-lookup > UDP: src-port 4500 dst-port 4500 > 00:00:11:655243: ipsec4-tun-input > IPSec: remote:192.168.10.1 spi:0 (0x) sa:218136463 tun:5 seq > 4260287868 sa 1 > 00:00:11:655258: punt-dispatch > reason: [1] ipsec4-spi-o-udp-0 flags: ip4-packet > 00:00:11:655268: ikev2-ip4-natt > ikev2: sw_if_index 5, next index 0 > > Filip > > -- > *From:* vpp-dev@lists.fd.io on behalf of Stanislav > Zaikin > *Sent:* Friday, May 13, 2022 11:17 AM > *To:* Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco) < > fteh...@cisco.com> > *Cc:* vpp-dev ; Benoit Ganne (bganne) < > bga...@cisco.com> > *Subject:* Re: [vpp-dev] ikev2 and nat-t > > Hi Filip, > > In my case an initiator is behind NAT while a responder has a public IP. > What node should check for SPI=0? I also have LCP enabled on some > interfaces, maybe it breaks the default punt behaviour. > > On Fri, 13 May 2022 at 10:54, Filip Tehlar -X (ftehlar - PANTHEON TECH SRO > at Cisco) wrote: > > I'm not entirely sure that's the case - the reason being that default port > 4500 is used for both nat traversal and encrypted dataplane traffic. The > way to distinguish between those two is having SPI=0 in case of NATT. For > this there is punt mechanism in vpp, which forwards 4500 IKE packets to > natt-node. Since this isn't happening judging from your packet trace I > wonder if you maybe have responder behind nat? Such case isn't supported > > Filip > -- > *From:* vpp-dev@lists.fd.io on behalf of Benoit > Ganne (bganne) via lists.fd.io > *Sent:* Friday, May 13, 2022 10:26 AM > *To:* Stanislav Zaikin ; vpp-dev > *Subject:* Re: [vpp-dev] ikev2 and nat-t > > Hmm good catch, I wonder why we did not catch it - maybe the unit tests > use only non-standard port... > Can you try to patch it accordingly and if it solves the issue, push it on > gerrit for review? > If you can update the unit tests to reproduce the issue and verify the fix > fixes it it would be ideal of course. > > Best > Ben > > > -Original Message- > > From: vpp-dev@lists.fd.io On Behalf Of Stanislav > > Zaikin > > Sent: Thursday, May 12, 2022 18:11 > > To: vpp-dev > > Subject: [vpp-dev] ikev2 and nat-t > > > > Hello folks, > > > > I have an issue with ikev2 and the host over the nat. IKE_AUTH packet > goes > > to ikev2-ip4 node instead of ikev2-ip4-natt and it causes > > IKEV2_ERROR_BAD_LENGTH. > > > > > > I'm not an expert in ike, but are there the right nodes specified below? > > > > udp_register_dst_port (vm, IKEV2_PORT, ikev2_node_ip4.index, 1); > > udp_register_dst_port (vm, IKEV2_PORT, ikev2_node_ip6.index, 0); > > udp_register_dst_port (vm, IKEV2_PORT_NATT, ikev2_node_ip4.index, > > 1); > > udp_register_dst_port (vm, IKEV2_PORT_NATT, ikev2_node_ip6.index, > > 0); > > > > Shouldn't it be ikev2_node_ip4_natt instead of ikev2_node_ip4 for > > IKEV2_PORT_NATT? > > > > Errors: > > > > 12 ikev2-ip4 packets processed > > info > > 6 ikev2-ip4 Bad packet length > > error > > 6 ikev2-ip4 IKE EXCHANGE SA requests > > receivedinfo > > > > > > The trace > > 06:19:16:980290: dpdk-input > > GigabitEthernet5/0/0 rx queue 0 > > buffer 0x84923: current data 0, length 290, buffer-pool 0, ref-count 1, > > trace handle 0x1 > > ext-hdr-valid > > PKT MBUF: port 0, nb_segs 1, pkt_len 290 > > buf_len 2176, data_len 290, ol_flags 0x180, data_off 128, phys_addr > > 0x59124940 > > packet_
Re: [vpp-dev] handling L2 and L3 traffic in gtpu plugin
Hi Vijay, You can adopt something similar to what was implemented for vxlan. Like specifying the next-node for the tunnel when creating. On Tue, 24 May 2022 at 07:52, wrote: > Hi, > > I wants to understand, how can i handle L2 and L3 traffic in gtpu plugin > during encap and decap. > Do anyone have any idea? How can this be handled. > > Regards, > Vijay > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21434): https://lists.fd.io/g/vpp-dev/message/21434 Mute This Topic: https://lists.fd.io/mt/91305840/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] nat44 not working under Ubuntu 22.04
Hi Andre,
I think you forgot to enable nat44 feature. `nat44 plugin enable` and
probably `nat44 forwarding enable`
On Thu, 16 Jun 2022 at 22:40, Andre Courchesne
wrote:
> I have this very simple config:
>
> startup.conf
> unix {
> nodaemon
> log /var/log/vpp/vpp.log
> full-coredump
> cli-listen /run/vpp/cli.sock
> gid vpp
> startup-config /etc/vpp/initial_setup.conf
> poll-sleep-usec 100
> }
>
> api-trace {
> on
> }
>
> api-segment {
> gid vpp
> }
>
> socksvr {
> default
> }
>
> cpu {
> }
>
> buffers {
> buffers-per-numa 512000
> default data-size 4096
> }
>
> dpdk {
> dev default {
> num-rx-queues 3
> num-tx-queues 3
> num-rx-desc 512
> num-tx-desc 512
> rss-queues 0,2,5-7
> }
>
> dev :01:00.0 {
> name wanport
> }
> dev :03:00.0 {
> name guestport
> }
> }
>
> plugins {
> plugin default { disable }
> plugin dpdk_plugin.so { enable }
> plugin acl_plugin.so { enable }
> plugin dhcp_plugin.so { enable }
> plugin dns_plugin.so { disable }
> plugin nat_plugin.so { enable }
> plugin nat44_plugin.so { enable }
> plugin cnat_plugin.so { enable }
> plugin ping_plugin.so { enable }
> }
>
> logging {
> default-log-level debug
> default-syslog-log-level debug
> }
>
> initial_setup.conf
> comment { configure wan port 0c:c4:7a:c8:fc:e4 }
> set int mac address wanport 0c:c4:7a:c8:fc:e4
> set dhcp client intfc wanport hostname vpprouter
> set int state wanport up
>
> comment { Add Linux VLAN interfaces }
> create sub-interfaces guestport 1000
>
> comment { Create loop0 -> untag traffic }
> loopback create-interface
> set int l2 bridge loop0 1 bvi
> set int ip address loop0 192.168.2.1/24
> set int state loop0 up
>
> comment { Loop interfaces for VLANs }
> comment { Create loop1 -> VLAN 1000 }
> loopback create-interface
> set int l2 bridge loop1 2 bvi
> set int ip address loop1 172.20.0.0/20
> set int state loop1 up
>
>
> comment { Add untag guest to loop0 }
> set int l2 bridge guestport 1
> set int state guestport up
>
> comment { Add VLAN 1000 guest to loop1 }
> set int l2 bridge guestport.1000 2
> set int l2 tag-rewrite guestport.1000 pop 1
> set int state guestport.1000 up
>
>
> comment { create tap interface for dhcp server and host-stack access
> (untag - loop0 - tap0) }
> create tap id 0 host-if-name eno3 host-ip4-addr 192.168.2.2/24
> host-ip4-gw 192.168.2.1
> set int l2 bridge tap0 1
> set int state tap0 up
>
> comment { tap interfaces for VLANs }
> comment { create tap interface for dhcp server and host-stack access
> (VLAN 1000 - loop1 - tap1) }
> create tap id 1 host-if-name eno3.1000 host-ip4-addr 172.20.0.2/20
> host-ip4-gw 172.20.0.1
> set int l2 bridge tap1 2
> set int state tap1 up
>
> comment { configure nat }
> nat44 add interface address wanport
> set interface nat44 in loop1 out wanport
>
> comment { Route ssh (TCP 22) to the untag Linux interface }
> nat44 add static mapping local 192.168.2.2 22 external wanport 22 tcp
>
>
> When starting vpp manually I get an error on NAT44:
>
> guestport.1000
> loop0
> loop1
> tap0
> tap1
> nat44 add interface address: add wanport address failed
>
>
> This same config works on CentOS with vpp 20.09 but failt with v22.06-rc1
>
> wanport did get an IP via DHCP.
>
> Any clues ?
>
> Andre Courchesne - Consultant
> http://net-forces.blogspot.ca <http://www.net-forces.com/>
> https://www.co2.click
> Twitter: @IndianaTux
> LinkedIn: http://www.linkedin.com/pub/andr%C3%A9-courchesne/0/b0b/688
>
> L'information contenue dans le présent document est la propriété de Andre
> Courchesne. Et est divulguée en toute confidentialité. Cette information ne
> doit pas être utilisée, divulguée à d'autres personnes ou reproduite sans
> le consentement écrit explicite de Andre Courchesne.
>
> The information contained in this document is confidential and property of
> Andre Courchesne. It shall not be used, disclosed to others or reproduced
> without the express written consent of Andre Courchesne.
>
>
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21548): https://lists.fd.io/g/vpp-dev/message/21548
Mute This Topic: https://lists.fd.io/mt/91808820/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vpp api versioning
Hello folks, According to [0] it should be possible to add breaking changes to vpp api with incrementing the major version of the api. There's one issue in the LCP api - a C++ keyword "namespace" is used there and I want to change it to "netns" and increase a major version. But make checkstyle-api still fails. Any ideas? Of course, I can add new methods _v2 and deprecate the older ones. But it'd lead to code duplication and still I'd need to wait at least 2 releases. [0] https://wiki.fd.io/view/VPP/API_Versioning -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21662): https://lists.fd.io/g/vpp-dev/message/21662 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hi Andrew, Thanks for the explanation. I'll try to reach maintainers of the lcp plugin and convince them :) Yes, I'm working on an agent for managing vpp through binary api and it's written in C++ - so it breaks the compilation. I have a patch in my local repo for that, but now I'm trying to merge all my patches upstream. On Fri, 15 Jul 2022 at 11:14, Andrew Yourtchenko wrote: > Hi Stanislav, > > The api is marked as “Production” so the behavior of checkstyle is there > to protect the users (as for the duplication - it is a choice to do it once > in VPP or in each and every downstream consumer). As for the pure code > exercise - I just did it for the sake of a test, took a grand total of 15 > minutes to add the new message versions. Hardly a massive deal. (We could > probably improve tooling on the lifecycle management of these, though) > > That said - for this specific case - is the presence of the “namespace” > member in a structure within the api a showstopper for you - that is, does > it cause a compilation failure of some sort ? If so - one option is to > mark the APIs as experimental and then change it in-place. It is up to > component owners to decide the policy. > > --a > > On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: > > > Hello folks, > > According to [0] it should be possible to add breaking changes to vpp api > with incrementing the major version of the api. There's one issue in the > LCP api - a C++ keyword "namespace" is used there and I want to change it > to "netns" and increase a major version. But make checkstyle-api still > fails. Any ideas? > > Of course, I can add new methods _v2 and deprecate the older ones. But > it'd lead to code duplication and still I'd need to wait at least 2 > releases. > > [0] https://wiki.fd.io/view/VPP/API_Versioning > > -- > Best regards > Stanislav Zaikin > > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21666): https://lists.fd.io/g/vpp-dev/message/21666 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hi Pim, There's also lcp_default_ns_get broken. I fixed that locally and want to send the patch. Can take a look at lcp_itf_pair_add_del_v2 as well. On Fri, 15 Jul 2022 at 12:57, Pim van Pelt wrote: > Hoi, > > Currently, linux-cp API doesn't seem to work, at least in Python and GoVPP > (see previous threads on this mailinglist with bugreports), > lcp_itf_pair_add_del_v2() eventually succeeds but throws an error to the > caller. This snippet: > > r = vpp.api.create_loopback() > > print(r) > > > host_if_name = "loop%d" % r.sw_if_index > > t=0 ## LCP_API_ITF_HOST_TAP > > n="dataplane" > > r = vpp.api.lcp_itf_pair_add_del_v2(is_add=True, > sw_if_index=r.sw_if_index, host_if_name=host_if_name, host_if_type=t, > namespace=n) > > print(r) > > Shows as log, the following: > > create_loopback_reply(_0=758, context=3, retval=0, sw_if_index=10) > ### hangs for a few seconds ... > Traceback (most recent call last): > File "./v3.py", line 35, in > r = vpp.api.lcp_itf_pair_add_del_v2(is_add=True, > sw_if_index=r.sw_if_index, host_if_name=host_if_name, host_if_type=t, > namespace=n) > File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 121, in > __call__ > return self._func(**kwargs) > File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 495, in > f > return self._call_vpp(i, msg, multipart, **kwargs) > File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 757, in > _call_vpp > raise VPPIOError(2, 'VPP API client: read failed') > vpp_papi.vpp_papi.VPPIOError: [Errno 2] VPP API client: read failed > > Even though the LCP was created: > > DBGvpp# show lcp > > lcp default netns dataplane > > lcp lcp-auto-subint off > > lcp lcp-sync on > > itf-pair: [0] GigabitEthernet3/0/0 tap1 e0 29 type tap netns dataplane > > itf-pair: [1] GigabitEthernet3/0/0.101 tap1.101 servers 33 type tap netns > dataplane > > itf-pair: [2] GigabitEthernet3/0/0.179 tap1.179 ixp 32 type tap netns > dataplane > > itf-pair: [3] loop0 tap6 loop10 34 type tap netns dataplane > > Matt may have more insights (and Ole at some point tried to help me fix > it, also), but if the API is actually busted, I am personally comfortable > changing it in-place from s/namespace/netns/ rather than adding a _v3; but > that's just one user's opinion. I would defer to +Matthew Smith > as the maintainer of the plugin. > > groet, > Pim > > On Fri, Jul 15, 2022 at 11:14 AM Andrew Yourtchenko > wrote: > >> Hi Stanislav, >> >> The api is marked as “Production” so the behavior of checkstyle is there >> to protect the users (as for the duplication - it is a choice to do it once >> in VPP or in each and every downstream consumer). As for the pure code >> exercise - I just did it for the sake of a test, took a grand total of 15 >> minutes to add the new message versions. Hardly a massive deal. (We could >> probably improve tooling on the lifecycle management of these, though) >> >> That said - for this specific case - is the presence of the “namespace” >> member in a structure within the api a showstopper for you - that is, does >> it cause a compilation failure of some sort ? If so - one option is to >> mark the APIs as experimental and then change it in-place. It is up to >> component owners to decide the policy. >> >> --a >> >> On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: >> >> >> Hello folks, >> >> According to [0] it should be possible to add breaking changes to vpp api >> with incrementing the major version of the api. There's one issue in the >> LCP api - a C++ keyword "namespace" is used there and I want to change it >> to "netns" and increase a major version. But make checkstyle-api still >> fails. Any ideas? >> >> Of course, I can add new methods _v2 and deprecate the older ones. But >> it'd lead to code duplication and still I'd need to wait at least 2 >> releases. >> >> [0] https://wiki.fd.io/view/VPP/API_Versioning >> >> -- >> Best regards >> Stanislav Zaikin >> >> >> >> >> >> >> > > -- > Pim van Pelt > PBVP1-RIPE - http://www.ipng.nl/ > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21667): https://lists.fd.io/g/vpp-dev/message/21667 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hello folks, I've just sent 3 patches addressing issues in LCP [0] [1] [2]. First one for marking APIs in progress. 2nd only for s/namespace/netns/g. 3rd fixes endian issues in different methods. One thing I can't understand - if the "autoendian" keyword is specified for API type - I should use macros end with _END, right? It worked for lcp_itf_pair_add_del_v2 and lcp_default_ns_get, but for some reason it doesn't work for lcp_itf_pair_details (though the type is also marked with "autoendian"). Any inputs here much appreciated. Thanks guys [0] - https://gerrit.fd.io/r/c/vpp/+/36708 [1] - https://gerrit.fd.io/r/c/vpp/+/36709 [2] - https://gerrit.fd.io/r/c/vpp/+/36710 On Fri, 15 Jul 2022 at 17:41, Matthew Smith via lists.fd.io wrote: > Hi Andrew, > > Neale and I are the maintainers of linux-cp. I am ok with changing it in > place because the use of "namespace" is preventing Stanislav from even > being able to compile his code. > > When you say "mark the APIs as experimental" are you talking about putting > "state: experimental" in the FEATURE.yaml file or something else? If you're > talking about FEATURE.yaml, the file at src/plugins/linux-cp/FEATURE.yaml > already lists the state as experimental. Maybe the formatting of the file > is bad? > > Thanks, > -Matt > > > On Fri, Jul 15, 2022 at 4:14 AM Andrew Yourtchenko > wrote: > >> Hi Stanislav, >> >> The api is marked as “Production” so the behavior of checkstyle is there >> to protect the users (as for the duplication - it is a choice to do it once >> in VPP or in each and every downstream consumer). As for the pure code >> exercise - I just did it for the sake of a test, took a grand total of 15 >> minutes to add the new message versions. Hardly a massive deal. (We could >> probably improve tooling on the lifecycle management of these, though) >> >> That said - for this specific case - is the presence of the “namespace” >> member in a structure within the api a showstopper for you - that is, does >> it cause a compilation failure of some sort ? If so - one option is to >> mark the APIs as experimental and then change it in-place. It is up to >> component owners to decide the policy. >> >> --a >> >> On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: >> >> >> Hello folks, >> >> According to [0] it should be possible to add breaking changes to vpp api >> with incrementing the major version of the api. There's one issue in the >> LCP api - a C++ keyword "namespace" is used there and I want to change it >> to "netns" and increase a major version. But make checkstyle-api still >> fails. Any ideas? >> >> Of course, I can add new methods _v2 and deprecate the older ones. But >> it'd lead to code duplication and still I'd need to wait at least 2 >> releases. >> >> [0] https://wiki.fd.io/view/VPP/API_Versioning >> >> -- >> Best regards >> Stanislav Zaikin >> >> >> >> >> >> >> > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21685): https://lists.fd.io/g/vpp-dev/message/21685 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Bridge-domain function and usage.
Hi Pragya, Could you attach a trace? On Fri, 22 Jul 2022 at 13:14, Pragya Nand Bhagat < pragya.nand.bhaga...@gmail.com> wrote: > Hi All, > > Please have a look on the below issue: > I have attached my conf file. > > Or is the bridge-domain functionality broken . > > Thanks > Pragya Nand > > On Wed, Jul 20, 2022 at 9:57 AM Pragya Nand Bhagat via lists.fd.io > wrote: > >> Hi All, >> >> I'm trying to create a bridge domain and add ports to it for layer 2 >> functionality. >> There are 3 physical ports. >> I have used the following commands : >> >> create bridge-domain 100 >> set interface l2 bridge port0/0 100 >> set interface l2 bridge port0/1 100 >> set interface l2 bridge port0/2 100 >> >> set bridge-domain flood 100 disable >> >> vpp# show bridge-domain >> BD-ID Index BSN Age(min) Learning U-Forwrd UU-Flood Flooding >> ARP-Term arp-ufwd Learn-co Learn-li BVI-Intf >>100 1 0 off onon >> flood offoffoff 1 >> 16777216 N/A >> >> I have the expectation if I disable flooding on the bridge domain and as >> UU-Flood is enabled it'll still flood on all the ports part of bridge >> domain. >> >> Above is not happening . >> >> Also when I try to add mac in l2fib on port using : >> >> l2fib add 52:54:00:53:18:55 200 port0/0 static >> >> vpp should unicast the packet which is also not happening . >> >> I'm using vpp version 22.06 . >> >> Please suggest how to achieve this or if I missed something . >> >> Thank You >> Pragya Nand >> >> >> >> >> >> >> >> > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21707): https://lists.fd.io/g/vpp-dev/message/21707 Mute This Topic: https://lists.fd.io/mt/92498639/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] benchmark for a patch
Hello folks, Is it possible to trigger a benchmark (csit, only 1 test case) for a specific patch which is not merged? -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21842): https://lists.fd.io/g/vpp-dev/message/21842 Mute This Topic: https://lists.fd.io/mt/93397909/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] libnl as external dependency?
Hello folks, I have a patch to download, build and link statically libnl3 for linux-cp netlink plugin (as part of vpp-ext-deps and aligned with other packages in build/external/packages/). Would it be useful for the rest of the community? For instance, not to be dependent on the libnl version in the host or to be able to apply custom patches for libnl. -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22009): https://lists.fd.io/g/vpp-dev/message/22009 Mute This Topic: https://lists.fd.io/mt/94282694/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] libnl as external dependency?
Hi Pim, Not any problems at all. Until you start to play with vxlan interfaces, bridge af and so on :) I'm living on a bleeding edge with some custom patches to libnl (planning to upstream them as well). So, for my case I need to link statically libnl to the plugin (not to depend on the host version of libnl). But since it's quite questionable to merge something similar to upstream - I'm asking the community if it can be useful for smb also. On Wed, 12 Oct 2022 at 20:10, Pim van Pelt wrote: > Hoi Stanislav, > > What's the issue with using libnl3-dev from Ubuntu/Debian? Are you > imagining adding patches from libnl (I'd love to learn more, if you do :-). > > groet, > Pim > > On Wed, Oct 12, 2022 at 4:58 PM Stanislav Zaikin > wrote: > >> Hello folks, >> >> I have a patch to download, build and link statically libnl3 for linux-cp >> netlink plugin (as part of vpp-ext-deps and aligned with other packages in >> build/external/packages/). >> >> Would it be useful for the rest of the community? For instance, not to be >> dependent on the libnl version in the host or to be able to apply custom >> patches for libnl. >> >> -- >> Best regards >> Stanislav Zaikin >> >> >> >> > > -- > Pim van Pelt > PBVP1-RIPE - http://www.ipng.nl/ > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22015): https://lists.fd.io/g/vpp-dev/message/22015 Mute This Topic: https://lists.fd.io/mt/94282694/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] assertion for going before the headroom
Hello folks,
I've updated to 22.10 and an assertion failed. Looks like I went more than
8 bytes before the headroom (although the packet looks fine). Since it's
quite hard to tell who's the bad guy, shouldn't we have the following
assertion in vlib_buffer_advance also?
ASSERT ((signed) b->current_data >= (signed) -VLIB_BUFFER_PRE_DATA_SIZE);
Also, any thoughts on this backtrace will be appreciated.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7fda89ae4859 in __GI_abort () at abort.c:79
#2 0x00407397 in os_exit (code=1) at
/home/runner/work/vpp/vpp/src/vpp/vnet/main.c:440
#3 0x7fda89ffcd17 in unix_signal_handler (signum=6, si=0x7fda3fba34b0,
uc=0x7fda3fba3380) at /home/runner/work/vpp/vpp/src/vlib/unix/main.c:188
#4
#5 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#6 0x7fda89ae4859 in __GI_abort () at abort.c:79
#7 0x00407333 in os_panic () at
/home/runner/work/vpp/vpp/src/vpp/vnet/main.c:416
#8 0x7fda89e34059 in debugger () at
/home/runner/work/vpp/vpp/src/vppinfra/error.c:84
#9 0x7fda89e33e1a in _clib_error (how_to_die=2, function_name=0x0,
line_number=0, fmt=0x7fda8ad6f208 "%s:%d (%s) assertion `%s' fails") at
/home/runner/work/vpp/vpp/src/vppinfra/error.c:143
#10 0x7fda8a1ca2cd in vlib_buffer_get_current (b=0x100236d100) at
/home/runner/work/vpp/vpp/src/vlib/buffer.h:260
#11 0x7fda8a1c9a79 in vnet_update_l2_len (b=0x100236d100) at
/home/runner/work/vpp/vpp/src/vnet/l2/l2_input.h:300
#12 0x7fda8a1c63e7 in simulated_ethernet_interface_tx
(vm=0x7fda4e304440, node=0x7fda503d5700, frame=0x7fda5029ecc0) at
/home/runner/work/vpp/vpp/src/vnet/ethernet/interface.c:712
#13 0x7fda89f9c19d in dispatch_node (vm=0x7fda4e304440,
node=0x7fda503d5700, type=VLIB_NODE_TYPE_INTERNAL,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fda5029ecc0,
last_time_stamp=55481133387672310) at
/home/runner/work/vpp/vpp/src/vlib/main.c:960
#14 0x7fda89f9cc40 in dispatch_pending_node (vm=0x7fda4e304440,
pending_frame_index=5, last_time_stamp=55481133387672310) at
/home/runner/work/vpp/vpp/src/vlib/main.c:1119
#15 0x7fda89f97eaf in vlib_main_or_worker_loop (vm=0x7fda4e304440,
is_main=0) at /home/runner/work/vpp/vpp/src/vlib/main.c:1588
#16 0x7fda89f975d7 in vlib_worker_loop (vm=0x7fda4e304440) at
/home/runner/work/vpp/vpp/src/vlib/main.c:1722
#17 0x7fda89fd7044 in vlib_worker_thread_fn (arg=0x7fda4a27a000) at
/home/runner/work/vpp/vpp/src/vlib/threads.c:1598
#18 0x7fda89fd2005 in vlib_worker_thread_bootstrap_fn
(arg=0x7fda4a27a000) at /home/runner/work/vpp/vpp/src/vlib/threads.c:418
#19 0x7fda89eee609 in start_thread (arg=) at
pthread_create.c:477
#20 0x7fda89be1163 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) f 11
#11 0x7fda8a1c9a79 in vnet_update_l2_len (b=0x100236d100) at
/home/runner/work/vpp/vpp/src/vnet/l2/l2_input.h:300
300 /home/runner/work/vpp/vpp/src/vnet/l2/l2_input.h: No such file or
directory.
(gdb) p b
$33 = (vlib_buffer_t *) 0x100236d100
(gdb) p *b
$34 = {{cacheline0 = 0x100236d100 "x\377", ,
current_data = -136, current_length = 198, flags = 1572864, flow_id = 0,
ref_count = 1 '\001', buffer_pool_index = 0 '\000', error = 2293,
next_buffer = 0, {current_config_index = 0, punt_reason = 0},
opaque = {6, 4294967294, 917504, 0, 181, 5, 1600038282, 0, 14, 2},
template_end = 0x100236d140 "", second_half = 0x100236d140 "", trace_handle
= 0, total_length_not_including_first_buffer = 0, opaque2 = {0, 0, 0, 0, 0,
0, 0, 2366162944, 61927, 0, 0, 1744896000, 2917007366,
646508478}, headroom = 0x100236d180 "\277f\026\261\b",
pre_data = ...,
data = 0x100236d200 ...
(gdb) p (b->data + b->current_data)
$35 = (u8 *) 0x100236d178 "\006"
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22088): https://lists.fd.io/g/vpp-dev/message/22088
Mute This Topic: https://lists.fd.io/mt/94622622/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] crash in vlib_get_next_frame_internal
Hello folks, I've got a crash on v22.10 vnet[2391390]: received signal SIGSEGV, PC 0x7f4847feb994, faulting address 0x0 vnet[2391390]: #0 0x7f484805e85b 0x7f484805e85b vnet[2391390]: #1 0x7f4847f753c0 0x7f4847f753c0 vnet[2391390]: #2 0x7f4847feb994 vlib_get_next_frame_internal + 0x64 vnet[2391390]: #3 0x7f484814e729 vlib_buffer_enqueue_to_next_fn_hsw + 0x3289 vnet[2391390]: #4 0x7f4848dcbf2e ip4_rewrite_node_fn_hsw + 0x28ae vnet[2391390]: #5 0x7f4847fee6fb vlib_worker_loop + 0x1b3b vnet[2391390]: #6 0x7f4848040afa vlib_worker_thread_fn + 0xaa vnet[2391390]: #7 0x7f484803ae01 vlib_worker_thread_bootstrap_fn + 0x51 vnet[2391390]: #8 0x7f4847f69609 start_thread + 0xd9 vnet[2391390]: #9 0x7f4847ca7163 clone + 0x43 (gdb) info line *0x7f4847feb994 Line 371 of "/home/runner/work/vpp/vpp/src/vlib/main.c" starts at address 0x7f4847feb994 and ends at 0x7f4847feb998 . And the code for this line is following: n_used = f->n_vectors; Which means that vlib_node_runtime_get_next_frame allocated vlib_next_frame with NULL in the frame field. I wonder how I can debug it further since vpp caught a segfault signal and in the core file I've got a completely different stacktrace. Is there a way to find exactly this vlib_next_frame structure? Any ideas are much appreciated. -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22277): https://lists.fd.io/g/vpp-dev/message/22277 Mute This Topic: https://lists.fd.io/mt/95465711/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] crash in vlib_get_next_frame_internal
Keeping you updated :)
So, having the following piece of code in src/vlib/main.c,
/* ??? Don't need valid flag: can use frame_index == ~0 */
if (PREDICT_FALSE (!(*nf->flags & VLIB_FRAME_IS_ALLOCATED*)))
{
nf->frame = vlib_frame_alloc (vm, node, next_index);
nf->flags |= VLIB_FRAME_IS_ALLOCATED;
}
f = nf->frame;
...
n_used = *f->n_vectors*; // line 371 where null dereferencing took place
I assume that I got a vlib_next_frame with flags VLIB_FRAME_IS_ALLOCATED
but without a frame inside.
The only place which does that thing was introduced by
9f5b36926b74109974e7c3ce9bb3a0a7d676c46c (which is a good job btw), so I
think we should clear that flag as it done in other places.
I prepared a fix[0], please have a look.
[0] - https://gerrit.fd.io/r/c/vpp/+/37749
On Mon, 5 Dec 2022 at 10:53, Stanislav Zaikin wrote:
> Hello folks,
>
> I've got a crash on v22.10
> vnet[2391390]: received signal SIGSEGV, PC 0x7f4847feb994, faulting
> address 0x0
> vnet[2391390]: #0 0x7f484805e85b 0x7f484805e85b
> vnet[2391390]: #1 0x7f4847f753c0 0x7f4847f753c0
> vnet[2391390]: #2 0x7f4847feb994 vlib_get_next_frame_internal + 0x64
> vnet[2391390]: #3 0x7f484814e729 vlib_buffer_enqueue_to_next_fn_hsw +
> 0x3289
> vnet[2391390]: #4 0x7f4848dcbf2e ip4_rewrite_node_fn_hsw + 0x28ae
> vnet[2391390]: #5 0x7f4847fee6fb vlib_worker_loop + 0x1b3b
> vnet[2391390]: #6 0x7f4848040afa vlib_worker_thread_fn + 0xaa
> vnet[2391390]: #7 0x7f484803ae01 vlib_worker_thread_bootstrap_fn +
> 0x51
> vnet[2391390]: #8 0x7f4847f69609 start_thread + 0xd9
> vnet[2391390]: #9 0x7f4847ca7163 clone + 0x43
>
> (gdb) info line *0x7f4847feb994
> Line 371 of "/home/runner/work/vpp/vpp/src/vlib/main.c" starts at address
> 0x7f4847feb994 and ends at
> 0x7f4847feb998 .
>
> And the code for this line is following:
> n_used = f->n_vectors;
>
> Which means that vlib_node_runtime_get_next_frame allocated
> vlib_next_frame with NULL in the frame field.
>
> I wonder how I can debug it further since vpp caught a segfault signal and
> in the core file I've got a completely different stacktrace. Is there a
> way to find exactly this vlib_next_frame structure? Any ideas are much
> appreciated.
>
> --
> Best regards
> Stanislav Zaikin
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22285): https://lists.fd.io/g/vpp-dev/message/22285
Mute This Topic: https://lists.fd.io/mt/95465711/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] arm64 / clearfog + VPP
The platform looks interesting indeed, guys, please share if it's possible to use ipsec offloading on it. On Mon, 5 Dec 2022 at 21:59, Xiaodong Xu wrote: > There is a guide to run VPP on dpaa2 board from NXP at > https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/GUID-EBA9A5C6-2407-4AC7-87B6-C1470B2CD92D.html > It > requires a few scripts as well as some driver tools (restool, etc.) not > sure they had any specific changes to VPP for this purpose. It is unclear > what the startup.conf looks like to run VPP either. > > If anyone had any successful experience to bring up VPP on a dpaa2 > platform, please share with us and it would be much appreciated. > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22286): https://lists.fd.io/g/vpp-dev/message/22286 Mute This Topic: https://lists.fd.io/mt/94234426/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] crash in vlib_get_next_frame_internal
It was pointed out by Dmitry that my fix doesn't make much sense. Any other ideas much appreciated. On Mon, 5 Dec 2022 at 10:53, Stanislav Zaikin via lists.fd.io wrote: > Hello folks, > > I've got a crash on v22.10 > vnet[2391390]: received signal SIGSEGV, PC 0x7f4847feb994, faulting > address 0x0 > vnet[2391390]: #0 0x7f484805e85b 0x7f484805e85b > vnet[2391390]: #1 0x7f4847f753c0 0x7f4847f753c0 > vnet[2391390]: #2 0x7f4847feb994 vlib_get_next_frame_internal + 0x64 > vnet[2391390]: #3 0x7f484814e729 vlib_buffer_enqueue_to_next_fn_hsw + > 0x3289 > vnet[2391390]: #4 0x7f4848dcbf2e ip4_rewrite_node_fn_hsw + 0x28ae > vnet[2391390]: #5 0x7f4847fee6fb vlib_worker_loop + 0x1b3b > vnet[2391390]: #6 0x7f4848040afa vlib_worker_thread_fn + 0xaa > vnet[2391390]: #7 0x7f484803ae01 vlib_worker_thread_bootstrap_fn + > 0x51 > vnet[2391390]: #8 0x7f4847f69609 start_thread + 0xd9 > vnet[2391390]: #9 0x7f4847ca7163 clone + 0x43 > > (gdb) info line *0x7f4847feb994 > Line 371 of "/home/runner/work/vpp/vpp/src/vlib/main.c" starts at address > 0x7f4847feb994 and ends at > 0x7f4847feb998 . > > And the code for this line is following: > n_used = f->n_vectors; > > Which means that vlib_node_runtime_get_next_frame allocated > vlib_next_frame with NULL in the frame field. > > I wonder how I can debug it further since vpp caught a segfault signal and > in the core file I've got a completely different stacktrace. Is there a > way to find exactly this vlib_next_frame structure? Any ideas are much > appreciated. > > -- > Best regards > Stanislav Zaikin > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22294): https://lists.fd.io/g/vpp-dev/message/22294 Mute This Topic: https://lists.fd.io/mt/95465711/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP LCP: IS-IS does not work
Hello folks,
In old router plugin it was done with the following snippet:
```
#include
...
osi_register_input_protocol (OSI_PROTOCOL_isis, im->tx_node_index);
```
So, I'd give it a try to register this protocol for `lip_punt_node`
(`lcp_router_init` seems quite suitable). Something like this:
diff --git a/src/plugins/linux-cp/lcp.h b/src/plugins/linux-cp/lcp.h
index 4ddaa3898..51f6b1b3e 100644
--- a/src/plugins/linux-cp/lcp.h
+++ b/src/plugins/linux-cp/lcp.h
@@ -52,6 +52,8 @@ u8 lcp_get_del_static_on_link_down (void);
void lcp_set_del_dynamic_on_link_down (u8 is_del);
u8 lcp_get_del_dynamic_on_link_down (void);
+extern vlib_node_registration_t lip_punt_node;
+
#endif
/*
diff --git a/src/plugins/linux-cp/lcp_router.c
b/src/plugins/linux-cp/lcp_router.c
index 3534b597e..1f2c126d9 100644
--- a/src/plugins/linux-cp/lcp_router.c
+++ b/src/plugins/linux-cp/lcp_router.c
@@ -37,6 +37,7 @@
#include
#include "lcp_nl_evpn.h"
+#include "vnet/osi/osi.h"
typedef struct lcp_router_table_t_
{
@@ -1416,6 +1417,8 @@ lcp_router_init (vlib_main_t *vm)
lcp_rt_fib_src_dynamic = fib_source_allocate (
"lcp-rt-dynamic", FIB_SOURCE_PRIORITY_HI + 1, FIB_SOURCE_BH_API);
+ osi_register_input_protocol( OSI_PROTOCOL_isis, lip_punt_node.index);
+
return (NULL);
}
It compiles, but I haven't checked anything since I'm too lazy to configure
ISIS.
On Mon, 23 Jan 2023 at 18:14, Pim van Pelt via lists.fd.io wrote:
> Hoi,
>
> I would suggest not matching (only) MAC but (foremost) the ethertype, and
> then punting those packets into the TAP, take a look at VLIB_REGISTER_NODE
> (lip_punt_node) in src/plugins/linux-cp/lcp_node.c, contributions are
> welcome.
>
> groet,
> Pim
>
> On Mon, Jan 23, 2023 at 6:06 PM wrote:
>
>> Hoi Pim,
>>
>> As for distinguishing IS-IS packets, I think that should not be really
>> difficult, it's just all the packets with specific DST MACs:
>> 09:00:2b:00:00:05, 09:00:2b:00:00:14,09:00:2b:00:00:15.
>> It's hard to imagine situation when they are needed to be processed by
>> DataPlane.
>>
>>
>>
>
> --
> Pim van Pelt
> PBVP1-RIPE - http://www.ipng.nl/
>
>
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22494): https://lists.fd.io/g/vpp-dev/message/22494
Mute This Topic: https://lists.fd.io/mt/96476162/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] help with review
Hello folks,
Any help with review is much appreciated. Both patches are waiting for
quite a long time.
- https://gerrit.fd.io/r/c/vpp/+/36721
Short description: "autoendian" was broken for streaming message types like:
service {
rpc lcp_itf_pair_get returns lcp_itf_pair_get_reply
*stream lcp_itf_pair_details*;
};
vppapigen_c.py isn't generating boilerplate (endian handler, json handler,
format handler, erc) for such types (both for vpp side and for vapi).
There's currently also no support for streaming services in VAPI/C++, I
have a patch for that, I will send it after this one will be merged (if it
will be merged in the end).
- https://gerrit.fd.io/r/c/vpp/+/36110
Short description: there is a fast path in "ethernet-input" for whole
frames with ETH_INPUT_FRAME_F_SINGLE_SW_IF_IDX flag. The rest input nodes
have this snippet to allocate a frame per interface when receiving the
packets (at least in dpdk-input and memif-input). I thought it'd be useful
to have this fast path for tap interfaces. Theoretically it can be even
measured with csit but I didn't succeed at that :)
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22496): https://lists.fd.io/g/vpp-dev/message/22496
Mute This Topic: https://lists.fd.io/mt/96493146/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP LCP: IS-IS does not work
That's not surprising, could you also show me a trace? (trace add dpdk-input 10 and then show trace with ISIS packet) On Tue, 24 Jan 2023 at 16:25, wrote: > Hi Stanislav, > > Unfortunately, your patch didn't help. VPP builds, but IS-IS packets still > cannot be passed between the CP and the wire. > > Furthermore, it looks like LCP lcp-auto-subint feature was broken: > > root@tn3:/home/abramov/vpp# vppctl > _____ _ ___ > __/ __/ _ \ (_)__| | / / _ \/ _ \ > _/ _// // / / / _ \ | |/ / ___/ ___/ > /_/ /(_)_/\___/ |___/_/ /_/ > > vpp# > vpp# > vpp# > vpp# show interface > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > TenGigabitEthernet1c/0/1 1 down 9000/0/0/0 > local00 down 0/0/0/0 > vpp# set interface state TenGigabitEthernet1c/0/1 up > vpp# lcp create 1 host-if Ten0 > vpp# show interface > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > TenGigabitEthernet1c/0/1 1 up 9000/0/0/0 rx > packets 2451 > rx > bytes 228627 > tx > packets 7 > tx > bytes 746 > > drops 2451 > > ip49 > > ip62 > local00 down 0/0/0/0 > tap1 2 up 9000/0/0/0 rx > packets 7 > rx > bytes 746 > > ip67 > vpp# quit > root@tn3:/home/abramov/vpp# ip link set Ten0 up > root@tn3:/home/abramov/vpp# vppctl > _____ _ ___ > __/ __/ _ \ (_)__| | / / _ \/ _ \ > _/ _// // / / / _ \ | |/ / ___/ ___/ > /_/ /(_)_/\___/ |___/_/ /_/ > > vpp# lcp lcp > lcp-auto-subint lcp-sync > vpp# lcp lcp-auto-subint on > vpp# lcp lcp-sync on > vpp# show lcp > lcp default netns '' > lcp lcp-auto-subint on > lcp lcp-sync on > lcp del-static-on-link-down off > lcp del-dynamic-on-link-down off > itf-pair: [0] TenGigabitEthernet1c/0/1 tap1 Ten0 1248 type tap > vpp# quit > root@tn3:/home/abramov/vpp# ip link add Ten0.1914 link Ten0 type vlan id > 1914 > root@tn3:/home/abramov/vpp# ip link set Ten0.1914 up > root@tn3:/home/abramov/vpp# vppctl > _____ _ ___ > __/ __/ _ \ (_)__| | / / _ \/ _ \ > _/ _// // / / / _ \ | |/ / ___/ ___/ > /_/ /(_)_/\___/ |___/_/ /_/ > > vpp# show int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > TenGigabitEthernet1c/0/1 1 up 9000/0/0/0 rx > packets 16501 > rx > bytes 1519839 > tx > packets 7 > tx > bytes 746 > > drops 16501 > > ip4 39 > > ip68 > local00 down 0/0/0/0 > tap1 2 up 9000/0/0/0 rx > packets17 > rx > bytes 19710 > > drops 10 > > ip67 > > > vpp# show node counters >Count Node > Reason Severity > 10 lldp-inputlldp packets received on > disabled i error >516 dpdk-input no > errorerror > 21arp-disabled ARP > Disabled error > 74 osi-input unknown osi > protocol error > 5 snap-input unknown oui/snap > protocolerror > 11 ethernet-input unknown ethernet > type error > 74127 ethernet-input unknown > vlan error >145 ethernet-input
Re: [vpp-dev] VPP LCP: IS-IS does not work
Could you check again with the following patch? The previous didn't work
because the linker couldn't find a symbol with the node (apparently, linux
cp plugin divided into 2 parts: a library and a plugin).
I replayed a pcap containing some OSI frames and got this trace:
00:00:18:025096: virtio-input
virtio: hw_if_index 1 next-index 4 vring 0 len 1514
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0
csum_offset 0 num_buffers 1
00:00:18:025161: ethernet-input
frame: flags 0x1, hw-if-index 1, sw-if-index 1
0x05dc: c2:03:29:a9:00:00 -> 01:80:c2:00:00:15
00:00:18:025187: llc-input
LLC osi_layer5 -> osi_layer5
00:00:18:025198: *osi-input*
OSI isis
00:00:18:025214: *linux-cp-punt*
lip-punt: 1 -> 2
00:00:18:025236: tap1-output
tap1 flags 0x00180005
0x05dc: c2:03:29:a9:00:00 -> 01:80:c2:00:00:15
00:00:18:025255: tap1-tx
buffer 0x9f947: current data 0, length 1514, buffer-pool 0, ref-count
1, trace handle 0x1
l2-hdr-offset 0 l3-hdr-offset 14
hdr-sz 0 l2-hdr-offset 0 l3-hdr-offset 14 l4-hdr-offset 0 l4-hdr-sz 0
0x05dc: c2:03:29:a9:00:00 -> 01:80:c2:00:00:15
diff --git a/src/plugins/linux-cp/lcp_interface.c
b/src/plugins/linux-cp/lcp_interface.c
index eef06ecfa..81ec6f9ec 100644
--- a/src/plugins/linux-cp/lcp_interface.c
+++ b/src/plugins/linux-cp/lcp_interface.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
vlib_log_class_t lcp_itf_pair_logger;
@@ -1206,6 +1207,10 @@ lcp_interface_init (vlib_main_t *vm)
lcp_itf_pair_logger = vlib_log_register_class ("linux-cp", "itf");
+ vlib_node_t *lip_punt_node = vlib_get_node_by_name (vm, (u8 *)
"linux-cp-punt");
+ if (lip_punt_node)
+osi_register_input_protocol (OSI_PROTOCOL_isis, lip_punt_node->index);
+
return NULL;
}
On Wed, 25 Jan 2023 at 16:11, wrote:
> Hi Stanislav!
>
> Here is it!
>
> 00:31:48:504910: dpdk-input
> TenGigabitEthernet1c/0/1 rx queue 0
> buffer 0x9ad69: current data 0, length 1518, buffer-pool 0, ref-count 1,
> trace handle 0xb
> ext-hdr-valid
> PKT MBUF: port 0, nb_segs 1, pkt_len 1518
> buf_len 2176, data_len 1518, ol_flags 0x180, data_off 128, phys_addr
> 0x188b5ac0
> packet_type 0x1 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_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt.
> PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt.
> Packet Types
> RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
> 0x05dc: 3c:ec:ef:5f:78:7a -> 09:00:2b:00:00:05 802.1q vlan 1914
> 00:31:48:504913: ethernet-input
> frame: flags 0x3, hw-if-index 1, sw-if-index 1
> 0x05dc: 3c:ec:ef:5f:78:7a -> 09:00:2b:00:00:05 802.1q vlan 1914
> 00:31:48:504917: llc-input
> LLC osi_layer5 -> osi_layer5
> 00:31:48:504918: osi-input
> OSI isis
> 00:31:48:504919: error-drop
> rx:TenGigabitEthernet1c/0/1.1914
> 00:31:48:504920: drop
> osi-input: unknown osi protocol
>
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22510): https://lists.fd.io/g/vpp-dev/message/22510
Mute This Topic: https://lists.fd.io/mt/96476162/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP LCP: IS-IS does not work
I really hoped that there's a better and shorter solution, but I couldn't
find it.
You can try with this ugly patch with a (lot of) copy-paste from
lip_punt_node :)
On Thu, 26 Jan 2023 at 14:14, wrote:
> Hi Stanislav,
>
> Situation is better now, but still only half of the problem solved :-)
> OSI IS-IS packets passed from network to tap, but not passed from tap to
> network.
> These are on TAP interface, where:78 is VPP-based router, :7a is non-VPP
> peer, both directions are seen:
> 13:03:22.911887 3c:ec:ef:5f:78:7a > 09:00:2b:00:00:05, 802.3, length 1500:
> LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI
> NLPID IS-IS (0x83): p2p IIH, src-id ..0001, length 1497
> 13:03:23.433773 3c:ec:ef:5f:77:8f > 09:00:2b:00:00:05, 802.3, length 1500:
> LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI
> NLPID IS-IS (0x83): p2p IIH, src-id ..0001, length 1497
> ,
> These are on opposite side of link, (Linux IS-IS router without VPP), only
> outgoing packets are seen:
> 13:08:54.796588 3c:ec:ef:5f:78:7a > 09:00:2b:00:00:05, 802.3, length 1500:
> LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI
> NLPID IS-IS (0x83): p2p IIH, src-id ..0001, length 1497
> 13:08:57.662629 3c:ec:ef:5f:78:7a > 09:00:2b:00:00:05, 802.3, length 1500:
> LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI
> NLPID IS-IS (0x83): p2p IIH, src-id ..0001, length 1497
>
>
> Also, it looks like lcp auto-subint is broken ; VPP aborts on ip link add
> on TAP device, instead of creating subif. I'll provide back
> trace later on
>
> Jan 26 12:57:04 tn3 vnet[1133419]: unix_signal_handler:191: received
> signal SIGWINCH, PC 0x7fdd59a34f41
> Jan 26 12:57:11 tn3 vnet[1133419]: received signal SIGWINCH, PC
> 0x7fdd59a34f41
> Jan 26 12:57:11 tn3 vnet[1133419]: #0 0x7fdd59a95c92
> unix_signal_handler + 0x1f2
> Jan 26 12:57:11 tn3 vnet[1133419]: #1 0x7fdd59993420 0x7fdd59993420
> Jan 26 12:57:11 tn3 vnet[1133419]: #2 0x7fdd5a5b8f00
> virtio_refill_vring_split + 0x60
> Jan 26 12:57:11 tn3 vnet[1133419]: #3 0x7fdd5a5b7f52
> virtio_device_input_inline + 0x2f2
> Jan 26 12:57:11 tn3 vnet[1133419]: #4 0x7fdd5a5b7acb
> virtio_input_node_fn_skx + 0x19b
> Jan 26 12:57:11 tn3 vnet[1133419]: #5 0x7fdd59a3515d dispatch_node +
> 0x33d
> Jan 26 12:57:11 tn3 vnet[1133419]: #6 0x7fdd59a30c72
> vlib_main_or_worker_loop + 0x632
> Jan 26 12:57:11 tn3 vnet[1133419]: #7 0x7fdd59a3277a vlib_main_loop +
> 0x1a
> Jan 26 12:57:11 tn3 vnet[1133419]: #8 0x7fdd59a3229a vlib_main + 0x60a
> Jan 26 12:57:11 tn3 vnet[1133419]: #9 0x7fdd59a94a14 thread0 + 0x44
> Jan 26 12:57:11 tn3 vnet[1133419]: #10 0x7fdd598e43d8 0x7fdd598e43d8
>
>
>
--
Best regards
Stanislav Zaikin
diff --git a/src/plugins/linux-cp/lcp_node.c b/src/plugins/linux-cp/lcp_node.c
index b00049884..c119b8bd7 100644
--- a/src/plugins/linux-cp/lcp_node.c
+++ b/src/plugins/linux-cp/lcp_node.c
@@ -15,6 +15,7 @@
* limitations under the License.
*/
+#include "vnet/osi/osi.h"
#include
#include
@@ -935,6 +936,147 @@ VNET_FEATURE_INIT (lcp_arp_host_arp_feat, static) = {
.runs_before = VNET_FEATURES ("arp-reply"),
};
+typedef struct l2_punt_trace_t_
+{
+ u8 direction;
+ u32 phy_sw_if_index;
+ u32 host_sw_if_index;
+} l2_punt_trace_t;
+
+static u8 *
+format_l2_punt_trace (u8 *s, va_list *args)
+{
+ CLIB_UNUSED (vlib_main_t * vm) = va_arg (*args, vlib_main_t *);
+ CLIB_UNUSED (vlib_node_t * node) = va_arg (*args, vlib_node_t *);
+ l2_punt_trace_t *t = va_arg (*args, l2_punt_trace_t *);
+
+ if (t->direction)
+{
+ s = format (s, "l2-punt: %u -> %u", t->host_sw_if_index,
+ t->phy_sw_if_index);
+}
+ else
+{
+ s = format (s, "l2-punt: %u -> %u", t->phy_sw_if_index,
+ t->host_sw_if_index);
+}
+
+ return s;
+}
+
+VLIB_NODE_FN (l2_punt_node)
+(vlib_main_t *vm, vlib_node_runtime_t *node, vlib_frame_t *frame)
+{
+ u32 n_left_from, *from, *to_next, n_left_to_next;
+ lip_punt_next_t next_index;
+
+ next_index = node->cached_next_index;
+ n_left_from = frame->n_vectors;
+ from = vlib_frame_vector_args (frame);
+
+ while (n_left_from > 0)
+{
+ vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
+
+ while (n_left_from > 0 && n_left_to_next > 0)
+ {
+ vlib_buffer_t *b0;
+ const lcp_itf_pair_t *lip0 = NULL;
+ u32 next0 = ~0;
+ u32 bi0, lipi0;
+ u32 sw_if_index0;
+ u8 direction = 0;
+ u8 len0;
+
+ bi0 = to_next[0] = from[0];
+
+ from += 1;
+ to_next += 1;
+ n_left_from -= 1;
+ n_left_to_next -= 1;
+ next0 = LIP_PUNT_NEXT_DROP;
+
+ b0 = vlib_get_buffer (vm, bi0);
+
+ sw_if_index
Re: [vpp-dev] VPP LCP: IS-IS does not work
(obj=0x5a3450,
> arg=0x7fffbb9b18c8) at
> /home/abramov/vpp-p3-lcp/src/plugins/linux-cp/lcp_nl.c:323
> #12 0x7fffaf4a0f52 in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200
> #13 0x7fffaf441990 in ?? () from
> /lib/x86_64-linux-gnu/libnl-route-3.so.200
> #14 0x7fffaf49db52 in nl_cache_parse () from
> /lib/x86_64-linux-gnu/libnl-3.so.200
> #15 0x7fffaf4a2984 in nl_msg_parse () from
> /lib/x86_64-linux-gnu/libnl-3.so.200
> #16 0x7fffaf40c4c4 in nl_route_process_msgs () at
> /home/abramov/vpp-p3-lcp/src/plugins/linux-cp/lcp_nl.c:344
> #17 0x7fffaf40b721 in nl_route_process (vm=0x7fffb6ae8740,
> node=0x7fffb8794380, frame=0x0) at
> /home/abramov/vpp-p3-lcp/src/plugins/linux-cp/lcp_nl.c:557
> #18 0x76fc528d in vlib_process_bootstrap (_a=140736123472776) at
> /home/abramov/vpp-p3-lcp/src/vlib/main.c:1221
> #19 0x76e753d8 in clib_calljmp () at
> /home/abramov/vpp-p3-lcp/src/vppinfra/longjmp.S:123
> #20 0x7fffaea58b80 in ?? ()
> #21 0x76fc4d0f in vlib_process_startup (vm=0x8, p=0x76fc7bea
> , f=0x7fffaea58c90) at
> /home/abramov/vpp-p3-lcp/src/vlib/main.c:1246
> #22 0x76ed3c1e in vec_mem_size (v=0xbf3d636e2d3e12) at
> /home/abramov/vpp-p3-lcp/src/vppinfra/vec.c:15
> #23 0x7fffb6ae8740 in ?? ()
> #24 0x0035 in ?? ()
> #25 0x0009 in ?? ()
> #26 0x7fffbb96b7e0 in ?? ()
> #27 0x7fffbb96b7e0 in ?? ()
> #28 0x7fffbb9a00a0 in ?? ()
> #29 0x00bf3d636e2d116c in ?? ()
> #30 0x7fffbb92b9b8 in ?? ()
> #31 0x00bf3d636e2d3e12 in ?? ()
> #32 0x7fffbb96b7e0 in ?? ()
> #33 0x7fffb8794380 in ?? ()
> #34 0x in ?? ()
> (gdb)
> (gdb) info locals
> set = {__val = {0, 2479908161616046770, 2479908161616046770,
> 2479908161616046770, 2479908161616046770, 2479908161616046770,
> 7865077477686057405, 7865077477686057405, 7865077477686057405,
> 7865077477686057405, 7865077477686057405, 7865077477686057405,
> 7865077477686057405, 7865077477686057405, 8521594516526759676,
> 8521594516526759676}}
> pid =
> tid =
> ret =
> (gdb)
>
> As for lcp-sync, situation is harder to debug. It initially works, but
> host-if (TAP interface) goes down from time to time (I could not understand
> well , and after some iterations VPP also crashes.
>
>
>
>
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22530): https://lists.fd.io/g/vpp-dev/message/22530
Mute This Topic: https://lists.fd.io/mt/96476162/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] sigsegv and its handler
Hello folks, I've been experiencing rare crashes (one crash in 3 months or so), it looks like the heap is corrupted somehow. Sometimes, the trace shows very unexpected nodes (like ip6-map-t although I don't configure any ipv6 map) or sometimes it's just a crash inside ip4-rewrite-node. After a look I found that last 2 crashes occured in the same way: 1. vnet_feature_arc_start_w_cfg_index or vnet_feature_arc_start call 2. vnet_get_config_data call But then VPP received and handled a SIGSEGV signal. It completely broke the stack trace in the core dump (for the corresponding worker): #0 0x7f44fa0812c6 in __GI_epoll_pwait (epfd=8, events=0x7f44babe52d8, maxevents=, timeout=9, set=0x7f44fa5c66f8 ) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42 #1 0x00089f6fab2b in ?? () #2 0x7f44babe52d8 in ?? () #3 0x00090100 in ?? () #4 0x7f44fa5c66f8 in _vlib_init_function_init_linux_epoll_input_init () from /lib/x86_64-linux-gnu/libvlib.so.22.10.0 #5 0x in ?? () So, I can't analyze the core dump. Any ideas on how to catch this crash correctly? Disable receiving SIGSEGV? Or is there a way to restore the original stack trace of the worker? For the reference, stack traces from syslog: vnet[2856086]: received signal SIGSEGV, PC 0x7f44b76dbee3, faulting address 0xb0040114 vnet[2856086]: #0 0x7f44fa43885b 0x7f44fa43885b (unix_signal_handler+379) vnet[2856086]: #1 0x7f44fa34f3c0 0x7f44fa34f3c0 (__funlockfile) vnet[2856086]: #2 0x7f44b76dbee3 0x7f44b76dbee3 (ip6_map_t+675) vnet[2856086]: #3 0x7f44fa3c86fb vlib_worker_loop + 0x1b3b vnet[2856086]: #4 0x7f44fa41aafa vlib_worker_thread_fn + 0xaa vnet[2856086]: #5 0x7f44fa414e01 vlib_worker_thread_bootstrap_fn + 0x51 vnet[2856086]: #6 0x7f44fa343609 start_thread + 0xd9 vnet[2856086]: #7 0x7f44fa081163 clone + 0x43 vnet[944491]: received signal SIGSEGV, PC 0x7faf922ca6ae, faulting address 0x7fb3519530fc vnet[944491]: #0 0x7faf9102785b 0x7faf9102785b vnet[944491]: #1 0x7faf90f3e3c0 0x7faf90f3e3c0 vnet[944491]: #2 0x7faf922ca6ae ip4_rewrite_node_fn_skx + 0x149e vnet[944491]: #3 0x7faf90fb76fb vlib_worker_loop + 0x1b3b vnet[944491]: #4 0x7faf91009afa vlib_worker_thread_fn + 0xaa vnet[944491]: #5 0x7faf91003e01 vlib_worker_thread_bootstrap_fn + 0x51 vnet[944491]: #6 0x7faf90f32609 start_thread + 0xd9 vnet[944491]: #7 0x7faf90c70163 clone + 0x43 Line information: Line 135 of "/home/runner/work/vpp/vpp/src/vnet/config.h" starts at address 0x7f44b76dbee3 and ends at 0x7f44b76dbee7 . Line 135 of "/home/runner/work/vpp/vpp/src/vnet/config.h" starts at address 0x7f44fb6db6ae and ends at 0x7f44fb6db6b1 . -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22531): https://lists.fd.io/g/vpp-dev/message/22531 Mute This Topic: https://lists.fd.io/mt/96673497/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] additional email
Hello folks, I have a stupid question. I want to add an additional email (my employer asked me to sign commits with my working email). I've added new email at linuxfoundation.org, but gerrit keeps showing me the error: Error 405 (Method Not Allowed): realm does not allow adding emails Endpoint: /account/self/emails/* What can I do about it? I also tried to push with no luck: remote: ERROR: commit e1d7fd7: email address stanislav.zai...@46labs.com is not registered in your account, and you lack 'forge committer' permission. remote: The following addresses are currently registered: remote:zsta...@gmail.com -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22536): https://lists.fd.io/g/vpp-dev/message/22536 Mute This Topic: https://lists.fd.io/mt/96696880/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP LCP: IS-IS does not work
Hello Gennady,
Could you try again with this patch[0]?
[0] - https://gerrit.fd.io/r/c/vpp/+/38118
On Wed, 1 Feb 2023 at 19:38, Gennady Abramov wrote:
> Hello Stanislav,
>
> Here is it!
>
> Thread 1 "vpp_main" received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb)
> (gdb) f 9
> #9 0x7fffaf404b6a in lcp_router_link_add (rl=0x5a38e0,
> ctx=0x7fffbb9add18) at
> /home/abramov/vpp-p3-lcp/src/plugins/linux-cp/lcp_router.c:423
> 423 if (vnet_create_sub_interface
> (lip->lip_host_sw_if_index, vlan, 18,
> (gdb) info locals
> lip = 0x7fffbb9abd70
> if_name = 0x0
> sub_phy_sw_if_index = 3
> sub_host_sw_if_index = 8
> vlan = 1914
> ns = 0x0
> if_namev = 0xf90b93202e1d7baf 0xf90b93202e1d7baf>
> lipi = 0
> up = 0
> vnm = 0x77f696e8
> (gdb) p lipi
> $1 = 0
> (gdb) p *lip
> $2 = {lip_host_sw_if_index = 1745050366, lip_phy_sw_if_index = 32767,
> lip_host_name = 0x43 ,
> lip_vif_index = 1,
> lip_namespace = 0x50005 "", lip_host_type = (LCP_ITF_HOST_TUN |
> unknown: 4294967294), lip_phy_adjs = {adj_index = {0, 0}}, lip_flags =
> (unknown: 0),
> lip_rewrite_len = 0 '\000', lip_create_ts = 0}
> (gdb)
>
>
>
--
Best regards
Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22537): https://lists.fd.io/g/vpp-dev/message/22537
Mute This Topic: https://lists.fd.io/mt/96476162/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] additional email
Hi Dave, Thanks for the help! The case number is IT-25142. On Fri, 3 Feb 2023 at 03:21, Dave Wallace wrote: > Hi Stanislav, > > Please open a case with LF-IT and let me know what the case number is. > > https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/create/37 > > I will follow up with LF-IT folks to make sure that it is picked up > promptly. > > Thanks, > -daw- > > On 2/2/23 4:22 AM, Stanislav Zaikin wrote: > > Hello folks, > > I have a stupid question. I want to add an additional email (my employer > asked me to sign commits with my working email). I've added new email at > linuxfoundation.org, but gerrit keeps showing me the error: > > Error 405 (Method Not Allowed): realm does not allow adding emails > Endpoint: /account/self/emails/* > > What can I do about it? > > I also tried to push with no luck: > remote: ERROR: commit e1d7fd7: email address stanislav.zai...@46labs.com > is not registered in your account, and you lack 'forge committer' > permission. > remote: The following addresses are currently registered: > remote: zsta...@gmail.com > > -- > Best regards > Stanislav Zaikin > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22540): https://lists.fd.io/g/vpp-dev/message/22540 Mute This Topic: https://lists.fd.io/mt/96696880/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Forwarding ARP Messages
Hi Burcu, You can still use IP forwarding, LCP and other features with bridge-domain. All you need is to create a loopback interface and assign it as bridge-domain's BVI. About reassembling packets between node A and B - I'm not 100% sure, but I suppose that you can do that with enabling proxy arp on the BVI interface. On Fri, 3 Feb 2023 at 14:29, Burcu YUKSEL < burcu.yuk...@ulakhaberlesme.com.tr> wrote: > Hello everyone, > > In the tests with VPP, we want to ping from Device A to Device B. ARP and > ICMP packets can be transmitted correctly by using bridge domain between > GigabitEthernet0 and memif0/0 on VPP1. However we do not want to use it > because we have also transfer L3 packets and these L3 packets should be > forwarded to IP nodes to utilize the useful features like lcp, reassembly, > fragmentation and so on. Is there a way to transmit the ARP message from > Device A to Device B without bridge domain? > > > > Best Regards, > Burcu > > Bu elektronik posta ve onunla iletilen bütün dosyalar sadece göndericisi > tarafından alması amaçlanan yetkili, gerçek ya da tüzel kişinin kullanımı > içindir. Eğer söz konusu yetkili alıcı değilseniz, bu elektronik postanın > içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız > kesinlikle yasaktır ve bu elektronik postayı derhal silmeniz gerekmektedir. > Şirketimiz bu mesajın içerdiği bilgilerin doğruluğu veya eksiksiz olduğu > konusunda herhangi bir garanti vermemektedir. Bu nedenle, bu bilgilerin ne > şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından ve > saklanmasından sorumlu değildir. Bu mesajdaki görüşler yalnızca gönderen > kişiye aittir ve Şirketimizin görüşlerini yansıtmayabilir. Tarafınız ile > paylaşılan kişisel verilerin, 6698 sayılı Kişisel Verilerin Korunması > Kanununa uygun olarak işlenmesi gereğini bilginize sunarız. > -- > > This e-mail and all files sent with it are intended for authorized natural > or legal persons, who should be the only persons to open and read them. If > you are not an authorized recipient, you are strictly prohibited from > disclosing, copying, forwarding, and using the contents of this e-mail, and > you must immediately delete it. Our company does not guarantee the accuracy > or thoroughness of the information contained in this message. It is > therefore in no way responsible for the content, sending, retrieval and > storage of this information. The opinions contained in this message are the > views of the sender only and do not necessarily reflect the views of the > company. We would like to inform you that any personal data shared with you > should be processed in accordance with the Law on Protection of Personal > Data numbered 6698. > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22543): https://lists.fd.io/g/vpp-dev/message/22543 Mute This Topic: https://lists.fd.io/mt/96722260/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] periodical build failure of external dependency ipsec-mb
Hi Laszlo, Have you checked the system's logs? It might be killed by an out-of-memory killer. On Mon, 13 Feb 2023 at 11:45, Laszlo Király wrote: > Hello, > > Time to time our automated build fails during ipsec-mb external > dependency. It is not a constant failure, usually passing for second run. > The failure have been seen on vpp versions 22.06 and 22.04. > > --- building ipsec-mb 1.1 - log: > /vpp/build/external/rpm/tmp/ipsec-mb.build.log > [91mmake[4]: *** [Makefile:791: obj/aes256_gcm_by48_api_vaes_avx512.o] > Killed > > Seems to me like the nasm (nasm 2.14.02) target is not ready when the gcc > tries to use it as source. It can be some nasty dependency or timing issue > in ipsec-mb build. > > Did you faced similar phenomenon? > > -- > Thanks, > Laszlo Kiraly > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22584): https://lists.fd.io/g/vpp-dev/message/22584 Mute This Topic: https://lists.fd.io/mt/96933164/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP Policer API Memory Leak
gt; > 0x7efd0a896b91 > > vl_msg_api_socket_handler + 0x226 > > vl_socket_process_api_msg + 0x1d > > 0x7efd0c177171 > > 0x7efd0a588837 > > 0x7efd0a48d6a8 > > 858001 0x7efb135ca840 _vec_realloc_internal + 0x89 > > vl_socket_api_send + 0x720 > > vl_api_sockclnt_create_t_handler + 0x2e2 > > vl_msg_api_socket_handler + 0x226 > > vl_socket_process_api_msg + 0x1d > > 0x7efd0c177171 > > 0x7efd0a588837 > > 0x7efd0a48d6a8 > > 41041 0x7efb13dcf220 _vec_alloc_internal + 0x6b > > 0x7efd0a5e0965 > > 0x7efd0a5f05c4 > > 0x7efd0a584978 > > 0x7efd0a5845f5 > > 0x7efd0a5f213b > > 0x7efd0a48d6a8 > > 1920 16 0x7efb13e62a40 _vec_realloc_internal + 0x89 > > 0x7efd0a482d1d > > va_format + 0xf62 > > format + 0x83 > > va_format + 0x1041 > > format + 0x83 > > va_format + 0x1041 > > vlib_log + 0x2c6 > > 0x7efb08b033aa > > 0x7efb08b031c9 > > 0x7efb08b0cc6d > > 0x7efb08b988ee > > > > vpp# show memory main-heap verbose > > Thread 0 vpp_main > > base 0x7efb0a117000, size 8g, locked, unmap-on-destroy, traced, name > 'main heap' > > page stats: page-size 4K, total 2097152, mapped 170152, not-mapped > 1396380, unknown 530620 > > numa 0: 169806 pages, 663.30m bytes > > numa 1: 346 pages, 1.35m bytes > > total: 7.99G, used: 289.51M, free: 7.72G, trimmable: 7.71G > > free chunks 93 free fastbin blks 0 > > max total allocated 7.99G > > > > BytesCount Sample Traceback > > 29822832 248408 0x7efb18bbfaf0 _vec_alloc_internal + 0x6b > > vl_msg_api_trace + 0x4a4 > > vl_msg_api_socket_handler + 0x10f > > vl_socket_process_api_msg + 0x1d > > 0x7efd0c177171 > > 0x7efd0a588837 > > 0x7efd0a48d6a8 > > 22669680 822640 0x7efb19210510 _vec_alloc_internal + 0x6b > > va_format + 0x2318 > > format + 0x83 > > 0x7efd0a896b91 > > vl_msg_api_socket_handler + 0x226 > > vl_socket_process_api_msg + 0x1d > > 0x7efd0c177171 > > 0x7efd0a588837 > > 0x7efd0a48d6a8 > > 22120401 0x7efb17ee2220 _vec_realloc_internal + 0x89 > > vl_msg_api_trace + 0x529 > > vl_msg_api_socket_handler + 0x10f > > vl_socket_process_api_msg + 0x1d > > 0x7efd0c177171 > > 0x7efd0a588837 > > 0x7efd0a48d6a8 > > 858001 0x7efb135ca840 _vec_realloc_internal + 0x89 > > vl_socket_api_send + 0x720 > > vl_api_sockclnt_create_t_handler + 0x2e2 > > vl_msg_api_socket_handler + 0x226 > > vl_socket_process_api_msg + 0x1d > > 0x7efd0c177171 > > 0x7efd0a588837 > > 0x7efd0a48d6a8 > > > > Thanks in Advance > > > > Best Regards, > > Eugene > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22612): https://lists.fd.io/g/vpp-dev/message/22612 Mute This Topic: https://lists.fd.io/mt/97110527/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Issue with tap FDs of bvi interface.
Hello Pragya, Do you see any errors in `show log`? Do you see this fd 59 in `show unix files`? On Fri, 24 Feb 2023 at 07:59, Pragya Nand Bhagat < pragya.nand.bhaga...@gmail.com> wrote: > Hi All, > > I'm using an older version of vpp 20.09 . > When I create a bvi interface using bvi create cli. > A corresponding tap is created with same name as follows: > > > > *itf-pair: [19] bvi100 tap-39-bvi100 bvi100 960 type tap * > > But one FD of the tap interface is *missing* when I check in linux. > > vpp# *show tap tap-39-bvi100* > > Interface: tap-39-bvi100 (ifindex 40) > > name "bvi100" > > host-ns "(nil)" > > host-mac-addr: e4:43:4b:21:f3:86 > > *vhost-fds 213 214* > > * tap-fds 59* > > gso-enabled 0 > > csum-enabled 0 > > > In above output there should be 3 FDs associated with the tap but* one > of them is missing.* > > [root@0-9 /]# ls -l /proc/37/fd | grep 59 > > lrwx-- 1 root root 64 Feb 23 12:03 159 -> /dev/vhost-net > > *FD 59 is missing*, as a result of which packet transfer between linux > and mdp is not happening. > > Is there some checkin/patch to fix this issue? > Any help in debugging this issue will be helpful . > > Thanks > Pragya Nand > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22622): https://lists.fd.io/g/vpp-dev/message/22622 Mute This Topic: https://lists.fd.io/mt/97201480/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Issue with tap FDs of bvi interface.
Hi Pragya, Could you provide me with the steps to reproduce? On Tue, 28 Feb 2023 at 14:10, Pragya Nand Bhagat < pragya.nand.bhaga...@gmail.com> wrote: > Hi Stanislav, > > I debug it further. Here are the steps > > 1> In my config I am creating a veth interface in kernel > 2> for that interface I am creating a hostif interface using "create > host-interface name " > 3> This intern create 4 fds in "show unix files" > 4> > [image: image.png] > > 5> I think this 59 fd is fd of af_packet socket for hostif. Correct me > if I am wrong. > 6> but I don't see any inode entry for it in /proc//fd > 7> So according to my understanding for other tap creation it tries to > take 59 as free fd and allocate > 8> that happens to be in bvi tap interface creation > 9> and that causes traffic flow issues. > > Do you see its a valid analysis? Please provide your comments and let me > know your thoughts on this. > > Thanks, > Pragya > > > On Tue, Feb 28, 2023 at 4:13 PM Pragya Nand Bhagat via lists.fd.io > wrote: > >> Hi Stanislav, >> >> Thanks for the response. >> Please find the response inline >> >> >> Do you see any errors in `show log`? >> >>>>[Pragya] No I don't see any error log >> >> Do you see this fd 59 in `show unix files`? >> >>>>[Pragya] Yes, I can see 59 in show unix files >> "show unix files" fetch the fd from "/proc/self/fd/" >> but if we go and see /proc//fd we don't see any file inode being >> created. >> >> So according to OS 59 is never assigned and for subsequent interface >> creation it try to have that same tap fd which is 59 here. >> I think that causes the issue where the traffic flow is not OK. >> >> Can you suggest how I can debug and address this issue? >> >> Thanks, >> Pragya >> >> >> On Fri, Feb 24, 2023 at 3:24 PM Stanislav Zaikin >> wrote: >> >>> Hello Pragya, >>> >>> Do you see any errors in `show log`? >>> Do you see this fd 59 in `show unix files`? >>> >>> On Fri, 24 Feb 2023 at 07:59, Pragya Nand Bhagat < >>> pragya.nand.bhaga...@gmail.com> wrote: >>> >>>> Hi All, >>>> >>>> I'm using an older version of vpp 20.09 . >>>> When I create a bvi interface using bvi create cli. >>>> A corresponding tap is created with same name as follows: >>>> >>>> >>>> >>>> *itf-pair: [19] bvi100 tap-39-bvi100 bvi100 960 type tap * >>>> >>>> But one FD of the tap interface is *missing* when I check in linux. >>>> >>>> vpp# *show tap tap-39-bvi100* >>>> >>>> Interface: tap-39-bvi100 (ifindex 40) >>>> >>>> name "bvi100" >>>> >>>> host-ns "(nil)" >>>> >>>> host-mac-addr: e4:43:4b:21:f3:86 >>>> >>>> *vhost-fds 213 214* >>>> >>>> * tap-fds 59* >>>> >>>> gso-enabled 0 >>>> >>>> csum-enabled 0 >>>> >>>> >>>> In above output there should be 3 FDs associated with the tap but* >>>> one of them is missing.* >>>> >>>> [root@0-9 /]# ls -l /proc/37/fd | grep 59 >>>> >>>> lrwx-- 1 root root 64 Feb 23 12:03 159 -> /dev/vhost-net >>>> >>>> *FD 59 is missing*, as a result of which packet transfer between linux >>>> and mdp is not happening. >>>> >>>> Is there some checkin/patch to fix this issue? >>>> Any help in debugging this issue will be helpful . >>>> >>>> Thanks >>>> Pragya Nand >>>> >>>> >>>> >>>> >>> >>> -- >>> Best regards >>> Stanislav Zaikin >>> >>> >>> >>> >> >> >> > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22665): https://lists.fd.io/g/vpp-dev/message/22665 Mute This Topic: https://lists.fd.io/mt/97201480/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Issue with tap FDs of bvi interface.
Hi Pragya, Could you give it a try with VPP master? I can't reproduce it on the master. On Fri, 3 Mar 2023 at 16:15, Pragya Nand Bhagat < pragya.nand.bhaga...@gmail.com> wrote: > Hi Stanislav, > > Following are the steps to reproduce in VPP 20.09: > > ip link add name vcsr-f1c1 type veth peer name f1c1 > ip link set dev f1c1 up > ip link set dev vcsr-f1c1 up > create host-interface name vcsr-f1c1 > lcp create host-vcsr-f1c1 host-if Ethernet0 > > check in show tap > Check for fd in /proc//fd > check in "show unix files" > > Thanks > Pragya > > > On Fri, 3 Mar, 2023, 8:34 pm Stanislav Zaikin, wrote: > >> Hi Pragya, >> >> Could you provide me with the steps to reproduce? >> >> On Tue, 28 Feb 2023 at 14:10, Pragya Nand Bhagat < >> pragya.nand.bhaga...@gmail.com> wrote: >> >>> Hi Stanislav, >>> >>> I debug it further. Here are the steps >>> >>> 1> In my config I am creating a veth interface in kernel >>> 2> for that interface I am creating a hostif interface using "create >>> host-interface name " >>> 3> This intern create 4 fds in "show unix files" >>> 4> >>> [image: image.png] >>> >>> 5> I think this 59 fd is fd of af_packet socket for hostif. Correct me >>> if I am wrong. >>> 6> but I don't see any inode entry for it in /proc//fd >>> 7> So according to my understanding for other tap creation it tries to >>> take 59 as free fd and allocate >>> 8> that happens to be in bvi tap interface creation >>> 9> and that causes traffic flow issues. >>> >>> Do you see its a valid analysis? Please provide your comments and let me >>> know your thoughts on this. >>> >>> Thanks, >>> Pragya >>> >>> >>> On Tue, Feb 28, 2023 at 4:13 PM Pragya Nand Bhagat via lists.fd.io >>> wrote: >>> >>>> Hi Stanislav, >>>> >>>> Thanks for the response. >>>> Please find the response inline >>>> >>>> >>>> Do you see any errors in `show log`? >>>> >>>>[Pragya] No I don't see any error log >>>> >>>> Do you see this fd 59 in `show unix files`? >>>> >>>>[Pragya] Yes, I can see 59 in show unix files >>>> "show unix files" fetch the fd from "/proc/self/fd/" >>>> but if we go and see /proc//fd we don't see any file inode being >>>> created. >>>> >>>> So according to OS 59 is never assigned and for subsequent interface >>>> creation it try to have that same tap fd which is 59 here. >>>> I think that causes the issue where the traffic flow is not OK. >>>> >>>> Can you suggest how I can debug and address this issue? >>>> >>>> Thanks, >>>> Pragya >>>> >>>> >>>> On Fri, Feb 24, 2023 at 3:24 PM Stanislav Zaikin >>>> wrote: >>>> >>>>> Hello Pragya, >>>>> >>>>> Do you see any errors in `show log`? >>>>> Do you see this fd 59 in `show unix files`? >>>>> >>>>> On Fri, 24 Feb 2023 at 07:59, Pragya Nand Bhagat < >>>>> pragya.nand.bhaga...@gmail.com> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I'm using an older version of vpp 20.09 . >>>>>> When I create a bvi interface using bvi create cli. >>>>>> A corresponding tap is created with same name as follows: >>>>>> >>>>>> >>>>>> >>>>>> *itf-pair: [19] bvi100 tap-39-bvi100 bvi100 960 type tap * >>>>>> >>>>>> But one FD of the tap interface is *missing* when I check in linux. >>>>>> >>>>>> vpp# *show tap tap-39-bvi100* >>>>>> >>>>>> Interface: tap-39-bvi100 (ifindex 40) >>>>>> >>>>>> name "bvi100" >>>>>> >>>>>> host-ns "(nil)" >>>>>> >>>>>> host-mac-addr: e4:43:4b:21:f3:86 >>>>>> >>>>>> *vhost-fds 213 214* >>>>>> >>>>>> * tap-fds 59* >>>>>> >>>>>> gso-enabled 0 >>>>>> >>>>>> csum-enabled 0 >>>>>> >>>>>> >>>>>> In above output there should be 3 FDs associated with the tap but* >>>>>> one of them is missing.* >>>>>> >>>>>> [root@0-9 /]# ls -l /proc/37/fd | grep 59 >>>>>> >>>>>> lrwx-- 1 root root 64 Feb 23 12:03 159 -> /dev/vhost-net >>>>>> >>>>>> *FD 59 is missing*, as a result of which packet transfer between >>>>>> linux and mdp is not happening. >>>>>> >>>>>> Is there some checkin/patch to fix this issue? >>>>>> Any help in debugging this issue will be helpful . >>>>>> >>>>>> Thanks >>>>>> Pragya Nand >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Best regards >>>>> Stanislav Zaikin >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> -- >> Best regards >> Stanislav Zaikin >> >> >> >> > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22675): https://lists.fd.io/g/vpp-dev/message/22675 Mute This Topic: https://lists.fd.io/mt/97201480/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP + DPDK + Mellanox CX4/5 buffers being utilized on wrong numa node?
tm2 ssse3 sdbg fma cx16 xtpr > pdcm pcid dca sse4_1 sse4_2 x2apic movbe > popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm > 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 intel_ppin > ssbd mba ibrs ibpb stibp tpr_shadow > flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 > erms invpcid rtm cqm mpx rdt_a avx512f avx512dq r > dseed adx smap clflushopt clwb intel_pt > avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc > cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida > arat pln pts vnmi pku ospke md_clear flush_l1d > arch_capabilities > Virtualization features: > Virtualization:VT-x > Caches (sum of all): > L1d: 1.3 MiB (40 instances) > L1i: 1.3 MiB (40 instances) > L2:40 MiB (40 instances) > L3:55 MiB (2 instances) > NUMA: > NUMA node(s): 2 > NUMA node0 CPU(s): > 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 > NUMA node1 CPU(s): > 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39 > Vulnerabilities: > Gather data sampling: Vulnerable > Indirect target selection: Not affected > Itlb multihit: KVM: Vulnerable > L1tf: Mitigation; PTE Inversion; VMX vulnerable, SMT > disabled > Mds: Vulnerable; SMT disabled > Meltdown: Vulnerable > Mmio stale data: Vulnerable > Reg file data sampling:Not affected > Retbleed: Vulnerable > Spec rstack overflow: Not affected > Spec store bypass: Vulnerable > Spectre v1:Vulnerable: __user pointer sanitization and > usercopy barriers only; no swapgs barriers > Spectre v2:Vulnerable; IBPB: disabled; STIBP: disabled; > PBRSB-eIBRS: Not affected; BHI: Not affected > Srbds: Not affected > Tsa: Not affected > Tsx async abort: Vulnerable > > > I was wondering if this is correct, or if I missed something? > > Regards > Nigel > > > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26235): https://lists.fd.io/g/vpp-dev/message/26235 Mute This Topic: https://lists.fd.io/mt/114480912/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
