[vpp-dev] Forwarding packet from kernel interface to VPP srv6 policy

[Chinmaya Aggarwal]

Hi,
We have a use case where on a VPP machine, we want to generate ping request 
from kernel, which is then forwarded to VPP and then according to the policy 
configured, VPP add SRH into it and act on that packet accordingly.
Can anyone please suggest how we can can achieve this?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16351): https://lists.fd.io/g/vpp-dev/message/16351
Mute This Topic: https://lists.fd.io/mt/74175816/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] Chelsio CXGBE crash on startup #dpdk

[Mohammed Alshohayeb]

Hi Benoit,

Here ( https://drive.google.com/open?id=1ZRJ-ZMuRLYMXBZxYiVBbbU7GZjdNKE0d ) are 
the artifacts (with another coredump for style)

And here is the testpmd output (dpdk-19.08)

./testpmd -w :af:00.4 -- -i
testpmd> show port info all
PMD: rte_cxgbe_pmd: Port0: passive DA port module inserted
PMD: rte_cxgbe_pmd: Port1: passive DA port module inserted
* Infos for port 0  *
MAC address: 00:07:43:4A:93:50
Device name: :af:00.4
Driver name: net_cxgbe
Devargs:
Connect to socket: 1
memory allocation on the socket: 1
Link status: up
Link speed: 10 Mbps
Link duplex: full-duplex
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 1
Maximum number of MAC addresses of hash filtering: 0
VLAN offload:
strip off
filter off
qinq(extend) off
Hash key size in bytes: 40
Redirection table size: 32
Supported RSS offload flow types:
ipv4
ipv4-frag
ipv4-tcp
ipv4-udp
ipv4-other
ipv6
ipv6-frag
ipv6-tcp
ipv6-udp
ipv6-other
user defined 15
user defined 16
user defined 17
Minimum size of RX buffer: 68
Maximum configurable length of RX packet: 9018
Maximum number of VFs: 256
Current number of RX queues: 1
Max possible RX queues: 32
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 128
RXDs number alignment: 1
Current number of TX queues: 1
Max possible TX queues: 32
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 128
TXDs number alignment: 1
Max segment number per packet: 0
Max segment number per MTU/TSO: 0

* Infos for port 1  *
MAC address: 00:07:43:4A:93:58
Device name: :af:00.4_1
Driver name: net_cxgbe
Devargs:
Connect to socket: 1
memory allocation on the socket: 1
Link status: up
Link speed: 10 Mbps
Link duplex: full-duplex
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 1
Maximum number of MAC addresses of hash filtering: 0
VLAN offload:
strip off
filter off
qinq(extend) off
Hash key size in bytes: 40
Redirection table size: 32
Supported RSS offload flow types:
ipv4
ipv4-frag
ipv4-tcp
ipv4-udp
ipv4-other
ipv6
ipv6-frag
ipv6-tcp
ipv6-udp
ipv6-other
user defined 15
user defined 16
user defined 17
Minimum size of RX buffer: 68
Maximum configurable length of RX packet: 9018
Maximum number of VFs: 256
Current number of RX queues: 1
Max possible RX queues: 32
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 128
RXDs number alignment: 1
Current number of TX queues: 1
Max possible TX queues: 32
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 128
TXDs number alignment: 1
Max segment number per packet: 0
Max segment number per MTU/TSO: 0
testpmd>

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

View/Reply Online (#16350): https://lists.fd.io/g/vpp-dev/message/16350
Mute This Topic: https://lists.fd.io/mt/74113417/21656
Mute #dpdk: https://lists.fd.io/mk?hashtag=dpdk=1480452
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-2001 update: Xeon Skylake Performance and Progressions/Regressions RCAs

[Maciek Konstantynowicz (mkonstan) via lists.fd.io]

Slides used on today’s VPP call: 
https://wiki.fd.io/view/File:200512-csit-vpp-readout.pptx

> On 12 May 2020, at 15:18, Maciek Konstantynowicz (mkonstan) 
>  wrote:
> 
> Dear All,
> 
> We have finally pushed out an update to CSIT-2001 report with VPP
> performance data for testbeds with Intel Xeon Skylake processors (2n-skx
> and 3n-skx testbeds), with SUT and TG servers impacted by firmware and
> OS upgrades (BIOS, ucode, kernel updates with mitigations against the
> newly discovered Spectre-Meltdown security vulnerabilities).
> 
> The updated CSIT-2001 report should be available for browsing just
> before 15:00 UTC today, subject to Jenkins job execution (will have
> updated version timestamp):
> 
>https://docs.fd.io/csit/rls2001/report/
>
> https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/csit_release_notes.html
> 
> In addition to 2n-skx and 3n-skx performance data available at the usual
> locations in the report (see links [r1] to [r4] referenced below), we
> have expanded the way we do VPP release-to-release comparisons and root
> cause analysis (RCA) for any identified performance progressions and
> regressions:
> 
>- CSIT test environment is now versioned, with ver. 1 associated
>  with CSIT rls1908 git branch as of 2019-08-21, and ver. 2
>  associated with CSIT master and rls2001 git branches as of
>  2020-03-27.
> 
>- To identify SUT performance change(s) due to CSIT test environment
>  change(s) from ver. 1 to ver. 2, VPP v19.08.1 has been re-tested
>  in ver. 2 and results compared against the past data obtained with
>  ver. 1. RCA1 analysis has been applied to this part. See [r5].
> 
>- To identify SUT performance change(s) due to VPP code change(s)
>  from v19.08.1 to v20.01.0, both VPP versions have been tested in
>  CSIT environment ver. 2 and results compared. Separate RCA2
>  analysis has been applied to this part. See [r5].
> 
>- At this stage RCA1 and RCA2 analyses are focusing on progressions > +5%
>  and regressions < -5%.
> 
> Attached pasted complete list of RCAs identified as part of this
> exercise [1] to [12].
> 
> Hope it makes sense. For any questions and comments please contact
> csit-...@lists.fd.io.
> 
> Regards,
> Maciek
> (on behalf of FD.io CSIT team)
> 
> 
> Specific links within the report:
> 
> [r1] VPP throughput graphs,
> 
> https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/index.html
> 
> [r2] VPP throughput speedup multi-core,
> 
> https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/throughput_speedup_multi_core/ip4-2n-skx-xxv710.html
> 
> [r3] VPP packet latency,
> 
> https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_latency/index.html
> 
> [r4] VPP soak tests,
> 
> https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/soak_tests/index.html
> 
> [r5] 2n-skx PDR comparison with RCA,
> 
> https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#n-skx
> 
> [r6] 3n-skx PDR comparison with RCA,
> 
> https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#id1
> 
> RCA1:
> 
> [1] DONE, Impact of upgrades: i) Skx ucode from 0x243 to 0x265,
>[ii) Linux kernel from 4.15.0-60 to 4.15.0-72 and iii) SuperMicro
>[motherboard BIOS from 3.0c to 3.2.
> 
> [2] DONE, Applied fix of FVL NIC firmware 6.0.1 for increasing TRex pps
>rate from 27 Mpps to 37 Mpps, [CSIT-1503], [TRex-519].
> 
> [3] DONE, Applied VPP PAPI fix to enable memif zero-copy, [CSIT-1592],
>[VPP-1764].
> 
> [4] OPEN, Higher than before StDev of PDR throughput for VPP vhost-user
>with VPP-inside-VM, under investigation, [CSIT-1699], [CSIT-1704].
> 
> RCA2:
> 
> [5] OPEN, dot1q-l2xcbase progression, retro-inspection of weekly ndrpdr
>tests points to ge-22805, automated bisect script does not work
>due to frequent API changes, [CSIT-1699], [CSIT-1705].
> 
> [6] DONE, ip4base-nat44 regression, ge-23963
>(https://gerrit.fd.io/r/c/vpp/+/23963#message-044278e6_752c3327).
> 
> [7] WIP, avf-ip4scale regression, CANDIDATE(S) before ge-22699, [
>CSIT-1699], [CSIT-1706].
> 
> [8] OPEN, VPP vhost-user with VPP-inside-VM higher than before stdev
>of PDR throughput, under investigation, [CSIT-1699], [CSIT-1704].
> 
> [9] WIP, vhost-user with testpmd-in-VM progression, CANDIDATE(S)
>before 22277, [CSIT-1699], [CSIT-1707].
> 
> [10] WIP, avf-ip4base regression, CANDIDATE(S) range
> ge-18361..ge-24505, [CSIT-1699], [CSIT-1708].
> 
> [11] DONE, memif regression, CANDIDATE(S) confirmed ge-23801.
> 
> [12] WIP, ipsec tnl sw scale regression, CANDIDATE(S) before ge-23557,
> [CSIT-1699], [CSIT-1712].

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

View/Reply Online (#16349): https://lists.fd.io/g/vpp-dev/message/16349
Mute This Topic: https://lists.fd.io/mt/74159188/21656
Group 

Re: [vpp-dev] pppoe plugin + vlan

[Stanislav Zaikin]

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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Chelsio CXGBE crash on startup #dpdk

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

Hi Mohammed,

> I've uploaded the coredump here  UDt_W-AXwHePaq1O03ubhmPheVJ>

I need the build artifacts too - content of 
./build-root/install-vpp_debug-native/ .

> Are there any venues I might explore that might be causing the issue?

Can you share the output of testpmd 'show port info all'? See 
https://doc.dpdk.org/guides/testpmd_app_ug/testpmd_funcs.html#show-port

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

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

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Ole Troan]

Alexander,

Is your use case list all sessions matching x rather than list all sessions 
with sa==n?

Cheers 
Ole

> On 12 May 2020, at 16:28, Klement Sekera via lists.fd.io 
>  wrote:
> 
> ED NAT no longer has “user” concept and it doesn’t differentiate one session 
> from another. (So technically the API works just fine). Even if we wanted to 
> recreate that information it means to build a hash of “users” on the fly for 
> API purpose, do the dump and then throw it away. I don’t see any other way to 
> guarantee that there are no duplicates in the dump even if we didn’t care for 
> numbers like number of sessions or so…
> 
> Thanks,
> Klement
> 
>> On 12 May 2020, at 15:56, Alexander Chernavin via lists.fd.io 
>>  wrote:
>> 
>> Klement,
>> 
>> I would prefer the existing API working.
>> 
>> I expect millions of sessions and it's clear that dumping them all is a 
>> blocker but during debug, there are not so many of them.
>> 
>> Thanks,
>> Alexander 
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16346): https://lists.fd.io/g/vpp-dev/message/16346
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Klement Sekera via lists.fd.io]

