[vpp-dev] #vpp #vpp_qos
Hi, I want to apply policer to all incoming packets on a particular interface. I understood VPP policer and classify configuration. But the classify table command need a mask . Is there a way to apply policer configuration for *all* packets on an interface? Is there any kind of wildcard configuration ? Thanks -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16052): https://lists.fd.io/g/vpp-dev/message/16052 Mute This Topic: https://lists.fd.io/mt/72981956/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Mute #vpp_qos: https://lists.fd.io/mk?hashtag=vpp_qos&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP checksum behavior problems
Hi experts, I am confusing about the L4 checksum behavior in VPP. I noticed the code was there for a very long time(more than 3 years) so I open this topic to see if anybody knows the history and why. The first problem is in DPDK plugin and was introduced in commit d81566ff92: Disable for-us udp/tcp checksum validation by default in Current DPDK plugin, the code clears flags VNET_BUFFER_F_L4_CHECKSUM_COMPUTED and VNET_BUFFER_F_L4_CHECKSUM_CORRECT when "enable-tcp-udp-checksum" option is enabled. While these two flags are used to identify if the L4 checksum is checked and correct, respectively. So I think this is a wrong behavior - are we doing the opposite? The current DPDK plugin assumes all the packets from DPDK are correct but in fact we should check per packet and set the corresponding bits. I've pushed a patch to fix this issue and Dave invited experts to help to review - Thanks Dave :-) Another problem in the IP4 graph node. The following mechanism was first introduced in commit 96be8e88109b3e1 and got refactored in commit 1b25552eb. #define ip4_local_csum_is_offloaded(_b) \ _b->flags & VNET_BUFFER_F_OFFLOAD_TCP_CKSUM \ || _b->flags & VNET_BUFFER_F_OFFLOAD_UDP_CKSUM #define ip4_local_need_csum_check(is_tcp_udp, _b) \ (is_tcp_udp && !(_b->flags & VNET_BUFFER_F_L4_CHECKSUM_COMPUTED \ || ip4_local_csum_is_offloaded (_b))) #define ip4_local_csum_is_valid(_b) \ (_b->flags & VNET_BUFFER_F_L4_CHECKSUM_CORRECT \ || (ip4_local_csum_is_offloaded (_b))) != 0 In my understanding, the Marcos ip4_local_need_csum_check and ip4_local_csum_is_valid are used to check if the L4 checksum is computed and checked before ip4-local node. While the Macro ip4_local_csum_is_offloaded is to check if the L4 checksum can be offloaded to NIC on the *TX side*. I am not very clear why do we need to check the tx offload capability in the RX path - maybe we are expecting the NIC can help to re-calculate the checksum before sending out? Think about if an APP(local APP running upon TCP/UDP stack or a tunnel like VxLAN/GTPU/etc...) is running on L4, it would get invalid checksum packets(Considering the DPDK plugin marked all the packets are COMPUTED and CORRECT as I described in the first problem). see in: commit 96be8e88109b3e166b76f58e552dbe438d73bb73 Author: Jakub Grajciar Date: Mon Oct 30 14:56:17 2017 +0100 vnet: ip4/6_local->don't drop packet if marked for TCP/UDP offload cksum calculation -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16053): https://lists.fd.io/g/vpp-dev/message/16053 Mute This Topic: https://lists.fd.io/mt/72982275/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] ipv6 reassembly support in vpp
Hi, I am trying to validate ipv6 reassembly on vpp 20.01. My observation is that fragmented packets which are terminated on vpp are landing on shallow reassembly ( *ip6-sv-reassembly)* node and not on full reassembly node ( *ip6-full-reassembly* ), So, full reassembly is not happening with default vpp configuration. Is this understanding correct? I am able to find another way where when we enable reassembly feature on the interface(on which fragmented packets are received) by running following command, packets are getting reassembled. But in this case, as this is a feature arc, all packets are getting routed to the full reassembly node whether those are locally terminated or not. set interface reassembly [on|off|ip4|ip6] Would like to know what is the way to enable full reassembly only for the locally terminated packets in vpp 20.01 via configuration. Please provide relevant pointers in this regard. Thanks & Regards, Khushwant -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16054): https://lists.fd.io/g/vpp-dev/message/16054 Mute This Topic: https://lists.fd.io/mt/72982362/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] dpdk-20.02 compile error for Intel atom
-- hi all, I've added two files, content is as follows: *mk/machine/atom/rte. Vars. Mk* # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2010-2014 Intel Corporation # # machine: # # - can define ARCH variable (overridden by cmdline value) # - can define CROSS variable (overridden by cmdline value) # - define MACHINE_CFLAGS variable (overridden by cmdline value) # - define MACHINE_LDFLAGS variable (overridden by cmdline value) # - define MACHINE_ASFLAGS variable (overridden by cmdline value) # - can define CPU_CFLAGS variable (overridden by cmdline value) that # overrides the one defined in arch. # - can define CPU_LDFLAGS variable (overridden by cmdline value) that # overrides the one defined in arch. # - can define CPU_ASFLAGS variable (overridden by cmdline value) that # overrides the one defined in arch. # - may override any previously defined variable # # ARCH = # CROSS = # MACHINE_CFLAGS = # MACHINE_LDFLAGS = # MACHINE_ASFLAGS = # CPU_CFLAGS = # CPU_LDFLAGS = # CPU_ASFLAGS = MACHINE_CFLAGS = -march=atom # On FreeBSD systems, sometimes the correct CPU type is not picked up. # To get everything to compile, we need SSE4.2 support, so check if that is # reported by compiler. If not, check if the CPU actually supports it, and if # so, set the compilation target to be a corei7, minimum target with SSE4.2. SSE42_SUPPORT=$(shell $(CC) -march=native -dM -E - -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16055): https://lists.fd.io/g/vpp-dev/message/16055 Mute This Topic: https://lists.fd.io/mt/72983203/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP checksum behavior problems
[Edited Message Follows] Hi experts, I am confusing about the L4 checksum behavior in VPP. I noticed the code was there for a very long time(more than 3 years) so I open this topic to see if anybody knows the history and why. * The first problem is in DPDK plugin and was introduced in commit d81566ff92: Disable for-us udp/tcp checksum validation by default in Current DPDK plugin, the code clears flags VNET_BUFFER_F_L4_CHECKSUM_COMPUTED and VNET_BUFFER_F_L4_CHECKSUM_CORRECT when "enable-tcp-udp-checksum" option is enabled. While these two flags are used to identify if the L4 checksum is checked and correct, respectively. So I think this is a wrong behavior - *are we doing the opposite* ? The current DPDK plugin assumes all the packets from DPDK are correct but in fact we should check per packet and set the corresponding bits. I've pushed a patch to fix this issue and Dave invited experts to help to review - Thanks Dave :-) * Another problem in the IP4 graph node. The following mechanism was first introduced in commit 96be8e88109b3e1 and got refactored in commit 1b25552eb. #define ip4_local_csum_is_offloaded(_b) \ _b->flags & VNET_BUFFER_F_OFFLOAD_TCP_CKSUM \ || _b->flags & VNET_BUFFER_F_OFFLOAD_UDP_CKSUM #define ip4_local_need_csum_check(is_tcp_udp, _b) \ (is_tcp_udp && !(_b->flags & VNET_BUFFER_F_L4_CHECKSUM_COMPUTED \ || ip4_local_csum_is_offloaded (_b))) #define ip4_local_csum_is_valid(_b) \ (_b->flags & VNET_BUFFER_F_L4_CHECKSUM_CORRECT \ || (ip4_local_csum_is_offloaded (_b))) != 0 In my understanding, the Marcos ip4_local_need_csum_check and ip4_local_csum_is_valid are used to check if the L4 checksum is computed and checked before ip4-local node. While the Macro ip4_local_csum_is_offloaded is to check if the L4 checksum can be offloaded to NIC on the *TX side*. *I am not very clear why do we need to check the tx offload capability in the RX path* - maybe we are expecting the NIC can help to re-calculate the checksum before sending out? Think about if an APP(local APP running upon TCP/UDP stack or a tunnel like VxLAN/GTPU/etc...) is running on L4, it would get invalid checksum packets(Considering the DPDK plugin marked all the packets are COMPUTED and CORRECT as I described in the first problem). see in: commit 96be8e88109b3e166b76f58e552dbe438d73bb73 Author: Jakub Grajciar Date: Mon Oct 30 14:56:17 2017 +0100 vnet: ip4/6_local->don't drop packet if marked for TCP/UDP offload cksum calculation -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16053): https://lists.fd.io/g/vpp-dev/message/16053 Mute This Topic: https://lists.fd.io/mt/72982275/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] Centos-7 jobs failing in the CI
This seemed to go away Friday evening (EDT) and it looks like it happened twice since then although most jobs have been passing. I'll keep an eye on it and see if I can figure out the root cause... Thanks, -daw- On 4/11/2020 12:05 PM, Paul Vinciguerra wrote: Jobs are consistently failing in the CI now. make[6]: warning: Clock skew detected. Your build may be incomplete. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16056): https://lists.fd.io/g/vpp-dev/message/16056 Mute This Topic: https://lists.fd.io/mt/72947521/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 checksum behavior problems
Hi Chenmin, Regarding your second question, some of the device drivers could mark buffers for tx csum offload which is honored only if data is about to be delivered to the network (or if some other action performed to the buffer requires csums to be computed). Otherwise, if packets end up consumed locally, e.g., tunnel or host stack termination, the data is assumed to be correct and no checksum is computed. So, for instance, if udp/tcp packets received from a tap interface are terminated locally, we don’t try to compute/validate checksum, since there’s nothing to validate as the checksum has not yet been filled in. Regards, Florin > On Apr 13, 2020, at 12:52 AM, Sun, Chenmin wrote: > > [Edited Message Follows] > > Hi experts, > > I am confusing about the L4 checksum behavior in VPP. I noticed the code was > there for a very long time(more than 3 years) so I open this topic to see if > anybody knows the history and why. > > The first problem is in DPDK plugin and was introduced in commit d81566ff92: > Disable for-us udp/tcp checksum validation by default > in Current DPDK plugin, the code clears flags > VNET_BUFFER_F_L4_CHECKSUM_COMPUTED and VNET_BUFFER_F_L4_CHECKSUM_CORRECT when > "enable-tcp-udp-checksum" option is enabled. While these two flags are used > to identify if the L4 checksum is checked and correct, respectively. So I > think this is a wrong behavior - are we doing the opposite? > The current DPDK plugin assumes all the packets from DPDK are correct but in > fact we should check per packet and set the corresponding bits. I've pushed a > patch to fix this issue and Dave invited experts to help to review - Thanks > Dave :-) > > Another problem in the IP4 graph node. The following mechanism was first > introduced in commit 96be8e88109b3e1 and got refactored in commit 1b25552eb. > > #define ip4_local_csum_is_offloaded(_b) \ > _b->flags & VNET_BUFFER_F_OFFLOAD_TCP_CKSUM \ > || _b->flags & VNET_BUFFER_F_OFFLOAD_UDP_CKSUM > > #define ip4_local_need_csum_check(is_tcp_udp, _b) \ > (is_tcp_udp && !(_b->flags & VNET_BUFFER_F_L4_CHECKSUM_COMPUTED \ > || ip4_local_csum_is_offloaded (_b))) > > #define ip4_local_csum_is_valid(_b) \ > (_b->flags & VNET_BUFFER_F_L4_CHECKSUM_CORRECT \ > || (ip4_local_csum_is_offloaded (_b))) != 0 > > In my understanding, the Marcos ip4_local_need_csum_check and > ip4_local_csum_is_valid are used to check if the L4 checksum is computed and > checked before ip4-local node. While the Macro ip4_local_csum_is_offloaded is > to check if the L4 checksum can be offloaded to NIC on the TX side. I am not > very clear why do we need to check the tx offload capability in the RX path - > maybe we are expecting the NIC can help to re-calculate the checksum before > sending out? Think about if an APP(local APP running upon TCP/UDP stack or a > tunnel like VxLAN/GTPU/etc...) is running on L4, it would get invalid > checksum packets(Considering the DPDK plugin marked all the packets are > COMPUTED and CORRECT as I described in the first problem). > > see in: > commit 96be8e88109b3e166b76f58e552dbe438d73bb73 > Author: Jakub Grajciar > Date: Mon Oct 30 14:56:17 2017 +0100 > > vnet: ip4/6_local->don't drop packet if marked for TCP/UDP offload cksum > calculation > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16057): https://lists.fd.io/g/vpp-dev/message/16057 Mute This Topic: https://lists.fd.io/mt/72982275/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] Centos-7 jobs failing in the CI
The logs did look pretty weird - well before the message Paul sent there is a slew of complaints about the checksums in a tarball being X seconds in the future. And it seems like that tarball is made earlier in the same job. Does this correlate with what you saw ? --a > On 13 Apr 2020, at 17:55, Dave Wallace wrote: > > > This seemed to go away Friday evening (EDT) and it looks like it happened > twice since then although most jobs have been passing. > I'll keep an eye on it and see if I can figure out the root cause... > > Thanks, > -daw- > >> On 4/11/2020 12:05 PM, Paul Vinciguerra wrote: >> Jobs are consistently failing in the CI now. >> >> make[6]: warning: Clock skew detected. Your build may be incomplete. >> >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16058): https://lists.fd.io/g/vpp-dev/message/16058 Mute This Topic: https://lists.fd.io/mt/72947521/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] Centos-7 jobs failing in the CI
Yes, that's exactly what I saw. I'm trying to figure out if the issue was actually related to the system clock / ntp or perhaps some weird form of corruption of the file metadata during the creation or extraction of the tarball. Thanks, -daw- On 4/13/2020 12:58 PM, Andrew 👽 Yourtchenko wrote: The logs did look pretty weird - well before the message Paul sent there is a slew of complaints about the checksums in a tarball being X seconds in the future. And it seems like that tarball is made earlier in the same job. Does this correlate with what you saw ? --a On 13 Apr 2020, at 17:55, Dave Wallace wrote: This seemed to go away Friday evening (EDT) and it looks like it happened twice since then although most jobs have been passing. I'll keep an eye on it and see if I can figure out the root cause... Thanks, -daw- On 4/11/2020 12:05 PM, Paul Vinciguerra wrote: Jobs are consistently failing in the CI now. make[6]: warning: Clock skew detected. Your build may be incomplete. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16059): https://lists.fd.io/g/vpp-dev/message/16059 Mute This Topic: https://lists.fd.io/mt/72947521/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] Centos-7 jobs failing in the CI
> On 13 Apr 2020, at 19:56, Dave Wallace wrote: > > Yes, that's exactly what I saw. > > I'm trying to figure out if the issue was actually related to the system > clock / ntp or perhaps some weird form of corruption of the file metadata > during the creation or extraction of the tarball. The make got into some weird convulsion later - would tarball on its own be implicated ? —a > > Thanks, > -daw- > >> On 4/13/2020 12:58 PM, Andrew 👽 Yourtchenko wrote: >> The logs did look pretty weird - well before the message Paul sent there is >> a slew of complaints about the checksums in a tarball being X seconds in the >> future. >> >> And it seems like that tarball is made earlier in the same job. >> >> Does this correlate with what you saw ? >> >> --a >> On 13 Apr 2020, at 17:55, Dave Wallace wrote: >>> >>> >>> This seemed to go away Friday evening (EDT) and it looks like it happened >>> twice since then although most jobs have been passing. >>> I'll keep an eye on it and see if I can figure out the root cause... >>> >>> Thanks, >>> -daw- >>> On 4/11/2020 12:05 PM, Paul Vinciguerra wrote: Jobs are consistently failing in the CI now. make[6]: warning: Clock skew detected. Your build may be incomplete. > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16060): https://lists.fd.io/g/vpp-dev/message/16060 Mute This Topic: https://lists.fd.io/mt/72947521/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
