date:20210325

Re: [vpp-dev] vpp main thread crashed at mspace_put

2021-03-25 Thread Sudhir CR via lists.fd.io

Hi All,

The segmentation fault is happening at memset in the code below.

#if CLIB_DEBUG 
> 0 && !defined(CLIB_SANITIZE_ADDR)

  */* Poison the object */*
  {
 size_t psize = mspace_usable_size

(object_header);
 memset (object_header, 0x13, psize);
   }
#endif

Not sure how to proceed further to root cause the issue.


Thanks,

Sudhir



On Thu, Mar 25, 2021 at 5:31 PM Sudhir CR  wrote:

> Hi All,
> We have loaded our box with internet feed routes. Initially everything is
> good.
> But after *three hours* we observed a *vpp main thread crashed* due to 
> *segmentation
> error *at mspace_put function.
>
> #28 0x7f0f802c0793 in unix_signal_handler (signum=11, si=0x7f0f33c086b0, 
> uc=0x7f0f33c08580)
> at /development/libvpp/src/vlib/unix/main.c:127
> #29 
> #30 __memset_avx2_erms () at 
> ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:145
> #31 0x7f0f7fa67735 in mspace_put (msp=0x130044010, p_arg=0x130089a48) at 
> /development/libvpp/src/vppinfra/dlmalloc.c:4316
>
> We are using *20.09 version* and the complete* backtrace *is  pasted below. 
> Any help in fixing the issue would be appreciated.
>
> Thread 3 (Thread 0x7f0eccbfe700 (LWP 476)):
> #0  0x7f0f8023cff7 in vlib_worker_thread_barrier_check () at 
> /development/libvpp/src/vlib/threads.h:438
> #1  0x7f0f8023751e in vlib_main_or_worker_loop (vm=0x7f0f652dd300, 
> is_main=0) at /development/libvpp/src/vlib/main.c:1788
> #2  0x7f0f80236d37 in vlib_worker_loop (vm=0x7f0f652dd300) at 
> /development/libvpp/src/vlib/main.c:2008
> #3  0x7f0f8028e91a in vlib_worker_thread_fn (arg=0x7f0f4a974940) at 
> /development/libvpp/src/vlib/threads.c:1862
> #4  0x7f0f7fab5c34 in clib_calljmp () at 
> /development/libvpp/src/vppinfra/longjmp.S:123
> #5  0x7f0eccbfdec0 in ?? ()   
> [58/393]
> #6  0x7f0f80286ac3 in vlib_worker_thread_bootstrap_fn 
> (arg=0x7f0f4a974940) at /development/libvpp/src/vlib/threads.c:585
> ---Type  to continue, or q  to quit---
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 2 (Thread 0x7f0ecd3ff700 (LWP 475)):
> #0  0x7f0f8023cfec in vlib_worker_thread_barrier_check () at 
> /development/libvpp/src/vlib/threads.h:438
> #1  0x7f0f8023751e in vlib_main_or_worker_loop (vm=0x7f0f64d99ec0, 
> is_main=0) at /development/libvpp/src/vlib/main.c:1788
> #2  0x7f0f80236d37 in vlib_worker_loop (vm=0x7f0f64d99ec0) at 
> /development/libvpp/src/vlib/main.c:2008
> #3  0x7f0f8028e91a in vlib_worker_thread_fn (arg=0x7f0f4a974840) at 
> /development/libvpp/src/vlib/threads.c:1862
> #4  0x7f0f7fab5c34 in clib_calljmp () at 
> /development/libvpp/src/vppinfra/longjmp.S:123
> #5  0x7f0ecd3feec0 in ?? ()
> #6  0x7f0f80286ac3 in vlib_worker_thread_bootstrap_fn 
> (arg=0x7f0f4a974840) at /development/libvpp/src/vlib/threads.c:585
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x7f0f8d076d00 (LWP 280)):
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f0f8c0d3921 in __GI_abort () at abort.c:79
> #2  0x7f0f81cbd253 in os_panic () at 
> /development/libvpp/src/vpp/vnet/main.c:572
> #3  0x7f0f7fa91aa9 in debugger () at 
> /development/libvpp/src/vppinfra/error.c:84
> #4  0x7f0f7fa91827 in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x7f0f7fb613df "%s:%d (%s) assertion `%s' fails")
> at /development/libvpp/src/vppinfra/error.c:143
> #5  0x7f0f7fa98e61 in _vec_resize_inline (v=0x7f0f4a69fa90, 
> length_increment=16, data_bytes=16, header_bytes=0, data_align=1,
> numa_id=255) at /development/libvpp/src/vppinfra/vec.h:154
> #6  0x7f0f7fa98b8b in va_format (s=0x7f0f4a69fa90 "", fmt=0x7f0f802dbf1b 
> "received signal %U, PC %U", va=0x7f0f33c065f0)
> at /development/libvpp/src/vppinfra/format.c:403
> #7  0x7f0f7faa03c6 in format (s=0x7f0f4a69fa90 "", fmt=0x7f0f802dbf1b 
> "received signal %U, PC %U")
> at /development/libvpp/src/vppinfra/format.c:428
> #8  0x7f0f802c0793 in unix_signal_handler (signum=6, si=0x7f0f33c068b0, 
> uc=0x7f0f33c06780)
> at /development/libvpp/src/vlib/unix/main.c:127
> #9  
> #10 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #11 0x7f0f8c0d3921 in __GI_abort () at abort.c:79
> #12 0x7f0f81cbd253 in os_panic () at 
> /development/libvpp/src/vpp/vnet/main.c:572
> #13 0x7f0f7fa91aa9 in debugger () at 
> /development/libvpp/src/vppinfra/error.c:84
> #14 0x7f0f7fa91827 in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x7f0f7fb613df "%s:%d (%s) assertion `%s' f[23/393]
> at /development/libvpp/src/vppinfra/error.c:143
> ---Type  to continue, or q  to quit---
> #15 0x7f0f7fa98e61 in _vec_resize_i