ED NAT no longer has “user” concept and it doesn’t differentiate one session 
from another. (So technically the API works just fine). Even if we wanted to 
recreate that information it means to build a hash of “users” on the fly for 
API purpose, do the dump and then throw it away. I don’t see any other way to 
guarantee that there are no duplicates in the dump even if we didn’t care for 
numbers like number of sessions or so…

Thanks,
Klement

> On 12 May 2020, at 15:56, Alexander Chernavin via lists.fd.io 
>  wrote:
> 
> Klement,
> 
> I would prefer the existing API working.
> 
> I expect millions of sessions and it's clear that dumping them all is a 
> blocker but during debug, there are not so many of them.
> 
> Thanks,
> Alexander 

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

View/Reply Online (#16345): https://lists.fd.io/g/vpp-dev/message/16345
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Chelsio CXGBE crash on startup #dpdk

[Mohammed Alshohayeb]

Hi Benoit,

Yes, testpmd works perfectly well.

I've uploaded the coredump here ( 
https://drive.google.com/open?id=12sIi-UDt_W-AXwHePaq1O03ubhmPheVJ )

Version:                  v20.01-release
Compiled by:              root
Compile host:             pb
Compile date:             2020-05-11T12:33:39
Compile location:         /opt/vpp-src/vpp
Compiler:                 GCC 7.3.1 20180303 (Red Hat 7.3.1-5)
Current PID:              60547
Command line arguments:
./build-root/install-vpp_debug-native/vpp/bin/vpp
unix { interactive } dpdk { dev :af:00.4 }

Are there any venues I might explore that might be causing the issue?

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

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

[vpp-dev] CSIT-2001 update: Xeon Skylake Performance and Progressions/Regressions RCAs

[Maciek Konstantynowicz (mkonstan) via lists.fd.io]

Dear All,

We have finally pushed out an update to CSIT-2001 report with VPP
performance data for testbeds with Intel Xeon Skylake processors (2n-skx
and 3n-skx testbeds), with SUT and TG servers impacted by firmware and
OS upgrades (BIOS, ucode, kernel updates with mitigations against the
newly discovered Spectre-Meltdown security vulnerabilities).

The updated CSIT-2001 report should be available for browsing just
before 15:00 UTC today, subject to Jenkins job execution (will have
updated version timestamp):

https://docs.fd.io/csit/rls2001/report/

https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/csit_release_notes.html

In addition to 2n-skx and 3n-skx performance data available at the usual
locations in the report (see links [r1] to [r4] referenced below), we
have expanded the way we do VPP release-to-release comparisons and root
cause analysis (RCA) for any identified performance progressions and
regressions:

- CSIT test environment is now versioned, with ver. 1 associated
  with CSIT rls1908 git branch as of 2019-08-21, and ver. 2
  associated with CSIT master and rls2001 git branches as of
  2020-03-27.

- To identify SUT performance change(s) due to CSIT test environment
  change(s) from ver. 1 to ver. 2, VPP v19.08.1 has been re-tested
  in ver. 2 and results compared against the past data obtained with
  ver. 1. RCA1 analysis has been applied to this part. See [r5].

- To identify SUT performance change(s) due to VPP code change(s)
  from v19.08.1 to v20.01.0, both VPP versions have been tested in
  CSIT environment ver. 2 and results compared. Separate RCA2
  analysis has been applied to this part. See [r5].

- At this stage RCA1 and RCA2 analyses are focusing on progressions > +5%
  and regressions < -5%.

Attached pasted complete list of RCAs identified as part of this
exercise [1] to [12].

Hope it makes sense. For any questions and comments please contact
csit-...@lists.fd.io.

Regards,
Maciek
(on behalf of FD.io CSIT team)


Specific links within the report:

[r1] VPP throughput graphs,
 
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/index.html

[r2] VPP throughput speedup multi-core,
 
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/throughput_speedup_multi_core/ip4-2n-skx-xxv710.html

[r3] VPP packet latency,
 
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_latency/index.html

[r4] VPP soak tests,
 
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/soak_tests/index.html

[r5] 2n-skx PDR comparison with RCA,
 
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#n-skx

[r6] 3n-skx PDR comparison with RCA,
 
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#id1

RCA1:

[1] DONE, Impact of upgrades: i) Skx ucode from 0x243 to 0x265,
[ii) Linux kernel from 4.15.0-60 to 4.15.0-72 and iii) SuperMicro
[motherboard BIOS from 3.0c to 3.2.

[2] DONE, Applied fix of FVL NIC firmware 6.0.1 for increasing TRex pps
rate from 27 Mpps to 37 Mpps, [CSIT-1503], [TRex-519].

[3] DONE, Applied VPP PAPI fix to enable memif zero-copy, [CSIT-1592],
[VPP-1764].

[4] OPEN, Higher than before StDev of PDR throughput for VPP vhost-user
with VPP-inside-VM, under investigation, [CSIT-1699], [CSIT-1704].

RCA2:

[5] OPEN, dot1q-l2xcbase progression, retro-inspection of weekly ndrpdr
tests points to ge-22805, automated bisect script does not work
due to frequent API changes, [CSIT-1699], [CSIT-1705].

[6] DONE, ip4base-nat44 regression, ge-23963
(https://gerrit.fd.io/r/c/vpp/+/23963#message-044278e6_752c3327).

[7] WIP, avf-ip4scale regression, CANDIDATE(S) before ge-22699, [
CSIT-1699], [CSIT-1706].

[8] OPEN, VPP vhost-user with VPP-inside-VM higher than before stdev
of PDR throughput, under investigation, [CSIT-1699], [CSIT-1704].

[9] WIP, vhost-user with testpmd-in-VM progression, CANDIDATE(S)
before 22277, [CSIT-1699], [CSIT-1707].

[10] WIP, avf-ip4base regression, CANDIDATE(S) range
 ge-18361..ge-24505, [CSIT-1699], [CSIT-1708].

[11] DONE, memif regression, CANDIDATE(S) confirmed ge-23801.

[12] WIP, ipsec tnl sw scale regression, CANDIDATE(S) before ge-23557,
 [CSIT-1699], [CSIT-1712].-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Alexander Chernavin via lists.fd.io]

Klement,

I would prefer the existing API working.

I expect millions of sessions and it's clear that dumping them all is a blocker 
but during debug, there are not so many of them.

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

View/Reply Online (#16342): https://lists.fd.io/g/vpp-dev/message/16342
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] min_log2 abuse

[Dave Barach via lists.fd.io]

Thanks for the patch. Anyway your code reads much more easily than the 
original. [Jenkins is screwed up at the moment, Dave Wallace is working on it.]

We could do something like this to track down min_log2(0) calls:

#if defined (count_leading_zeros)
always_inline uword
min_log2 (uword x)
{
  uword n;

#if CLIB_DEBUG > 0
  if (x == 0) abort();
#endif
  n = count_leading_zeros (x);
  return BITS (uword) - n - 1;
}
#else
... obvious variation ...
#undef _

From: vpp-dev@lists.fd.io  On Behalf Of Andreas Schultz
Sent: Tuesday, May 12, 2020 8:51 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev 
Subject: Re: [vpp-dev] min_log2 abuse



Am Di., 12. Mai 2020 um 13:17 Uhr schrieb Dave Barach (dbarach) 
mailto:dbar...@cisco.com>>:
Dear Andreas,

Do you have a handy list of places which convert netmasks to lengths? 
Regardless of what one might do with min_log2, we ought to clean up those 
places in time for the 20.05 release (if possible).

Unfortunately not.

This is the code that caused problems for us: 
https://gerrit.fd.io/r/c/vpp/+/27016

Grepping through the code shows additional places that appear to have the 
potential to pass a 0 to one of the log2 functions. But we haven't investigated 
any of them closer.

I was trying to add an ASSERT (x != 0) to the log2 functions. But those 
functions are defined in clib.h, and that header is required by 
error_bootstrap.h that defines ASSERTs. The resulting include dependency loop 
is only solvable by moving the log2 functions out of clib.h

Andreas

Dave

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andreas Schultz
Sent: Tuesday, May 12, 2020 5:42 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] min_log2 abuse

