Re: [vpp-dev] classifier howto?

[hemant via lists.fd.io]

Please see this PR to fix what I need.  

 

https://github.com/FDio/vpp/pull/33

 

Please review - thanks.  

 

Hemant

 

From: vpp-dev@lists.fd.io  On Behalf Of hemant via
lists.fd.io
Sent: Monday, January 18, 2021 10:52 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] classifier howto?

 

I am used to the bihash's easy to understand key-value pair API to program
an entry for table lookup using the hash.

 

https://github.com/FDio/vpp/blob/master/src/vppinfra/bihash_48_8.h#L39

 

The value in the struct is a u64.

 

To see how I program a classifier entry for use by the data plane, I looked
at the classifier entry data structure:

 

https://github.com/FDio/vpp/blob/master/src/vnet/classify/vnet_classify.h#L6
6

 

The data structure uses a "u32x4 key[0];" key, but where is the value?  I am
used to seeing a key and value in an entry.  

 

Is "u32 opaque_index" the value?  

If yes, why does bihash use a "u64" for value but the classifier uses a u32?

If the classifier table is hit, my next_node needs the "value" associated
with the key that incurred the table hit.  After all, for bihash, e.g.,
clib_bihash_search_48_8() API returns an explicit value. 

 

I plan to use the API in vnet_classify_add_del_session() to program ip4 and
ip6 src and dst address prefix matching.

 

Thanks,

 

Hemant

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18541): https://lists.fd.io/g/vpp-dev/message/18541
Mute This Topic: https://lists.fd.io/mt/79925983/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] Newbie question about Creating and Replacing ACL Rule #vpp-dev #vpp #vapi

[hyongsop]

Hi,

Thanks for the great info!  I'll take a look at the test code and apply to my 
own testing.

Thanks,
--Hyong

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18540): https://lists.fd.io/g/vpp-dev/message/18540
Mute This Topic: https://lists.fd.io/mt/79928765/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vapi
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Newbie question about Creating and Replacing ACL Rule #vpp-dev #vpp #vapi

[Andrew Yourtchenko]

Hi Hyong,

When you use acl plugin to apply an acl to an interface, it has the implicit 
“deny everything” in the end of processing.

If you want to only drop a selected port, you need to add an explicit “permit” 
at the end. If you didn’t do it, I would expect the results as you describe 
them.