Re: [vpp-dev] GRE-over-IPSec fails

2021-03-25 Thread Vijay Kumar

Hi Neale,

Is this issue due to adjacency being wrong. Is this a day one issue or is
this issue due to the way I added routes in my test case. As far as I know
the way I configured GRE peer and routing seems to be correct.

Did you see this issue anytime on your setup?


Regards.

On Thu, 25 Mar 2021, 19:41 Vijay Kumar,  wrote:

> Hi Neale,
>
> I was able to make a good progress for the GRE-over-IPSec use case. But
> stumbled at the last step.
> I have explained the problem faced (an extra IP header added by VPP,
> overall 4 IP headers in the pkt) and other details about logs and
> configuration below. Also attached the decrypted pcap (frame 4 shows the
> problem)
>
> Kindly let me know if you can catch the problem at the VPP side.
>
> *Topology*
> **
> Strongswan  <>  VPP
> loopback 7.7.7.7
>  loopback 8.8.8.8
> GRE  44.44.44.44
>   GRE src 42.42.42.42 (tunnel remote 44.44.44.44)
> IPSEC20.20.99.215
> IPSEC 20.20.99.99
>
>
> create gre tunnel src 42.42.42.42 instance 1
> multipoint
>
> set interface state gre1 up
>
> set interface ip addr gre1 2.2.2.2/32
>
> create teib gre1 peer 2.2.2.1 nh 44.44.44.44
>
>
> ip route add 7.7.7.7/32 via 2.2.2.1 gre1 (added
> route to the overlay 7.7.7.7 of SS)
>
>
> /* added below commands after IPSec is UP */
>
> set interface state ipip0 up
>
> ip route add 44.44.44.44/32 via ipip0
>
> set interface unnumbered ipip0 use
> VirtualFuncEthernet0/7/0.1556
>
> Problem faced
> ==
> --- SS sends ICMP over GRE over IPSEC. The VPP also replies with
> ICMP-o-GRE-o-IPSEC. But the SS was dropping the packets. Debugging the SS
> logs did not show any decryption failure. I decrypted the packets captured
> at SS. On applying the encrytion and auth keys in the wireshark, it
> was showing an extra IP header added to the reply packet making it a
> total of 4 IP headers which is wrong
>
> --- I observed that VPP had added GRE tunnel IP header on top of the inner
> most packet. Again on top of the GRE IP header, another IP was added by VPP
> with SRC and DST being same as that of IPSec tunnel header
> (20.20.99.99-to-20.20.99.215). Now on top of this extra IP header
> the ESP encapsulation was added with outermost IP header IPs of that of
> the IPSec tunnel (20.20.99.99-to-20.20.99.215)
>
> --- Why is VPP adding an extra header on top of GRE IP header. Is this
> because of the route adjacencies that has gone bad causing an extra IP
> header to be added?
>
> --- Below I have pasted the FIB entry for the destination 7.7.7.7 that are
> stacked on FIB entry 73 and 75
>
> --- Attached IPSec decoded pcap, please check frame 4 that is the ICMP
> reply from VPP to SS
>
> --- Is there anything wrong in the way I have added routes on the VPP side
> for the overlay 7.7.7.7 and GRE destination 44.44.44.44
>
>
> Ping on SS
> 
> root@SS# ping 8.8.8.8 -I 7.7.7.7 -c 3
> PING 8.8.8.8 (8.8.8.8) from 7.7.7.7 : 56(84) bytes of data.
>
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss, time 2041ms
>
>
> TCPDUMP taken on SS
> ===
> 12:46:48.439122 IP vmsrvrlnx-strongswan-215 > dns.google: ICMP echo
> request, id 43, seq 1, length 64
> 12:46:48.439174 IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
> ESP(spi=0x1234567b,seq=0x1), length 148
> 12:46:48.439178 ethertype IPv4, IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
> ESP(spi=0x1234567b,seq=0x1), length 148
> 12:46:48.439487 ethertype IPv4, IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
> ESP(spi=0xce90b744,seq=0x1), length 180
> 12:46:48.439487 IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
> ESP(spi=0xce90b744,seq=0x1), length 180
> 12:46:49.455775 IP vmsrvrlnx-strongswan-215 > dns.google: ICMP echo
> request, id 43, seq 2, length 64
> 12:46:49.455826 IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
> ESP(spi=0x1234567b,seq=0x2), length 148
> 12:46:49.455831 ethertype IPv4, IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
> ESP(spi=0x1234567b,seq=0x2), length 148
> 12:46:49.455958 ethertype IPv4, IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
> ESP(spi=0xce90b744,seq=0x2), length 180
> 12:46:49.455958 IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
> ESP(spi=0xce90b744,seq=0x2), length 180
> 12:46:50.479872 IP vmsrvrlnx-strongswan-215 > dns.google: ICMP echo
> request, id 43, seq 3, length 64
> 12:46:50.479933 IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
> ESP(spi=0x1234567b,seq=0x3), length 148
> 12:46:50.479939 ethertype IPv4, IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
> ESP(spi=0x1234567b,seq=0x3), length 148
> 12:46:50.480080 ethertype IPv4, IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
> ESP(spi=0xce90b744,seq=0x3), length 180
> 12:46:50.480080 IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
> ESP(spi=0xce90b744,seq=0x3), len