Hi,

There are few places in VPP (most notable when trying to convert a netmask into 
a length) that can pass 0 (zero) into min_log2 and expect to get a meaningful 
result.

Obviously log2(0) is undefined. It turns out that this also applies to the 
return of min_log2. Under the hood the function uses __builtin_clzl, and the 
return of that function is also undefined for input 0.

 __builtin_clzl  could be replaced with __builtin_ia32_lzcnt_u64 on supported 
CPUs to avoid the undefined behaviour. That would still not fix the problem 
that passing 0 into a log function is broken by design.

Any comments?
Andreas

--

Andreas Schultz


--

Andreas Schultz

--

Principal Engineer

t: +49 391 819099-224

--- enabling your networks 
-

Travelping GmbH
Roentgenstraße 13
39108 Magdeburg
Germany

t: +49 391 819099-0
f: +49 391 819099-299

e: i...@travelping.com
w: https://www.travelping.com/
Company registration: Amtsgericht Stendal
Geschaeftsfuehrer: Holger Winkelmann
Reg. No.: HRB 10578
VAT ID: DE236673780

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

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

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Klement Sekera via lists.fd.io]

Alexander,

It seems that fixing existing API is a huge pain. What we could do is implement 
an API which dumps all the sessions and the client app could sort it out. How 
many sessions do you typically have? As by default APIs run in a stop-the-world 
state, having millions of sessions will stop all the forwarding until the dump 
is complete. Writing it in a thread-safe way is a more complicated effort…