You can take a look at logs created as part of “TEST=acl* make test”, as well 
as the test code in src/plugins/acl/test/* to have an idea of how the ACLs are 
being used, as well as various troubleshooting commands.

--a

> On 18 Jan 2021, at 18:28, hyong...@gmail.com wrote:
> 
> Hi all,
> 
> I'm using the python api to create a ACL rule and apply it to the egress side 
> of an interface.  The VPP version = 20.09-release, and the ACL plugin version 
> is 1.4.
> 
> The rule is to block all the packets addressed to a host's address at port 
> .  When the rule is added to the interface, it blocks the said traffic, 
> and when the rule is deleted from the interface, the traffic is allowed.
> 
> Then I update (or replace) the rule so that it blocks packets addressed to 
> port .  I use 'acl_add_replace()' with 'acl_index' set to the 'acl_index' 
> received when creating the rule in the first place.  I also check that 
> 'acl_index' is the same as before.
> 
> However, when I add the updated rule to the same interface, the traffic to 
> port  is still getting blocked, and when I remove the updated rule, the 
> traffic to port  is allowed.  Seeing this, I didn't even try to generate 
> the traffic to  at this point.
> 
> Given I'm new only to VPP but also to ACL, I feel I must be missing 
> something.  Any help would be greatly appreciated.
> 
> Thanks,
> --Hyong
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18539): https://lists.fd.io/g/vpp-dev/message/18539
Mute This Topic: https://lists.fd.io/mt/79928765/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vapi
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Newbie question about Creating and Replacing ACL Rule #vpp-dev #vpp #vapi

[hyongsop]

Hi all,

I'm using the python api to create a ACL rule and apply it to the egress side 
of an interface.  The VPP version = 20.09-release, and the ACL plugin version 
is 1.4.

The rule is to block all the packets addressed to a host's address at port 
.  When the rule is added to the interface, it blocks the said traffic, and 
when the rule is deleted from the interface, the traffic is allowed.

Then I update (or replace) the rule so that it blocks packets addressed to port 
.  I use 'acl_add_replace()' with 'acl_index' set to the 'acl_index' 
received when creating the rule in the first place.  I also check that 
'acl_index' is the same as before.

However, when I add the updated rule to the same interface, the traffic to port 
 is still getting blocked, and when I remove the updated rule, the traffic 
to port  is allowed.  Seeing this, I didn't even try to generate the 
traffic to  at this point.

Given I'm new only to VPP but also to ACL, I feel I must be missing something.  
Any help would be greatly appreciated.

Thanks,
--Hyong

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18538): https://lists.fd.io/g/vpp-dev/message/18538
Mute This Topic: https://lists.fd.io/mt/79928765/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vapi
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
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

[Stanislav Zaikin]

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, , 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->cached_buffers + len - n_buffers;
>> (gdb)
>> 596vlib_buffer_copy_indices (dst, src, n_buffers);
>> (gdb)
>> 597bpt->n_cached -= n_buffers;
>> (gdb)
>> 602return 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
>> 664return 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 

[vpp-dev] classifier howto?

[hemant via lists.fd.io]

I am used to the bihash's easy to understand key-value pair API to program
an entry for table lookup using the hash.

 

https://github.com/FDio/vpp/blob/master/src/vppinfra/bihash_48_8.h#L39

 

The value in the struct is a u64.

 

To see how I program a classifier entry for use by the data plane, I looked
at the classifier entry data structure:

 

https://github.com/FDio/vpp/blob/master/src/vnet/classify/vnet_classify.h#L6
6

 

The data structure uses a "u32x4 key[0];" key, but where is the value?  I am
used to seeing a key and value in an entry.  

 

Is "u32 opaque_index" the value?  

If yes, why does bihash use a "u64" for value but the classifier uses a u32?

If the classifier table is hit, my next_node needs the "value" associated
with the key that incurred the table hit.  After all, for bihash, e.g.,
clib_bihash_search_48_8() API returns an explicit value. 

 

I plan to use the API in vnet_classify_add_del_session() to program ip4 and
ip6 src and dst address prefix matching.

 

Thanks,

 

Hemant

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18536): https://lists.fd.io/g/vpp-dev/message/18536
Mute This Topic: https://lists.fd.io/mt/79925983/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

[Matthew Smith via lists.fd.io]

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
> 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, , 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 

Re: [vpp-dev] DPDK change in link speed convention

[Mohammed Hawari]

Hi everyone,

I agree with opinion #3 as well. It allows us to keep 0 as “unknown" (i.e., not 
set by the driver), and we can specify ~0 as “Not Applicable” (typically the 
case for virtual links) and change format_vnet_hw_interface_link_speed 
accordingly.

Best regards,

Mohammed

> On 18 Jan 2021, at 12:06, Benoit Ganne (bganne) via lists.fd.io 
>  wrote:
> 
> Hi Matt,
> 
> I am adding the list so that maybe VPP DPDK plugin users/maintainers can 
> chime in.
> In my opinion #3 setting link speed to ~0 makes sense as VPP usually use ~0 
> as "invalid".
> 
> The original issue I attempted to fix in DPDK was that the Mellanox DPDK 
> driver was not able to return link status in Azure because it refused to 
> return link status if it could not determine link speed. My original proposed 
> change in DPDK was just for the Mellanox DPDK driver to return link status 
> anyway but not link speed in that case (as eg. Intel drivers do). It ended up 
> being a bit more complicated in the end 
> 
> Best
> ben
> 
>> -Original Message-
>> From: Matthew Smith 
>> Sent: vendredi 15 janvier 2021 21:12
>> To: Benoit Ganne (bganne) 
>> Cc: Jim Thompson 
>> Subject: DPDK change in link speed convention
>> 
>> 
>> Hi Benoit,
>> 
>> i saw a change to DPDK which listed "Suggested-by: Benoit Ganne
>> mailto:bga...@cisco.com> >" -
>> -
>> https://github.com/DPDK/dpdk/commit/810b17d116f03783843d23ac900a3794675f66
>> 16#diff-2e1c01c3a61689ba8e51c0cf41d4d8153870532b8d64ea0847dff7a169e54bef.
>> 
>> Due to this change, it seems that rte_eth_link_get_nowait() can now return
>> ~0 for ports where the link speed is unknown or for virtual links. Along
>> with another change
>> (https://github.com/DPDK/dpdk/commit/b415b7a06856b148ace29ffcc6e9740a12b9e
>> c33#diff-c943f71001a82a273432fb087f7cd461d9666ee5cfd58a0b1b2b93b68d9f6234)
>> this has resulted in VPP reporting the link speed of DPDK virtio
>> interfaces as 4294966296 kbps. This is because the VPP DPDK plugin calls
>> vnet_hw_interface_set_link_speed() with the link speed value retrieved by
>> rte_eth_link_get_nowait() multiplied by 1000 to convert Mbps to kbps. When
>> rte_eth_link_get_nowait() returns a link speed of ~0, multiplying it by
>> 1000 overflows a u32 and the value that is set on the vnet_hw_interface_t
>> is 4294966296.
>> 
>> It seems like something different should happen in the VPP DPDK plugin
>> when the link speed is reported by DPDK as ~0. Maybe one of these options
>> would be good:
>> 
>> 1. Don't call vnet_hw_interface_set_link_speed() at all in this case. If
>> the current link speed is being reported as "unknown", maybe whatever
>> value is set on the VPP hw interface should be left as it is.
>> 2. Call vnet_hw_interface_set_link_speed() with a link speed of 0. The
>> default link speed value of a new vnet_hw_interface_t is 0, so 0 could be
>> viewed as the de facto VPP version of "unknown".
>> 3. Call vnet_hw_interface_set_link_speed() with a link speed of ~0 rather
>> than (~0 * 1000) as is currently done. And agree/document that this value
>> means "unknown" in VPP.
>> 
>> Since the DPDK commit that announced this change had a Suggested-by header
>> that mentioned you, I wanted to find out if you had thoughts on how this
>> should be handled or if you already had some work in progress to deal with
>> this.
>> 
>> Thanks!
>> -Matt
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18534): https://lists.fd.io/g/vpp-dev/message/18534
Mute This Topic: https://lists.fd.io/mt/79920343/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] DPDK change in link speed convention

[Benoit Ganne (bganne) via lists.fd.io]

Hi Matt,

I am adding the list so that maybe VPP DPDK plugin users/maintainers can chime 
in.
In my opinion #3 setting link speed to ~0 makes sense as VPP usually use ~0 as 
"invalid".

The original issue I attempted to fix in DPDK was that the Mellanox DPDK driver 
was not able to return link status in Azure because it refused to return link 
status if it could not determine link speed. My original proposed change in 
DPDK was just for the Mellanox DPDK driver to return link status anyway but not 
link speed in that case (as eg. Intel drivers do). It ended up being a bit more 
complicated in the end 

Best
ben

> -Original Message-
> From: Matthew Smith 
> Sent: vendredi 15 janvier 2021 21:12
> To: Benoit Ganne (bganne) 
> Cc: Jim Thompson 
> Subject: DPDK change in link speed convention
> 
> 
> Hi Benoit,
> 
> i saw a change to DPDK which listed "Suggested-by: Benoit Ganne
> mailto:bga...@cisco.com> >" -
> -
> https://github.com/DPDK/dpdk/commit/810b17d116f03783843d23ac900a3794675f66
> 16#diff-2e1c01c3a61689ba8e51c0cf41d4d8153870532b8d64ea0847dff7a169e54bef.
> 
> Due to this change, it seems that rte_eth_link_get_nowait() can now return
> ~0 for ports where the link speed is unknown or for virtual links. Along
> with another change
> (https://github.com/DPDK/dpdk/commit/b415b7a06856b148ace29ffcc6e9740a12b9e
> c33#diff-c943f71001a82a273432fb087f7cd461d9666ee5cfd58a0b1b2b93b68d9f6234)
> this has resulted in VPP reporting the link speed of DPDK virtio
> interfaces as 4294966296 kbps. This is because the VPP DPDK plugin calls
> vnet_hw_interface_set_link_speed() with the link speed value retrieved by
> rte_eth_link_get_nowait() multiplied by 1000 to convert Mbps to kbps. When
> rte_eth_link_get_nowait() returns a link speed of ~0, multiplying it by
> 1000 overflows a u32 and the value that is set on the vnet_hw_interface_t
> is 4294966296.
> 
> It seems like something different should happen in the VPP DPDK plugin
> when the link speed is reported by DPDK as ~0. Maybe one of these options
> would be good:
> 
> 1. Don't call vnet_hw_interface_set_link_speed() at all in this case. If
> the current link speed is being reported as "unknown", maybe whatever
> value is set on the VPP hw interface should be left as it is.
> 2. Call vnet_hw_interface_set_link_speed() with a link speed of 0. The
> default link speed value of a new vnet_hw_interface_t is 0, so 0 could be
> viewed as the de facto VPP version of "unknown".
> 3. Call vnet_hw_interface_set_link_speed() with a link speed of ~0 rather
> than (~0 * 1000) as is currently done. And agree/document that this value
> means "unknown" in VPP.
> 
> Since the DPDK commit that announced this change had a Suggested-by header
> that mentioned you, I wanted to find out if you had thoughts on how this
> should be handled or if you already had some work in progress to deal with
> this.
> 
> Thanks!
> -Matt


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18533): https://lists.fd.io/g/vpp-dev/message/18533
Mute This Topic: https://lists.fd.io/mt/79920343/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] GRE Tunnel IP6 over IP6

[Neale Ranns]

Hi Vikram,

I don’t see a v6 tunnel encapped packet in that trace.

/neale


From: Vikram Sachdeva 
Date: Monday, 18 January 2021 at 09:11
To: Neale Ranns 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] GRE Tunnel IP6 over IP6
Hi Neale,
Please find the pcap attached.

I have created two tunnels IPv4 GRE tunnel and & IPv6 based tunnel.
The IPv4 based tunnel is working fine where as IPv6 based tunnels the packets 
are getting dropped.

--
Vikram

On Tue, Jan 5, 2021 at 9:43 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi,

It’s not clear [to me at least] why the packet in your trace was dropped. It 
was an IPv6 packet to/from the tunnel src/dst, but it has IPv6 extension header 
for ‘destination options’. VPP was not able to read past this header for 
reasons I cannot say from that trace alone. I would suggest you capture a pcap 
trace to get more info:


DBGvpp# pcap ?

  pcap trace   pcap trace [rx] [tx] [drop] [off] 
[max ] [intfc |any]

   [file ] [status] [max-bytes-per-pkt ][filter]

   [preallocate-data][free-data]

/neale

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Date: Thursday, 31 December 2020 at 14:46
To: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] GRE Tunnel IP6 over IP6
I am creating IP6 over IP6 GRE Tunnel in VPP & VM instance.

I am able to see the outgoing tunneled ICMP6 from VPP to the VM instance as 
captured over the Wireshark.
The other instance is able to reply that but the reply packets are not reaching 
and pingis failing.

>From the VM side if I ping the VPP gre IP address 5001:1::1, the ping is 
>failing.
Please let me know what I am missing.

Configuration as below

VPP Instance [ Configuration ]

vpp# show version
vpp v20.09-release built by root on 38f81bec6dbd at 2020-10-01T02:57:46


vpp# set interface state GigabitEthernet0/8/0 up
vpp# set interface ip address GigabitEthernet0/8/0 2001:100::1/64
vpp# ip route add 2005:100::1/64 via GigabitEthernet0/8/0


vpp# ping 2005:100::1
76 bytes from 2005:100::1: icmp_seq=1 ttl=64 time=.2364 ms
76 bytes from 2005:100::1: icmp_seq=2 ttl=64 time=.2273 ms
76 bytes from 2005:100::1: icmp_seq=3 ttl=64 time=.2159 ms
76 bytes from 2005:100::1: icmp_seq=4 ttl=64 time=.2678 ms
76 bytes from 2005:100::1: icmp_seq=5 ttl=64 time=.2027 ms

Statistics: 5 sent, 5 received, 0% packet loss


vpp# create gre tunnel src 2001:100::1 dst 2005:100::1

vpp# set interface ip address gre0 5001:1::1/64

vpp# ip route add 3005:1::/64 via gre0

vpp# set interface state gre0 up

vpp# show int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
GigabitEthernet0/8/0  1  up  9000/0/0/0 rx packets  
  13
rx bytes
1602
tx packets  
  15
tx bytes
1750
drops   
   3
punt
   1
ip6 
  13
gre0  2  up  9000/0/0/0
local00 down  0/0/0/0


vpp# ping 3005:1::1

Statistics: 5 sent, 0 received, 100% packet loss

vpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:16:46:761592: dpdk-input
  GigabitEthernet0/8/0 rx queue 0
  buffer 0x9be79: current data 0, length 182, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 182
buf_len 2176, data_len 182, ol_flags 0x0, data_off 128, phys_addr 0x782f9ec0
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
  IP6: 08:00:27:7d:b1:12 -> 08:00:27:34:a5:29
  IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
tos 0x00, flow label 0x90736, hop limit 64, payload length 128
00:16:46:761602: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  IP6: 08:00:27:7d:b1:12 -> 08:00:27:34:a5:29
00:16:46:761605: ip6-input
  IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
tos 0x00, flow label 0x90736, hop limit 64, payload length 128
00:16:46:761606: ip6-lookup
  fib 0 dpo-idx 8 flow hash: 0x
  IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
tos 0x00, flow label 0x90736, hop limit 64, payload length 128
00:16:46:761608: ip6-local
IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
  tos 0x00, flow label 0x90736, hop limit 64, payload length 128

Re: [vpp-dev] how to allocate new buffer correctly

[Benoit Ganne (bganne) via lists.fd.io]

Hi Stanislas,

All I can say is the buffer management routine are widely used & tested so 
chances are the bug comes from your code but it is hard to guess what is 
happening without looking into it. If you can share it, we can have a quick 
look to see if we can spot any obvious error there.
By the way, if you are looking at using a TAP device, VPP already has an 
optimized driver for it, see src/vnet/devices/tap and 'create tap ...' commands.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Stanislav
> Zaikin
> Sent: samedi 16 janvier 2021 12:50
> To: vpp-dev 
> Subject: 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, , 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) next
> vlib_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 

Re: [vpp-dev] GRE Tunnel IP6 over IP6

[Vikram Sachdeva]

Hi Neale,
Please find the pcap attached.

I have created two tunnels IPv4 GRE tunnel and & IPv6 based tunnel.
The IPv4 based tunnel is working fine where as IPv6 based tunnels the
packets are getting dropped.

--
*Vikram*

On Tue, Jan 5, 2021 at 9:43 PM Neale Ranns  wrote:

> Hi,
>
>
>
> It’s not clear [to me at least] why the packet in your trace was dropped.
> It was an IPv6 packet to/from the tunnel src/dst, but it has IPv6 extension
> header for ‘destination options’. VPP was not able to read past this header
> for reasons I cannot say from that trace alone. I would suggest you capture
> a pcap trace to get more info:
>
>
>
> DBGvpp# pcap ?
>
>   pcap trace   pcap trace [rx] [tx] [drop]
> [off] [max ] [intfc |any]
>
>[file ] [status] [max-bytes-per-pkt ][filter]
>
>[preallocate-data][free-data]
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io 
> *Date: *Thursday, 31 December 2020 at 14:46
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] GRE Tunnel IP6 over IP6
>
> I am creating IP6 over IP6 GRE Tunnel in VPP & VM instance.
>
> I am able to see the outgoing tunneled ICMP6 from VPP to the VM instance
> as captured over the Wireshark.
> The other instance is able to reply that but the reply packets are not
> reaching and pingis failing.
>
> From the VM side if I ping the VPP gre IP address 5001:1::1, the ping is
> failing.
> Please let me know what I am missing.
>
> Configuration as below
>
> VPP Instance [ Configuration ]
>
> vpp# show version
> vpp v20.09-release built by root on 38f81bec6dbd at 2020-10-01T02:57:46
>
>
> vpp# set interface state GigabitEthernet0/8/0 up
> vpp# set interface ip address GigabitEthernet0/8/0 2001:100::1/64
> vpp# ip route add 2005:100::1/64 via GigabitEthernet0/8/0
>
> 
> vpp# ping 2005:100::1
> 76 bytes from 2005:100::1: icmp_seq=1 ttl=64 time=.2364 ms
> 76 bytes from 2005:100::1: icmp_seq=2 ttl=64 time=.2273 ms
> 76 bytes from 2005:100::1: icmp_seq=3 ttl=64 time=.2159 ms
> 76 bytes from 2005:100::1: icmp_seq=4 ttl=64 time=.2678 ms
> 76 bytes from 2005:100::1: icmp_seq=5 ttl=64 time=.2027 ms
>
> Statistics: 5 sent, 5 received, 0% packet loss
>
>
> vpp# create gre tunnel src 2001:100::1 dst 2005:100::1
>
> vpp# set interface ip address gre0 5001:1::1/64
>
> vpp# ip route add 3005:1::/64 via gre0
>
> vpp# set interface state gre0 up
>
> vpp# show int
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
> GigabitEthernet0/8/0  1  up  9000/0/0/0 rx
> packets13
> rx
> bytes1602
> tx
> packets15
> tx
> bytes1750
>
> drops  3
>
> punt   1
>
> ip6   13
> gre0  2  up  9000/0/0/0
> local00 down  0/0/0/0
>
>
> vpp# ping 3005:1::1
>
> Statistics: 5 sent, 0 received, 100% packet loss
>
> vpp# show trace
> --- Start of thread 0 vpp_main ---
> Packet 1
>
> 00:16:46:761592: dpdk-input
>   GigabitEthernet0/8/0 rx queue 0
>   buffer 0x9be79: current data 0, length 182, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x0
>   ext-hdr-valid
>   l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 182
> buf_len 2176, data_len 182, ol_flags 0x0, data_off 128, phys_addr
> 0x782f9ec0
> 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
>   IP6: 08:00:27:7d:b1:12 -> 08:00:27:34:a5:29
>   IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
> tos 0x00, flow label 0x90736, hop limit 64, payload length 128
> 00:16:46:761602: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   IP6: 08:00:27:7d:b1:12 -> 08:00:27:34:a5:29
> 00:16:46:761605: ip6-input
>   IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
> tos 0x00, flow label 0x90736, hop limit 64, payload length 128
> 00:16:46:761606: ip6-lookup
>   fib 0 dpo-idx 8 flow hash: 0x
>   IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
> tos 0x00, flow label 0x90736, hop limit 64, payload length 128
> 00:16:46:761608: ip6-local
> IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
>   tos 0x00, flow label 0x90736, hop limit 64, payload length 128
> 00:16:46:761609: ip6-punt
> IP6_DESTINATION_OPTIONS: 2005:100::1 -> 2001:100::1
>   tos 0x00, flow label 0x90736, hop limit 64, payload length 128
> 00:16:46:761610: error-punt
>   rx:GigabitEthernet0/8/0
> 00:16:46:761611: punt
>   ip6-input: valid ip6 packets
>
>
>
>
>
> Other VM Instance
> -
>
> ip link add deth0 type dummy
>