Re: [vpp-dev] keeping tests outside of src/

2021-03-25 Thread hemant via lists.fd.io

 

+1 to DaveW’s comments.

 

Hemant

 

From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
Sent: Thursday, March 25, 2021 4:15 PM
To: dmar...@me.com; vpp-dev 
Subject: Re: [vpp-dev] keeping tests outside of src/

 

Hi Damjan,

This initiative originated with the wider adoption of plugin development at the 
request of Dave Barach to allow the development of plugins outside the VPP 
repo.  After completing the job for plugins, there were several requests to 
extend that to all of the features.  Presumably this was coupled with the 
desire to migrate feature source code from vnet into the plugin arena, but I 
don't recall all of the details of the discussion.

Unfortunately, this effort stalled across several releases due to lack of 
cycles and I'm just now in the process of completing the job.

I'm perfectly ok accepting a -2 for test code that maintainers prefer to leave 
in .../vpp/test, but I don't see the original requirement to co-locate plugin 
source & test code going away.  So the majority of the feature source & test 
code will remain structured that way and the end result will be inconsistent at 
best.

Personally, I think that it makes sense to continue to move features source, 
test code, and documentation to be co-located in a modular and consistent 
sub-tree structure.  I also see value in migrating features out of vnet into 
the plugin sub-tree.

For what its worth, the changes to test/Makefile gather all of the source as 
soft links into the build tree (.../vpp/build-root/build-test/src), but I 
understand that is not the same your original plan.

Thanks,
-daw-

On 3/25/2021 3:16 PM, Damjan Marion via lists.fd.io wrote:

 
Hi,
 
It may be that it is not discussed or i was just ignorant, but I noticed that 
there is ongoing activity to scatter tests all across the src/.
When I started "make test" long long time ago i intentionally put it to 
separate tree following the pattern from other projects and to be honest
it makes me more sense that all tests are contained in the separate tree.
 
Are we sure that this test file scatter activity is right thing to do?
Anyone aware of any other project doing the same?
 
— 
Damjan
 





 
 
 

 



smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19030): https://lists.fd.io/g/vpp-dev/message/19030
Mute This Topic: https://lists.fd.io/mt/81611239/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] keeping tests outside of src/

2021-03-25 Thread Paul Vinciguerra

Hi Damian.

Why do you care?  I just looked in the flowprobe folder, for example, and
there is a flowprobe_test.c.  We have tests in the src tree.  I'm not
trying to argue for or against this, I'm trying to understand why.

We can make out of tree tests work without moving the files.  The test
runner has a custom discovery method. We just need to agree on how we want
it to behave.  What is the process used for out of tree plugins?  What has
worked for me is to create a new repository and add the repo as a git
submodule under plugins.

I'm glad Dave provided some background.  From my vantage point, Andrew said
on the list a while back that the maintainers owned the tests and shortly
thereafter, the tests started to be rearranged under their modules.

I do however want to raise the scapy licensing issue.  If I recall
correctly, there was some talk from the tsc about tagging the test folder
to indicate that the use of scapy required different licensing, so a new
plan would need to be devised.  I was doing some research on this, and the
FRR folks seem to have addressed the licensing issue around the scapy code,
by not importing it but rather by moving it to a single file that they fork
to run.  See:
https://github.com/FRRouting/frr/blob/master/tests/topotests/lib/send_bsr_packet.py

Paul

On Thu, Mar 25, 2021 at 4:13 PM Dave Wallace  wrote:

> Hi Damjan,
>
> This initiative originated with the wider adoption of plugin development
> at the request of Dave Barach to allow the development of plugins outside
> the VPP repo.  After completing the job for plugins, there were several
> requests to extend that to all of the features.  Presumably this was
> coupled with the desire to migrate feature source code from vnet into the
> plugin arena, but I don't recall all of the details of the discussion.
>
> Unfortunately, this effort stalled across several releases due to lack of
> cycles and I'm just now in the process of completing the job.
>
> I'm perfectly ok accepting a -2 for test code that maintainers prefer to
> leave in .../vpp/test, but I don't see the original requirement to
> co-locate plugin source & test code going away.  So the majority of the
> feature source & test code will remain structured that way and the end
> result will be inconsistent at best.
>
> Personally, I think that it makes sense to continue to move features
> source, test code, and documentation to be co-located in a modular and
> consistent sub-tree structure.  I also see value in migrating features out
> of vnet into the plugin sub-tree.
>
> For what its worth, the changes to test/Makefile gather all of the source
> as soft links into the build tree (.../vpp/build-root/build-test/src), but
> I understand that is not the same your original plan.
>
> Thanks,
> -daw-
>
> On 3/25/2021 3:16 PM, Damjan Marion via lists.fd.io wrote:
>
> Hi,
>
> It may be that it is not discussed or i was just ignorant, but I noticed that 
> there is ongoing activity to scatter tests all across the src/.
> When I started "make test" long long time ago i intentionally put it to 
> separate tree following the pattern from other projects and to be honest
> it makes me more sense that all tests are contained in the separate tree.
>
> Are we sure that this test file scatter activity is right thing to do?
> Anyone aware of any other project doing the same?
>
> —
> Damjan
>
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19029): https://lists.fd.io/g/vpp-dev/message/19029
Mute This Topic: https://lists.fd.io/mt/81611239/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] keeping tests outside of src/

2021-03-25 Thread Dave Wallace


Hi Damjan,

This initiative originated with the wider adoption of plugin development 
at the request of Dave Barach to allow the development of plugins 
outside the VPP repo.  After completing the job for plugins, there were 
several requests to extend that to all of the features.  Presumably this 
was coupled with the desire to migrate feature source code from vnet 
into the plugin arena, but I don't recall all of the details of the 
discussion.