Thanks,
Klement

> On 12 May 2020, at 14:10, Alexander Chernavin via lists.fd.io 
>  wrote:
> 
> Klement,
> 
> Basically print statistics and debug info: number of users, what user 
> consumes what number of sessions, what session created for what communication.
> 
> Thanks,
> Alexander 

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

View/Reply Online (#16340): https://lists.fd.io/g/vpp-dev/message/16340
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
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 ip6 neighbor" not working on VPP v20.01

[Neale Ranns via lists.fd.io]

“set ip neighbor …”

/neale

From:  on behalf of Chinmaya Aggarwal 

Date: Tuesday 12 May 2020 at 14:43
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] "set ip6 neighbor" not working on VPP v20.01

Hi,
We have installed VPP v20.01 on a Centos machine, on executing command: -
vpp# set ip6 neighbor GigabitEthernet0/a/0 2001:5b0:abcd::121 52:54:00:98:29:e0
set ip6: unknown input `neighbor GigabitEthernet0/a/0 ...'
Error is  encountered. On checking the possible commands with "set ip6", we 
found: -
vpp# set ip6 ?
  set ip6 address  set ip6 address  [prefix 
group ]  [del]
  set ip6 classify set ip6 classify intfc  
table-index 
  set ip6 flow-hashset ip6 flow-hash table  
[src] [dst] [sport] [dport] [proto] [reverse]
  set ip6 nd proxy set ip6 nd proxy  
Neighbor is not present. Whereas, executing same on VPP v19.08 gives : -
vpp# set ip6 ?
  set ip6 address  set ip6 address  [prefix 
group ]  [del]
  set ip6 classify set ip6 classify intfc  
table-index 
  set ip6 flow-hashset ip6 flow-hash table  
[src] [dst] [sport] [dport] [proto] [reverse]
  set ip6 nd proxy set ip6 nd proxy  
  set ip6 neighbor set ip6 neighbor [del]  
  [static]
Neighbor option is present.

Does VPP v20.01 does not support "set ip6 neighbor"? If yes, what is the 
alternative for this?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16339): https://lists.fd.io/g/vpp-dev/message/16339
Mute This Topic: https://lists.fd.io/mt/74157335/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] min_log2 abuse

[Andreas Schultz]

Am Di., 12. Mai 2020 um 13:17 Uhr schrieb Dave Barach (dbarach) <
dbar...@cisco.com>:

> Dear Andreas,
>
>
>
> Do you have a handy list of places which convert netmasks to lengths?
> Regardless of what one might do with min_log2, we ought to clean up those
> places in time for the 20.05 release (if possible).
>

Unfortunately not.

This is the code that caused problems for us:
https://gerrit.fd.io/r/c/vpp/+/27016

Grepping through the code shows additional places that appear to have the
potential to pass a 0 to one of the log2 functions. But we haven't
investigated any of them closer.

I was trying to add an ASSERT (x != 0) to the log2 functions. But those
functions are defined in clib.h, and that header is required by
error_bootstrap.h that defines ASSERTs. The resulting include dependency
loop is only solvable by moving the log2 functions out of clib.h

Andreas

>
>
> Dave
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Andreas
> Schultz
> *Sent:* Tuesday, May 12, 2020 5:42 AM
> *To:* vpp-dev 
> *Subject:* [vpp-dev] min_log2 abuse
>
>
>
> Hi,
>
>
>
> There are few places in VPP (most notable when trying to convert a netmask
> into a length) that can pass 0 (zero) into min_log2 and expect to get a
> meaningful result.
>
>
>
> Obviously log2(0) is undefined. It turns out that this also applies to the
> return of min_log2. Under the hood the function uses __builtin_clzl, and
> the return of that function is also undefined for input 0.
>
>
>
>  __builtin_clzl  could be replaced with __builtin_ia32_lzcnt_u64 on
> supported CPUs to avoid the undefined behaviour. That would still not fix
> the problem that passing 0 into a log function is broken by design.
>
>
>
> Any comments?
>
> Andreas
>
>
>
> --
>
> Andreas Schultz
>


-- 

Andreas Schultz

-- 

Principal Engineer

t: +49 391 819099-224

--- enabling your networks
-

Travelping GmbH
Roentgenstraße 13
39108 Magdeburg
Germany

t: +49 391 819099-0
f: +49 391 819099-299

e: i...@travelping.com
w: https://www.travelping.com/
Company registration: Amtsgericht Stendal
Geschaeftsfuehrer: Holger Winkelmann
Reg. No.: HRB 10578
VAT ID: DE236673780
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16338): https://lists.fd.io/g/vpp-dev/message/16338
Mute This Topic: https://lists.fd.io/mt/74155196/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] min_log2 abuse

[Damjan Marion via lists.fd.io]

> On 12 May 2020, at 14:37, Andreas Schultz  
> wrote:
> 
> 
> Am Di., 12. Mai 2020 um 13:53 Uhr schrieb Damjan Marion  >:
> 
> 
> > On 12 May 2020, at 11:41, Andreas Schultz  > > wrote:
> > 
> > Hi,
> > 
> > There are few places in VPP (most notable when trying to convert a netmask 
> > into a length) that can pass 0 (zero) into min_log2 and expect to get a 
> > meaningful result.
> > 
> > Obviously log2(0) is undefined. It turns out that this also applies to the 
> > return of min_log2. Under the hood the function uses __builtin_clzl, and 
> > the return of that function is also undefined for input 0.
> > 
> >  __builtin_clzl  could be replaced with __builtin_ia32_lzcnt_u64 on 
> > supported CPUs to avoid the undefined behaviour. That would still not fix 
> > the problem that passing 0 into a log function is broken by design.
> 
> Compiler uses LZCNT for __builtin_clzl when target -march supports it. Today 
> we use -march=corei7 as baseline and that one doesn’t know about LZCNT, so 
> BSR is emitted instead, which indeed have undefined behaviour. In other words 
> replacing __builtin_clzl with __builtin_ia32_lzcnt_u64 will not work, but 
> simply changing baseline -march= to something newer will address that 
> transparently...
> 
> Even using -march doesn't change the fact that  __builtin_clzl is documented 
> to have undefined behavior for zero inputs. Relying on undocumented side 
> effects is IMHO not a good idea. Not to mention that clang and gcc might 
> behave differently.

I was not questioning your statement about undefined behaviour.
I was just saying that your proposal about swapping __builtin_clzl  with 
__builtin_ia32_lzcnt_u64 will not work...

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

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

[vpp-dev] "set ip6 neighbor" not working on VPP v20.01

[Chinmaya Aggarwal]

Hi,
We have installed VPP v20.01 on a Centos machine, on executing command: -
*vpp# set ip6 neighbor GigabitEthernet0/a/0 2001:5b0:abcd::121 
52:54:00:98:29:e0*
*set ip6: unknown input `neighbor GigabitEthernet0/a/0 ...'*
Error is  encountered. On checking the possible commands with "set ip6", we 
found: -
vpp# set ip6 ?
set ip6 address                          set ip6 address  [prefix 
group ]  [del]
set ip6 classify                         set ip6 classify intfc  
table-index 
set ip6 flow-hash                        set ip6 flow-hash table  
[src] [dst] [sport] [dport] [proto] [reverse]
set ip6 nd proxy                         set ip6 nd proxy  
Neighbor is not present. Whereas, executing same on VPP v19.08 gives : -
vpp# set ip6 ?
set ip6 address                          set ip6 address  [prefix 
group ]  [del]
set ip6 classify                         set ip6 classify intfc  
table-index 
set ip6 flow-hash                        set ip6 flow-hash table  
[src] [dst] [sport] [dport] [proto] [reverse]
set ip6 nd proxy                         set ip6 nd proxy  
*set ip6 neighbor                         set ip6 neighbor [del]  
  [static]*