Unfortunately, this effort stalled across several releases due to lack 
of cycles and I'm just now in the process of completing the job.


I'm perfectly ok accepting a -2 for test code that maintainers prefer to 
leave in .../vpp/test, but I don't see the original requirement to 
co-locate plugin source & test code going away.  So the majority of the 
feature source & test code will remain structured that way and the end 
result will be inconsistent at best.


Personally, I think that it makes sense to continue to move features 
source, test code, and documentation to be co-located in a modular and 
consistent sub-tree structure.  I also see value in migrating features 
out of vnet into the plugin sub-tree.


For what its worth, the changes to test/Makefile gather all of the 
source as soft links into the build tree 
(.../vpp/build-root/build-test/src), but I understand that is not the 
same your original plan.


Thanks,
-daw-

On 3/25/2021 3:16 PM, Damjan Marion via lists.fd.io wrote:

Hi,

It may be that it is not discussed or i was just ignorant, but I noticed that 
there is ongoing activity to scatter tests all across the src/.
When I started "make test" long long time ago i intentionally put it to 
separate tree following the pattern from other projects and to be honest
it makes me more sense that all tests are contained in the separate tree.

Are we sure that this test file scatter activity is right thing to do?
Anyone aware of any other project doing the same?

—
Damjan







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19028): https://lists.fd.io/g/vpp-dev/message/19028
Mute This Topic: https://lists.fd.io/mt/81611239/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 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code

2021-03-25 Thread Dave Barach

Dear Elias,

Glad that you were able to switch, and that you're not seeing the issue 
anymore...

Thanks for letting me know... Dave

-Original Message-
From: Elias Rudberg  
Sent: Thursday, March 25, 2021 12:43 PM
To: v...@barachs.net; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 
in IPv4 Shallow Virtual reassembly code

Hello Dave,

Just to follow up on this, we switched from 20.09 to 21.01 and that indeed 
seems to have solved the problem for us, having now run for about a month 
without the issue coming back.

Thanks for your help!

Best regards,
Elias


On Sun, 2021-02-21 at 07:43 -0500, v...@barachs.net wrote:
> That's right. In 20.09, bihash did its own os-level memory allocation. 
> You could (probably) pick up and port src/vppinfra/bihash*.[ch] to 
> 20.09, or you could add some config knobs to the reassembly code.
> 
> If switching to 21.01 is an option, that seems like the path of least 
> resistance.
> 
> HTH... Dave
> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Elias 
> Rudberg
> Sent: Friday, February 19, 2021 12:10 PM
> To: v...@barachs.net; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] VPP 20.09 os_out_of_memory() in
> clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code
> 
> Thanks Dave, however it looks like BIHASH_USE_HEAP does not exist in 
> VPP 20.09 but was introduced later. Looks like it appeared with the 
> commit 2454de2d4 "vppinfra: use heap to store bihash data" which was 
> after 20.09 was released.
> 
> I guess this means that bihash data is not stored on the heap in VPP 
> 20.09. Maybe switching to VPP 21.01 would help with this issue then, 
> or at least with 21.01 all of our main heap space would need to be 
> consumed before we get another os_out_of_memory() SIGABRT crash?
> 
> / Elias



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

[vpp-dev] keeping tests outside of src/

2021-03-25 Thread Damjan Marion via lists.fd.io


Hi,

It may be that it is not discussed or i was just ignorant, but I noticed that 
there is ongoing activity to scatter tests all across the src/.
When I started "make test" long long time ago i intentionally put it to 
separate tree following the pattern from other projects and to be honest
it makes me more sense that all tests are contained in the separate tree.

Are we sure that this test file scatter activity is right thing to do?
Anyone aware of any other project doing the same?

— 
Damjan


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

2021-03-25 Thread Dave Wallace


+1  Very nice!

Thanks,
-daw-

On 3/25/2021 5:39 AM, Andrew Yourtchenko wrote:

Hi Klement,

This is very cool! Thanks a lot for doing it!

--a


On 25 Mar 2021, at 10:29, Klement Sekera via lists.fd.io 
 wrote:

Hi all,

I’ve introduced a new checkstyle target, which should ease development. This 
one does a similar thing as test-checkstyle, but only on changed files. This is 
useful for local verification as it’s a bit faster and doesn’t pollute your 
screen with messages about checking unchanged files.

I kept semantics of test-checkstyle without change as in gerrit it doesn’t 
matter if it’s 30 seconds longer and to catch other types of failures - for 
example a tool change, which might not modify any python file, but could result 
in a diff and failure.

Regards,
Klement








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19025): https://lists.fd.io/g/vpp-dev/message/19025
Mute This Topic: https://lists.fd.io/mt/81598070/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] GoVpp different behaviour when compiling outside GoVpp project

2021-03-25 Thread Юрий Иванов

Yes, Arthur you right
Executing go get git.fd.io/govpp.git@master, solves this problem.
Looks like there was older library.
Thanks once more. ))


От: Arthur de Kerhor 
Отправлено: 25 марта 2021 г. 18:49
Кому: Юрий Иванов 
Копия: vpp-dev 
Тема: Re: [vpp-dev] GoVpp different behaviour when compiling outside GoVpp 
project

Hi,

The reason is that inside your govpp directory, you point to the latest version 
of GoVPP master branch, which supports the latest version of the VPP stats 
segment.

On the other hand, in your gst directory, I suspect that you have added govpp 
as a dependency (in go.mod) with a command like `go get 
git.fd.io/govpp.git`, which uses the latest 
released version. I think that this release does not support the stats segment 
evolution.
To use the latest version of govpp as a dependency, you should use the command  
`go get 
git.fd.io/govpp.git@master`.
 In general, if you want to use a specific commit, you can add @ at 
the end of the get command.

Hope that helps.

Best regards,
Arthur

Le 25 mars 2021 à 17:13, Юрий Иванов 
mailto:format_...@outlook.com>> a écrit :

Hi, first of all sorry for such noob question.
I'm need to write go based program utilizing govpp stats-api.
There is official example in library which I've trunk to minimal usable which 
only opens socket:
~/GoVpp/govpp$ cat examples/stats-client/stats_api.go
package main

import (
"log"

"git.fd.io/govpp.git/adapter/statsclient"
"git.fd.io/govpp.git/core"
)

func main() {
var (
client *statsclient.StatsClient
c  *core.StatsConnection
errerror
)

client = statsclient.NewStatsClient("/run/vpp/stats.sock") 
//(*statsSocket)
c, err = core.ConnectStats(client)
if err != nil {
log.Fatalln("Connecting failed:", err)
}
defer c.Disconnect()
}

In case I build it from govpp package with the help of make examples it works, 
but when I've created separete my own project execution fails with error:
$ sudo ./stats
2021/03/25 15:43:01 Connecting failed: stat segment version is not supported: 2 
(minimal version: 1)

What the difference when building the same file from govpp library folder from 
separate project?

You may look all my steps to reproduce problem here 
https://pastebin.com/Lv89BrVk




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19024): https://lists.fd.io/g/vpp-dev/message/19024
Mute This Topic: https://lists.fd.io/mt/81606546/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] GoVpp different behaviour when compiling outside GoVpp project

2021-03-25 Thread Arthur de Kerhor

Hi,

The reason is that inside your govpp directory, you point to the latest version 
of GoVPP master branch, which supports the latest version of the VPP stats 
segment.

On the other hand, in your gst directory, I suspect that you have added govpp 
as a dependency (in go.mod) with a command like `go get git.fd.io/govpp.git 
`, which uses the latest released version. I think 
that this release does not support the stats segment evolution.
To use the latest version of govpp as a dependency, you should use the command  
`go get git.fd.io/govpp.git@master ` 
. In general, if you want to use a 
specific commit, you can add @ at the end of the get command.

Hope that helps.

Best regards,
Arthur

> Le 25 mars 2021 à 17:13, Юрий Иванов  a écrit :
> 
> Hi, first of all sorry for such noob question.
> I'm need to write go based program utilizing govpp stats-api.
> There is official example in library which I've trunk to minimal usable which 
> only opens socket:
> ~/GoVpp/govpp$ cat examples/stats-client/stats_api.go 
> package main
>
> import (
> "log"
> "git.fd.io/govpp.git/adapter/statsclient 
> "
> "git.fd.io/govpp.git/core "
> )
>
> func main() {
> var (
> client *statsclient.StatsClient
> c  *core.StatsConnection
> errerror
> )
>
> client = statsclient.NewStatsClient("/run/vpp/stats.sock") 
> //(*statsSocket)
> c, err = core.ConnectStats(client)
> if err != nil {
> log.Fatalln("Connecting failed:", err)
> }
> defer c.Disconnect()
> }
> 
> In case I build it from govpp package with the help of make examples it 
> works, but when I've created separete my own project execution fails with 
> error:
> $ sudo ./stats 
> 2021/03/25 15:43:01 Connecting failed: stat segment version is not supported: 
> 2 (minimal version: 1)
> 
> What the difference when building the same file from govpp library folder 
> from separate project?
> 
> You may look all my steps to reproduce problem here 
> https://pastebin.com/Lv89BrVk 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19023): https://lists.fd.io/g/vpp-dev/message/19023
Mute This Topic: https://lists.fd.io/mt/81606546/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 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code

2021-03-25 Thread Elias Rudberg

Hello Dave,

Just to follow up on this, we switched from 20.09 to 21.01 and that
indeed seems to have solved the problem for us, having now run for
about a month without the issue coming back.

Thanks for your help!

Best regards,
Elias


On Sun, 2021-02-21 at 07:43 -0500, v...@barachs.net wrote:
> That's right. In 20.09, bihash did its own os-level memory
> allocation. You could (probably) pick up and port
> src/vppinfra/bihash*.[ch] to 20.09, or you could add some config
> knobs to the reassembly code. 
> 
> If switching to 21.01 is an option, that seems like the path of least
> resistance.
> 
> HTH... Dave
> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Elias
> Rudberg
> Sent: Friday, February 19, 2021 12:10 PM
> To: v...@barachs.net; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] VPP 20.09 os_out_of_memory() in
> clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code
> 
> Thanks Dave, however it looks like BIHASH_USE_HEAP does not exist in
> VPP 20.09 but was introduced later. Looks like it appeared with the
> commit 2454de2d4 "vppinfra: use heap to store bihash data" which was
> after 20.09 was released.
> 
> I guess this means that bihash data is not stored on the heap in VPP
> 20.09. Maybe switching to VPP 21.01 would help with this issue then,
> or at least with 21.01 all of our main heap space would need to be
> consumed before we get another os_out_of_memory() SIGABRT crash?
> 
> / Elias


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

[vpp-dev] GoVpp different behaviour when compiling outside GoVpp project

2021-03-25 Thread Юрий Иванов

Hi, first of all sorry for such noob question.
I'm need to write go based program utilizing govpp stats-api.
There is official example in library which I've trunk to minimal usable which 
only opens socket:
~/GoVpp/govpp$ cat examples/stats-client/stats_api.go
package main