Neighbor option is present.

Does VPP v20.01 does not support "set ip6 neighbor"? If yes, what is the 
alternative for this?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16336): https://lists.fd.io/g/vpp-dev/message/16336
Mute This Topic: https://lists.fd.io/mt/74157335/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] min_log2 abuse

[Andreas Schultz]

Am Di., 12. Mai 2020 um 13:53 Uhr schrieb Damjan Marion :

>
>
> > On 12 May 2020, at 11:41, Andreas Schultz <
> andreas.schu...@travelping.com> wrote:
> >
> > Hi,
> >
> > There are few places in VPP (most notable when trying to convert a
> netmask into a length) that can pass 0 (zero) into min_log2 and expect to
> get a meaningful result.
> >
> > Obviously log2(0) is undefined. It turns out that this also applies to
> the return of min_log2. Under the hood the function uses __builtin_clzl,
> and the return of that function is also undefined for input 0.
> >
> >  __builtin_clzl  could be replaced with __builtin_ia32_lzcnt_u64 on
> supported CPUs to avoid the undefined behaviour. That would still not fix
> the problem that passing 0 into a log function is broken by design.
>
> Compiler uses LZCNT for __builtin_clzl when target -march supports it.
> Today we use -march=corei7 as baseline and that one doesn’t know about
> LZCNT, so BSR is emitted instead, which indeed have undefined behaviour. In
> other words replacing __builtin_clzl with __builtin_ia32_lzcnt_u64 will not
> work, but simply changing baseline -march= to something newer will address
> that transparently...
>

Even using -march doesn't change the fact that  __builtin_clzl is
documented to have undefined behavior for zero inputs. Relying on
undocumented side effects is IMHO not a good idea. Not to mention that
clang and gcc might behave differently.

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

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

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Alexander Chernavin via lists.fd.io]

Klement,

Basically print statistics and debug info: number of users, what user consumes 
what number of sessions, what session created for what communication.

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

View/Reply Online (#16334): https://lists.fd.io/g/vpp-dev/message/16334
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Klement Sekera via lists.fd.io]

Hi Alexander,

Understood. So when you get those sessions, what do you do with them? 

Thanks,
Klement

> On 12 May 2020, at 13:45, Alexander Chernavin via lists.fd.io 
>  wrote:
> 
> Hello Klement,
> 
> I want to list all NAT sessions. In order to do that I used to call 
> VL_API_NAT44_USER_DUMP. After that, I had all users, and I could call 
> VL_API_NAT44_USER_SESSION_DUMP to get sessions for every user.
> 
> Now VL_API_NAT44_USER_DUMP returns nothing in ED mode and I don't know what 
> users are. At the same time, VL_API_NAT44_USER_SESSION_DUMP requires 
> ip_address and vrf_id arguments. So if you don't know users, you cannot get 
> sessions.
> 
> Thanks,
> Alexander 

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

View/Reply Online (#16332): https://lists.fd.io/g/vpp-dev/message/16332
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] min_log2 abuse

[Damjan Marion via lists.fd.io]

> On 12 May 2020, at 11:41, Andreas Schultz  
> wrote:
> 
> Hi,
> 
> There are few places in VPP (most notable when trying to convert a netmask 
> into a length) that can pass 0 (zero) into min_log2 and expect to get a 
> meaningful result.
> 
> Obviously log2(0) is undefined. It turns out that this also applies to the 
> return of min_log2. Under the hood the function uses __builtin_clzl, and the 
> return of that function is also undefined for input 0.
> 
>  __builtin_clzl  could be replaced with __builtin_ia32_lzcnt_u64 on supported 
> CPUs to avoid the undefined behaviour. That would still not fix the problem 
> that passing 0 into a log function is broken by design.

Compiler uses LZCNT for __builtin_clzl when target -march supports it. Today we 
use -march=corei7 as baseline and that one doesn’t know about LZCNT, so BSR is 
emitted instead, which indeed have undefined behaviour. In other words 
replacing __builtin_clzl with __builtin_ia32_lzcnt_u64 will not work, but 
simply changing baseline -march= to something newer will address that 
transparently...




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

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

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Alexander Chernavin via lists.fd.io]

Hello Klement,

I want to list all NAT sessions. In order to do that I used to call 
VL_API_NAT44_USER_DUMP. After that, I had all users, and I could call 
VL_API_NAT44_USER_SESSION_DUMP to get sessions for every user.

Now VL_API_NAT44_USER_DUMP returns nothing in ED mode and I don't know what 
users are. At the same time, VL_API_NAT44_USER_SESSION_DUMP requires ip_address 
and vrf_id arguments. So if you don't know users, you cannot get sessions.

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

View/Reply Online (#16330): https://lists.fd.io/g/vpp-dev/message/16330
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] NAT ED empty users dump #nat #nat44