import (
"log"
"git.fd.io/govpp.git/adapter/statsclient"
"git.fd.io/govpp.git/core"
)

func main() {
var (
client *statsclient.StatsClient
c  *core.StatsConnection
errerror
)

client = statsclient.NewStatsClient("/run/vpp/stats.sock") 
//(*statsSocket)
c, err = core.ConnectStats(client)
if err != nil {
log.Fatalln("Connecting failed:", err)
}
defer c.Disconnect()
}

In case I build it from govpp package with the help of make examples it works, 
but when I've created separete my own project execution fails with error:
$ sudo ./stats
2021/03/25 15:43:01 Connecting failed: stat segment version is not supported: 2 
(minimal version: 1)

What the difference when building the same file from govpp library folder from 
separate project?

You may look all my steps to reproduce problem here 
https://pastebin.com/Lv89BrVk

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

[vpp-dev] FDIO Maintenance - 2021-03-31 1700 UTC to 2200 UTC

2021-03-25 Thread Vanessa Valderrama

*What:*

  * Jenkins (sandbox and production)
  o OS and security updates
  o Upgrade to 2.277.1
  o Plugin updates
  * Nexus
  o OS updates
  o Upgrade to 2.14.20-02
  * Jira
  o OS updates
  o Upgrade to 8.16.0
  * Gerrit
  o OS updates

*When:  *2021-03-31  1700 UTC to 2200  UTC

*Impact:*

Maintenance will require a reboot of each FD.io system. Jenkins will be
placed in shutdown mode at 1600 UTC. Jobs will be terminated at 17:00 UTC.

The following systems will be unavailable during the maintenance window:

  *     Jenkins sandbox
  *     Jenkins production
  *     Nexus
  *     Jira
  *     Gerrit



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

2021-03-25 Thread Vijay Kumar

Hi Neale,

I was able to make a good progress for the GRE-over-IPSec use case. But
stumbled at the last step.
I have explained the problem faced (an extra IP header added by VPP,
overall 4 IP headers in the pkt) and other details about logs and
configuration below. Also attached the decrypted pcap (frame 4 shows the
problem)

Kindly let me know if you can catch the problem at the VPP side.

*Topology*
**
Strongswan  <>  VPP
loopback 7.7.7.7
   loopback 8.8.8.8
GRE  44.44.44.44
GRE src 42.42.42.42 (tunnel remote 44.44.44.44)
IPSEC20.20.99.215
IPSEC 20.20.99.99


  create gre tunnel src 42.42.42.42 instance 1
multipoint

  set interface state gre1 up

  set interface ip addr gre1 2.2.2.2/32

  create teib gre1 peer 2.2.2.1 nh 44.44.44.44


  ip route add 7.7.7.7/32 via 2.2.2.1 gre1 (added route
to the overlay 7.7.7.7 of SS)


  /* added below commands after IPSec is UP */

  set interface state ipip0 up

  ip route add 44.44.44.44/32 via ipip0

  set interface unnumbered ipip0 use
VirtualFuncEthernet0/7/0.1556

Problem faced
==
--- SS sends ICMP over GRE over IPSEC. The VPP also replies with
ICMP-o-GRE-o-IPSEC. But the SS was dropping the packets. Debugging the SS
logs did not show any decryption failure. I decrypted the packets captured
at SS. On applying the encrytion and auth keys in the wireshark, it
was showing an extra IP header added to the reply packet making it a total
of 4 IP headers which is wrong

--- I observed that VPP had added GRE tunnel IP header on top of the inner
most packet. Again on top of the GRE IP header, another IP was added by VPP
with SRC and DST being same as that of IPSec tunnel header
(20.20.99.99-to-20.20.99.215). Now on top of this extra IP header
the ESP encapsulation was added with outermost IP header IPs of that of the
IPSec tunnel (20.20.99.99-to-20.20.99.215)

--- Why is VPP adding an extra header on top of GRE IP header. Is this
because of the route adjacencies that has gone bad causing an extra IP
header to be added?

--- Below I have pasted the FIB entry for the destination 7.7.7.7 that are
stacked on FIB entry 73 and 75

--- Attached IPSec decoded pcap, please check frame 4 that is the ICMP
reply from VPP to SS

--- Is there anything wrong in the way I have added routes on the VPP side
for the overlay 7.7.7.7 and GRE destination 44.44.44.44


Ping on SS

root@SS# ping 8.8.8.8 -I 7.7.7.7 -c 3
PING 8.8.8.8 (8.8.8.8) from 7.7.7.7 : 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2041ms


TCPDUMP taken on SS
===
12:46:48.439122 IP vmsrvrlnx-strongswan-215 > dns.google: ICMP echo
request, id 43, seq 1, length 64
12:46:48.439174 IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
ESP(spi=0x1234567b,seq=0x1), length 148
12:46:48.439178 ethertype IPv4, IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
ESP(spi=0x1234567b,seq=0x1), length 148
12:46:48.439487 ethertype IPv4, IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
ESP(spi=0xce90b744,seq=0x1), length 180
12:46:48.439487 IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
ESP(spi=0xce90b744,seq=0x1), length 180
12:46:49.455775 IP vmsrvrlnx-strongswan-215 > dns.google: ICMP echo
request, id 43, seq 2, length 64
12:46:49.455826 IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
ESP(spi=0x1234567b,seq=0x2), length 148
12:46:49.455831 ethertype IPv4, IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
ESP(spi=0x1234567b,seq=0x2), length 148
12:46:49.455958 ethertype IPv4, IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
ESP(spi=0xce90b744,seq=0x2), length 180
12:46:49.455958 IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
ESP(spi=0xce90b744,seq=0x2), length 180
12:46:50.479872 IP vmsrvrlnx-strongswan-215 > dns.google: ICMP echo
request, id 43, seq 3, length 64
12:46:50.479933 IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
ESP(spi=0x1234567b,seq=0x3), length 148
12:46:50.479939 ethertype IPv4, IP vmsrvrlnx-strongswan-215 > 20.20.99.99:
ESP(spi=0x1234567b,seq=0x3), length 148
12:46:50.480080 ethertype IPv4, IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
ESP(spi=0xce90b744,seq=0x3), length 180
12:46:50.480080 IP 20.20.99.99 > vmsrvrlnx-strongswan-215:
ESP(spi=0xce90b744,seq=0x3), length 180



VPP LOGS
=
vpp# show gre tunnel
[0] instance 1 src 42.42.42.42 dst 0.0.0.0 fib-idx 0 sw-if-idx 20 payload
L3 multi-point

vpp# show teib
[0] gre1:2.2.2.1 via [0]:44.44.44.44/32

vpp# show ipip tunnel
[0] instance 0 src 20.20.99.99 dst 20.20.99.215 table-ID 0 sw-if-idx 21
flags [none] dscp CS0

FIB ouput of loopback IPs and GRE tunnel IPs shown in topology
=
7.7.7.7/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:75 buckets:1 uRPF:105 to:[0:0]]
[0

[vpp-dev] vpp main thread crashed at mspace_put

2021-03-25 Thread Sudhir CR via lists.fd.io

Hi All,
We have loaded our box with internet feed routes. Initially everything is
good.
But after *three hours* we observed a *vpp main thread crashed* due to
*segmentation
error *at mspace_put function.

#28 0x7f0f802c0793 in unix_signal_handler (signum=11,
si=0x7f0f33c086b0, uc=0x7f0f33c08580)
at /development/libvpp/src/vlib/unix/main.c:127
#29 
#30 __memset_avx2_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:145
#31 0x7f0f7fa67735 in mspace_put (msp=0x130044010,
p_arg=0x130089a48) at /development/libvpp/src/vppinfra/dlmalloc.c:4316

We are using *20.09 version* and the complete* backtrace *is  pasted
below. Any help in fixing the issue would be appreciated.

Thread 3 (Thread 0x7f0eccbfe700 (LWP 476)):
#0  0x7f0f8023cff7 in vlib_worker_thread_barrier_check () at
/development/libvpp/src/vlib/threads.h:438
#1  0x7f0f8023751e in vlib_main_or_worker_loop (vm=0x7f0f652dd300,
is_main=0) at /development/libvpp/src/vlib/main.c:1788
#2  0x7f0f80236d37 in vlib_worker_loop (vm=0x7f0f652dd300) at
/development/libvpp/src/vlib/main.c:2008
#3  0x7f0f8028e91a in vlib_worker_thread_fn (arg=0x7f0f4a974940)
at /development/libvpp/src/vlib/threads.c:1862
#4  0x7f0f7fab5c34 in clib_calljmp () at
/development/libvpp/src/vppinfra/longjmp.S:123
#5  0x7f0eccbfdec0 in ?? ()

[58/393]
#6  0x7f0f80286ac3 in vlib_worker_thread_bootstrap_fn
(arg=0x7f0f4a974940) at /development/libvpp/src/vlib/threads.c:585
---Type  to continue, or q  to quit---
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 0x7f0ecd3ff700 (LWP 475)):
#0  0x7f0f8023cfec in vlib_worker_thread_barrier_check () at
/development/libvpp/src/vlib/threads.h:438
#1  0x7f0f8023751e in vlib_main_or_worker_loop (vm=0x7f0f64d99ec0,
is_main=0) at /development/libvpp/src/vlib/main.c:1788
#2  0x7f0f80236d37 in vlib_worker_loop (vm=0x7f0f64d99ec0) at
/development/libvpp/src/vlib/main.c:2008
#3  0x7f0f8028e91a in vlib_worker_thread_fn (arg=0x7f0f4a974840)
at /development/libvpp/src/vlib/threads.c:1862
#4  0x7f0f7fab5c34 in clib_calljmp () at
/development/libvpp/src/vppinfra/longjmp.S:123
#5  0x7f0ecd3feec0 in ?? ()
#6  0x7f0f80286ac3 in vlib_worker_thread_bootstrap_fn
(arg=0x7f0f4a974840) at /development/libvpp/src/vlib/threads.c:585
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 0x7f0f8d076d00 (LWP 280)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7f0f8c0d3921 in __GI_abort () at abort.c:79
#2  0x7f0f81cbd253 in os_panic () at
/development/libvpp/src/vpp/vnet/main.c:572
#3  0x7f0f7fa91aa9 in debugger () at
/development/libvpp/src/vppinfra/error.c:84
#4  0x7f0f7fa91827 in _clib_error (how_to_die=2,
function_name=0x0, line_number=0, fmt=0x7f0f7fb613df "%s:%d (%s)
assertion `%s' fails")
at /development/libvpp/src/vppinfra/error.c:143
#5  0x7f0f7fa98e61 in _vec_resize_inline (v=0x7f0f4a69fa90,
length_increment=16, data_bytes=16, header_bytes=0, data_align=1,
numa_id=255) at /development/libvpp/src/vppinfra/vec.h:154
#6  0x7f0f7fa98b8b in va_format (s=0x7f0f4a69fa90 "",
fmt=0x7f0f802dbf1b "received signal %U, PC %U", va=0x7f0f33c065f0)
at /development/libvpp/src/vppinfra/format.c:403
#7  0x7f0f7faa03c6 in format (s=0x7f0f4a69fa90 "",
fmt=0x7f0f802dbf1b "received signal %U, PC %U")
at /development/libvpp/src/vppinfra/format.c:428
#8  0x7f0f802c0793 in unix_signal_handler (signum=6,
si=0x7f0f33c068b0, uc=0x7f0f33c06780)
at /development/libvpp/src/vlib/unix/main.c:127
#9  
#10 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#11 0x7f0f8c0d3921 in __GI_abort () at abort.c:79
#12 0x7f0f81cbd253 in os_panic () at
/development/libvpp/src/vpp/vnet/main.c:572
#13 0x7f0f7fa91aa9 in debugger () at
/development/libvpp/src/vppinfra/error.c:84
#14 0x7f0f7fa91827 in _clib_error (how_to_die=2,
function_name=0x0, line_number=0, fmt=0x7f0f7fb613df "%s:%d (%s)
assertion `%s' f[23/393]
at /development/libvpp/src/vppinfra/error.c:143
---Type  to continue, or q  to quit---
#15 0x7f0f7fa98e61 in _vec_resize_inline (v=0x7f0f4a69fa90,
length_increment=16, data_bytes=16, header_bytes=0, data_align=1,
numa_id=255) at /development/libvpp/src/vppinfra/vec.h:154
#16 0x7f0f7fa98b8b in va_format (s=0x7f0f4a69fa90 "",
fmt=0x7f0f802dbf1b "received signal %U, PC %U", va=0x7f0f33c074f0)
at /development/libvpp/src/vppinfra/format.c:403
#17 0x7f0f7faa03c6 in format (s=0x7f0f4a69fa90 "",
fmt=0x7f0f802dbf1b "received signal %U, PC %U")
at /development/libvpp/src/vppinfra/format.c:428
#18 0x7f0f802c0793 in unix_signal_handler (signum=6,
si=0x7f0f33c077b0, uc=0x7f0f33c07680)
at /development/libvpp/src/vlib/unix/main.c:127
#19 
#20 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#21 0x7f0f8c0d3921 in __GI_abort () at abort.c:79
#22 0x7f0f81cbd253 in os_panic () at
/developme