[Klement Sekera via lists.fd.io]

Hi Alexander,

thanks for your feedback. The concept of user was really used for quickly 
re-using existing sessions in NAT. With port-overloading, ports are no longer a 
precious resource and dropping “users” means not having to maintain an extra 
hash table.

To better understand your problem, can you please state your use case for 
dumping these sessions?

Thanks,
Klement

> On 12 May 2020, at 13:18, Alexander Chernavin via lists.fd.io 
>  wrote:
> 
> Hello,
> 
> As I understand the "users" concept has been removed from NAT ED and now 
> vl_api_nat44_user_dump_t returns nothing in ED mode. 
> vl_api_nat44_user_session_dump_t returns sessions only if you know the user 
> you are requesting sessions for. But you can't get the user list. Therefore 
> this chain no longer works: dump all users, then dump all sessions of those 
> users.
> 
> I think the user dump code could build the user list based on the sessions, 
> but we need to collect these fields: IP address, VRF id, number of static and 
> dynamic sessions. For a big number of sessions it might be time-consuming 
> before the first user could be sent. Probably, maintaining a user list would 
> be cheaper.
> 
> How do you think vl_api_nat44_user_dump_t can be fixed for NAT ED?
> 
> 

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

View/Reply Online (#16329): https://lists.fd.io/g/vpp-dev/message/16329
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Reminder: VPP 20.05 RC1 is *tomorrow* 13th May 18:00 UTC

[Andrew Yourtchenko]

Hi all,

Just a friendly reminder that tomorrow at 18:00 UTC we have the VPP
20.05 RC1 milestone [0], during which a stable/2005 branch will be
created.

Until after I send an email announcing the end of that process, master
branch is still CLOSED for API changes and risky commits.

You may have notice that verify jobs are still being a bit
temperamental - some of the changes appeared to have made the
situation a bit better, but Dave and myself are still working on it to
properly diagnose the root cause of this intermittent issue. If you
have any persistent infrastructure-related difficulties with the
commits that you would like to see merged before the new stable branch
being cut, please let me know ASAP.

thanks!

--a
/* your friendly 20.05 release manager */

[0]: https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_20.05
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] NAT ED empty users dump #nat #nat44

[Alexander Chernavin via lists.fd.io]

Hello,

As I understand the "users" concept has been removed from NAT ED and now 
vl_api_nat44_user_dump_t returns nothing in ED mode. 
vl_api_nat44_user_session_dump_t returns sessions only if you know the user you 
are requesting sessions for. But you can't get the user list. Therefore this 
chain no longer works: dump all users, then dump all sessions of those users.

I think the user dump code could build the user list based on the sessions, but 
we need to collect these fields: IP address, VRF id, number of static and 
dynamic sessions. For a big number of sessions it might be time-consuming 
before the first user could be sent. Probably, maintaining a user list would be 
cheaper.

How do you think vl_api_nat44_user_dump_t can be fixed for NAT ED?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16327): https://lists.fd.io/g/vpp-dev/message/16327
Mute This Topic: https://lists.fd.io/mt/74156168/21656
Mute #nat: https://lists.fd.io/mk?hashtag=nat=1480452
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] min_log2 abuse

[Dave Barach via lists.fd.io]

Dear Andreas,

Do you have a handy list of places which convert netmasks to lengths? 
Regardless of what one might do with min_log2, we ought to clean up those 
places in time for the 20.05 release (if possible).

Dave

From: vpp-dev@lists.fd.io  On Behalf Of Andreas Schultz
Sent: Tuesday, May 12, 2020 5:42 AM
To: vpp-dev 
Subject: [vpp-dev] min_log2 abuse

Hi,

There are few places in VPP (most notable when trying to convert a netmask into 
a length) that can pass 0 (zero) into min_log2 and expect to get a meaningful 
result.

Obviously log2(0) is undefined. It turns out that this also applies to the 
return of min_log2. Under the hood the function uses __builtin_clzl, and the 
return of that function is also undefined for input 0.

 __builtin_clzl  could be replaced with __builtin_ia32_lzcnt_u64 on supported 
CPUs to avoid the undefined behaviour. That would still not fix the problem 
that passing 0 into a log function is broken by design.

Any comments?
Andreas

--

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