[vpp-dev] side effects of not using vlib_get_next_frame and put_frame in packet processing

2021-03-25 Thread Satya Murthy

Hi ,

A basic doubt on the VPP packet processing loop.

Typically, we see the packet processing loop as:

while(n_left_from > 0)
{
get_next_frame
quad-loop
single-loop
put_next_frame
}

>From the code, I could not fully understand if it is mandatory to have the 
>outerloop or not.
Even when I do directly do  the quad-loop and single-loop and not use the 
get-next and put-next-frames, it is working fine.
What is the side effect of not using get-next-frame and put-next-frame macros 
and avoiding the outer loop.
Any inputs on this would be really helpful.

--
Thanks & Regards,
Murthy

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

2021-03-25 Thread Andrew Yourtchenko

Hi Klement,

This is very cool! Thanks a lot for doing it!

--a

> On 25 Mar 2021, at 10:29, Klement Sekera via lists.fd.io 
>  wrote:
> 
> Hi all,
> 
> I’ve introduced a new checkstyle target, which should ease development. This 
> one does a similar thing as test-checkstyle, but only on changed files. This 
> is useful for local verification as it’s a bit faster and doesn’t pollute 
> your screen with messages about checking unchanged files.
> 
> I kept semantics of test-checkstyle without change as in gerrit it doesn’t 
> matter if it’s 30 seconds longer and to catch other types of failures - for 
> example a tool change, which might not modify any python file, but could 
> result in a diff and failure.
> 
> Regards,
> Klement
> 
> 

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

[vpp-dev] make test-checkstyle-diff

2021-03-25 Thread Klement Sekera via lists.fd.io

Hi all,

I’ve introduced a new checkstyle target, which should ease development. This 
one does a similar thing as test-checkstyle, but only on changed files. This is 
useful for local verification as it’s a bit faster and doesn’t pollute your 
screen with messages about checking unchanged files.

I kept semantics of test-checkstyle without change as in gerrit it doesn’t 
matter if it’s 30 seconds longer and to catch other types of failures - for 
example a tool change, which might not modify any python file, but could result 
in a diff and failure.

Regards,
Klement
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19015): https://lists.fd.io/g/vpp-dev/message/19015
Mute This Topic: https://lists.fd.io/mt/81598070/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 main thread crashed at mspace_put

Re: [vpp-dev] GRE-over-IPSec fails

Re: [vpp-dev] keeping tests outside of src/

Re: [vpp-dev] keeping tests outside of src/

Re: [vpp-dev] keeping tests outside of src/

Re: [vpp-dev] VPP 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code

[vpp-dev] keeping tests outside of src/

Re: [vpp-dev] make test-checkstyle-diff

Re: [vpp-dev] GoVpp different behaviour when compiling outside GoVpp project

Re: [vpp-dev] GoVpp different behaviour when compiling outside GoVpp project

Re: [vpp-dev] VPP 20.09 os_out_of_memory() in clib_bihash_add_del_16_8 in IPv4 Shallow Virtual reassembly code

[vpp-dev] GoVpp different behaviour when compiling outside GoVpp project

[vpp-dev] FDIO Maintenance - 2021-03-31 1700 UTC to 2200 UTC

Re: [vpp-dev] GRE-over-IPSec fails

[vpp-dev] vpp main thread crashed at mspace_put

[vpp-dev] side effects of not using vlib_get_next_frame and put_frame in packet processing

Re: [vpp-dev] make test-checkstyle-diff

[vpp-dev] make test-checkstyle-diff

18 matches

Site Navigation

Mail list logo

Footer information