View/Reply Online (#16326): https://lists.fd.io/g/vpp-dev/message/16326
Mute This Topic: https://lists.fd.io/mt/74155196/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] clang-9

[Damjan Marion via lists.fd.io]

> On 12 May 2020, at 11:07, Andreas Schultz  
> wrote:
> 
> 
> 
> Am Di., 12. Mai 2020 um 10:42 Uhr schrieb Damjan Marion  >:
> 
> 
>> On 12 May 2020, at 10:10, Andreas Schultz > > wrote:
>> 
>> 
>> 
>> Am Di., 12. Mai 2020 um 10:00 Uhr schrieb Damjan Marion via lists.fd.io 
>>  > >:
>> 
>> 
>> 
>> > On 12 May 2020, at 03:40, Lijian Zhang > > > wrote:
>> > 
>> > 
>> >> -Original Message-
>> >> From: Damjan Marion mailto:dmar...@me.com>>
>> >> Sent: 2020年5月12日 0:46
>> >> To: Lijian Zhang mailto:lijian.zh...@arm.com>>
>> >> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; nd 
>> >> mailto:n...@arm.com>>
>> >> Subject: Re: [vpp-dev] clang-9
>> >> 
>> >> 
>> >> Hi Lijian,
>> >> 
>> >> If I got it right, neither gcc or clang available in ubuntu 18.04 LTS are 
>> >> able to
>> >> produce N1 optimised binaries. correct?
>> > Yes, that's right. Support for optimized compiling for N1 starts with 
>> > gcc-9.2.0 and clang-10, which are not available in Ubuntu-18.04 yet.
>> >> 
>> >> If yes, can we just add clang-10 from: https://apt.llvm.org 
>> >>  to vpp build scripts?
>> >> 
>> > Currently clang-10/clang-11 Aarch64 packages are not available at 
>> > apt.llvm.org  yet. Arm compiler team is working on 
>> > getting AArch64 packages available at apt.llvm.org . 
>> > It may take a couple of weeks.
>> 
>> So let’s wait then. For people who wants to use N1 probably there is more 
>> sense in
>> using ubuntu 20.04 anyway, and 20.04 is coming with clang10.
>> 
>> Yeah, but Ubuntu 20.04 and Debian Sid are in the process of removing python2 
>> support and that creates a whole bunch of other problems. Removing the 
>> python2 deb references from `make install-dep` is relatively simple, but 
>> cleaning up the debian rules and control files without breaking support for 
>> older Ubuntu and Debian releases is more complicated.
> 
> Can you explain what exactly is more complicated?
> 
> Debian Sid has completely removed python2, but the debs still depend on them. 
> Making this more flexible requires some creative changes to the rules files.
> We have worked around that [1],[2] by removing the python2 dependencies, but 
> that would probably break builds on older Debian/Ubuntu versions.
> 
> [1]: 
> https://github.com/travelping/vpp/commit/77acccae792180f0ae94058a3b1ca7db0f995dd0
>  
> 
>   
> [2]: 
> https://github.com/travelping/vpp/commit/7d52fd387b4c8a3a2f33c27f031b283d260301f2
>  
> —
>  

something like:

https://gerrit.fd.io/r/c/vpp/+/27010

Changes in ./Makefile probably require a bit of brain police form somebody 
fluent in python….



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

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

[vpp-dev] min_log2 abuse

[Andreas Schultz]

Hi,

There are few places in VPP (most notable when trying to convert a netmask
into a length) that can pass 0 (zero) into min_log2 and expect to get a
meaningful result.

Obviously log2(0) is undefined. It turns out that this also applies to the
return of min_log2. Under the hood the function uses __builtin_clzl, and
the return of that function is also undefined for input 0.

 __builtin_clzl  could be replaced with __builtin_ia32_lzcnt_u64 on
supported CPUs to avoid the undefined behaviour. That would still not fix
the problem that passing 0 into a log function is broken by design.

Any comments?
Andreas

-- 

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

View/Reply Online (#16324): https://lists.fd.io/g/vpp-dev/message/16324
Mute This Topic: https://lists.fd.io/mt/74155196/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] clang-9

[Andreas Schultz]

Am Di., 12. Mai 2020 um 10:42 Uhr schrieb Damjan Marion :

>
>
> On 12 May 2020, at 10:10, Andreas Schultz 
> wrote:
>
>
>
> Am Di., 12. Mai 2020 um 10:00 Uhr schrieb Damjan Marion via lists.fd.io
> :
>
>>
>>
>>
>> > On 12 May 2020, at 03:40, Lijian Zhang  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Damjan Marion 
>> >> Sent: 2020年5月12日 0:46
>> >> To: Lijian Zhang 
>> >> Cc: vpp-dev ; nd 
>> >> Subject: Re: [vpp-dev] clang-9
>> >>
>> >>
>> >> Hi Lijian,
>> >>
>> >> If I got it right, neither gcc or clang available in ubuntu 18.04 LTS
>> are able to
>> >> produce N1 optimised binaries. correct?
>> > Yes, that's right. Support for optimized compiling for N1 starts with
>> gcc-9.2.0 and clang-10, which are not available in Ubuntu-18.04 yet.
>> >>
>> >> If yes, can we just add clang-10 from: https://apt.llvm.org to vpp
>> build scripts?
>> >>
>> > Currently clang-10/clang-11 Aarch64 packages are not available at
>> apt.llvm.org yet. Arm compiler team is working on getting AArch64
>> packages available at apt.llvm.org. It may take a couple of weeks.
>>
>> So let’s wait then. For people who wants to use N1 probably there is more
>> sense in
>> using ubuntu 20.04 anyway, and 20.04 is coming with clang10.
>>
>
> Yeah, but Ubuntu 20.04 and Debian Sid are in the process of removing
> python2 support and that creates a whole bunch of other problems. Removing
> the python2 deb references from `make install-dep` is relatively simple,
> but cleaning up the debian rules and control files without breaking support
> for older Ubuntu and Debian releases is more complicated.
>
>
> Can you explain what exactly is more complicated?
>

Debian Sid has completely removed python2, but the debs still depend on
them. Making this more flexible requires some creative changes to the rules
files.
We have worked around that [1],[2] by removing the python2 dependencies,
but that would probably break builds on older Debian/Ubuntu versions.

[1]:
https://github.com/travelping/vpp/commit/77acccae792180f0ae94058a3b1ca7db0f995dd0

[2]:
https://github.com/travelping/vpp/commit/7d52fd387b4c8a3a2f33c27f031b283d260301f2
-- 

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

View/Reply Online (#16323): https://lists.fd.io/g/vpp-dev/message/16323
Mute This Topic: https://lists.fd.io/mt/73327785/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] clang-9

[Damjan Marion via lists.fd.io]

> On 12 May 2020, at 10:10, Andreas Schultz  
> wrote:
> 
> 
> 
> Am Di., 12. Mai 2020 um 10:00 Uhr schrieb Damjan Marion via lists.fd.io 
>   >:
> 
> 
> 
> > On 12 May 2020, at 03:40, Lijian Zhang  > > wrote:
> > 
> > 
> >> -Original Message-
> >> From: Damjan Marion mailto:dmar...@me.com>>
> >> Sent: 2020年5月12日 0:46
> >> To: Lijian Zhang mailto:lijian.zh...@arm.com>>
> >> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; nd 
> >> mailto:n...@arm.com>>
> >> Subject: Re: [vpp-dev] clang-9
> >> 
> >> 
> >> Hi Lijian,
> >> 
> >> If I got it right, neither gcc or clang available in ubuntu 18.04 LTS are 
> >> able to
> >> produce N1 optimised binaries. correct?
> > Yes, that's right. Support for optimized compiling for N1 starts with 
> > gcc-9.2.0 and clang-10, which are not available in Ubuntu-18.04 yet.
> >> 
> >> If yes, can we just add clang-10 from: https://apt.llvm.org 
> >>  to vpp build scripts?
> >> 
> > Currently clang-10/clang-11 Aarch64 packages are not available at 
> > apt.llvm.org  yet. Arm compiler team is working on 
> > getting AArch64 packages available at apt.llvm.org . 
> > It may take a couple of weeks.
> 
> So let’s wait then. For people who wants to use N1 probably there is more 
> sense in
> using ubuntu 20.04 anyway, and 20.04 is coming with clang10.
> 
> Yeah, but Ubuntu 20.04 and Debian Sid are in the process of removing python2 
> support and that creates a whole bunch of other problems. Removing the 
> python2 deb references from `make install-dep` is relatively simple, but 
> cleaning up the debian rules and control files without breaking support for 
> older Ubuntu and Debian releases is more complicated.

Can you explain what exactly is more complicated?-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16322): https://lists.fd.io/g/vpp-dev/message/16322
Mute This Topic: https://lists.fd.io/mt/73327785/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] clang-9

[Andreas Schultz]

Am Di., 12. Mai 2020 um 10:00 Uhr schrieb Damjan Marion via lists.fd.io
:

>
>
>
> > On 12 May 2020, at 03:40, Lijian Zhang  wrote:
> >
> >
> >> -Original Message-
> >> From: Damjan Marion 
> >> Sent: 2020年5月12日 0:46
> >> To: Lijian Zhang 
> >> Cc: vpp-dev ; nd 
> >> Subject: Re: [vpp-dev] clang-9
> >>
> >>
> >> Hi Lijian,
> >>
> >> If I got it right, neither gcc or clang available in ubuntu 18.04 LTS
> are able to
> >> produce N1 optimised binaries. correct?
> > Yes, that's right. Support for optimized compiling for N1 starts with
> gcc-9.2.0 and clang-10, which are not available in Ubuntu-18.04 yet.
> >>
> >> If yes, can we just add clang-10 from: https://apt.llvm.org to vpp
> build scripts?
> >>
> > Currently clang-10/clang-11 Aarch64 packages are not available at
> apt.llvm.org yet. Arm compiler team is working on getting AArch64
> packages available at apt.llvm.org. It may take a couple of weeks.
>
> So let’s wait then. For people who wants to use N1 probably there is more
> sense in
> using ubuntu 20.04 anyway, and 20.04 is coming with clang10.
>

Yeah, but Ubuntu 20.04 and Debian Sid are in the process of removing
python2 support and that creates a whole bunch of other problems. Removing
the python2 deb references from `make install-dep` is relatively simple,
but cleaning up the debian rules and control files without breaking support
for older Ubuntu and Debian releases is more complicated.

Andreas

>
> [...]
>

-- 

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

View/Reply Online (#16321): https://lists.fd.io/g/vpp-dev/message/16321
Mute This Topic: https://lists.fd.io/mt/73327785/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] clang-9

[Damjan Marion via lists.fd.io]

> On 12 May 2020, at 03:40, Lijian Zhang  wrote:
> 
> 
>> -Original Message-
>> From: Damjan Marion 
>> Sent: 2020年5月12日 0:46
>> To: Lijian Zhang 
>> Cc: vpp-dev ; nd 
>> Subject: Re: [vpp-dev] clang-9
>> 
>> 
>> Hi Lijian,
>> 
>> If I got it right, neither gcc or clang available in ubuntu 18.04 LTS are 
>> able to
>> produce N1 optimised binaries. correct?
> Yes, that's right. Support for optimized compiling for N1 starts with 
> gcc-9.2.0 and clang-10, which are not available in Ubuntu-18.04 yet.
>> 
>> If yes, can we just add clang-10 from: https://apt.llvm.org to vpp build 
>> scripts?
>> 
> Currently clang-10/clang-11 Aarch64 packages are not available at 
> apt.llvm.org yet. Arm compiler team is working on getting AArch64 packages 
> available at apt.llvm.org. It may take a couple of weeks.

So let’s wait then. For people who wants to use N1 probably there is more sense 
in
using ubuntu 20.04 anyway, and 20.04 is coming with clang10.


>> In particular:
>> 
>> # 10
>> deb http://apt.llvm.org/bionic/ llvm-toolchain-bionic-10 main deb-src
>> http://apt.llvm.org/bionic/ llvm-toolchain-bionic-10 main
>> 
>> 
>> Damjan
>> 
>> 
>>> On 9 May 2020, at 12:12, Lijian Zhang  wrote:
>>> 
>>> Hi Damjan,
>>> The patch[2] installs clang-9 in package dependencies and sets “clang-10
>> clang-9 gcc-9 cc” as the default compiler.
>>> 
>>> The problem is,
>>> 1. clang-9 does not support ‘-mtune=qdf24xx’, ‘-mtune=neoverse-n1’, ‘-
>> mcpu=neoverse-n1’, so it cannot do arch-specific compiling and optimal
>> function selection for those two CPUs.
>>> These options requires gcc-9.2, clang-10 and any newer versions.
>>> 2. The clang package servers for Ubuntu-18.04 mentioned in
>> https://apt.llvm.org/ support x86, but does not support Arm64, so we cannot
>> install clang-10/clang-11 directly via apt commands on Arm servers.
>>> 
>>> I’m thinking two options,
>>> 1. remove clang-9 dependency in Makefile or add for x86_64 only, so that
>> users should install clang-10/clang-9 for x86 manually, and for Arm, install 
>> gcc-
>> 9 and clang-10/clang-11(not available yet). Just like CSIT has to update gcc
>> version to gcc-8.3 manually(gcc-8.3 not listed in dependencies) previously.
>>> 2. there are other several workaround,
>>>  2.1 install clang-10 from source code until we can do clang-10 
>>> binary
>> install on Ubuntu-18.04 on Arm;
>>>  2.2 keep the code as it is now, although it will disable 
>>> multi-arch
>> support for these two CPUs with clang-9;
>>>  2.3 when we are developing code or doing benchmarking, we need
>> to hack the code temporarily from “set(CMAKE_C_COMPILER_NAMES clang-
>> 10 clang-9 gcc-9 cc)” to “set(CMAKE_C_COMPILER_NAMES clang-10 gcc-9 cc)”,
>> so that multi-arch will be supported with gcc-9.
>>> 
>>> Could you suggest on this issue?
>>> Thanks.
>>> From: vpp-dev@lists.fd.io  On Behalf Of Damjan
>>> Marion via lists.fd.io
>>> Sent: 2020年4月28日 22:14
>>> To: vpp-dev 
>>> Subject: [vpp-dev] clang-9
>>> 
>>> 
>>> Folks,
>>> 
>>> As there is bug in gnu assembler which is shipping with ubuntu 18.04 we are
>> not able to produce working binaries with avx512 instruction set.
>>> Because of that, I had to change default to avx2. reported bug[1], but it is
>> ignored for a year.
>>> 
>>> As alternative[2], I wanted to consider using clang-9 which is shipped with
>> ubuntu 18.04 and seems like it is even capable of producing faster binaries
>> than gcc.
>>> Unfortunately, "make test" is failing at several places including vxlan, 
>>> ipsec
>> and tcp stack[3].
>>> 
>>> May I ask folks who “own” that code to take a quick look?
>>> 
>>> Thanks,
>>> 
>>> Damjan
>>> 
>>> [1]
>>> https://bugs.launchpad.net/ubuntu/cosmic/+source/binutils/+bug/1819961
>>> [2] https://gerrit.fd.io/r/c/vpp/+/26744
>>> [3]
>>> https://jenkins.fd.io/job/vpp-verify-master-ubuntu1804/3615/console
>>> 
>>> 
>>> 
>>> 
> 

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

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