Re: [vpp-dev] Forwarding Specific Packet with LCP Plugin

[Matthew Smith via lists.fd.io]

You set the next hop address to the same as the local interface address:

On Tue, Feb 14, 2023 at 7:42 AM Burcu YUKSEL <
burcu.yuk...@ulakhaberlesme.com.tr> wrote:

[...]

> set int ip address memif0/0 10.10.1.1/24
>
[...]

> abf policy add id 0 acl 0 via 10.10.1.1 memif0/0
>

If you want packets matching the ACL to be sent to 10.10.1.4 as in your
original diagram, the abf policy should be via 10.10.1.4, not 10.10.1.1.

-Matt

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

Re: [vpp-dev] Help:VPP-DPDK #acl_plugin #dpdk

[Matthew Smith via lists.fd.io]

You haven't shared any details of where you placed these calls in the dpdk
plugin, but I suspect that they were successful because they were executed
after the dpdk plugin had already called rte_eal_init(). When called from
your plugin, rte_eal_init() had probably not been called yet.

You could try to confirm that this is the problem by adding log messages to
announce when rte_eal_init(), rte_ring_create(), and rte_mempool_create()
are about to be called and check the order that those messages appear in
your logs. Or you could run VPP in a debugger and set breakpoints on those
3 functions and check what order the breakpoints are hit. If the calls to
rte_ring_create() and rte_mempool_create() come before rte_eal_init() has
been called, you need to adjust your plugin code so it calls them after
rte_eal_init() has been called. If not, and rte_eal_init() is being called
first, then I have no further guesses on the source of your issues.

-Matt



On Tue, Feb 7, 2023 at 7:23 PM kk  wrote:

> I read the official example given by dpdk. The two function interfaces
> "rte_ring_create and rte_mempool_create" should indeed be called after
> rte_eal_init(). The problem is that I have no problem calling these two
> function interfaces in the vpp dpdk plug-in, which is very strange.
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22576): https://lists.fd.io/g/vpp-dev/message/22576
Mute This Topic: https://lists.fd.io/mt/96804295/21656
Mute #acl_plugin:https://lists.fd.io/g/vpp-dev/mutehashtag/acl_plugin
Mute #dpdk:https://lists.fd.io/g/vpp-dev/mutehashtag/dpdk
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Forwarding Specific Packet with LCP Plugin

[Matthew Smith via lists.fd.io]

Hi Burcu,

You can probably use ABF (https://wiki.fd.io/view/VPP/ABF) to do this. When
you have linux-cp enabled and an interface is added to a linux-cp interface
pair, the normal behavior is that packets received on that interface which
are destined to the interface IP address will be punted to the host over
the linux-cp tap. This occurs after the FIB lookup that occurs at the end
of the ip4-unicast feature arc. ABF policies are evaluated earlier on the
feature arc and can match packets and forward them elsewhere before they
are punted to linux-cp.

You can create an ACL that has rules like this:
1. ipv4 deny src 0.0.0.0/0 dst 10.20.10.22/32 proto 6 sport 0 dport 22 -
this deny rule will cause the tcp/22 packets to be excluded from ABF
processing, so they will follow the normal path into linux-cp
2. ipv4 permit src 0.0.0.0/0 dst 10.20.10.22/32 proto 0 sport 0-65535 dport
0-65535 - this will match all the other packets which would normally be
punted to linux-cp and cause them to be forwarded using ABF policy instead

Then you can add an ABF policy referencing the ACL you created which sends
packets 'via 10.10.1.4 memif0' and attach that policy to the hardware
interface.

The patch that enables the use of deny rules to exclude packets from ABF
processing was added after the stable/2210 branch was created. So the above
will only work on a build from VPP's master branch.

-Matt




On Thu, Feb 9, 2023 at 4:13 AM Burcu YUKSEL <
burcu.yuk...@ulakhaberlesme.com.tr> wrote:

> Hello Everyone,
>
> We want to transfer the SSH packets coming from Device A to Linux Stack,
> other packets to Application B full duplex. We transferred packets with
> using LCP plugin. However in this case we have transferred all the packets
> to Linux stack. Is there a way to forward only TCP packets with port 22 to
> Linux with LCP?
>
>
>
> VPP:
>
> lcp create TwentyFiveGigabitEthernetd8/0/0 host-if vpp-host
> set interface state TwentyFiveGigabitEthernetd8/0/0 up
> set interface ip address TwentyFiveGigabitEthernetd8/0/0 10.20.10.22/24
> ip route add 0.0.0.0/0 via 10.20.10.22 TwentyFiveGigabitEthernetd8/0/0
>
> Linux Server:
>
> sudo ip link set vpp-host up
> sudo ip addr add 10.20.10.22/24 dev vpp-host
> sudo route add default gw 10.20.10.1
>
> Best Regards,
> Burcu
>
> Bu elektronik posta ve onunla iletilen bütün dosyalar sadece göndericisi
> tarafından alması amaçlanan yetkili, gerçek ya da tüzel kişinin kullanımı
> içindir. Eğer söz konusu yetkili alıcı değilseniz, bu elektronik postanın
> içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız
> kesinlikle yasaktır ve bu elektronik postayı derhal silmeniz gerekmektedir.
> Şirketimiz bu mesajın içerdiği bilgilerin doğruluğu veya eksiksiz olduğu
> konusunda herhangi bir garanti vermemektedir. Bu nedenle, bu bilgilerin ne
> şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından ve
> saklanmasından sorumlu değildir. Bu mesajdaki görüşler yalnızca gönderen
> kişiye aittir ve Şirketimizin görüşlerini yansıtmayabilir. Tarafınız ile
> paylaşılan kişisel verilerin, 6698 sayılı Kişisel Verilerin Korunması
> Kanununa uygun olarak işlenmesi gereğini bilginize sunarız.
> --
>
> This e-mail and all files sent with it are intended for authorized natural
> or legal persons, who should be the only persons to open and read them. If
> you are not an authorized recipient, you are strictly prohibited from
> disclosing, copying, forwarding, and using the contents of this e-mail, and
> you must immediately delete it. Our company does not guarantee the accuracy
> or thoroughness of the information contained in this message. It is
> therefore in no way responsible for the content, sending, retrieval and
> storage of this information. The opinions contained in this message are the
> views of the sender only and do not necessarily reflect the views of the
> company. We would like to inform you that any personal data shared with you
> should be processed in accordance with the Law on Protection of Personal
> Data numbered 6698.
>
> 
>
>

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

Re: [vpp-dev] Help:VPP-DPDK #acl_plugin #dpdk

[Matthew Smith via lists.fd.io]

Are you calling those functions in an init/config function for your plugin?
Maybe they are being called before the dpdk plugin has executed
rte_eal_init().

-Matt


On Tue, Feb 7, 2023 at 4:05 AM kk  wrote:

> Hello everyone, I wrote a vpp plug-in by myself. I called the dpdk
> function interface "rte_ring_create and rte_mempool_create" in this
> plug-in, and then it will prompt:
> "MEMPOOL: Cannot allocate tailq entry!
> Problem getting send ring
> RING: Cannot reserve memory for tailq
> RING: Cannot reserve memory for tailq
> ",
> does anyone know what's going on?
> And I found that I have no problem calling this function interface in the
> vpp-dpdk plug-in.
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22561): https://lists.fd.io/g/vpp-dev/message/22561
Mute This Topic: https://lists.fd.io/mt/96804295/21656
Mute #acl_plugin:https://lists.fd.io/g/vpp-dev/mutehashtag/acl_plugin
Mute #dpdk:https://lists.fd.io/g/vpp-dev/mutehashtag/dpdk
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Linux-cp with Det44 stop working

[Matthew Smith via lists.fd.io]

Hi Petr,

Deterministic NAT is not compatible with linux-cp.

Linux-cp sets up some configuration for interfaces which are a member of a
linux-cp interface pair so that packets which arrive on the interface and
are punted get copied to the corresponding linux-cp tap. The packets which
are punted have a destination IP address that is "local' (usually interface
address or broadcast/multicast, but I believe that addresses in a NAT pool
also get local routes added) and are not handled by any other node via
registration of the destination protocol or port of the packet. For a
packet to be punted to the host across a linux-cp tap, it has to pass all
the way through the ip4-unicast feature arc. A FIB lookup happens at the
end of ip4-unicast, which determines that the destination is local and
passes packets to ip4-receive. From there, the packets can be sent across
the linux-cp tap.

Deterministic NAT has an out2in node on the ip4-unicast arc of an outside
interface which compares an inbound packet to any deterministic NAT
mappings that are configured. If it finds a relevant mapping & session for
the destination address/port, the destination address/port will be
rewritten and the packet will be forwarded. If none is found, the packet
will be dropped before it reaches the point where it could be punted and
sent across a linux-cp tap. So even though your inbound packets may be
addressed to the WAN interface address and not an address in the prefix
being used by deterministic NAT, they will be dropped. This seems to be the
default behavior of at least the det44, nat44-ed, and nat44-ei plugins -
they seem to assume that all packets passing through an interface should be
translated or dropped. IMO it seems like it would be better if an inbound
packet that has a destination address which is not in the NAT pool/prefix
should pass through the NAT out2in feature untouched, but that's not
currently how the NAT plugins work.

There is also a deterministic NAT in2out node on the ip4-unicast arc of an
inside interface that rewrites a packet's source address/port. This node
checks the source address to find if it matches an inside NAT prefix. If
not, the packet is dropped. If the source address is in an inside prefix,
the source address/port are rewritten. This happens, again, before the
packet reaches the end of ip4-unicast so the source address/port are
rewritten before it is determined that the destination address is local to
the system. I'm not sure exactly what happens once the FIB lookup occurs
and the packet is determined to have a local destination. I suspect that it
will be dropped by ip4_local_check_src() in ip4-receive (
https://github.com/FDio/vpp/blob/master/src/vnet/ip/ip4_forward.c#L1581)
because it will have a source address that is local and a destination
address that is local so it will be considered "spoofed". My guess may be
wrong and the packet may reach the tap but it will already have a rewritten
source address/port so replies sent by the host would not be sent to the
correct address/port.

I haven't experimented with it much, but I would guess that deterministic
NAT is not likely to be compatible with any other feature in VPP that
processes local packets (DHCP, DNS, IPsec/IKE, etc) for the same reasons
that linux-cp doesn't work.

-Matt


On Mon, Feb 6, 2023 at 8:18 AM Petr Boltík  wrote:

> Hi all,
>
> I have an issue with a combination of Linux-cp + Det44. If Det44 is
> activated, access to the VPP0 using Linux-cp is not working. All dynamic
> configuration possibility is lost. I lose access from both sides - WAN and
> LAN from any IP address (not only from configured 192.168.17.0/24).
> Any suggestions? In which section of VPP code is Det44 hooked before
> Linux-cp? Communication from PC1 to router0 successfully working. All ideas
> are welcome.
>
> Thank you very much
>
> Petr B.
>
>
> the simple scenario below ...
> 
> Upstream router0
> + address 192.168.15.1/24
> + route 213.192.0.0/32 via 192.168.15.2
> 
> VPP0 Device:
> WAN enp2s0
> + address 192.168.15.2/24
> + route 0.0.0.0/0 via 192.168.15.1
> + Linux-cp
>
> LAN enp3s0
> + address 192.168.16.1/24
> + route 192.168.17.0/24 via 192.168.16.2
> + Linux-cp
>
> det44 plugin enable
> set interface det44 inside enp3s0 outside enp2s0
> det44 add in 192.168.17.0/24 out 213.192.0.0/32
> -
> Internal router1
> + address 192.168.16.2/24 dev e1
> + address 192.168.17.1/24 dev e2
> + route 0.0.0.0/0 via 192.168.16.1
> -
> PC1 - test device
> + address 192.168.17.2/24
> + route 0.0.0.0/0 via 192.168.17.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22552): https://lists.fd.io/g/vpp-dev/message/22552
Mute This Topic: https://lists.fd.io/mt/96783537/21656
Group Owner: vpp-dev+ow...@lists.fd.io

Re: [vpp-dev] VPP Linux-CP/Linux-NL : MPLS?

[Matthew Smith via lists.fd.io]

No, this is not currently supported. MPLS configuration is not synched from
the host system using linux-nl. IP routes/addresses/neighbors and some
interface attributes (admin state, MTU, MAC address) are synched.

-Matt


On Tue, Jan 24, 2023 at 10:16 AM  wrote:

> Hello,
>
> I'm trying to populate MPLS FIB via Linux-CP plugin.
> MPLS records are created via FRR and populated to Linux Kernel routing
> table (I use default ns). Below one can see "push" operation and "swap"
> operation.
> mpls table 0 was created in vpp by "mpls table add 0" command.
> mpls was enabled on all the interfaces, both towards media and taps.
> Still, do not see anything in FIB. Should MPLS tables sync work, or may be,
> I forgot setup something in VPP?
>
> root@tn3:/home/abramov# ip -f mpls route show
> 40050 as to 41000 via inet6 fd00:200::2 dev Ten0.1914 proto static
> root@tn3:/home/abramov# ip -6 route show | grep 4
> fd00:100::4 nhid 209  encap mpls  4 via fd00:200::2 dev Ten0.1914
> proto static metric 20 pref medium
> root@tn3:/home/abramov# vppctl
>
> vpp# show mpls fib 0 40050
> MPLS-VRF:0, fib_index:1 locks:[interface:4, CLI:1, ]
> vpp# show ip6 fib
> ipv6-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ]
> epoch:0 flags:none locks:[adjacency:1, default-route:1, lcp-rt:1, ]
> ::/0
>   unicast-ip6-chain
>   [@0]: dpo-load-balance: [proto:ip6 index:6 buckets:1 uRPF:5 to:[0:0]]
> [0] [@0]: dpo-drop ip6
> fd00:100::4/128
>   unicast-ip6-chain
>   [@0]: dpo-load-balance: [proto:ip6 index:17 buckets:1 uRPF:17 to:[0:0]]
> [0] [@5]: ipv6 via fd00:200::2 TenGigabitEthernet1c/0/1.1914: mtu:9000
> next:5 flags:[] 2af08d2cf6163cecef5f778f8100077a86dd
> fd00:200::/64
>   unicast-ip6-chain
>   [@0]: dpo-load-balance: [proto:ip6 index:15 buckets:1 uRPF:14 to:[0:0]]
> [0] [@4]: ipv6-glean: [src:fd00:200::/64]
> TenGigabitEthernet1c/0/1.1914: mtu:9000 next:2 flags:[]
> 3cecef5f778f8100077a86dd
> fd00:200::1/128
>   unicast-ip6-chain
>   [@0]: dpo-load-balance: [proto:ip6 index:16 buckets:1 uRPF:15
> to:[10:848]]
> [0] [@20]: dpo-receive: fd00:200::1 on TenGigabitEthernet1c/0/1.1914
> fd00:200::2/128
>   unicast-ip6-chain
>   [@0]: dpo-load-balance: [proto:ip6 index:18 buckets:1 uRPF:12 to:[0:0]]
> [0] [@5]: ipv6 via fd00:200::2 TenGigabitEthernet1c/0/1.1914: mtu:9000
> next:5 flags:[] 2af08d2cf6163cecef5f778f8100077a86dd
> fe80::/10
>   unicast-ip6-chain
>   [@0]: dpo-load-balance: [proto:ip6 index:7 buckets:1 uRPF:6 to:[8:544]]
> [0] [@14]: ip6-link-local
> vpp# show mpls fib
> MPLS-VRF:0, fib_index:1 locks:[interface:4, CLI:1, ]
> ip4-explicit-null:neos/21 fib:1 index:30 locks:2
>   special refs:1 entry-flags:exclusive,
> src-flags:added,contributing,active,
> path-list:[43] locks:2 flags:exclusive, uPRF-list:31 len:0 itfs:[]
>   path:[53] pl-index:43 mpls weight=1 pref=0 exclusive:
> oper-flags:resolved, cfg-flags:exclusive,
> [@0]: dst-address,unicast lookup in interface's mpls table
>
>  forwarding:   mpls-neos-chain
>   [@0]: dpo-load-balance: [proto:mpls index:33 buckets:1 uRPF:31 to:[0:0]]
> [0] [@4]: dst-address,unicast lookup in interface's mpls table
> ip4-explicit-null:eos/21 fib:1 index:29 locks:2
>   special refs:1 entry-flags:exclusive,
> src-flags:added,contributing,active,
> path-list:[42] locks:2 flags:exclusive, uPRF-list:30 len:0 itfs:[]
>   path:[52] pl-index:42 mpls weight=1 pref=0 exclusive:
> oper-flags:resolved, cfg-flags:exclusive,
> [@0]: dst-address,unicast lookup in interface's ip4 table
>
>  forwarding:   mpls-eos-chain
>   [@0]: dpo-load-balance: [proto:mpls index:32 buckets:1 uRPF:30 to:[0:0]]
> [0] [@3]: dst-address,unicast lookup in interface's ip4 table
> router-alert:neos/21 fib:1 index:27 locks:2
>   special refs:1 entry-flags:exclusive,
> src-flags:added,contributing,active,
> path-list:[40] locks:2 flags:exclusive, uPRF-list:28 len:0 itfs:[]
>   path:[50] pl-index:40 mpls weight=1 pref=0 exclusive:
> oper-flags:resolved, cfg-flags:exclusive,
> [@0]: dpo-punt
>
>  forwarding:   mpls-neos-chain
>   [@0]: dpo-load-balance: [proto:mpls index:30 buckets:1 uRPF:28 to:[0:0]]
> [0] [@2]: dpo-punt
> router-alert:eos/21 fib:1 index:28 locks:2
>   special refs:1 entry-flags:exclusive,
> src-flags:added,contributing,active,
> path-list:[41] locks:2 flags:exclusive, uPRF-list:29 len:0 itfs:[]
>   path:[51] pl-index:41 mpls weight=1 pref=0 exclusive:
> oper-flags:resolved, cfg-flags:exclusive,
> [@0]: dpo-punt
>
>  forwarding:   mpls-eos-chain
>   [@0]: dpo-load-balance: [proto:mpls index:31 buckets:1 uRPF:29 to:[0:0]]
> [0] [@2]: dpo-punt
> ipv6-explicit-null:neos/21 fib:1 index:32 locks:2
>   special refs:1 entry-flags:exclusive,
> src-flags:added,contributing,active,
> path-list:[45] locks:2 flags:exclusive, uPRF-list:33 len:0 itfs:[]
>   path:[55] pl-index:45 mpls weight=1 pref=0 exclusive:
> oper-flags:resolved, cfg-flags:exclusive,
> [@0]: 

Re: [vpp-dev] Linux-cp Plugin Bird Routes Not Showing Up in VPP

[Matthew Smith via lists.fd.io]

We only set the default netns via startup.conf, so it is not critical to us
to be able to do it via CLI/API.

We don't currently create interface pairs in any netns other than the
default one. So it's not critical for us to be able to set a netns on a
per-pair basis currently.

-Matt


On Sun, Jan 8, 2023 at 5:54 PM Pim van Pelt  wrote:

> +Matthew Smith  and +Jon Loeliger  can
> you let me know what you think?
> Does Netgate value the 'lcp default netns' or ability to create LIPs in a
> namespace other than 'dataplane'?
> As I described, I think the ability to change these in the API, or set
> them in 'lcp create' yields erratic behavior.
>
> groet,
> Pim
>
> On Thu, Dec 22, 2022 at 4:28 PM Pim van Pelt  wrote:
>
>> Hoi,
>>
>>
>> On Thu, Dec 22, 2022 at 4:08 PM Matthew Smith via lists.fd.io > netgate@lists.fd.io> wrote:
>>
>>>
>>> On Thu, Dec 22, 2022 at 7:09 AM Petr Boltík 
>>> wrote:
>>>
>>>>
>>>> - To make "plugin linux_nl_plugin.so" working, you need to run VPP
>>>> inside netns dataplane (same as bird). This can be done by editing VPP
>>>> systemd startup file (add something like "
>>>> NetworkNamespacePath=/var/run/netns/dataplane" ) and ensuring that
>>>> netns "dataplane" will be started first.
>>>>
>>>
>>> I run VPP in the default netns and use FRR & iproute2 in the dataplane
>>> netns and it works fine. I test this regularly on AWS, Azure, KVM, and bare
>>> metal. I don't set the netns with vppctl CLI commands though, I set it in
>>> startup.conf with 'linux-cp { default netns dataplane }'. I will look into
>>> whether something is broken with the CLI command.
>>>
>> I run VPP in default netns and Bird2 & iproute2 in the dataplane netns. I
>> set default netns dataplane in startup.conf also.
>>
>> I think OP has a different problem, because I do see their netlink
>> messages arriving otherwise. One test that you can do, is in the network
>> namespace, change the link attribute (like ip link set  mtu 1500; or
>> ip link set  up; or down; and then see if 'vppctl show int' reflects
>> that change. That would demonstrate that end-to-end, netlink messages are
>> arriving from the dataplane netns, through kernel, through linux_nl plugin
>> and finally into the dataplane.
>>
>> One plausible explanation for the behavior is that linux_nl starts the
>> netlink listener immediately, based on startup.conf, and it does not change
>> its mind when you specify 'lcp netns default' on the CLI, in other words:
>> it will only listen to one namespace, namely the one it found when it
>> started up. I think this is OP's issue, and if so, then 'lcp netns' is
>> broken in linux-cp, it can never work, and actually should be considered
>> harmful because there will only be one netns listened to, so changing it
>> midflight will give erratic results. The same is true for the 'netns'
>> argument to lcp create -- the only place where linux_nl will ever pick up
>> netlink messages is in the very first namespace it started in, as specified
>> in startup.conf.
>>
>> As a point of comparison - lcpng will start a netlink listener *once the
>> first LIP is created*; which is why it will start the listener in either
>> what was setup in startup.conf, or what it changed to with 'lcp default
>> netns', to any value set before the very first interface pair is created.
>> 'lcp default netns' works there, but as with linux_nl, if any LIP is
>> created in a netns other than the initial one which has the (one and only)
>> netlink listener in it), it will give unexpected results.
>>
>> I think we should:
>> - remove lcp netns default from CLI
>> - remove changing the netns from API
>> - force use of only startup.conf to start the netlink listener in that,
>> and only that, network namespace.
>>
>> Thoughts ?
>>
>> --
>> Pim van Pelt 
>> PBVP1-RIPE - http://www.ipng.nl/
>>
>
>
> --
> Pim van Pelt 
> PBVP1-RIPE - http://www.ipng.nl/
>

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

Re: [vpp-dev] Slow VPP performance vs. DPDK l2fwd / l3wfd

[Matthew Smith via lists.fd.io]

Did you see my other suggestion about increasing buffers-per-numa? Your
NICs were missing some RX's because no buffers were available.

Setting the main heap page size to use either 2M or 1G hugepages instead of
using default 4k pages will probably help too.

-Matt


On Tue, Jan 3, 2023 at 1:37 PM  wrote:

> Hi Matt,
>
> thanks. The *no-multi-seq *option is actually dropping the performance
> even more. Once enable it drops from 5 Mpps ( out of expected 10 Mpps) to
> less than < 1 Mpps. Therefore I disabled the option again.
>
> The dpdk applications foward the full 10 Mpps without any dev-args:
>
> ./dpdk-l2fwd -n 4 -l 6  -a :4b:00.0 -a :4b:00.1   -- -q 2 -p 0x3
>
> but also adding those options confirm the full 10 Mpps. Either way *l2fwd*
> will not drop any packets and run the full load.
>
> ./dpdk-l2fwd -n 4 -l 6  -a
> :4b:00.0,mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9,txq_inline_mpw=128,rxq_pkt_pad_en=1,dv_flow_en=0
> -a
> :4b:00.1,mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9,txq_inline_mpw=128,rxq_pkt_pad_en=1,dv_flow_en=0
>  -- -q 2 -p 0x3
>
>
> Contrary by using the default */etc/vpp/startup.conf *options of DPDK I
> only yield 4 Mpps out of 10 Mpps expected.
> Once I added the devargs
> *mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9,txq_inline_mpw=128,rxq_pkt_pad_en=1,dv_flow_en=0
>  *it
> gained another 20% ( as recommended in DPDK mellanox perf-report )
> 
>
>

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

Re: [vpp-dev] Slow VPP performance vs. DPDK l2fwd / l3wfd

[Matthew Smith via lists.fd.io]

What arguments did you pass to l2fwd and l3fwd when you started them up?

Your NIC statistics show RX misses due to lack of available buffers

HundredGigabitEthernet4b/0/0   1 up   HundredGigabitEthernet4b/0/0
[...]
  rx_out_of_buffer 86941
HundredGigabitEthernet4b/0/1   2 up   HundredGigabitEthernet4b/0/1
[...]
  rx_out_of_buffer155395

I don't know if those errors are enough to cause the difference in your
throughput measurements between l2fwd/l3fwd and VPP, but it would probably
be worthwhile to increase buffers-per-numa and repeat your tests.

I have heard advice in the past that performance with Mellanox DPDK PMDs
can be improved by setting the no-multi-seg option. I don't know whether
that is still true and I never compared performance with that option set vs
without, so I'm not sure how much it would help. But it may be worth trying.

Thanks,
-Matt


On Tue, Jan 3, 2023 at 8:21 AM  wrote:

> Hi @Benoit, yes I can confirm NIC and VPP worker are on same node-0 . I am
> also using the same core-id for the benchmark comparison against plain dpdk
> l2fwd/l3fwd.
> 
>
>

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

Re: [vpp-dev] Linux-cp Plugin Bird Routes Not Showing Up in VPP

[Matthew Smith via lists.fd.io]

On Thu, Dec 22, 2022 at 7:09 AM Petr Boltík  wrote:

>
> - To make "plugin linux_nl_plugin.so" working, you need to run VPP inside
> netns dataplane (same as bird). This can be done by editing VPP systemd
> startup file (add something like "
> NetworkNamespacePath=/var/run/netns/dataplane" ) and ensuring that netns
> "dataplane" will be started first.
>

I run VPP in the default netns and use FRR & iproute2 in the dataplane
netns and it works fine. I test this regularly on AWS, Azure, KVM, and bare
metal. I don't set the netns with vppctl CLI commands though, I set it in
startup.conf with 'linux-cp { default netns dataplane }'. I will look into
whether something is broken with the CLI command.

-Matt



> čt 22. 12. 2022 v 13:53 odesílatel Christopher Adigun 
> napsal:
>
>> Hi Petr,
>>
>> Thanks for the response, bird is actually running in the dataplane ns:
>>
>> root@nat-gw-697d886cb4-xn62q:/etc/bird# *ip netns exec dataplane ip a*
>> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
>> default qlen 1000
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> inet 127.0.0.1/8 scope host lo
>>valid_lft forever preferred_lft forever
>> inet6 ::1/128 scope host
>>valid_lft forever preferred_lft forever
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *2: loop0:  mtu 9000 qdisc mq state UP
>> group default qlen 1000link/ether de:ad:00:00:00:00 brd
>> ff:ff:ff:ff:ff:ffinet 192.168.163.2/32  scope
>> global loop0   valid_lft forever preferred_lft foreverinet6
>> fe80::dcad:ff:fe00:0/64 scope link   valid_lft forever preferred_lft
>> forever3: xe0-1:  mtu 9001 qdisc mq state
>> UNKNOWN group default qlen 1000link/ether 02:40:0a:84:e3:83 brd
>> ff:ff:ff:ff:ff:ffinet 10.0.5.10/24  scope global
>> xe0-1   valid_lft forever preferred_lft foreverinet6
>> fe80::40:aff:fe84:e383/64 scope link   valid_lft forever preferred_lft
>> forever*
>> root@nat-gw-697d886cb4-xn62q:/etc/bird#
>> root@nat-gw-697d886cb4-xn62q:/etc/bird#
>> root@nat-gw-697d886cb4-xn62q:/etc/bird# ip netns exec *dataplane *ip r
>> 10.0.5.0/24 dev xe0-1 proto kernel scope link src 10.0.5.10
>> 10.45.0.0/16 via 10.0.5.9 dev xe0-1 proto bird
>>
>> One other thing, I am running this in a kubernetes POD, maybe this might
>> be affecting something.
>>
>> Also can you clarify how to perform *plugin "linux_nl_plugin.so" ignore
>> "lcp default netns" configuration?* Should this be placed in the
>> startup.conf or init.conf?
>> I want to test without netns, I tried the following in the startup config
>> but vpp was crashing
>>
>> plugin "linux_nl_plugin.so" {
>>   ignore "lcp default netns"
>> }
>>
>> I also tried using the full command in init.conf but that did not work.
>>
>>
>> On Thu, Dec 22, 2022 at 4:22 AM Petr Boltík 
>> wrote:
>>
>>> Hi,
>>>
>>> there can be a few misconfigurations:
>>> 1. "lcp default netns dataplane" start synchronizing
>>> interfaces/address/etc inside netns "dataplane" (netns "dataplane" must
>>> exist) - NOT synchronizing routes
>>> 2. plugin "linux_nl_plugin.so" ignore "lcp default netns" configuration
>>> =>  "linux_nl_plugin.so" will synchronize VPP with default namespace "0"
>>>
>>> Solution with netns:
>>> 0. Create netns "dataplane" with systemd
>>> 1. run VPP inside netns "dataplane" (edit systemd, start after previous
>>> point)
>>> 2. run Bird inside netns "dataplane" (edit systemd, start after previous
>>> point)
>>> 3. do not use "lcp default netns dataplane", it is controlled by VPP
>>> netns
>>>
>>> For running without netns only skip "lcp default netns dataplane".
>>>
>>> Petr
>>>
>>> čt 22. 12. 2022 v 10:07 odesílatel Pim van Pelt via lists.fd.io >> ipng...@lists.fd.io> napsal:
>>>
 Hoi,

 Is bird running in the 'dataplane' network namespace ?

 groet,
 Pim

 On Thu, Dec 22, 2022 at 12:52 AM Christopher Adigun <
 future...@gmail.com> wrote:

> Hi,
>
> I am currently trying to use linx-cp plugins to sync routes learned
> via BGP, bird is seeing the BGP route but I can't see the routes in VPP.
>
> Details:
>
> *vpp v22.10-release built by root on ff42e25458af at
> 2022-10-26T14:00:24*
>
> *startup.conf:*
>
> unix {
>   nodaemon
>   log /tmp/vpp.log
>   full-coredump
>   gid vpp
>   interactive
>   cli-listen /run/vpp/cli.sock
>   exec /etc/vpp/init.conf
> }
>
> cpu {
>   main-core 1
>   corelist-workers 19
> }
>
> memory {
>   main-heap-size 2G
> }
> api-trace {
>   on
> }
>
> dpdk {
>  dev :00:09.0 {name n6}
>  dev :00:07.0 {name internet}
> }
>
> api-segment {
>   gid vpp
> }
>
> plugins {
>   path /usr/lib/x86_64-linux-gnu/vpp_plugins/
>   plugin ping_plugin.so { disable }
>   plugin linux_cp_plugin.so { enable }
>   plugin linux_nl_plugin.so { enable }
>   plugin 

Re: [vpp-dev] mellanox mlx5 + rdma + lcpng + bond - performance (tuning ? or just FIB/RIB processing limit) (max performance pps about 2Mpps when packet drops starts)

[Matthew Smith via lists.fd.io]

HI Pawel,

On Sat, Dec 17, 2022 at 6:28 PM Paweł Staszewski 
wrote:

> Hi
>
>
> So without bgp (lcp) and only one static route performance is basically as
> it is on "paper" 24Mpps/100Gbit/s without problem.
>
> And then no matter if with bond or without bond (with lcp) there are
> problems starting.
>

When you tried it without bgp, did you still use lcp to manage
interfaces/addresses and add the single static route? If not, could you try
that and report whether the problem still occurs?

How many routes is your BGP daemon adding to VPP's FIB?

Are you isolating the cores that worker threads are bound to (e.g. via
isolcpus kernel argument or via cpuset)?


>
> Basically side where im Receiving most traffic that need to be TX-ed to
> other interface is ok.
>
> Interface with most RX traffic on vlan 2906 has ip address and when I ping
> from this ip address to ptp ip other side - there is no packet drops.
>
> But on the interface where this traffic trat was RX-ed from this vlan2906
> - and need to be TX-ed on vlan 514 - there are drops to ptp ip of other
> side - from 10 to 20%
>
> Same is when I ping /mtr from RX-side to TX side there are drops - but
> there are no drops when I ping from TX side to RX side - so forwarding is
> done other side thru interface that has most RX - less TX
>

How are you measuring packet loss? You mentioned 10 to 20% drops by ping &
mtr above. Are those tools all you're using, or are you running some
traffic generator like T-rex? My reason for asking is that when I look in
the 'show runtime' output you sent at the number of packets ("vectors")
handled by rdma-input on each thread and compare it to the number of
packets handled by enp59s0f0-rdma-output and enp59s0f1-rdma-output in the
same thread, the difference is much much smaller than 10 - 20%. So some
more specific information on how you're measuring that there is 10-20%
packet loss would be useful. Is the 10-20% packet loss only observed when
communicating directly to the interface addresses on the host system or are
10-20% of packets which should be forwarded between interfaces by VPP being
dropped?

I notice you mentioned "lcpng", which is a customized version of linux-cp.
I'm not sure the differences between the stock versions of
linux-cp/linux-nl and the code in lcpng. Have you tried this experiment
with the stock version of linux-cp/linux-nl from the VPP master branch on
gerrit?

Also, as Ben previously requested, the output of 'show errors' and  'show
hardware-interfaces' would be helpful.

Thanks,
-Matt

So it looks like interface busy with RX-traffix is ok - problem is when
> interface is mostly TX-ing traffic RX-ed from other interface... but dont
> know how to check what is causing it ... ethtool -S for any interface is
> showing no errors/drops at interface lvl.
>
>
>
>
> On 12/16/22 10:51 AM, Benoit Ganne (bganne) via lists.fd.io wrote:
>
> Hi,
>
>
> So the hardware is:
> Intel 6246R
> 96GB ram
> Mellanox Connect-X 5 2x 100GB Ethernet NIC
> And simple configuration  with vpp/frr where one vlan interface all
> traffix is RX-ed and second vlan interface where this traffic is TX-ed -
> it is normal internet traffic - about 20Gbit/s with 2Mpps
>
> 2Mpps looks definitely too low, in a similar setup, CSIT measures IPv4 NDR 
> with rdma at ~17.6Mpps with 2 workers on 1 core (2 hyperthreads): 
> http://csit.fd.io/trending/#eNrlkk0OwiAQhU-DGzNJwdKuXFh7D0NhtE36QwBN6-mljXHahTt3LoCQb-Y95gUfBocXj-2RyYLlBRN5Y-LGDqd9PB7WguhBtyPwJLmhsFyPUmYKnOkUNDaFLK2Aa8BQz7e4KuUReuNmFXGeVcw9bCSJ2Hoi8t2IGpRDRR3RjVBAv7LZvoeqrk516JsnUmmcgLiOeRDieqsfJrui7yHzcqn4XXj2H8Kzn_BkuesH1y0_UJYvWG6xEg
>
> The output of 'sh err' and 'sh hard' would be useful too.
>
>
> Below vpp config:
>
> To start with, I'd recommend doing a simple test removing lcp, vlan & bond to 
> see if you can reproduce CSIT performance, and then maybe add bond and 
> finally lcp and vlan. This could help narrowing where performance drops.
>
>
> Below also show run
>
> The vector rate is really low, so it is really surprising there are drops...
> Do you capture the show run output when you're dropping packets? Basically, 
> when traffic is going through VPP and performance is maxing out, do 'cle run' 
> and then 'sh run' to see the instantaneous values and not averages.
>
>
> Anyone know how to interpret this data ? what are the Suspends for
> api-rx-from-ring ?
>
> This is a control plane task in charge of processing API messages. VPP uses 
> cooperative multitasking within the main thread for control plane tasks, 
> Suspends counts the number of times this specific task voluntarily released 
> the CPU, yielding to other tasks.
>
>
> and how to check what type of error(traffic) is doing drops:
>
> You can capture dropped traffic:
> pcap trace drop
> 
> pcap trace drop off
>
> You can also use VPP packet tracer:
> tr add rdma-input 1000
> 
> tr filter include error-drop 1000
> sh tr max 1000
>
> Best
> ben
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to 

Re: [vpp-dev] Bug report - IP6 ND RA default route disappear from host device

[Matthew Smith via lists.fd.io]

Hi Petr,

You didn't miss any configuration. I don't see any place where the router
flag is set on an NA in current VPP master branch code.

Can you test with https://gerrit.fd.io/r/c/vpp/+/37582 applied and see if
it addresses the issue?

-Matt




On Fri, Nov 4, 2022 at 1:49 PM Petr Boltík  wrote:

> Hi,
>
> Thanks for your reply.
>
> I did a packet capture using Wireshark to compare RA from the
> VPP/MikroTik/Radvd. There is no problem with routing advertisements from
> VPP, but with Neighbor Advertisement when RA is enabled. ICMP v6 flag is
> not set correctly - The Router flag is NOT set on the VPP side. Debian 11
> ignores this, Windows and a few others remove the default gateway after
> receiving this neighbor advertisement. Wireshark .pcapng in the link.
>
> I use the Kea6 dhcp6 server for prefix delegation + VPP for RA (not using
> radvd - only for testing). Many users want to use VPP as a home gateway and
> IPv6 RA not working correctly with various end-user devices (like windows
> for this testing scenario).
>
> VPP RA+ND - line 914
> MikroTik RA+ND - line 819
>
> https://easyupload.io/m/xwvqjj
>
> If I missed something in the configuration of VPP, please let me know. I
> did not find any relevant CLI
>
> Best regards
> Petr
>
>
> pá 4. 11. 2022 v 13:25 odesílatel Benoit Ganne (bganne) via lists.fd.io
>  napsal:
>
>> Hi Petr,
>>
>> Unfortunately I can't confirm the issue, but I do not think it is a very
>> commonly tested scenario so it is not really surprising...
>> What could help understand the issue would be if you could capture the RA
>> traffic in both scenarios (VPP vs radvd) so we can compare.
>>
>> Best
>> ben
>>
>> > -Original Message-
>> > From: vpp-dev@lists.fd.io  On Behalf Of Petr
>> Boltík
>> > Sent: Friday, November 4, 2022 12:50
>> > To: vpp-dev 
>> > Subject: Re: [vpp-dev] Bug report - IP6 ND RA default route disappear
>> from
>> > host device
>> >
>> > Hi all,
>> >
>> > Can someone please confirm this VPP IP6 RA issue? Any idea is welcome. I
>> > already tested the latest VPP build v23.02-rc0~96-ge69d97438~b598 with
>> no
>> > success. Installed default IP6 GW on Windows7/10/UBNTairOS disappeared
>> > after a short time. Thanks
>> >
>> > Best regards
>> > Petr B.
>> >
>> > pá 28. 10. 2022 v 18:37 odesílatel Petr Boltík > >  > napsal:
>> >
>> >
>> >   Hi all,
>> >
>> >   I have discovered the problem with IP6 ND RA receiving side - it
>> > can be observed on Windows 10/7/UBNT airos8 and some others. Issue not
>> > observed on the Debian 11+nmcli. Configuration is pretty
>> straightforward.
>> > Tested with VPP 22.06, 22.10. Issue persists. VPP configuration is the
>> > default, tested on APU4D4 and a few others. No linuxcp/nl is used.
>> >
>> >   1. configure VPP:
>> >
>> >   set interface ip address GigabitEthernet3/0/0
>> 2a01:500::1/64
>> >   set interface state GigabitEthernet3/0/0 up
>> >   create loopback interface
>> >   set interface state loop0 up
>> >   set interface ip address loop0 2a01:400::1/64
>> >   ip6 nd GigabitEthernet3/0/0 prefix 2a01:500::/64 default
>> >   ip6 nd GigabitEthernet3/0/0 no ra-suppress
>> >
>> >
>> >
>> >   vpp# show version
>> >
>> >   vpp v22.10-release built by root on 89a4591888eb at
>> 2022-10-
>> > 26T14:00:30
>> >
>> >
>> >   2. connect host Windows7/10/ubnt to the GigabitEthernet3/0/0 and
>> > you can observe weird behavior
>> >   - RA from VPP is received, IP6 address is installed. Icmp echo to
>> > the VPP link local address and configured 2a01:500::1 works.
>> >   - RA from VPP is received, IP6 default route is installed and
>> > works. Icmp echo to the 2a01:400::1 works.
>> >
>> >
>> >   Issue:  After stopping all icmp echo for a few seconds/minutes,
>> IP6
>> > default route is removed from the host system, and the path to the
>> > 2a01:400::1 is unknown for the host. The default route is removed - the
>> > host device ignores ra-lifetime.
>> >
>> >   LinuxCP/NL + RADVD sollution test:
>> >   I have already tried to solve this problem by using linuxcp/nl and
>> > RADVD, but there is another issue. When radvd start, communication from
>> > the external host to the link-local address stop passing. The host
>> device
>> > successfully receives prefix and default route, but the default route is
>> > via the link-local address and the vpp link-local address is
>> inaccessible
>> > from the host device after radvd start.
>> >
>> >   Best regards
>> >   Petr Boltik
>> >
>> >
>>
>>
>>
>>
>>
> 
>
>

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

Re: [vpp-dev] Wireguard with Linux Control Plane

[Matthew Smith via lists.fd.io]

Hi Landy,

The packet you're receiving is probably not encrypted. You can see that
it was successfully decrypted after wg4-input because the trace shows the
inside addresses (192.168.42.7 -> 192.168.42.6). None of the nodes after
that point would have encrypted it again. The likely explanation is that
the buffer that the packet was written to still contains the outside
ethernet and IP headers, the inside packet was decrypted in place and a
current_data field was set with the offset of that packet. Since the packet
gets handed off to an L2 tap interface, the tap output node finds and uses
the original L2 headers. The decrypted packet is likely still sitting in
the payload.

When you create the linux-cp pair for an L3 tunnel interface, you need to
add the keyword 'tun' to the command. By default a tap (L2) interface is
created. Adding 'tun' to the command will create a tun (L3) interface. If
you do this, everything is likely to work as expected.

-Matt



On Thu, Oct 20, 2022 at 2:15 PM Landy Bible  wrote:

> I captured a trace of an incoming ping packet, and I have included it
> below.
>
> This is a ping from 192.168.42.7 (remote wireguard peer, tunnel
> address) to 192.168.42.6 ( local vpp host, tunnel address )
>
> It appears everything is good all the way through the punt stage, but
> for some reason the packet that's written to the tap7 interface ends
> up being the encrypted wireguard packet, not the unencrypted ping
> packet that had been previously processed that lead to the punt stage.
>
> -Landy
>
> 00:11:16:258487: dpdk-input
>   TenGigabitEthernet1/0/0 rx queue 0
>   buffer 0x4b0273: current data 0, length 170, buffer-pool 0,
> ref-count 1, trace handle 0x147
>ext-hdr-valid
>   PKT MBUF: port 0, nb_segs 1, pkt_len 170
> buf_len 2176, data_len 170, ol_flags 0x180, data_off 128,
> phys_addr 0x3c09d40
> packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Offload Flags
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>   PKT_RX_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt.
>   PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
>   PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt.
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>   RTE_PTYPE_L4_UDP (0x0200) UDP packet
>   IP4: e0:0e:da:a9:01:0d -> 3c:ec:ef:28:9c:70
>   UDP: 10.255.1.49 -> 207.188.7.26
> tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
> fragment id 0x29f4
>   UDP: 51822 -> 51820
> length 136, checksum 0x7aa1
> 00:11:16:258487: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   IP4: e0:0e:da:a9:01:0d -> 3c:ec:ef:28:9c:70
> 00:11:16:258499: ip4-input-no-checksum
>   UDP: 10.255.1.49 -> 207.188.7.26
> tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
> fragment id 0x29f4
>   UDP: 51822 -> 51820
> length 136, checksum 0x7aa1
> 00:11:16:258510: ip4-lookup
>   fib 0 dpo-idx 10 flow hash: 0x
>   UDP: 10.255.1.49 -> 207.188.7.26
> tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
> fragment id 0x29f4
>   UDP: 51822 -> 51820
> length 136, checksum 0x7aa1
> 00:11:16:258524: ip4-receive
> UDP: 10.255.1.49 -> 207.188.7.26
>   tos 0x00, ttl 60, length 156, checksum 0x7157 dscp CS0 ecn NON_ECN
>   fragment id 0x29f4
> UDP: 51822 -> 51820
>   length 136, checksum 0x7aa1
> 00:11:16:258539: ip4-udp-lookup
>   UDP: src-port 51822 dst-port 51820
> 00:11:16:258555: wg4-input
>   Wireguard input:
> Type: Data
> Peer: 0
> Length: 96
> Keepalive: false
> 00:11:16:258576: ip4-input-no-checksum
>   ICMP: 192.168.42.7 -> 192.168.42.6
> tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
> fragment id 0x4f4c, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x5c07 id 11
> 00:11:16:258593: ip4-lookup
>   fib 0 dpo-idx 18 flow hash: 0x
>   ICMP: 192.168.42.7 -> 192.168.42.6
> tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
> fragment id 0x4f4c, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x5c07 id 11
> 00:11:16:258612: ip4-receive
> ICMP: 192.168.42.7 -> 192.168.42.6
>   tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
>   fragment id 0x4f4c, flags DONT_FRAGMENT
> ICMP echo_request checksum 0x5c07 id 11
> 00:11:16:258632: ip4-icmp-input
>   ICMP: 192.168.42.7 -> 192.168.42.6
> tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
> fragment id 0x4f4c, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x5c07 id 11
> 00:11:16:258652: ip4-punt
> ICMP: 192.168.42.7 -> 192.168.42.6
>   tos 0x00, ttl 64, length 84, checksum 0x15ff dscp CS0 ecn NON_ECN
>   fragment id 0x4f4c, flags DONT_FRAGMENT
> ICMP echo_request checksum 0x5c07 id 11
> 00:11:16:258674: 

Re: [vpp-dev] vpp vpp v22.10-rc0~177-g563d34ba9 lcp create unknown input `' problem

[Matthew Smith via lists.fd.io]

Hi,

The help text can be displayed with '?' rather than 'help':
vpp# lcp create ?
  lcp create   lcp create
| host-if  netns  [tun]

When you ran 'lcp create 1', you got a different error message than you did
with the rest of your commands. That suggests that 1 is a valid
sw_if_index. The command 'lcp create 1 host-if ens1f1np1' may work. Since
you got an error when you tried other commands using 'e0', e0 is probably
not a valid interface in your VPP instance. What interfaces are displayed
by 'show interface'?

Thanks,
-Matt


On Wed, Sep 7, 2022 at 5:32 PM Paweł Staszewski 
wrote:

> Hi
>
>
> Was trying linux-cp vpp and the problem is that i cant create any
> interface with lcp because any command is like this:
>
> vpp# lcp create
> vpp# lcp create help
> lcp create: unknown input `'
> vpp# lcp create default
> lcp create: unknown input `'
> vpp# lcp create
> vpp# lcp create1
> lcp: unknown input `create1'
> vpp# lcp create
> vpp# lcp create  1
> lcp create: host interface name required
> vpp# lcp create  e0 host-if ens1f1np1
> lcp create: unknown input `'
> vpp# lcp create  e0 host-if
> lcp create: unknown input `'
> vpp# lcp create  e0 host-if
> lcp create: unknown input `'
> vpp# lcp create  e0  host-if
> lcp create: unknown input `'
> vpp# lcp create  e0  host-if
> lcp create: unknown input `'
> vpp# lcp create  e0  host-if
> lcp create: unknown input `'
> vpp# lcp create "e0"
> lcp create: unknown input `'
> vpp# lcp create 'e0'
> lcp create: unknown input `'
> vpp# lcp create 'e0' host-if 'abc'
> lcp create: unknown input `'
> vpp# lcp create  e0 host-if ens1f1np1
> lcp create: unknown input `'
>
>
> 
>
>

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

Re: [vpp-dev] VPP crashing when lcp is enabled and I try to add an interface to a linux bridge.

[Matthew Smith via lists.fd.io]

Hi Pragya,

I'm not aware of any plans to implement support for that. The main focus of
linux-cp/linux-nl so far has been to connect L3 networking on the host
system to VPP.

What's the use case you are trying to support? Bridging packets between VPP
hardware interfaces in L2 mode? Or bridging packets between a
kernel-managed interface and a VPP hardware interface?

-Matt




On Tue, Aug 23, 2022 at 11:02 PM Pragya Nand Bhagat <
pragya.nand.bhaga...@gmail.com> wrote:

> Hi Matthew,
>
> Yes I meant the same.
> Automatically creating a bridge domain in VPP and adding/removing member
> interfaces based on netlink messages.
>
> Thank You
> Pragya Nand
>
> On Wed, Aug 24, 2022 at 12:25 AM Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
>
>>
>> On Tue, Aug 23, 2022 at 7:40 AM Pragya Nand Bhagat <
>> pragya.nand.bhaga...@gmail.com> wrote:
>>
>>> Hi Matthew,
>>>
>>> Thanks for looking into this issue.
>>> After applying the patch the crash is not seen.
>>>
>>> However as mentioned earlier, we have faced this issue when configuring
>>> the bridge domain and adding a member port to it.
>>>
>>>1. create a bridge [ brctl addbr 100]
>>>2. try adding a interface to it [ brctl addif 100 Ethernet0 ]
>>>
>>> *Is there any plan to support this in VPP Linux cp*
>>>
>>>
>> Hi Pragya,
>>
>> What do you mean by "support this"? Are you talking about automatically
>> creating a bridge domain in VPP and adding/removing member interfaces based
>> on netlink messages? Or something else?
>>
>> -Matt
>>
>>
>>
>>> On Sat, Aug 20, 2022 at 2:13 AM Matthew Smith via lists.fd.io >> netgate@lists.fd.io> wrote:
>>>
>>>>
>>>> Hi Pragya,
>>>>
>>>> This patch should fix it - https://gerrit.fd.io/r/c/vpp/+/36961. Can
>>>> you apply it to your build and confirm whether it resolves the issue?
>>>>
>>>> Thanks,
>>>> -Matt
>>>>
>>>>
>>>> On Wed, Aug 17, 2022 at 6:55 AM Pragya Nand Bhagat <
>>>> pragya.nand.bhaga...@gmail.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I'm seeing a crash in VPP when we try to add a port to a bridge .
>>>>> VPP  is running with the lcp plugin.
>>>>>
>>>>>
>>>>> lcp default netns ''
>>>>> lcp lcp-auto-subint off
>>>>> lcp lcp-sync on
>>>>> lcp del-static-on-link-down off
>>>>> lcp del-dynamic-on-link-down off
>>>>>
>>>>> itf-pair: [0] port0/0 tap1 Ethernet0 96 type tap
>>>>> Following are the steps to recreate :
>>>>>
>>>>>
>>>>>
>>>>>1. create a bridge [ brctl addbr 100]
>>>>>2. try adding a interface to it [ brctl addif 100 Ethernet0 ]
>>>>>3. VPP crashes
>>>>>
>>>>> We got the following stack trace .
>>>>>
>>>>>
>>>>> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
>>>>> 0x7f1239448c30 in nl_addr_get_family () from
>>>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>>>> (gdb) bt
>>>>> #0  0x7f1239448c30 in nl_addr_get_family () from
>>>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>>>> #1  0x7f12393b9025 in lcp_router_mk_addr (rna=0x0,
>>>>> ia=0x7f123703ade0) at /vpp/src/plugins/linux-cp/lcp_router.c:589
>>>>> #2  lcp_router_neigh_add (rn=0x674b80) at
>>>>> /vpp/src/plugins/linux-cp/lcp_router.c:763
>>>>> #3  0x7f12393c2bcd in nl_neigh_add (rn=0x674b80, arg=>>>> out>) at /vpp/src/plugins/linux-cp/lcp_nl.c:232
>>>>> #4  nl_route_dispatch (obj=0x674b80, arg=) at
>>>>> /vpp/src/plugins/linux-cp/lcp_nl.c:311
>>>>> #5  0x7f123944e8ee in ?? () from
>>>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>>>> #6  0x7f1239404bb4 in ?? () from
>>>>> /lib/x86_64-linux-gnu/libnl-route-3.so.200
>>>>> #7  0x7f123944b5c3 in nl_cache_parse () from
>>>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>>>> #8  0x7f12394502cb in nl_msg_parse () from
>>>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>>>> #9  0x7f12393c2033 in nl_route_process_msgs () at
>>>>> /vpp/src/plugins/linux-cp/lcp_nl.c:344
>>>

Re: [vpp-dev] VPP crashing when lcp is enabled and I try to add an interface to a linux bridge.

[Matthew Smith via lists.fd.io]

On Tue, Aug 23, 2022 at 7:40 AM Pragya Nand Bhagat <
pragya.nand.bhaga...@gmail.com> wrote:

> Hi Matthew,
>
> Thanks for looking into this issue.
> After applying the patch the crash is not seen.
>
> However as mentioned earlier, we have faced this issue when configuring
> the bridge domain and adding a member port to it.
>
>1. create a bridge [ brctl addbr 100]
>2. try adding a interface to it [ brctl addif 100 Ethernet0 ]
>
> *Is there any plan to support this in VPP Linux cp*
>
>
Hi Pragya,

What do you mean by "support this"? Are you talking about automatically
creating a bridge domain in VPP and adding/removing member interfaces based
on netlink messages? Or something else?

-Matt



> On Sat, Aug 20, 2022 at 2:13 AM Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
>
>>
>> Hi Pragya,
>>
>> This patch should fix it - https://gerrit.fd.io/r/c/vpp/+/36961. Can you
>> apply it to your build and confirm whether it resolves the issue?
>>
>> Thanks,
>> -Matt
>>
>>
>> On Wed, Aug 17, 2022 at 6:55 AM Pragya Nand Bhagat <
>> pragya.nand.bhaga...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I'm seeing a crash in VPP when we try to add a port to a bridge .
>>> VPP  is running with the lcp plugin.
>>>
>>>
>>> lcp default netns ''
>>> lcp lcp-auto-subint off
>>> lcp lcp-sync on
>>> lcp del-static-on-link-down off
>>> lcp del-dynamic-on-link-down off
>>>
>>> itf-pair: [0] port0/0 tap1 Ethernet0 96 type tap
>>> Following are the steps to recreate :
>>>
>>>
>>>
>>>1. create a bridge [ brctl addbr 100]
>>>2. try adding a interface to it [ brctl addif 100 Ethernet0 ]
>>>3. VPP crashes
>>>
>>> We got the following stack trace .
>>>
>>>
>>> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
>>> 0x7f1239448c30 in nl_addr_get_family () from
>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>> (gdb) bt
>>> #0  0x7f1239448c30 in nl_addr_get_family () from
>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>> #1  0x7f12393b9025 in lcp_router_mk_addr (rna=0x0,
>>> ia=0x7f123703ade0) at /vpp/src/plugins/linux-cp/lcp_router.c:589
>>> #2  lcp_router_neigh_add (rn=0x674b80) at
>>> /vpp/src/plugins/linux-cp/lcp_router.c:763
>>> #3  0x7f12393c2bcd in nl_neigh_add (rn=0x674b80, arg=>> out>) at /vpp/src/plugins/linux-cp/lcp_nl.c:232
>>> #4  nl_route_dispatch (obj=0x674b80, arg=) at
>>> /vpp/src/plugins/linux-cp/lcp_nl.c:311
>>> #5  0x7f123944e8ee in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200
>>> #6  0x7f1239404bb4 in ?? () from
>>> /lib/x86_64-linux-gnu/libnl-route-3.so.200
>>> #7  0x7f123944b5c3 in nl_cache_parse () from
>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>> #8  0x7f12394502cb in nl_msg_parse () from
>>> /lib/x86_64-linux-gnu/libnl-3.so.200
>>> #9  0x7f12393c2033 in nl_route_process_msgs () at
>>> /vpp/src/plugins/linux-cp/lcp_nl.c:344
>>> #10 nl_route_process (vm=0x7f123ac6d700, node=,
>>> frame=) at /vpp/src/plugins/linux-cp/lcp_nl.c:557
>>> #11 0x7f127b1dbbe7 in vlib_process_bootstrap (_a=) at
>>> /vpp/src/vlib/main.c:1222
>>> #12 0x7f127b0e4258 in clib_calljmp () at
>>> /vpp/src/vppinfra/longjmp.S:123
>>> #13 0x7f1239245d60 in ?? ()
>>> #14 0x7f127b1d38b0 in vlib_process_startup (vm=0x7f123ac6d700,
>>> p=0x7f123c12bd80, f=0x0) at /vpp/src/vlib/main.c:1247
>>> #15 dispatch_process (vm=0x7f123ac6d700, p=0x7f123c12bd80, f=0x0,
>>> last_time_stamp=) at /vpp/src/vlib/main.c:1303
>>> #16 0x in ?? ()
>>>
>>>
>>> Looks like interface netlink event is not handled for scenarios when an
>>> interface is added to bridge.
>>> Please revert if any other information is required.
>>>
>>>
>>>
>>> Thank You
>>>
>>> Pragya Nand
>>>
>>>
>>>
>>>
>>
>>
>>
> 
>
>

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

Re: [vpp-dev] VPP crashing when lcp is enabled and I try to add an interface to a linux bridge.

[Matthew Smith via lists.fd.io]

Hi Pragya,

This patch should fix it - https://gerrit.fd.io/r/c/vpp/+/36961. Can you
apply it to your build and confirm whether it resolves the issue?

Thanks,
-Matt


On Wed, Aug 17, 2022 at 6:55 AM Pragya Nand Bhagat <
pragya.nand.bhaga...@gmail.com> wrote:

> Hi All,
>
> I'm seeing a crash in VPP when we try to add a port to a bridge .
> VPP  is running with the lcp plugin.
>
>
> lcp default netns ''
> lcp lcp-auto-subint off
> lcp lcp-sync on
> lcp del-static-on-link-down off
> lcp del-dynamic-on-link-down off
>
> itf-pair: [0] port0/0 tap1 Ethernet0 96 type tap
> Following are the steps to recreate :
>
>
>
>1. create a bridge [ brctl addbr 100]
>2. try adding a interface to it [ brctl addif 100 Ethernet0 ]
>3. VPP crashes
>
> We got the following stack trace .
>
>
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> 0x7f1239448c30 in nl_addr_get_family () from
> /lib/x86_64-linux-gnu/libnl-3.so.200
> (gdb) bt
> #0  0x7f1239448c30 in nl_addr_get_family () from
> /lib/x86_64-linux-gnu/libnl-3.so.200
> #1  0x7f12393b9025 in lcp_router_mk_addr (rna=0x0, ia=0x7f123703ade0)
> at /vpp/src/plugins/linux-cp/lcp_router.c:589
> #2  lcp_router_neigh_add (rn=0x674b80) at
> /vpp/src/plugins/linux-cp/lcp_router.c:763
> #3  0x7f12393c2bcd in nl_neigh_add (rn=0x674b80, arg=)
> at /vpp/src/plugins/linux-cp/lcp_nl.c:232
> #4  nl_route_dispatch (obj=0x674b80, arg=) at
> /vpp/src/plugins/linux-cp/lcp_nl.c:311
> #5  0x7f123944e8ee in ?? () from /lib/x86_64-linux-gnu/libnl-3.so.200
> #6  0x7f1239404bb4 in ?? () from
> /lib/x86_64-linux-gnu/libnl-route-3.so.200
> #7  0x7f123944b5c3 in nl_cache_parse () from
> /lib/x86_64-linux-gnu/libnl-3.so.200
> #8  0x7f12394502cb in nl_msg_parse () from
> /lib/x86_64-linux-gnu/libnl-3.so.200
> #9  0x7f12393c2033 in nl_route_process_msgs () at
> /vpp/src/plugins/linux-cp/lcp_nl.c:344
> #10 nl_route_process (vm=0x7f123ac6d700, node=,
> frame=) at /vpp/src/plugins/linux-cp/lcp_nl.c:557
> #11 0x7f127b1dbbe7 in vlib_process_bootstrap (_a=) at
> /vpp/src/vlib/main.c:1222
> #12 0x7f127b0e4258 in clib_calljmp () at
> /vpp/src/vppinfra/longjmp.S:123
> #13 0x7f1239245d60 in ?? ()
> #14 0x7f127b1d38b0 in vlib_process_startup (vm=0x7f123ac6d700,
> p=0x7f123c12bd80, f=0x0) at /vpp/src/vlib/main.c:1247
> #15 dispatch_process (vm=0x7f123ac6d700, p=0x7f123c12bd80, f=0x0,
> last_time_stamp=) at /vpp/src/vlib/main.c:1303
> #16 0x in ?? ()
>
>
> Looks like interface netlink event is not handled for scenarios when an
> interface is added to bridge.
> Please revert if any other information is required.
>
>
>
> Thank You
>
> Pragya Nand
>
> 
>
>

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

Re: [vpp-dev] vpp api versioning

[Matthew Smith via lists.fd.io]

Hi Andrew,

Neale and I are the maintainers of linux-cp. I am ok with changing it in
place because the use of "namespace" is preventing Stanislav from even
being able to compile his code.

When you say "mark the APIs as experimental" are you talking about putting
"state: experimental" in the FEATURE.yaml file or something else? If you're
talking about FEATURE.yaml, the file at src/plugins/linux-cp/FEATURE.yaml
already lists the state as experimental. Maybe the formatting of the file
is bad?

Thanks,
-Matt


On Fri, Jul 15, 2022 at 4:14 AM Andrew Yourtchenko 
wrote:

> Hi Stanislav,
>
> The api is marked as “Production” so the behavior of checkstyle is there
> to protect the users (as for the duplication - it is a choice to do it once
> in VPP or in each and every downstream consumer). As for the pure code
> exercise - I just did it for the sake of a test, took a grand total of 15
> minutes to add the new message versions. Hardly a massive deal. (We could
> probably improve tooling on the lifecycle management of these, though)
>
> That said - for this specific case - is the presence of the “namespace”
> member in a structure within the api a showstopper for you - that is, does
> it cause a compilation failure of some sort  ? If so - one option is to
> mark the APIs as experimental and then change it in-place. It is up to
> component owners to decide the policy.
>
> --a
>
> On 15 Jul 2022, at 09:39, Stanislav Zaikin  wrote:
>
> 
> Hello folks,
>
> According to [0] it should be possible to add breaking changes to vpp api
> with incrementing the major version of the api. There's one issue in the
> LCP api - a C++ keyword "namespace" is used there and I want to change it
> to "netns" and increase a major version. But make checkstyle-api still
> fails. Any ideas?
>
> Of course, I can add new methods _v2 and deprecate the older ones. But
> it'd lead to code duplication and still I'd need to wait at least 2
> releases.
>
> [0] https://wiki.fd.io/view/VPP/API_Versioning
>
> --
> Best regards
> Stanislav Zaikin
>
>
>
>
> 
>
>

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

Re: [vpp-dev] vpp refuses to use of see/use dpdk interfaces

[Matthew Smith via lists.fd.io]

The command you typed looks like it should be valid, at least with the
current code. I'm not sure what the correct syntax was in 21.10.

If you type 'create int rdma ?' and press enter it should print the help
text which describes what the valid options are.

Is the rdma plugin loaded? If you run 'show plugins' in vppctl, does it
list rdma_plugin.so?

-Matt


On Thu, Jul 7, 2022 at 3:19 PM Dave Houser  wrote:

> On Thu, Jul 7, 2022 at 01:53 PM, Matthew Smith wrote:
>
>
> https://s3-docs.fd.io/vpp/22.10/developer/devicedrivers/rdma.html?highlight=rdma
>
> Thanks Matt,
>
> I unbound the interfaces from dpdk and gave back to the kernel, then
> restart vpp.
> Working through the instructions, however they don't seem to work, or
> maybe not clear to me.
>
> create int rdma host-if enp94s0f0 name rdma-0
>
>
> This returns
> `create interface: unknown input `rdma host-if enp65s0f6 name rd...'`
>
> I wish there was a way to check commands I can use in vppctl (Like
> pressing `?` or tab-tab to see commands I can use based on the semantics I
> am using, but I don't see way to do this)
>
> Dont think I ever shared the version I am running so I am now:
> ```
> vpp# show vers
> vpp v21.10.1-release built by root on 4f6ead0c141f at 2021-11-17T14:25:30
> ```
>
> Am I using the command wrong?
>
> 
>
>

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

Re: [vpp-dev] make install-dep on Ubuntu 18.04 fails

[Matthew Smith via lists.fd.io]

Hi Dave,

I think make pkg-deb and make install-dep are the correct thing to use. I
haven't seen much maintenance of the vagrant build pieces over the past
couple of years so I don't know if they can be assumed to be working
anymore. The instructions on the wiki page you linked probably need to be
updated.

I don't think Ubuntu 18.04 is tested by the CI anymore, so it may require
some tinkering to make it work correctly. If you're able to build on Ubuntu
20.04 instead, I think you should not have any problems because that
version does get tested by CI.

-Matt


On Fri, Jul 8, 2022 at 9:08 AM Dave Houser  wrote:

> It seems I need to run `./extras/vagrant/build.sh` instead of running
> `make install-dep`. I can see earlier in the process that the same errors
> happen but are ignored and compiling continues. However I ran into a new
> error with clang, how do I get past this?
>
> ```
>
> -- Configuring done
>
> -- Generating done
>
> -- Build files have been written to:
> /home/ubuntu/vpp/vpp/build-root/build-vpp-native/vpp
>
>  Building vpp in /home/ubuntu/vpp/vpp/build-root/build-vpp-native/vpp
> 
>
> [766/2348] Building C object
> CMakeFiles/vnet/CMakeFiles/vnet_objs.dir/ipsec/ipsec_spd_policy.c.o
>
> FAILED: CMakeFiles/vnet/CMakeFiles/vnet_objs.dir/ipsec/ipsec_spd_policy.c.o
>
> /usr/bin/clang --target=x86_64-linux-gnu -D_FORTIFY_SOURCE=2
> -I/home/ubuntu/vpp/vpp/src
> -I/home/ubuntu/vpp/vpp/build-root/build-vpp-native/vpp/CMakeFiles
> -I/home/ubuntu/vpp/vpp/build-root/build-vpp-native/vpp/CMakeFiles/vnet
> -fPIC -g -Werror -Wall -Wno-address-of-packed-member -O3 -fstack-protector
> -fno-common -march=corei7 -mtune=corei7-avx -MD -MT
> CMakeFiles/vnet/CMakeFiles/vnet_objs.dir/ipsec/ipsec_spd_policy.c.o -MF
> CMakeFiles/vnet/CMakeFiles/vnet_objs.dir/ipsec/ipsec_spd_policy.c.o.d -o
> CMakeFiles/vnet/CMakeFiles/vnet_objs.dir/ipsec/ipsec_spd_policy.c.o -c
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:618:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:618:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:618:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:618:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:698:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:698:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:698:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> /home/ubuntu/vpp/vpp/src/vnet/ipsec/ipsec_spd_policy.c:698:30: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
>
>   ipsec_fp_5tuple_t mask = { 0 }, policy_5tuple;
>
>  ^
>
>  {}
>
> 8 errors generated.
>
> [861/2348] Building C object
> CMakeFiles/vnet/CMakeFiles/vnet_objs.dir/ipsec/esp_decrypt.c.o
>
> ninja: build stopped: subcommand failed.
>
> Makefile:693: recipe for target 'vpp-build' failed
>
> make[1]: *** [vpp-build] Error 1
>
> make[1]: Leaving directory '/home/ubuntu/vpp/vpp/build-root'
>
> Makefile:604: recipe for target 'pkg-deb' failed
>
> make: *** [pkg-deb] Error 2
> ```
>
> 
>
>

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

Re: [vpp-dev] vpp refuses to use of see/use dpdk interfaces

[Matthew Smith via lists.fd.io]

Hi Dave,

The mlx5 driver code gets statically linked by the shared library in
vpp-plugin-dpdk, so that's the package that needs to be updated. I'm not
aware of a way to build just that one package, running 'make pkg-deb' will
rebuild all of the VPP deb packages. Once they're built, you might be able
to get by with only updating vpp-plugin-dpdk, but I recommend you update
vpp, libvppinfra, vpp-plugin-core and vpp-plugin-dpdk just to avoid
headaches.

I personally have not tried using the rdma plugin. I have heard other VPP
devs recommend using it though. It's supposed to eliminate some processing
overhead caused by differences between VPP's internal structure of a buffer
and DPDK's, so it's possible that using an rdma interface would be more
efficient than using a DPDK interface. And using the rdma plugin should not
require rebuilding VPP for you to try it. This is the only doc I know of on
using rdma interfaces -
https://s3-docs.fd.io/vpp/22.10/developer/devicedrivers/rdma.html?highlight=rdma
.

-Matt


On Thu, Jul 7, 2022 at 12:31 PM Dave Houser  wrote:

> Hi Matt,
>
> These are Mellanox ConnectX6 Nics.
>
> Looking at the logs more I found these two lines:
>
> ```
>
> $vppctl show logs
>
> 2022/07/07 17:14:19:050 notice dpdk   EAL init args: -c 2 -n 4
> --in-memory --no-telemetry --file-prefix vpp -a :41:00.6 -a
> :41:01.6 --main-lcore 1
>
> 2022/07/07 17:14:19:161 notice dpdk   DPDK drivers found no
> Ethernet devices...
> ```
>
> I just found this post
>  in the mailing list.
> I assume this is my issue. I did not compile from source / configure
> appropriately. (I followed these instructions here
>  for
> how to deploy)
>
> Which specific package would I need to compile from source? (vpp
> vpp-plugin-core vpp-plugin-dpdk)?
> Is there any documentation on how to create a RMDA interface? Would an
> RDMA interface be just as efficient as a DPDK interface?
>
> - Dave
>
> 
>
>

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

Re: [vpp-dev] vpp refuses to use of see/use dpdk interfaces

[Matthew Smith via lists.fd.io]

Hi Dave,

What is the manufacturer & model of the NICs you're trying to use? It's
possible that either VPP's DPDK plugin does not consider them valid or that
the DPDK PMD which is capable of managing them is not built by default.

-Matt


On Thu, Jul 7, 2022 at 11:12 AM Dave Houser  wrote:

> Hello,
>
> I am not able to see my white listed dpdk interfaces in vppctl with `show
> int` or `show hardware`. I did the following to integrate the interfaces.
>
> - I shutdown the interfaces with `ifconfig`
> `ifconfig enp65s0f6 down`
> `ifconfig enp65s1f6 down`
>
> - I unbound them from the kernel with dpdk_devbind.py
> `sudo dpdk-devbind.py -b uio_pci_generic :41:01.6`
> `sudo dpdk-devbind.py -b uio_pci_generic :41:01.6`
>
> - I confirmed the correct interfaces were removed and bound by dpdk
> `ip -br a` (interfaces removed)
> `dpdk-devbind.py --status` (interfaces show up as dpdk bound interfaces)
>
> - I made sure the interfaces were white listed in my startup.conf
> ```
> unix {
>   nodaemon
>   log /var/log/vpp/vpp.log
>   full-coredump
>   cli-listen /run/vpp/cli.sock
> }
>
> api-trace {
>   on
> }
>
> dpdk {
>   dev :41:00.6
>   dev :41:01.6
> }
> ```
>
> - I restarted vpp
> `systemctl restart vpp`
>
> - Watched journalctl -fu output
> ```
> Jul 07 15:56:17 host1 systemd[1]: Stopping vector packet processing
> engine...
> Jul 07 15:56:17 host1 vnet[66266]: unix_signal_handler:190: received
> signal SIGCONT, PC 0x7f5f7e426da0
> Jul 07 15:56:17 host1 vnet[66266]: received SIGTERM, exiting...
> Jul 07 15:56:17 host1 vnet[66266]: unix_signal_handler:190: received
> signal SIGCONT, PC 0x7f5f7e426da0
> Jul 07 15:56:17 host1 systemd[1]: Stopped vector packet processing engine.
> Jul 07 15:56:40 host1 systemd[1]: Starting vector packet processing
> engine...
> Jul 07 15:56:40 host1 systemd[1]: Started vector packet processing engine.
> Jul 07 15:56:40 host1 vnet[71758]: dpdk/cryptodev: dpdk_cryptodev_init:
> Failed to configure cryptodev
> ```
>
> - I accessed vpp
> `vppctl`
>
> Interfaces never show up. I followed everything in the following guides
> and posts:
> - https://lists.fd.io/g/vpp-dev/topic/10642649
> - https://s3-docs.fd.io/vpp/22.02/configuration/reference.html
>
> Here is my apt list
> ```
> $sudo apt list | grep vpp
> libvppinfra/bionic,now 21.10.1-release amd64 [installed,automatic]
> libvppinfra-dev/bionic,now 21.10.1-release amd64 [installed,automatic]
> python3-vpp-api/bionic 21.10.1-release amd64
> vpp/bionic,now 21.10.1-release amd64 [installed]
> vpp-api-java/bionic 19.04-release amd64
> vpp-api-lua/bionic 19.01.3-release amd64
> vpp-api-python/bionic 21.01.1-release amd64
> vpp-dbg/bionic,now 21.10.1-release amd64 [installed]
> vpp-dev/bionic,now 21.10.1-release amd64 [installed]
> vpp-ext-deps/bionic 19.04-16 amd64
> vpp-lib/bionic 19.01.3-release amd64
> vpp-plugin-core/bionic,now 21.10.1-release amd64 [installed]
> vpp-plugin-dpdk/bionic,now 21.10.1-release amd64 [installed]
> vpp-plugins/bionic 19.01.3-release amd64
> ```
>
> What am I missing? Why does vpp refuses to recognize my dpdk interfaces?
> Note: these are SRIOV vf interfaces, but I dont think that matter does it?
>
> - Dave
>
> 
>
>

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

Re: [vpp-dev] Need suggestion to understand LCP failure on VPP restart

[Matthew Smith via lists.fd.io]

On Wed, Jun 29, 2022 at 10:23 PM Amaresh Parida 
wrote:

> Hi Dave,
>
> Thanks for the response.
> The initial run is ok. The issue just happen on vpp restart.
>
> I think that won't change any args.
>
> Its appears to me may be the logs are misleading and probably a side
> effect of corrupted memory or so.
>
> Let me know if you think otherwise.
>
>
In what way are the logs misleading? The call to the TUNSETIFF ioctl in
tap_create_if() is returning an error code. The message "Argument list too
long" corresponds to the error number E2BIG, which is being set by the
kernel's tun driver. AFAICT the tun driver only returns that error here -
https://github.com/torvalds/linux/blob/a175eca0f3d747599f1fdfac04cc9195b71ec996/drivers/net/tun.c#L771.
The condition that causes it is 'tun->numqueues + tun->numdisabled ==
MAX_TAP_QUEUES'. So too many queues are being allocated on the tap. That's
from the current upstream linux kernel source code. It's possible that some
older version returned that error code for some other reason.

What version of kernel are you running when this error happens? The current
value of MAX_TAP_QUEUES is 256. On older versions of the kernel it was 8.
Your screenshot showed that DPDK initialization detected 20 lcores. How
many worker threads does VPP have configured?

I don't ever run VPP in a docker container, so I don't know why this would
happen intermittently. Could your container be getting migrated to a
different host system when it restarts? Or could it be getting started with
a different number of CPU cores allocated or worker threads configured in
VPP's startup.conf?

-Matt



>
> On Wed, Jun 29, 2022, 18:17 Dave Barach  wrote:
>
>> You might try adding additional debugs to print the arg list length and
>> args.
>>
>> Comparing the success and failure cases should give at least a hint.
>>
>> HTH... Dave
>>
>> On Jun 29, 2022, at 7:55 AM, Amaresh Parida 
>> wrote:
>>
>> 
>> Hi All,
>> Any inputs on the below query will be very helpful.
>>
>> Thanks,
>> Amaresh
>>
>> On Fri, Jun 24, 2022 at 6:09 PM Amaresh Parida 
>> wrote:
>>
>>> Hi All,
>>>
>>> I am facing an issue on restarting VPP where sometimes LinuxCP
>>> tap interface is not getting created.
>>>
>>> Here is the complete problem statement.
>>>
>>> 1> I am running VPP inside a docker
>>> 2> I have the following VPP and LCP config
>>>   dev :02:00.1{
>>> name port0/0
>>>}
>>>vppctl lcp create port0/0 host-if Ethernet0
>>> 3> Everything works as expected  and the LCP tap interface is getting
>>> created on VPP bootup
>>> 4> When I stop and start the VPP docker *sometime* I see the following
>>> error and LCP fails on tap creation.
>>>
>>> [image: image.png]
>>>
>>> Any suggestions to understand the issue will be very helpful?
>>>
>>> Thanks,
>>> Amaresh
>>>
>>
>>
>>
>>
>>
>>
>>
> 
>
>

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

Re: [vpp-dev] #ipsec #dpdk VPP 22.02 no DPDK crypto devs available on AWS VM

[Matthew Smith via lists.fd.io]

Hi Gabi,

It looks like aesni_mb and aesni_gcm are disabled in VPP's DPDK build
configuration. see build/external/packages/dpdk.mk. You would probably need
to remove those from DPDK_DRIVERS_DISABLED and rebuild if you want to use
them. That said, I doubt you would see much improvement as a result of
using them. VPP's ipsecmb crypto plugin uses the same optimized crypto
library that those vdev's use. I think VPP's native crypto plugin is
assigned the highest priority, so that plugin is likely handling crypto
operations for your tunnels by default. If you want to use the ipsecmb
crypto plugin instead you can use a command like  "vppctl set crypto
handler  ipsecmb" for the ciphers used by your tunnels. I don't
know if you'll see any difference in performance by using ipsecmb instead
of native, but it doesn't hurt to try it.

Here are some thoughts and questions on tuning to improve IPsec throughput:

   - If you haven't already, you should configure at least one worker
   thread so your crypto operations are not being executed on the same CPU as
   the main thread.
   - Are you using one tunnel or multiple tunnels? An SA will be bound to a
   particular thread in order to keep packets in order. With synchronous
   crypto, all of the operations for the SA will be handled by that one thread
   and throughput will be limited to how much crypto the CPU that thread is
   bound to can handle. So you might get higher throughput by distributing
   traffic across multiple tunnels if possible. Or if you enable asynchronous
   crypto, the sw_scheduler plugin tries to distribute crypto operations to
   other threads, which might help.
   - With multiple workers, you could get encrypt & decrypt operations
   handled by different threads/cores. If you have a LAN interface and a WAN
   interface and your tunnel is terminated on the WAN interface to allow VMs
   on your LAN subnet to communicate with some remote systems on the other
   side of the tunnel, you could bind the RX queues for the interfaces to
   different threads. Outbound packets would be encrypted by the threads which
   handle the queues for the LAN interface. Inbound packets will be decrypted
   by the threads which handle the queues for the WAN interface.
   - You mentioned that you can't get better throughput from VPP than you
   can with kernel IPsec. Is the kernel getting the same throughput as VPP or
   higher? If it's close to the same, you may be hitting some external
   resource limit. E.g. the other end of the tunnel could be the bottleneck.
   Or AWS's traffic shaping might be preventing you from sending any faster.
   - Are you using policy-based IPsec or routed IPsec (creating a tunnel
   interface)? There have been patches merged recently which are intended to
   improve performance for policy-based IPsec, but if you are using
   policy-based IPsec you might try using a tunnel interface instead and see
   if your measurements improve.
   - Fragmentation and reassembly can impact IPsec throughput. If your
   packets are close to the size of the hardware interface that packets will
   be sent out, the encapsulation & crypto padding may push the packet size
   over the MTU and the encrypted packet may need to be fragmented before
   being sent. That means the other end of the tunnel will need to wait for
   all the fragments to arrive and reassemble them before it can decrypt the
   packet. If you are using a tunnel interface, you can set the MTU on the
   tunnel interface lower than the MTU on the hardware interface. Then packets
   would be fragmented by the tunnel interface before being encrypted and the
   other end would not need to reassemble them.

-Matt


On Fri, Jun 3, 2022 at 7:52 AM  wrote:

> Hi,
> I am a beginner in VPP and DPDK stuff, I am trying to create a high
> performance AWS VM which should do IPSec tunneling.
>
> The IPSEc traffic is running well, but I can not exceed 8Gb  traffic
> throughput and I can not convince VPP to beat the "ip xfrm" in terms of
> IPSec traffic throughput.
>
> When the VPP starts, I get this warning all the times:
>
> dpdk/cryptodev [warn  ]: dpdk_cryptodev_init: Not enough cryptodev
> resources
>
> whatever CPU I have enabled.
>
> If I specify
> vdev crypto_aesni_mb
> or
> vdev crypto_aesni_gcm
> on the dpdk section of startup.conf file, I always hit this error:
> 0: dpdk_config: rte_eal_init returned -1
>
> I am using Ubuntu 20.04 LTS and the CPU flags are:
>
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
> pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm
> constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid
> aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1
> sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
> hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust
> bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx
> smap clflushopt clwb 

Re: [vpp-dev] Query on VPP in Aure

[Matthew Smith via lists.fd.io]

Hi John,

I have had some problems on Azure with my build lately similar to the MTU
errors you mentioned. The build that has problems is based on the
commit b0f0f8c8d ("memif: fix memif_process_desc indexing") from the
upstream master branch (so..master branch from 1 or 2 months ago using DPDK
21.11, not a stable release version of VPP). Last week I applied these
recent patches to my build:

739a342b4 dpdk: fix overflow in mtu arithmetic
b6bf5c9c4 dpdk: clear the RTE_MEMPOOL_F_NON_IO

With those patches applied, the problems may have gone away. Netgate's QA
team is still trying to verify if they can reproduce the issue with the
patches applied. It was intermittent to begin with, so its not
straightforward to declare that the issue is resolved.

The build in our previous release, which did not have any issues with
setting MTUs on Azure netvsc interfaces, was based on commit 895def45c
("avf: fix RSS hash key") from the upstream master branch. The DPDK version
used there was 21.08.

-Matt


On Wed, May 18, 2022 at 12:20 PM Johnny Martinez 
wrote:

> Hello Matt,
>
> Can you *please *confirm which DPDK and VPP versions you have that are
> working in Azure?
>
> I am hoping to get a base build with no errors and the ability to set MTU
> size...
>
> *Thank you in advance for your help!!!*
>
> --
> John M.
>
>
> On Mon, May 2, 2022 at 1:42 PM Matthew Smith  wrote:
>
>>
>> Sorry, there was a typo. You should use DPDK_MLX5_COMMON_PMD=y instead
>> of DPDK_MLX_COMMON_PMD=y.
>>
>> -Matt
>>
>>
>> On Mon, May 2, 2022 at 11:28 AM Johnny Martinez 
>> wrote:
>>
>>> Hello Matt!
>>>
>>> *Thank you very much for the reply!*
>>>
>>> Our end goal is to be using Alma Linux but we went ahead and tried it in
>>> a fresh Ubuntu 20.04 installation with the same result.
>>>
>>> It looks like it is unable to compile the *mlx5 drivers*.
>>>
>>> *I’ve attached the complete build log for your review.*
>>>
>>>
>>>
>>> *Build was started with:*
>>>
>>> *make DPDK_MLX4_PMD=y DPDK_MLX5_PMD=y DPDK_MLX_COMMON_PMD=y pkg-deb |
>>> tee /root/vpp-build.log*
>>>
>>>
>>>
>>> As an extra precaution, the vpp.mk content is:
>>>
>>>
>>>
>>> *MACHINE=$(shell uname -m)*
>>>
>>> *vpp_arch = native*
>>>
>>> *vpp_root_packages = vpp*
>>>
>>> *vpp_debug_TAG_BUILD_TYPE = debug*
>>>
>>> *vpp_TAG_BUILD_TYPE = release*
>>>
>>> *vpp_clang_TAG_BUILD_TYPE = release*
>>>
>>> *vpp_gcov_TAG_BUILD_TYPE = gcov*
>>>
>>> *vpp_coverity_TAG_BUILD_TYPE = coverity*
>>>
>>> *vpp_dpdk_inc_dir = /usr/include/dpdk/*
>>>
>>> *vpp_dpdk_lib_dir = /usr/lib64/*
>>>
>>> *vpp_uses_dpdk_mlx4_pmd = yes*
>>>
>>> *DPDK_MLX4_PMD=y*
>>>
>>> *DPDK_MLX5_PMD=y*
>>>
>>> *DPDK_MLX_COMMON_PMD=y*
>>>
>>>
>>>
>>> The build completes, but there’s an issue with the MLX5 driver. As seen
>>> in the build log, the *MLX4 is built, but MLX5 is not*. I’ve tried
>>> searching online, but there’s reference to *glue* with regard to the
>>> MLX5, but nothing actionable I could find:
>>>
>>>
>>>
>>> *Part 1: Shows that the library “mlx4” and “mlx5” are included as part
>>> of “make” (means our build options were correctly interperated):*
>>>
>>>
>>>
>>> *cmake3 --build
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/build-rdma-core
>>> -- libccan.a libibverbs.a librdma_util.a libmlx5.a libmlx4.a >
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/rdma-core.build.log*
>>>
>>> *sed 's/^Libs.private:.*/Libs.private: -lmlx4 -lmlx5 -libverbs
>>> -lrdma_util -lccan -lpthread/' -i
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/build-rdma-core/lib/pkgconfig/libibverbs.pc
>>> >>
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/rdma-core.build.log*
>>>
>>>
>>> *Part 2: Shows that MLX5 is missing “common_mlx5” (which I can’t find a
>>> way to install…?) so is disabled. MLX4 however, is built:*
>>>
>>>
>>>
>>> *Using 'PKG_CONFIG_PATH' from environment with value:
>>> '/root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/install-vpp-native/external/lib/pkgconfig'*
>>>
>>

Re: [vpp-dev] Query on VPP in Aure

[Matthew Smith via lists.fd.io]

uot;*
>
> *Message: Disabling mlx5 [drivers/net/mlx5]: missing internal dependency
> "common_mlx5"*
>
> *Message: Disabling caam_jr [drivers/crypto/caam_jr]: missing internal
> dependency "bus_dpaa"*
>
> *Message: Disabling mlx5 [drivers/crypto/mlx5]: missing internal
> dependency "common_mlx5"*
>
> *Message: Disabling mlx5 [drivers/compress/mlx5]: missing internal
> dependency "common_mlx5"*
>
> *Message: Disabling mlx5 [drivers/regex/mlx5]: missing internal dependency
> "common_mlx5"*
>
> *Message: Disabling mlx5 [drivers/vdpa/mlx5]: missing internal dependency
> "common_mlx5"*
>
>
> *I am not able to find a way to enable MLX5.*
>
> --
> John M.
>
>
> On Fri, Apr 29, 2022 at 4:31 PM Matthew Smith  wrote:
>
>>
>> Hi John,
>>
>> Are you using a stock build of VPP from packagecloud or did you build
>> your own? VPP's build of DPDK does not enable the Mellanox (mlx4, mlx5)
>> PMDs by default. If you didn't already, you would need to build VPP with
>> the environment variables DPDK_MLX4_PMD,  DPDK_MLX5_PMD, and
>> DPDK_MLX_COMMON_PMD set to y. You could change the default values from n to
>> y in build/external/packages/dpdk.mk or you could run something like
>> 'make DPDK_MLX4_PMD=y DPDK_MLX5_PMD=y DPDK_MLX_COMMON_PMD=y pkg-deb'. That
>> presumes that you're running on ubuntu or some other debian-based distro,
>> if you're running some other OS maybe substituting pkg-snap or pkg-rpm for
>> the pkg-deb in that command would work for you.
>>
>> -Matt
>>
>>
>> On Fri, Apr 29, 2022 at 2:40 PM Johnny Martinez 
>> wrote:
>>
>>> Johnny Martinez 
>>> 9:57 AM (5 hours ago)
>>> to Benoit
>>> *@Ben *- thank you *VERY *much for the detailed response!
>>>
>>> I had *partial *success but almost there - now I am seeing some DPDK
>>> errors and other behavior outlined below.
>>>
>>> On my test device I have 3 interfaces:
>>>
>>>- Management interface (kernel interface, not managed by VPP)
>>>- vpp-wan interface
>>>- vpp-lan interface
>>>
>>> I configureD the interfaces with the following:
>>>
>>> set logging class linux-cp rate-limit 1000 level warn syslog-level notice
>>>
>>>
>>> lcp default netns dataplane
>>>
>>> lcp lcp-sync on
>>>
>>> lcp lcp-auto-subint on
>>>
>>>
>>> # vpp-wan
>>>
>>> vpp# lcp create NetVSC1 host-if vpp-wan
>>>
>>> vpp# set int state NetVSC1 up
>>>
>>> vpp# set int ip address NetVSC1 10.0.2.4/24
>>>
>>> vpp#  ip route add 0.0.0.0/0 via 10.0.2.1
>>>
>>>
>>> # vpp-lan
>>>
>>> vpp# lcp create NetVSC0 host-if vpp-lan
>>>
>>> vpp# set int state NetVSC0 up
>>>
>>> vpp# set int ip address NetVSC0 10.0.1.4/24
>>>
>>>
>>> I am now able to see the two interfaces in vpp *HOWEVER *I am not able
>>> to set the MTU size on either interface to 1500.
>>>
>>> vpp# set int mtu 1500 NetVSC0
>>> set interface mtu: Unsupported (dpdk driver doesn't support MTU change)
>>> vpp# set int mtu 1500 NetVSC1
>>> set interface mtu: Unsupported (dpdk driver doesn't support MTU change)
>>>
>>>
>>> I see the following in the log files using '*journalctl  | grep dpdk*'
>>> - we get two seperate DPDK errors. *One seems to be interface specific
>>> and the other when we try to set the MTU size*.
>>>
>>> The *orange *error is every second - whereas the MTU error is only when
>>> we try to set the MTU size.
>>>
>>> *Apr 29 12:55:15 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add():
>>> RNDIS reports VF but device not found, retrying*
>>>
>>> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_attach():
>>> Couldn't find port for VF*
>>>
>>> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add():
>>> RNDIS reports VF but device not found, retrying*
>>>
>>> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_attach():
>>> Couldn't find port for VF*
>>>
>>> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add():
>>> RNDIS reports VF but device not found, retrying*
>>>
>>> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: [0]
>>> rte_eth_dev_set_mtu failed (mtu 1496, rv -95)*
>>>
>>> *Apr 29 12:55:16 azure-demo-node-00

Re: [vpp-dev] Query on VPP in Aure

[Matthew Smith via lists.fd.io]

Hi John,

Are you using a stock build of VPP from packagecloud or did you build your
own? VPP's build of DPDK does not enable the Mellanox (mlx4, mlx5) PMDs by
default. If you didn't already, you would need to build VPP with the
environment variables DPDK_MLX4_PMD,  DPDK_MLX5_PMD, and
DPDK_MLX_COMMON_PMD set to y. You could change the default values from n to
y in build/external/packages/dpdk.mk or you could run something like 'make
DPDK_MLX4_PMD=y DPDK_MLX5_PMD=y DPDK_MLX_COMMON_PMD=y pkg-deb'. That
presumes that you're running on ubuntu or some other debian-based distro,
if you're running some other OS maybe substituting pkg-snap or pkg-rpm for
the pkg-deb in that command would work for you.

-Matt


On Fri, Apr 29, 2022 at 2:40 PM Johnny Martinez 
wrote:

> Johnny Martinez 
> 9:57 AM (5 hours ago)
> to Benoit
> *@Ben *- thank you *VERY *much for the detailed response!
>
> I had *partial *success but almost there - now I am seeing some DPDK
> errors and other behavior outlined below.
>
> On my test device I have 3 interfaces:
>
>- Management interface (kernel interface, not managed by VPP)
>- vpp-wan interface
>- vpp-lan interface
>
> I configureD the interfaces with the following:
>
> set logging class linux-cp rate-limit 1000 level warn syslog-level notice
>
>
> lcp default netns dataplane
>
> lcp lcp-sync on
>
> lcp lcp-auto-subint on
>
>
> # vpp-wan
>
> vpp# lcp create NetVSC1 host-if vpp-wan
>
> vpp# set int state NetVSC1 up
>
> vpp# set int ip address NetVSC1 10.0.2.4/24
>
> vpp#  ip route add 0.0.0.0/0 via 10.0.2.1
>
>
> # vpp-lan
>
> vpp# lcp create NetVSC0 host-if vpp-lan
>
> vpp# set int state NetVSC0 up
>
> vpp# set int ip address NetVSC0 10.0.1.4/24
>
>
> I am now able to see the two interfaces in vpp *HOWEVER *I am not able to
> set the MTU size on either interface to 1500.
>
> vpp# set int mtu 1500 NetVSC0
> set interface mtu: Unsupported (dpdk driver doesn't support MTU change)
> vpp# set int mtu 1500 NetVSC1
> set interface mtu: Unsupported (dpdk driver doesn't support MTU change)
>
>
> I see the following in the log files using '*journalctl  | grep dpdk*' -
> we get two seperate DPDK errors. *One seems to be interface specific and
> the other when we try to set the MTU size*.
>
> The *orange *error is every second - whereas the MTU error is only when
> we try to set the MTU size.
>
> *Apr 29 12:55:15 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add(): RNDIS
> reports VF but device not found, retrying*
>
> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_attach():
> Couldn't find port for VF*
>
> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add(): RNDIS
> reports VF but device not found, retrying*
>
> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_attach():
> Couldn't find port for VF*
>
> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add(): RNDIS
> reports VF but device not found, retrying*
>
> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: dpdk: [0]
> rte_eth_dev_set_mtu failed (mtu 1496, rv -95)*
>
> *Apr 29 12:55:16 azure-demo-node-001.vnet[2409]: set interface mtu:
> Unsupported (dpdk driver doesn't support MTU change*
>
> *Apr 29 12:55:17 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_attach():
> Couldn't find port for VF*
>
> *Apr 29 12:55:17 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add(): RNDIS
> reports VF but device not found, retrying*
>
> *Apr 29 12:55:17 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_attach():
> Couldn't find port for VF*
>
> *Apr 29 12:55:17 azure-demo-node-001.vnet[2409]: dpdk: hn_vf_add(): RNDIS
> reports VF but device not found, retrying*
>
>
> Anyone have any recommendation on how to resolve this?
>
> *I have also tried setting dev XXX and vdev commands in the dpdk{} block,
> but this causes the virtual interfaces not to be found (as you have
> previously mentioned).*
>
> *Thank you all in advance for your assistance!*
>
> --
> John M
>
>
> On Fri, Apr 29, 2022 at 2:40 PM Matthew Smith  wrote:
>
>> Hi Ben,
>>
>> Sure, I'll work on an update to the doc.
>>
>> -Matt
>>
>>
>> On Fri, Apr 29, 2022 at 3:48 AM Benoit Ganne (bganne) 
>> wrote:
>>
>>> Hi Matt, John,
>>>
>>> This is a great summary!
>>>
>>> >> The only reference I could find for VPP in Azure was in this link
>>> >> but it is very outdated:
>>> >> https://fd.io/docs/vpp/v2101/usecases/vppinazure.html
>>>
>>> > Yes, that doc is way outdated. I advise against following the
>>> instructions
>>> > in it.
>>>
>>> Matt or John, would you mind proposing a patch for that? Even a quick &
>>> dirty "here are the steps you need to follow" would be great.
>>>
>>> Best
>>> ben
>>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21306): https://lists.fd.io/g/vpp-dev/message/21306
Mute This Topic: https://lists.fd.io/mt/90759128/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] Query on VPP in Aure

[Matthew Smith via lists.fd.io]

Hi Ben,

Sure, I'll work on an update to the doc.

-Matt


On Fri, Apr 29, 2022 at 3:48 AM Benoit Ganne (bganne) 
wrote:

> Hi Matt, John,
>
> This is a great summary!
>
> >> The only reference I could find for VPP in Azure was in this link
> >> but it is very outdated:
> >> https://fd.io/docs/vpp/v2101/usecases/vppinazure.html
>
> > Yes, that doc is way outdated. I advise against following the
> instructions
> > in it.
>
> Matt or John, would you mind proposing a patch for that? Even a quick &
> dirty "here are the steps you need to follow" would be great.
>
> Best
> ben
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21303): https://lists.fd.io/g/vpp-dev/message/21303
Mute This Topic: https://lists.fd.io/mt/90759128/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] Prevent blackhole routes being leaked into VPP

[Matthew Smith via lists.fd.io]

There is also another linux-nl FIB source with a lower priority
("lcp-rt-dynamic"), which gets used based on the kernel route protocol. If
the route protocol is <= RTPROT_STATIC, lcp-rt is used. Otherwise, the
lower priority lcp-rt-dynamic is used. So if a route were added to the
kernel route table using iproute2 with 'proto bgp' (or 'proto bird', 'proto
zebra', etc)  added to the command, linux-nl would use the lower priority
FIB source to add the route to VPP's FIB.

I.e. this iproute2 command would probably have the desired effect - 'sudo
ip netns exec dataplane ip -6 route add blackhole 2001:50:10:a111::101/64
table 1203 proto bgp'.

-Matt


On Wed, Apr 6, 2022 at 3:28 AM Neale Ranns  wrote:

> Hi,
>
>
>
> You need to choose an appropriate priority for:
>
>
>
>   lcp_rt_fib_src =
>
> fib_source_allocate ("lcp-rt", FIB_SOURCE_PRIORITY_HI,
> FIB_SOURCE_BH_API);
>
>
>
> in plugins/linux-cp/lcp_router.c
>
>
>
> from vnet/fb/fib_source.h
>
>
>
> /**
>
> * The fixed source to priority mappings.
>
> * Declared here so those adding new sources can better determine their
> respective
>
> * priority values.
>
> */
>
> #define foreach_fib_source  \
>
> /** you can't do better then the special source */ \
>
> _(FIB_SOURCE_SPECIAL,   0x00, FIB_SOURCE_BH_SIMPLE)\
>
> _(FIB_SOURCE_CLASSIFY,  0x01, FIB_SOURCE_BH_SIMPLE)\
>
> _(FIB_SOURCE_PROXY, 0x02, FIB_SOURCE_BH_SIMPLE)\
>
> _(FIB_SOURCE_INTERFACE, 0x03, FIB_SOURCE_BH_INTERFACE) \
>
> _(FIB_SOURCE_SR,0x10, FIB_SOURCE_BH_API)   \
>
> _(FIB_SOURCE_BIER,  0x20, FIB_SOURCE_BH_SIMPLE)\
>
> _(FIB_SOURCE_6RD,   0x30, FIB_SOURCE_BH_API)   \
>
> _(FIB_SOURCE_API,   0x80, FIB_SOURCE_BH_API)   \
>
> _(FIB_SOURCE_CLI,   0x81, FIB_SOURCE_BH_API)   \
>
> _(FIB_SOURCE_LISP,  0x90, FIB_SOURCE_BH_LISP)  \
>
> _(FIB_SOURCE_MAP,   0xa0, FIB_SOURCE_BH_SIMPLE)\
>
> _(FIB_SOURCE_DHCP,  0xb0, FIB_SOURCE_BH_API)   \
>
> _(FIB_SOURCE_IP6_ND_PROXY,  0xc0, FIB_SOURCE_BH_API)   \
>
> _(FIB_SOURCE_IP6_ND,0xc1, FIB_SOURCE_BH_API)   \
>
> _(FIB_SOURCE_ADJ,   0xd0, FIB_SOURCE_BH_ADJ)   \
>
> _(FIB_SOURCE_MPLS,  0xe0, FIB_SOURCE_BH_MPLS)  \
>
> _(FIB_SOURCE_AE,0xf0, FIB_SOURCE_BH_SIMPLE)\
>
> _(FIB_SOURCE_RR,0xfb, FIB_SOURCE_BH_RR)\
>
> _(FIB_SOURCE_URPF_EXEMPT,   0xfc, FIB_SOURCE_BH_RR)\
>
> _(FIB_SOURCE_DEFAULT_ROUTE, 0xfd, FIB_SOURCE_BH_DROP)  \
>
> _(FIB_SOURCE_INTERPOSE, 0xfe, FIB_SOURCE_BH_INTERPOSE) \
>
> _(FIB_SOURCE_INVALID,   0xff, FIB_SOURCE_BH_DROP)
>
>
>
> /**
>
> * Some priority values that plugins might use when they are not to
> concerned
>
> * where in the list they'll go.
>
> */
>
> #define FIB_SOURCE_PRIORITY_HI 0x10
>
> #define FIB_SOURCE_PRIORITY_LOW 0xd0
>
>
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Chinmaya
> Aggarwal via lists.fd.io 
> *Date: *Tuesday, 5 April 2022 at 16:55
> *To: *vpp-dev@lists.fd.io 
> *Subject: *Re: [vpp-dev] Prevent blackhole routes being leaked into VPP
>
> Hi,
>
>
>
> We are adding blackhole routes via linux command "sudo ip netns exec
> dataplane ip -6 route add blackhole 2001:50:10:a111::101/64 table 1203"
>
>
>
> After adding blackhole routes on linux (that are leaked to vpp), if we try
> to view the route in vpp ,we get the below output
>
> [root@j3chysr01stg05 ~]# vppctl show ip6 fib table 1203
> 2001:50:10:a111::/64
>
> ipv6-VRF:1203, fib_index:3, flow hash:[src dst sport dport proto flowlabel
> ] epoch:0 flags:none locks:[CLI:3, lcp-rt:1, ]
>
> 2001:50:10:a111::/64 fib:3 index:86 locks:2
>
>   lcp-rt refs:1 entry-flags:drop, src-flags:added,contributing,active,
>
> path-list:[126] locks:2 flags:drop, uPRF-list:76 len:0 itfs:[]
>
>   path:[126] pl-index:126 ip6 weight=1 pref=0 deag:  cfg-flags:drop,
>
>  fib-index:0
>
>
>
>  forwarding:   unicast-ip6-chain
>
>   [@0]: dpo-load-balance: [proto:ip6 index:88 buckets:1 uRPF:76 to:[0:0]]
>
> [0] [@0]: dpo-drop ip6
>
> [root@j3chysr01stg05 ~]#
>
>
>
> Now, if we add another route via ipip tunnel (that supposedly should
> overwrite the blackhole route) using the API. We get below below output for
> command "show ip6 fib table 1203 2001:50:10:a111::/64"
>
>
>
> [root@j3chysr01stg05 ~]# vppctl show ip6 fib table 1203
> 2001:50:10:a111::/64
>
> ipv6-VRF:1203, fib_index:3, flow hash:[src dst sport dport proto flowlabel
> ] epoch:0 flags:none locks:[CLI:3, lcp-rt:1, ]
>
> 2001:50:10:a111::/64 fib:3 index:86 locks:3
>
>   lcp-rt refs:1 entry-flags:drop, src-flags:added,contributing,active,
>
> path-list:[126] locks:2 flags:drop, uPRF-list:76 len:0 itfs:[]
>
>   path:[126] pl-index:126 ip6 weight=1 pref=0 deag:  cfg-flags:drop,
>
>  fib-index:0
>
>
>
>   API refs:1 

Re: [vpp-dev] vlib_plugin_registration size mismatch

[Matthew Smith via lists.fd.io]

Hi Florin!

Apparently all those plugins are in vpp-plugin-devtools and I had an old
build of that package installed. Oops!

Thanks,
-Matt


On Wed, Mar 16, 2022 at 12:00 PM Florin Coras 
wrote:

> Hi Matt,
>
> Just tried running after a make build and no such message in show log for
> me. Did you try a make wipe?
>
> Regards,
> Florin
>
> > On Mar 16, 2022, at 9:50 AM, Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
> >
> > Hi,
> >
> > I have been testing against a build from yesterday's master branch
> (commit id b0f0f8c8dd9d694bfc13652f89b8b577e9c1c708) and have been seeing
> these messages when VPP starts up:
> >
> > vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
> bufmon_plugin.so
> > vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
> dispatch_trace_plugin.so
> > vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
> oddbuf_plugin.so
> > vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
> perfmon_plugin.so
> > vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
> tracedump_plugin.so
> > vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
> unittest_plugin.so
> >
> > I noticed the problem because I was trying to do some testing on the
> tracedump plugin and I could not get the tests to work. But many other
> plugins (vrrp, nat, acl) work fine and do not have similar messages logged.
> >
> > Does anyone have any ideas on what may cause this? Is anyone else seeing
> this issue on a build from the current master branch?
> >
> > Thanks,
> > -Matt
> >
> >
> > 
> >
>
>

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

[vpp-dev] vlib_plugin_registration size mismatch

[Matthew Smith via lists.fd.io]

Hi,

I have been testing against a build from yesterday's master branch (commit
id b0f0f8c8dd9d694bfc13652f89b8b577e9c1c708) and have been seeing these
messages when VPP starts up:

vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
bufmon_plugin.so
vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
dispatch_trace_plugin.so
vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
oddbuf_plugin.so
vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
perfmon_plugin.so
vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
tracedump_plugin.so
vpp: plugin/load: vlib_plugin_registration size mismatch in plugin
unittest_plugin.so

I noticed the problem because I was trying to do some testing on the
tracedump plugin and I could not get the tests to work. But many other
plugins (vrrp, nat, acl) work fine and do not have similar messages logged.

Does anyone have any ideas on what may cause this? Is anyone else seeing
this issue on a build from the current master branch?

Thanks,
-Matt

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21039): https://lists.fd.io/g/vpp-dev/message/21039
Mute This Topic: https://lists.fd.io/mt/89826377/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 interface configured under VRF is recognized as default VRF interface on FRR #vpp-dev

[Matthew Smith via lists.fd.io]

Hi Suresh,

The linux-cp/linux-nl plugins will not automatically manage assignments of
interfaces to a VRF/table, but you can use iproute2 commands to create a
VRF and move the tap to it.

Using table 1 and host interface lo5007 from your example, these commands
would associate that interface with the kernel's table 1:

ip link add dev vrf1 type vrf table 1
ip link set dev vrf1 up
ip link set dev lo5007 master vrf1

Routes added to the kernel's table 1 will be propagated to VPP's table 1 by
linux-nl.

-Matt


On Wed, Mar 9, 2022 at 8:27 PM suresh vuppala  wrote:

> HI VPP dev,
>
>   I have a loop configured under a vrf 1 in VPP. I need this interface to
> write into linux so it can be read by FRR as interface in vrf 1. I have
> configured as below but FRR still sees lo5007 in default vrf.
>
> ip table add 1
>
> set interface ip table loop5007 *1*
>
> lcp create loop5007 host-if lo5007
>
>
> FRR# show int br
>
> Interface   Status  VRF Addresses
>
> -   --  --- -
>
>
>
> lo  up  default
>
> lo5007  up * default   *  192.168.7.9/24
>
> lo5008  up  *default *192.168.6.9/24
>
> Can you please help here to config loop on VPP so FRR recognizes it as vrf
> interface
>
> Thanks,
> Suresh
>
>
>
> 
>
>

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

Re: [vpp-dev] VRRP master gratuitous ARP request with physical MAC address

[Matthew Smith via lists.fd.io]

Hi Ajesh,

Thanks for the explanation. When you have "accept mode" enabled on a VR and
that VR enters the master state, the virtual IP addresses get added on the
interface. From your description, it seems like the ARP/neighbor resolution
code is using the newly added IP address as the sender protocol address in
ARP requests rather than other addresses which were already configured on
the interface. I'll have to look into how that could be fixed.

Some possible workarounds for the time being:

   - Don't enable accept mode on the VR. If VRRP does not add the virtual
   IP address to the interface, it will not be used in ARP requests.
   - Create a static entry in the neighbor table for the gateway.

-Matt


On Fri, Feb 25, 2022 at 5:08 AM  wrote:

> Hi Matt,
>
> Thanks for the reply.
> We are(i am working with Mechthild) using an Ericsson R6K
> router(bridge/bvi on the router).
>
> The VPP VRRP master indeed sends GARP at start up with the right VRRP MAC
> address, so are the VRRP periodic advertisements using the correct virtual
> MAC.
> However, when it has to resolve the GW address it sends out ARP requests
> using the VIP and with the sender MAC as the physical interface MAC,
>
> like in this packet Mechthild has shown (172.17.1.3 is the VIP and .126 is
> the GW )
>
> 22:33:52.620143 78:ac:44:1f:47:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> (0x8100), length 46: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4
> (len 4), Request who-has 172.17.1.126 tell 172.17.1.3, length 28
>
> Frame 8: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
> Ethernet II, Src: Dell_1f:47:60 (78:ac:44:1f:47:60), Dst: Broadcast
> (ff:ff:ff:ff:ff:ff)
> 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 101
> Address Resolution Protocol (request)
> Hardware type: Ethernet (1)
> Protocol type: IPv4 (0x0800)
> Hardware size: 6
> Protocol size: 4
> Opcode: request (1)
> Sender MAC address: Dell_1f:47:60 (78:ac:44:1f:47:60)   <<
> Sender IP address: 172.17.1.3
> Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
> Target IP address: 172.17.1.126
>
> This causes the R6K to update the ARP/bridge table.
>
> The RFC states that,
>
>When a VRRP router restarts or boots, it SHOULD NOT send any ARP
>messages using its physical MAC address for the IPv4 address it owns;
>it should only send ARP messages that include virtual MAC addresses.
>
>
> However it is not mentioning about regular operation - but logically it
> should still work the same way, or?
>
> Thanks and best regards,
> Ajesh
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20918): https://lists.fd.io/g/vpp-dev/message/20918
Mute This Topic: https://lists.fd.io/mt/89367259/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] VRRP master gratuitous ARP request with physical MAC address

[Matthew Smith via lists.fd.io]

Hi Mechthild,

See comments below...

On Thu, Feb 24, 2022 at 9:30 AM Mechthild Buescher via lists.fd.io
 wrote:

> Hi all,
>
>
>
> We have another problem/question related to VRRP. When the router connect
> to the setup has disabled MAC learning, the ARP table on the router doesn’t
> have the virtual MAC for the VIP but the physical MAC of the interface on
> the VRRP master.
>
>
>
> Tracing showed that GARP is sent from VIP with physical MAC of the
> interface:
>
> 22:33:52.620143 78:ac:44:1f:47:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> (0x8100), length 46: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4
> (len 4), Request who-has 172.17.1.126 tell 172.17.1.3, length 28
>
> 22:33:52.620145 78:ac:44:1f:47:60 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> (0x8100), length 46: vlan 102, p 0, ethertype ARP, Ethernet (len 6), IPv4
> (len 4), Request who-has 172.17.2.126 tell 172.17.2.3, length 28
>
> 22:33:58.461327 78:ac:44:1f:47:60 > 00:25:90:5f:67:45, ethertype 802.1Q
> (0x8100), length 60: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4
> (len 4), Reply 172.17.1.3 is-at 00:00:5e:00:01:e7, length 42
>
> 22:33:59.485321 78:ac:44:1f:47:60 > 00:25:90:5f:67:45, ethertype 802.1Q
> (0x8100), length 60: vlan 101, p 0, ethertype ARP, Ethernet (len 6), IPv4
> (len 4), Reply 172.17.1.3 is-at 00:00:5e:00:01:e7, length 42
>
>
>

These packets are standard ARP replies & requests, not gratuitous ARP
requests. The "who-has" (target protocol address) and "tell" (source
protocol address) IP addresses would be the same if it was a gratuitous ARP
request. E.g. -

12:12:42.064324 00:08:a2:0b:0d:27 > Broadcast, ethertype ARP (0x0806),
length 60: Request who-has 198.51.100.5 (Broadcast) tell 198.51.100.5,
length 46



> This seems to be wrong. If I read the standard correctly (
> https://datatracker.ietf.org/doc/html/rfc3768, ch. 8.2), it should use
> the virtual router MAC address for GARP requests.
>
>
>

The RFC you cite (3768) is for VRRPv2. The VRRP plugin only implements
support for VRRPv3, which is specified in RFC 5798. Regardless, both of
those RFCs say: "When configuring an interface, Virtual Router Master
routers should broadcast a gratuitous ARP request containing the virtual
router MAC address for each IPv4 address on that interface". The gratuitous
ARP packet sent by VPP's VRRP plugin does contain the VR virtual MAC
address in the ARP sender hardware address field. It does not use the VR
virtual MAC address as the source MAC address in the ethernet header of the
ARP request packet though, it uses the MAC address of the hardware
interface. RFC 5798 does not say anything about which source MAC address
(hardware vs virtual) should be used on a gratuitous ARP request. The only
mention I found related to ARP source MAC addresses is in section 8.1.2 (
https://datatracker.ietf.org/doc/html/rfc5798#section-8.1.2) which says
that ARP replies to requests for the VR virtual IP addresses should use the
hardware MAC address rather than the virtual MAC address - "Note that the
source address of the Ethernet frame of this ARP response is the physical
MAC address of the physical router".

If your router is populating it's ARP table using the source MAC address of
a gratuitous ARP packet rather than using the sender protocol address from
the packet payload, that seems like incorrect behavior. What type of router
is it?

Thanks,
-Matt



> MASTER conifg:
> # vppctl show vrrp vr
>
> [0] sw_if_index 26 VR ID 231 IPv4
>
>state Master flags: preempt no accept yes unicast no
>
>priority: configured 200 adjusted 200
>
>timers: adv interval 100 master adv 100 skew 21 master down 321
>
>virtual MAC 00:00:5e:00:01:e7
>
>addresses 172.17.1.3
>
>peer addresses
>
>tracked interfaces
>
>
>
> VPP version (includes  https://gerrit.fd.io/r/c/vpp/+/34815 ):
> # vppctl show version verbose
>
> Version:  v21.06.0-2~g4ffc97bad
>
> Compiled by:  suse
>
> Compile host: SUSE
>
> Compile date: 2022-02-21T13:42:14
>
> Compile location: /root/vpp-21.06-release/vpp
>
> Compiler: GCC 7.5.0
>
> Current PID:  6528
>
>
>
> Is this a bug in VPP or is there a configuration parameter which I
> overlooked?
>
>
>
> Thanks for your help,
>
>
>
> BR/Mechthild
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20911): https://lists.fd.io/g/vpp-dev/message/20911
Mute This Topic: https://lists.fd.io/mt/89367259/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] VRRP issue when using VRs in different VLANs

[Matthew Smith via lists.fd.io]

Hi Mechthild,

It looks like you are running version 21.06 of VPP. This patch was merged
last month and may resolve the issue - https://gerrit.fd.io/r/c/vpp/+/34815.
Can you try applying that patch to your build?

Let me know if that helps.

Thanks,
-Matt


On Fri, Feb 18, 2022 at 3:06 PM Mechthild Buescher via lists.fd.io
 wrote:

> Hi all,
>
>
>
> We are using VPP on two nodes and run VRRP on them. This works fine as
> long as we use one VLAN. But if we configure VRs in different VLANs we see
> strange behavior: Every 4 seconds, the backup  VRRP VR shortly changes to
> master and sends an advertisement message to the master and then it changes
> back to master.
>
> The symptom:
> # while true; do date; vppctl show vrrp vr | grep state; echo; sleep 1;
> done
>
> Fri Feb 18 20:33:15 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Backup flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:16 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Backup flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:17 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Backup flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:18 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Master flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:19 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Backup flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:20 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Backup flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:21 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Backup flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:22 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Master flags: preempt no accept yes unicast no
>
>
>
> Fri Feb 18 20:33:23 UTC 2022
>
>state Backup flags: preempt no accept yes unicast no
>
>state Backup flags: preempt no accept yes unicast no
>
>
>
> # tcpdump -nve -r /tmp/my_vppExt0_2vrid_2vlan.pcap | grep -B1 "vrid 232”
>
> 00:02:25.805841 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q
> (0x8100), length 50: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id
> 0, offset 0, flags [none], proto VRRP (112), length 32)
>
> 172.17.2.2 > 224.0.0.18: vrrp 172.17.2.2 > 224.0.0.18: VRRPv3,
> Advertisement, vrid 232, prio 100, intvl 100cs, length 12, addrs: 172.17.2.3
>
> --
>
> 00:02:26.190168 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q
> (0x8100), length 60: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id
> 0, offset 0, flags [none], proto VRRP (112), length 32)
>
> 172.17.2.3 > 224.0.0.18: vrrp 172.17.2.3 > 224.0.0.18: VRRPv3,
> Advertisement, vrid 232, prio 200, intvl 100cs, length 12, addrs: 172.17.2.3
>
> --
>
> 00:02:27.194227 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q
> (0x8100), length 60: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id
> 0, offset 0, flags [none], proto VRRP (112), length 32)
>
> 172.17.2.3 > 224.0.0.18: vrrp 172.17.2.3 > 224.0.0.18: VRRPv3,
> Advertisement, vrid 232, prio 200, intvl 100cs, length 12, addrs: 172.17.2.3
>
>
>
> The configuration:
> BACKUP system:
> ip table add 26
>
> ip table add 27
>
> set interface state Ext-0 up
>
> create sub-interfaces Ext-0 101
>
> create sub-interfaces Ext-0 102
>
> set interface state Ext-0.101 up
>
> set interface state Ext-0.102 up
>
>
>
> set interface ip table Ext-0.101 26
>
> set interface ip table Ext-0.102 27
>
> set interface ip address Ext-0.101 172.17.1.2/25
>
> set interface ip address Ext-0.102 172.17.2.2/25
>
> vrrp vr add Ext-0.101 vr_id 231 priority 100 no_preempt accept_mode
> 172.17.1.3
>
> vrrp vr add Ext-0.102 vr_id 232 priority 100 no_preempt accept_mode
> 172.17.2.3
>
>
>
> MASTER system:
> ip table add 26
>
> ip table add 27
>
> set interface state Ext-0 up
>
> create sub-interfaces Ext-0 101
>
> create sub-interfaces Ext-0 102
>
> set interface state Ext-0.101 up
>
> set interface state Ext-0.102 up
>
>
>
> set interface ip table Ext-0.101 26
>
> set interface ip table Ext-0.102 27
>
> set interface ip address Ext-0.101 172.17.1.1/25
>
> set interface ip address Ext-0.102 172.17.2.1/25
>
> vrrp vr add Ext-0.101 vr_id 231 priority 200 no_preempt accept_mode
> 172.17.1.3
>
> vrrp vr add Ext-0.102 vr_id 232 priority 200 no_preempt accept_mode
> 172.17.2.3
>
>
>
> Running BACKUP config:
>
> # vppctl show vrrp vr
>
> [0] sw_if_index 2 VR ID 231 IPv4
>
>state Backup flags: preempt no accept yes unicast no
>
>priority: configured 100 adjusted 100
>
>timers: adv interval 100 master adv 100 skew 60 master down 360
>
>virtual MAC 00:00:5e:00:01:e7
>
>addresses 172.17.1.3
>
>peer addresses
>
>tracked interfaces
>
> [1] sw_if_index 3 VR ID 232 IPv4
>
> 

Re: [vpp-dev] Is it too late for Wireguard patches getting in for VPP22.02?

[Matthew Smith via lists.fd.io]

Hi Andrew,

The change in crypto.h that you called out as being whitespace-only
actually changes more than whitespace... It also appends '_
(CHACHA20_POLY1305, "chacha20-poly1305", 32, 16, 0)'
to foreach_crypto_aead_async_alg.

-Matt


On Wed, Jan 19, 2022 at 10:21 AM Andrew  Yourtchenko 
wrote:

> Hi Fan,
>
> With my release manager hat on:
>
> the first three patches are solely contained (minus seemingly
> whitespace change in 34660? can it be avoided ?) within wireguard
> plugin, which has "experimental" status, with which I would be happy
> to err on the side of keeping the velocity - so once the nit i pointed
> out is taken care of, I would be happy to merge the cherry-picks into
> the stable/2202, provided it is "soon" for some very proximate value
> of "soon" :)
>
> the last patch  to crypto-dev is an improvement, and looks fairly
> straightforward addition, backwards compatible, and was +2'd by Damjan
> back in December. So, from the "technical" standpoint it should have
> been in, but there was new year break period, etc, etc. So I would
> again would be fine with merging the cherry-pick into stable/2202, but
> for this one" the value of "soon" should not exceed "end of this
> week".
>
> In case no-one from the community objects to the above by this Friday
> 12:00 UTC, let's get these as cherry-picks into stable/2202.
>
> (p.s.: the 22.02 RC1 is not tagged yet, but the v22.06-rc0 tag is
> already on master, I would rather not mess with that).
>
> --a
>
>
> On 1/19/22, Fan Zhang  wrote:
> > Hi,
> >
> > Sorry for the late notice, but we have a bunch of patches waiting to be
> > reviewed/merged if possible for VPP22.02.
> >
> > The patches do 2 things
> >
> >   *   Optimizing wireguard performance by introducing burst processing of
> > packets and chacha-poly encryption/decryption.
> >   *   Adding async mode to wireguard so the crypto can be processed by
> > sw-crypto-scheduler or QAT.
> >
> > They are
> > https://gerrit.fd.io/r/c/vpp/+/34324
> > https://gerrit.fd.io/r/c/vpp/+/34660/2
> > https://gerrit.fd.io/r/c/vpp/+/34661/2
> > https://gerrit.fd.io/r/c/vpp/+/34662/4
> >
> > We know the patches are not perfect - as Matthew already pointed out
> there
> > are some improvements can be done (thank you very much Matthew!).
> > The bottom line is
> >
> >   *   They passed the wireguard unit tests, and we will keep improving
> > them.
> >   *   The code change had >5% performance improvement with small packets.
> >
> > But are they too late for VPP22.02? Much appreciate for the help in
> > advance!
> >
> > Regards,
> > fan
> >
> >
> >
>

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

Re: [vpp-dev] how to config vrrp unicast mode

[Matthew Smith via lists.fd.io]

Hi Guangming,

I merged https://gerrit.fd.io/r/c/vpp/+/34768. It allows the virtual
address to be added when accept mode is enabled on a VR which sends unicast
advertisements.

Thanks,
-Matt


On Mon, Jan 3, 2022 at 10:07 PM Guangming 
wrote:

> Hi,Matt
> Thanks for your detail reply.  Maybe I was wrong about VRRP in VPP.
> My expected behavior is that the master and backup  have a virtual
> ip and virtual  mac. The virtual ip and mac are  used to connected with
> the other device.
> They are removed when device switch to backup and are  added when switch
> to master. Or they are always exist on the two device, but only the mater
> device can send and
> recieve the packet  which destination ip address  is the virtual ip.
>
>  The reason is  i want to use unicast is remote  disaster recovey
> scenario , not only cloud. The other is reduce the multicast packet in LAN.
>
>  From  the code , I think the device may drop the packet which dst
> address is virtual,  because the virtual ip is not the second address of
> the interface with your proposal configure. My vpp version is 2110.1
>  Now my test environment is not ready because  our lab is removal. I will
> verify your configure  when test environment is ready .
>
>  I aslo found the other issue about VRRP.  One is the source ethenet
>  address in  gratuitous ARP  is not the virtual MAC, so the the virtaul MAC
> in switch is unkonwn unicast .
> The other is the  MAC is not same that master device used when it handle
> the send and recieve packet. One is virtual MAC , the other is real MAC.  I
> think  both are virtual mac is more
> friendly to peer device.
>
>
>
> Thanks
> Guangming
>
>
>
>
> --
> zhangguangm...@baicells.com
>
> *From:* Matthew Smith 
> *Date:* 2022-01-04 03:02
> *To:* zhangguangm...@baicells.com
> *CC:* vpp-dev 
> *Subject:* Re: how to config vrrp unicast mode
> Hi Guangming,
>
> I think the signaling between unicast peers should work if you do
> something like this:
>
> device A:
> set int ip address GigabitEthernet0/14/0 10.10.10.10/24
> set int state GigabitEthernet0/14/0 up
> vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 10.10.10.15 unicast 
> vrrp
> peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5
> vrrp proto start GigabitEthernet0/14/0 vr_id 1
>
> device B:
> set int ip address GigabitEthernet0/14/0 10.10.10.5/24
> set int state GigabitEthernet0/14/0 up
> vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 10.10.10.15 unicast
> vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10
> vrrp proto start GigabitEthernet0/14/0 vr_id 1
>
> That ought to cause your two instances to elect device A as the master. It
> should send advertisements to device B while it's up. It should also reply
> to ARP requests for 10.10.10.15 if it receives them, but it will reply with
> a VRRP virtual MAC address, which may not be the correct behavior for a
> unicast scenario. I originally added the capability to send unicast
> advertisements because I thought it may be useful for cloud environments
> which do not support multicast (AWS, Azure). But replying to an ARP request
> with a VRRP virtual MAC address may not be valid for cloud environments. Or
> it might not matter because the ARP request may be handled by
> infrastructure in those cloud environments and never actually delivered to
> the VM where VPP runs, I'm not sure.
>
> Your original commands enabled accept mode on each VR and added the VR
> virtual IP address (10.10.10.10/24) on the interface where the VR was
> being configured. In general, when you use accept mode, you don't need to
> configure the VR virtual IP address on the interface. You should only
> configure the virtual IP address on an interface of a VR that has priority
> 255 (the "owner" of the virtual IP address). On VR's with priority lower
> than 255, the address will automatically be added when the VR transitions
> into the master state and removed when it transitions from master to
> backup.  I don't recall whether enabling accept mode does anything if
> you're using unicast advertisements. As I mentioned, the functionality was
> intended for cloud environments and in those environments, it does not work
> to just add an IP address on an interface, there needs to be some outside
> action taken (use AWS/Azure API to remove address from one host/interface
> and add it on another).
>
> I have not tried to use unicast VRRP in production and I have not received
> any questions about it from users before, so YMMV. If you find something
> specific that is not working as expected, please let me know.
>
> Thanks,
> -Matt
>
>
>
> On Tue, Dec 28, 2021 at 3:37 AM zhangguangm...@ba

Re: [vpp-dev] how to config vrrp unicast mode

[Matthew Smith via lists.fd.io]

Hi Guangming,

I think the signaling between unicast peers should work if you do something
like this:

device A:
set int ip address GigabitEthernet0/14/0 10.10.10.10/24
set int state GigabitEthernet0/14/0 up
vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 10.10.10.15 unicast vrrp
peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5
vrrp proto start GigabitEthernet0/14/0 vr_id 1

device B:
set int ip address GigabitEthernet0/14/0 10.10.10.5/24
set int state GigabitEthernet0/14/0 up
vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 10.10.10.15 unicast
vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10
vrrp proto start GigabitEthernet0/14/0 vr_id 1

That ought to cause your two instances to elect device A as the master. It
should send advertisements to device B while it's up. It should also reply
to ARP requests for 10.10.10.15 if it receives them, but it will reply with
a VRRP virtual MAC address, which may not be the correct behavior for a
unicast scenario. I originally added the capability to send unicast
advertisements because I thought it may be useful for cloud environments
which do not support multicast (AWS, Azure). But replying to an ARP request
with a VRRP virtual MAC address may not be valid for cloud environments. Or
it might not matter because the ARP request may be handled by
infrastructure in those cloud environments and never actually delivered to
the VM where VPP runs, I'm not sure.

Your original commands enabled accept mode on each VR and added the VR
virtual IP address (10.10.10.10/24) on the interface where the VR was being
configured. In general, when you use accept mode, you don't need to
configure the VR virtual IP address on the interface. You should only
configure the virtual IP address on an interface of a VR that has priority
255 (the "owner" of the virtual IP address). On VR's with priority lower
than 255, the address will automatically be added when the VR transitions
into the master state and removed when it transitions from master to
backup.  I don't recall whether enabling accept mode does anything if
you're using unicast advertisements. As I mentioned, the functionality was
intended for cloud environments and in those environments, it does not work
to just add an IP address on an interface, there needs to be some outside
action taken (use AWS/Azure API to remove address from one host/interface
and add it on another).

I have not tried to use unicast VRRP in production and I have not received
any questions about it from users before, so YMMV. If you find something
specific that is not working as expected, please let me know.

Thanks,
-Matt



On Tue, Dec 28, 2021 at 3:37 AM zhangguangm...@baicells.com <
zhangguangm...@baicells.com> wrote:

>
> Hi Matthew
> I want to use two device that runing VPP as HA cluster. I found the vrrp
> cli support unicast mode.
> Can you give me a right vrrp unicast example ?
>
> My configure is as follow,
> device A :
> set int ip address GigabitEthernet0/14/0 10.10.10.10/24
> set int ip address GigabitEthernet0/14/0 10.10.10.15/24
> set int state GigabitEthernet0/14/0 up
>
> vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 accept_mode
> 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5
> vrrp proto start GigabitEthernet0/14/0 vr_id 1
>
> device B:
> set int ip address GigabitEthernet0/14/0 10.10.10.5/24
> set int ip address GigabitEthernet0/14/0 10.10.10.15/24
> set int state GigabitEthernet0/14/0 up
>
> vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 accept_mode
> 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10
> vrrp proto start GigabitEthernet0/14/0 vr_id 1
>
>
> Thanks
> Guangming
>
>
> --
> zhangguangm...@baicells.com
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20677): https://lists.fd.io/g/vpp-dev/message/20677
Mute This Topic: https://lists.fd.io/mt/87993023/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] MLX5 NIC interface is not visible

[Matthew Smith via lists.fd.io]

Your options are:

1. Use the rdma plugin and create rdma interfaces.
2. Use the DPDK plugin. The DPDK build that is generated when you build VPP
will not include the mellanox PMDs by default. You need to explicitly
enable them when you build. There are build variables named DPDK_MLX5_PMD
and DPDK_MLX5_COMMON_PMD which have default values set to 'n'. Those need
to be set to 'y' to build the mlx5 PMD. You can set these by running
something like 'make DPDK_MLX5_PMD=y DPDK_MLX5_COMMON_PMD=y pkg-deb', or
you could edit build/external/packages/dpdk.mk and change the defaults
there.

-Matt




On Fri, Dec 17, 2021 at 1:12 PM Varun Rapelly  wrote:

> Hi,
>
>
>
> I’m trying to use ConnectX-5 NIC interfaces in VPP (20.09) application
> running on a x86 host (Ubuntu 18.04), but *unable to find this interface
> in VPP*.
>
> Do we need to create *rdma interface to use mlx5 NIC interfaces? Or is
> there any other way to use this?*
>
>
>
> Below are configuration/NIC and other relevant details:
>
> *vpp# sh interface*
>
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
>
> local00 down  0/0/0/0
>
>
>
> *VPP startup configuration:*
>
> dpdk {
>
>dev :d9:00.0 {
>
> name eth0
>
> }
>
> }
>
>
>
> plugins {
>
> plugin default { enable }
>
> plugin dpdk_plugin.so {enable }
>
> }
>
>
>
> *NIC driver status:*
>
> Network devices using kernel driver
>
> ===
>
> :d9:00.0 'MT28800 Family [ConnectX-5 Ex] 1019' if=eth4 drv=*mlx5_core*
> unused=uio_pci_generic
>
>
>
> *vpp# sh pci*
>
> *:d9:00.0   1  15b3:1019   8.0 GT/s x16  mlx5_core   CX516A -
> ConnectX-5 QSFP28   PN: MCX516A-CDAT*
>
>
> EC: AA
>
>
> V2: 0x 4d 43 58 35 31 36 41 2d
> ...
>
>
> SN: MT2017J09203
>
>
> V3: 0x 39 36 38 37 30 34 64 62 ...
>
>
> VA: 0x 4d 4c 58 3a 4d 4f 44 4c ...
>
>
>   V0: 0x 50 43 49 65 47 65 6e 34 ...
>
>
> RV: 0x 08 00 00
>
>
>
> *vpp# sh log*
>
> 2021/12/17 18:53:08:339 notice dpdk   EAL init args: -c e -n 4
> --in-memory --no-telemetry --file-prefix vpp -a :d9:00.0 --main-lcore 1
>
> *2021/12/17 18:53:08:489 notice dpdk   DPDK drivers found no
> Ethernet devices...*
>
>
>
>
>
> Thanks,
>
> Varun
>
> 
>
>

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

[Matthew Smith via lists.fd.io]

+1



On Tue, Nov 9, 2021 at 11:20 AM Damjan Marion via lists.fd.io  wrote:

>
> Today on the project call, we were discussing about doing some changes on
> those calls.
>
> Proposal from few of us who were attending is:
>
> - we should make it less formal, stop doing readouts and focus on specific
> topics to discuss, if there is no topics to discuss we simply drop
>
> - we move to biweekly, same time, 2nd and 4th Tue each month
>
> - to increase attendance we encourage people having something to discuss
> to announce that in advance on the mailing list
>
> - we should preferably use this mailing list if we need to make any
> decisions
>
>
> What other people think?
>
> Thanks,
>
> —
> Damjan
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20467): https://lists.fd.io/g/vpp-dev/message/20467
Mute This Topic: https://lists.fd.io/mt/86936610/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] linux-cp patches 31122 ipv6 mtu TTL issue

[Matthew Smith via lists.fd.io]

I can't reproduce that issue.

When you ping from host2 to host1, the hop limit on the echo reply packets
would be set by host1. Is host1 using linux kernel networking? You have
specifically identified that host2 uses "Vpp+LinuxCP" and omitted that
designation from host1, so I presume host1 is not running VPP. If host1 is
using linux kernel networking, you could run tcpdump or wireshark to
inspect outbound packets from 2a01:500:10::1 to 2a01:500:10::2 to confirm
what hop limit is being sset on the echo reply packets sent by host1 to
host2.

-Matt


On Mon, Oct 11, 2021 at 4:13 PM Petr Boltík  wrote:

> Hi Matt,
> thank you - tested, but not fully solved.
> IPv4 icmp works fine
> IPv6 icmp
>
> [2a01:500:10::1/64host1]=>ether=>[host2-Vpp+LinuxCP 2a01:500:10::2/64]
> host2=>host1 new issue occur, ttl change to 255 after few icmp6, example
> below
> host1=>host2 works now fine
>
> Regards
> Petr
>
> 64 bytes from 2a01:500:10::1: icmp_seq=12 ttl=64 time=0.269 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=13 ttl=64 time=0.213 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=14 ttl=64 time=0.239 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=15 ttl=64 time=0.210 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=16 ttl=64 time=5.28 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=17 ttl=64 time=0.240 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=18 ttl=255 time=0.268 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=19 ttl=255 time=0.210 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=20 ttl=255 time=0.276 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=21 ttl=255 time=0.484 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=22 ttl=255 time=3.87 ms
>> 64 bytes from 2a01:500:10::1: icmp_seq=23 ttl=255 time=9.34 ms
>>
>
> po 11. 10. 2021 v 21:54 odesílatel Matthew Smith 
> napsal:
>
>>
>> Hi Petr,
>>
>> I don't think it is related to patch 31122, this seems to happen whether
>> you are using that patch or not. Both ip4-icmp-echo-request and
>> ip6-icmp-echo-request set outbound echo replies to have a TTL/hop-limit of
>> 64. The IPv4 node sets the VNET_BUFFER_F_LOCALLY_ORIGINATED flag on the
>> packets it sends but the IPv6 node neglects to do this. Setting that flag
>> will prevent a rewrite node from decrementing the TTL/hop-limit later on.
>>
>> Here's a patch which sets the flag for outbound IPv6 echo replies -
>> https://gerrit.fd.io/r/c/vpp/+/34040. Can you please test it and report
>> whether it solves the problem?
>>
>> Thanks,
>> -Matt
>>
>>
>> On Mon, Oct 11, 2021 at 1:03 PM Petr Boltík 
>> wrote:
>>
>>> Hi,
>>> I have found an issue with with linux-cp patch 31122.
>>> [192.168.15.1/24 host1]=>ether=>[host2-Vpp+LinuxCP 192.168.15.2/24]
>>> ipv4 icmp TTL
>>> host2=>host1 TTL64
>>> host1=>host2 TTL64
>>>
>>> ipv6 icmp TTL:
>>> host2=>host1 TTL64
>>> host1 =>host2 TTL63 (there should be the same increasing TTL mechanism
>>> as in the ipv4)
>>>
>>> Thanks for report this message to the right hands.
>>> Regards Petr
>>>
>>> 
>>>
>>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20313): https://lists.fd.io/g/vpp-dev/message/20313
Mute This Topic: https://lists.fd.io/mt/86243713/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] linux-cp patches 31122 ipv6 mtu TTL issue

[Matthew Smith via lists.fd.io]

Hi Petr,

I don't think it is related to patch 31122, this seems to happen whether
you are using that patch or not. Both ip4-icmp-echo-request and
ip6-icmp-echo-request set outbound echo replies to have a TTL/hop-limit of
64. The IPv4 node sets the VNET_BUFFER_F_LOCALLY_ORIGINATED flag on the
packets it sends but the IPv6 node neglects to do this. Setting that flag
will prevent a rewrite node from decrementing the TTL/hop-limit later on.

Here's a patch which sets the flag for outbound IPv6 echo replies -
https://gerrit.fd.io/r/c/vpp/+/34040. Can you please test it and report
whether it solves the problem?

Thanks,
-Matt


On Mon, Oct 11, 2021 at 1:03 PM Petr Boltík  wrote:

> Hi,
> I have found an issue with with linux-cp patch 31122.
> [192.168.15.1/24 host1]=>ether=>[host2-Vpp+LinuxCP 192.168.15.2/24]
> ipv4 icmp TTL
> host2=>host1 TTL64
> host1=>host2 TTL64
>
> ipv6 icmp TTL:
> host2=>host1 TTL64
> host1 =>host2 TTL63 (there should be the same increasing TTL mechanism as
> in the ipv4)
>
> Thanks for report this message to the right hands.
> Regards Petr
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20311): https://lists.fd.io/g/vpp-dev/message/20311
Mute This Topic: https://lists.fd.io/mt/86243713/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] Unexpected return from python3 api

[Matthew Smith via lists.fd.io]

The value of retval from the 2nd reply can be looked up in
src/vnet/api_errno.h:

_(VLAN_ALREADY_EXISTS, -56, "VLAN subif already exists")

The attempt to create a VLAN subif is failing because the one you're trying
to create has already been created.


On Sat, Oct 2, 2021 at 3:23 AM Eyle Brinkhuis 
wrote:

> Hi,
>
> While using a small piece of python code to create a vlan subinterface, we
> get some unexpected returns:
>
> We run:
> vpp.api.create_vlan_subif(sw_if_index=3, vlan_id=101);
>
> The return for this varies, one time it is:
>
> create_vlan_subif_reply(_0=121, context=4, retval=0, sw_if_index=5)
>
> But it is not consistent, we get
> create_vlan_subif_reply(_0=121, context=4, retval=-56,
> sw_if_index=4294967295)
> Back as well, which is of no use to us. Anyone experienced the same?
>
> We run vpp 21.06 (installed from package cloud)
>
> Regards,
>
> Eyle
> 
>
>

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

[Matthew Smith via lists.fd.io]

Try "dslite { ce }" in startup.conf instead.

DS-lite used to be part of the NAT plugin. The NAT plugin was broken up
into several smaller plugins so DS-lite startup.conf items moved from the
"nat" section to a new "dslite" section.

-Matt


On Fri, Oct 1, 2021 at 3:28 PM Ameen Al-Azzawi 
wrote:

> Hi
>
> Every time I add the command "nat { dslite ce } "  to my "startup.conf"
> file, then restart vpp, I get the below error message.
>
> "clib_socket_init: connect (fd 3, '/run/vpp/cli.sock'): Connection refused"
>
> I have disabled "selinux"  already.
>
> My entire " startup.conf "  file is attached.
>
> Regards
> Ameen
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20273): https://lists.fd.io/g/vpp-dev/message/20273
Mute This Topic: https://lists.fd.io/mt/86010302/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] rx-miss while sending packets to Interface (IMPORTANT)

[Matthew Smith via lists.fd.io]

I saw two noteworthy items in your 'vppctl show runtime' output:

1. All of the packets received/processed appear to be handled by the
gtpu4-input node. They also all appear to be received/handled by a single
worker thread.
2. Nearly all of the packets are being dropped. I mean the packets that
were actually received and processed - not the packets that were counted as
an rx-miss.

Regarding #1 -

I imagine that one thread might be receiving all inbound packets because
you're sending across a single GTPU tunnel (i.e. a single stream). If this
is true, AFAIK most NICs will hash all of the packets to the same queue.
This means you will likely be constrained to handling however many packets
can be handled by a single thread and increasing the number of workers or
rx queues won't help. You might be able to utilize multiple workers/queues
by sending across  multiple tunnels. I know very little about GTPU use
cases so I don't know whether it's practical for you to use multiple
tunnels.

Regarding #2 -

Out of 8004674 packets received by dpdk-input, 7977696 packets end up being
dropped by error-drop. It would probably be useful to look at a packet
trace and see what node is sending the packets to error-drop. If packets
are being passed to error-drop by gtpu4-input, maybe they do not match any
configured tunnel.

-Matt


On Tue, Sep 28, 2021 at 9:24 AM Akash S R  wrote:

> Hello,
>
> I have tried increasing the workers from 2 to 5 and rx/tx queues from 1024
> (default) to 2048 ,also decreasing till 256 but of no use.
> As you told, vector is very high (> 100). Please let us know if there is
> any other way or reason for the same.
>
>
> Thread 1 vpp_wk_0 (lcore 2)
> Time 41.3, 10 sec internal node vector rate 79.42 loops/sec 3628.25
>   vector rates in 1.9388e5, out 6.5319e2, drop 1.9322e5, punt 0.e0
>  Name State Calls  Vectors
>Suspends Clocks   Vectors/Call
> TenGigabitEthernet4/0/0-output   active  19735   26978
>   0  2.12e31.37
> TenGigabitEthernet4/0/0-tx   active  19735   26969
>   0  1.43e31.37
> dpdk-input   polling  10241833 8004674
>   0  2.81e3 .78
> drop active  92422 7977696
>   0  1.31e3   86.32
> error-drop   active  92422 7977696
>   0  6.82e1   86.32
> ethernet-input   active  93109 8004674
>   0  1.84e2   85.97
> gtpu4-input  active  93106 8004671
>   0  3.29e2   85.97
> ip4-drop active  2   2
>   0  1.33e41.00
> ip4-inputactive  93106 8004671
>   0  6.82e2   85.97
> ip4-input-no-checksumactive  93106 8004673
>   0  2.37e2   85.97
> ip4-localactive  93106 8004671
>   0  2.66e2   85.97
> ip4-lookup   active 112841 8031651
>   0  3.55e2   71.18
> ip4-policer-classify active  93106 8004671
>   0  1.35e3   85.97
> ip4-rewrite  active  19735   26978
>   0  2.43e31.37
> ip4-udp-lookup   active  93106 8004671
>   0  3.17e2   85.97
> ip6-inputactive  1   1
>   0  1.99e41.00
> ip6-not-enabled  active  1   1
>   0  2.59e41.00
> unix-epoll-input polling  9998   0
>   0  3.30e30.00
> ---
> Thread 2 vpp_wk_1 (lcore 3)
> Time 41.3, 10 sec internal node vector rate 0.00 loops/sec 988640.31
>   vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0
>  Name State Calls  Vectors
>Suspends Clocks   Vectors/Call
> dpdk-input   polling  37858263   0
>   0  1.14e30.00
> unix-epoll-input polling 36940   0
>   0  3.54e30.00
> ---
> Thread 3 vpp_wk_2 (lcore 4)
> Time 41.3, 10 sec internal node vector rate 0.00 loops/sec 983700.23
>   vector rates in 4.8441e-2, out 0.e0, drop 4.8441e-2, punt 0.e0
>   

Re: [vpp-dev] upcoming change in nat44-ed static mapping API

[Matthew Smith via lists.fd.io]

On Tue, Sep 28, 2021 at 5:50 AM Klement Sekera -X (ksekera - PANTHEON TECH
SRO at Cisco)  wrote:

> Hi Matt/vpp-dev,
>
> I’m reaching out after discussion with Andrew regarding an upcoming change
> in behaviour of an API. Currently, when
> nat44_ed_add_del_static_mapping[_v2] is called, the supplied u8 protocol
> value is taken and silently converted into
> NAT_PROTOCOL_(TCP|UDP|ICMP|OTHER). Part of upcoming change is to drop this
> internal enum and treat static mappings (SM) same way as dynamic mappings -
> to store IANA IP protocol value in SM instead of said nat_protocol_t. This
> however causes a behaviour change.
>
> For TCP, UDP and ICMP there is NO change. For everything else the change
> is:
>
> Old:
>
> nat44_ed_add_del_static_mapping (is_add=1, protocol=101) is treated as
> "nat44_ed_add_del_static_mapping (protocol=other)", so this creates a
> catch-almost-all SM, which then translates also all other protocols except
> tcp, udp and icmp. Calling nat44_ed_add_del_static_mapping (is_add=1,
> protocol=102) would then return VNET_API_ERROR_VALUE_EXIST (because it’s
> internally translated to the same “other” thingie).
>
> New:
>
> protocol is stored in (and matched by) static mapping exactly as it’s
> supplied. To get old behaviour a user would have to create 252 static
> mappings (with all protocol values except tcp, udp, icmp). New feature with
> this is ability to translate only some of non-tcp/udp/icmp protocols as it
> isn’t a catch-almost-all logic anymore.
>
> Question is whether there is a real need to do the usual deprecate old api
> and keep its behaviour (which would now internally add/del 252 mappings)
> while introducing a new api with new behaviour routine or it’s okay to
> change it under the hood keeping apis intact. The apis are already
> accepting ip protocol value, so there is no change required in api
> signature.
>
> Would you be so kind to share your thoughts on this topic?
>
> Thanks,
> Klement


Hi Klement,

It's ok with me. Netgate does not have any code that relies on the old
behavior.

Thanks,
-Matt

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20225): https://lists.fd.io/g/vpp-dev/message/20225
Mute This Topic: https://lists.fd.io/mt/85921424/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] Linux CP: crash in lcp_node.c

[Matthew Smith via lists.fd.io]

Hi Pim,

Responses are inline...

On Tue, Aug 24, 2021 at 4:47 AM Pim van Pelt  wrote:

> Hoi,
>
> I've noticed that when a linuxcp enabled VPP 21.06 with multiple threads
> receives many ARP requests, eventually it crashes in lcp_arp_phy_node in
> lcp_node.c:675 and :775 because we do a vlib_buffer_copy() which returns
> NULL, after which we try to dereference the result. How to repro:
> 1) create a few interfaces/subints and give them IP addresses in Linux and
> VPP. I made 5 phy subints and 5 subints on a bondethernet.
> 2) rapidly fping the Linux CP and at the same time continuously flush the
> neighbor cache on the Linux namespace:
> On the vpp machine in 'dataplane' namespace:
>   while :; do ip nei flush all; done
> On a Linux machine connected to VPP:
>   while :; do fping -c 1 -B 1 -p 10 10.1.1.2 10.1.2.2 10.1.3.2
> 10.1.4.2 10.1.5.2 10.0.1.2 10.0.2.2 10.0.3.2 10.0.4.2 10.0.5.2
> 2001:db8:1:1::2 2001:db8:1:2::2 2001:db8:1:3::2 2001:db8:1:4::2
> 2001:db8:1:5::2 2001:db8:0:1::2 2001:db8:0:2::2 2001:db8:0:3::2
> 2001:db8:0:4::2 2001:db8:0:5::2; done
>
> VPP will now be seeing lots of ARP traffic to and from the host. After a
> while, c0 or c1 from lcp_node.c:675 and lcp_node.c:775 will be NULL and
> cause a crash.
> I temporarily worked around this by simply adding:
>
> @@ -675,6 +675,10 @@ VLIB_NODE_FN (lcp_arp_phy_node)
>
>   c0 = vlib_buffer_copy (vm, b0);
>
>   vlib_buffer_advance (b0, len0);
>
>
>
> + // pim(2021-08-24) -- address SIGSEGV when copy returns
> NULL
>
> + if (!c0)
>
> +   continue;
>
> +
>
>   /* Send to the host */
>
>   vnet_buffer (c0)->sw_if_index[VLIB_TX] =
>
> lip0->lip_host_sw_if_index;
>
> but I'm not very comfortable in this part of VPP, and I'm sure there's a
> better way to catch the buffer copy failing?
>

No, checking whether the return value is null is the correct way to detect
failure.



> I haven't quite understood this code yet, but shouldn't we free c0 and c1
> in these functions?
>

No, c0 and c1 are enqueued to another node (interface-output). The buffers
are freed after being transmitted or dropped by subsequent nodes. Freeing
them in this node while also enqueuing them would result in problems.



> It seems that when I'm doing my rapid ping/arp/flush exercise above, VPP
> is slowly consuming more memory (as seen by show memory main-heap; all 4
> threads are monotonously growing by a few hundred kB per minute of runtime).
>

I made a quick attempt to reproduce the issue and was unsuccessful. Though
I did not use a bond interface or subinterfaces, just physical interfaces.

How many buffers are being allocated (vppctl show buffers)? Does the issue
occur if you only send IPv4 packets instead of both IPv4 and IPv6? Are
other packets besides the ICMP and ARP being forwarded while you're running
this test? Is there any other control plane activity occurring during the
test (E.g. BGP adding routes)?



> If somebody could help me take a look, I'd appreciate it.
>

 It would be better to make your patch like this:

  if (c0)
{
  /* Send to the host */
  vnet_buffer (c0)->sw_if_index[VLIB_TX] =
lip0->lip_host_sw_if_index;
  reply_copies[n_copies++] = vlib_get_buffer_index (vm,
c0);
}

When you do the opposite ('if (!c0) continue;'), you skip the call to
vlib_validate_buffer_enqueue_x2() at the end of the loop body which would
enqueue the original buffers to the next node. So those buffers will leak
and the issue will be exacerbated.

Thanks,
-Matt

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20019): https://lists.fd.io/g/vpp-dev/message/20019
Mute This Topic: https://lists.fd.io/mt/85107134/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 got stucked after bridge and loop interfaces is created and snat is configured #nat44

[Matthew Smith via lists.fd.io]

What version of VPP are you using? A patch was merged 2 days ago which may
fix the problem - https://gerrit.fd.io/r/c/vpp/+/33018.

-Matt


On Thu, Aug 19, 2021 at 7:57 AM  wrote:

> vpp version: 21.06
> vpp main core will be stucked after bridge and loop interfaces and snat is 
> configured, here is my topology.
>
> /--\/--\/--\
> |  ||  ||  |
> |client  enp0s8  GE0/2/0   vpp  GE0/5/0  enp0s10  server   |
> |  ||  ||  |
> \--/\--/\--/
>
>192.0.2.0/24192.168.3.0/24
>
> and here is my configuration:
> nat44 enable
> nat44 forwarding enable
> nat44 add int address GigabitEthernet5/0/0
> set int nat44 in GigabitEthernet2/0/0 out GigabitEthernet5/0/0
> output-feature
> create tap id 0
> set interface state tap0 up
> set int l2 bridge GigabitEthernet2/0/0 1
> set int l2 bridge tap0 1
> create loopback interface
> set int l2 bridge loop0 1 bvi
> set int ip addr loop0 192.0.2.11/24
> set int state loop0 up
>
> vpp will be stucked after a few ping from client to server, here is
> backtrace info in gdb:
> #0  0x7f980557f0d1 in internal_mallinfo (m=0x7f97bb18b040) at
> /usr/src/debug/vpp-0.1/src/vppinfra/dlmalloc.c:2099
> #1  0x7f98055707d7 in mspace_mallinfo (msp=) at
> /usr/src/debug/vpp-0.1/src/vppinfra/dlmalloc.c:4803
> #2  clib_mem_get_heap_usage (heap=, 
> usage=usage@entry=0x7f97bb05df40)
> at /usr/src/debug/vpp-0.1/src/vppinfra/mem_dlmalloc.c:475
> #3  0x55c1903304fa in do_stat_segment_updates (sm=0x55c1903c7ac0
> ) at
> /usr/src/debug/vpp-0.1/src/vpp/stats/stat_segment.c:661
> #4  stat_segment_collector_process (vm=0x7f98056b2680 ,
> rt=, f=) at
> /usr/src/debug/vpp-0.1/src/vpp/stats/stat_segment.c:761
> #5  0x7f9805648897 in vlib_process_bootstrap (_a=) at
> /usr/src/debug/vpp-0.1/src/vlib/main.c:1477
> #6  0x7f9805587d80 in clib_calljmp () from /lib64/libvppinfra.so.0.1
> #7  0x7f97bd38add0 in ?? ()
>
> after debugs i found the reason, vpp counts the packets through snat, it
> store the result in nm->counters.fastpath.in2out.icmp, which is a vector
> struct, the size of the vector is based on interfaces index, based on my
> configures above, the size is 3, but after i configured loop and bridge
> interfaces, both the new interface index is bigger than 3. when packets
> pass through snat, it thought packet is received from loop interface, and
> then got out of bonds when writing vector.
> and my question is:
> 1.based on my configuration above, does packets counts saved to loop
> interface is correct?
> 2.Besides avoiding misconfiguration, how to fix it?
> thanks a lot.
>
> 
>
>

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

Re: [vpp-dev] BondedInterface and memif interface for raw packet #memif #BondedInterface #plugin

[Matthew Smith via lists.fd.io]

On Thu, Jul 15, 2021 at 2:12 PM RaviKiran Veldanda 
wrote:

> Hi Experts,
> We implemented a PLUGIN, this plugin reads packets from physical interface
> and sends to memif.
> The memif other end is our application, it takes necessary action.
> The packet flow would be
>
> Devie-Input --> OUR Plugin --> Memif --> Our application.(Plugin filters
> the packets and send to memif or Bond-input.)
> or
> Devie-Input --> OUR Plugin --> bond-input --> VPP processing.
>
> Our plugin is working with only physical interface. Now we are trying to
> make this work with Bonded Interface, its not working with bonded interface.
> If we disable bond-input for that physical interface and only enable our
> plugin it will work fine. But we needed BondedInterface support for LACP.
> So we can't just avoid BondedInterface.
>

Hi Ravi,

What constitutes "not working"? Packets are not reaching your plugin node?
Packets are not reaching your application across the memif? Packets handed
by your plugin node to bond-input are not forwarded as expected? VPP
crashes? Something else?



> Our feature arc is
> VNET_FEATURE_INIT (ipgw_ent, static) =
> {
>   .arc_name = "device-input",
>   .node_name = "ravi_plugin",
>   .runs_before = VNET_FEATURES ("ethernet-input"),
> };
>
> I tried placing different arcs for my plugin, its not working. Can you
> please suggest how can our plugin to make it work for logical interfaces.
> Like if we want to make it work for BondedInterface.1100? which arc we
> should choose, we need raw packet to our application.
> Any pointers are very big help.
>
>
It's hard to say what the problem is without more information. It would be
helpful to see output of a vppctl packet trace for one of the packets which
is being handled incorrectly. Hopefully your plugin node is capable of
adding trace data.
Output of 'vppctl show runtime' might also be helpful.

Some guesses of things that might be related to the problem:

   - If you're using LACP, some inband signaling is required between your
   physical interfaces and the devices they're attached to. Is your plugin
   causing LACP packets to be dropped?
   - bond-input is itself a node on the device-input arc. With your
   declaration containing '.runs_before = VNET_FEATURES ("ethernet-input"),',
   I don't think you are guaranteed that your plugin node will process a
   packet before bond-input does. Maybe changing to '.runs_before =
   VNET_FEATURES ("bond-input"),' will help.
   - How is your plugin node handing packets off to bond-input? Are you
   calling vnet_feature_next() or are you explicitly handing off to
   bond-input? bond-input calls vnet_feature_next() to figure out the next
   node it should hand a packet to. If your plugin node did not call
   vnet_feature_next() and instead just handed the packet directly to
   bond-input, that might cause issues when bond-input calls
   vnet_feature_next().

-Matt

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

Re: [vpp-dev] VRRP issue when using interface in a table

[Matthew Smith via lists.fd.io]

Hi Mechthild,

Here is a patch you can try - https://gerrit.fd.io/r/c/vpp/+/32999.

Let me know if it works for you. I don't have an i40e readily available to
test it on and my local build is still using DPDK 21.01 while the
current gerrit master branch uses DPDK 21.05 by default. So I could not
test it against the current gerrit master branch. The exact same patch
works against DPDK 21.01 and the function it modifies was not changed
between 21.01 and 21.05 so I expect it ought to work, but. YMMV.

I'll set the review score to -2 until I receive confirmation from you that
it is working.

-Matt


On Fri, Jul 2, 2021 at 11:48 AM Mechthild Buescher <
mechthild.buesc...@ericsson.com> wrote:

> Hi Matt,
>
>
>
> Thanks for your fast reply. Yes, it seems to be the “source pruning” issue
> on X710/XL710.
>
>
>
> When both VRs are in the master state, I can’t see any VRRP messages in
> the dpdk-input trace. Furthermore, I tried VRRP with Intel e1000 NICs where
> it behaves correctly: When the interface of the VRRP master goes down, the
> VRRP backup changes to state master and when the VRRP master recovers (ie.
> Interface is up), the peer node changes back to state backup.
>
>
>
> It would be nice if you can tell me how to disable source pruning with
> DPDK PMD.
>
>
>
> Thank you,
>
>
>
> BR/Mechthild
>
>
>
> *From:* Matthew Smith 
> *Sent:* Friday, 2 July 2021 16:06
> *To:* Neale Ranns 
> *Cc:* Mechthild Buescher ;
> vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] VRRP issue when using interface in a table
>
>
>
>
>
> There could be an issue with the NIC:
>
>
>
> vpp# show hardware-interfaces
>   NameIdx   Link  Hardware
> Ext-0  1 up   Ext-0
>   Link speed: 10 Gbps
>   Ethernet address e4:43:4b:ed:59:10
>   Intel X710/XL710 Family
>
>
>
> With certain versions of firmware, these interfaces have a feature called
> "source pruning" enabled by default. When a MAC address is added on a
> X710/XL710 interface, packets which arrive with that address as their
> source MAC address are filtered by the NIC. Since VRRP uses a virtual MAC
> address as the source address of advertisements sent to peers, source
> pruning causes problems for it. A VRRP VR entering the master state will
> add the virtual MAC address to the NIC and henceforth the NIC will filter
> any higher priority advertisements that a peer might send because they are
> sourced from the virtual MAC address. I reported a bug to DPDK about it
> which has more details - https://bugs.dpdk.org/show_bug.cgi?id=648
> <https://protect2.fireeye.com/v1/url?k=7eb6f901-212dc042-7eb6b99a-861fcb972bfc-dfa86a12f9703310=1=a84fe3d4-3e6b-4dc3-be3e-b200c6641169=https%3A%2F%2Fbugs.dpdk.org%2Fshow_bug.cgi%3Fid%3D648>
> .
>
>
>
> Mechthild, you can check whether this is the issue you're experiencing by
> taking a packet trace on node 1 when both VRs are in the master state. If
> source pruning is causing the problem, you will not see any received
> advertisements from the peer in the trace because they will have been
> filtered by the hardware and never reach VPP. There is no supported way to
> disable source pruning when using the DPDK PMD, but if your packet trace
> indicates that this appears to be the issue I can give you a patch to try
> which should disable it. If not, please send the output from the packet
> trace anyway so I can try to diagnose what else might be going on.
>
>
>
> Thanks,
>
> -Matt
>
>
>
>
>
>
>
> On Fri, Jul 2, 2021 at 4:04 AM Neale Ranns  wrote:
>
>
>
> Hi Mechthild,
>
>
>
> Core VRRP issues I can’t help with, I no next to nothing about VRRP. I’ll
> hand over to those who do.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Mechthild
> Buescher via lists.fd.io
> <https://protect2.fireeye.com/v1/url?k=2c6b4627-73f07f64-2c6b06bc-861fcb972bfc-cf791770fb17ceed=1=a84fe3d4-3e6b-4dc3-be3e-b200c6641169=http%3A%2F%2Flists.fd.io%2F>
> 
> *Date: *Thursday, 1 July 2021 at 22:55
> *To: *vpp-dev@lists.fd.io 
> *Subject: *Re: [vpp-dev] VRRP issue when using interface in a table
>
> Hi Neale,
>
>
>
> I did some deeper investigations on the vrrp issue. What I observed is as
> follows:
>
>
>
> On one node1 the VRRP config is:
> set interface state Ext-0 up
>
> set interface ip address Ext-0 192.168.61.52/25
> <https://protect2.fireeye.com/v1/url?k=9226f0ca-cdbdc989-9226b051-861fcb972bfc-987c9fef2ec84c30=1=a84fe3d4-3e6b-4dc3-be3e-b200c6641169=http%3A%2F%2F192.168.61.52%2F25>
>
> vrrp vr add Ext-0 vr_id 61 priority 200 no_preempt accept_mode
> 192.168.61.5

Re: [vpp-dev] VRRP issue when using interface in a table

[Matthew Smith via lists.fd.io]

There could be an issue with the NIC:

vpp# show hardware-interfaces
>   NameIdx   Link  Hardware
> Ext-0  1 up   Ext-0
>   Link speed: 10 Gbps
>   Ethernet address e4:43:4b:ed:59:10
>   Intel X710/XL710 Family


With certain versions of firmware, these interfaces have a feature called
"source pruning" enabled by default. When a MAC address is added on a
X710/XL710 interface, packets which arrive with that address as their
source MAC address are filtered by the NIC. Since VRRP uses a virtual MAC
address as the source address of advertisements sent to peers, source
pruning causes problems for it. A VRRP VR entering the master state will
add the virtual MAC address to the NIC and henceforth the NIC will filter
any higher priority advertisements that a peer might send because they are
sourced from the virtual MAC address. I reported a bug to DPDK about it
which has more details - https://bugs.dpdk.org/show_bug.cgi?id=648.


Mechthild, you can check whether this is the issue you're experiencing by
taking a packet trace on node 1 when both VRs are in the master state. If
source pruning is causing the problem, you will not see any received
advertisements from the peer in the trace because they will have been
filtered by the hardware and never reach VPP. There is no supported way to
disable source pruning when using the DPDK PMD, but if your packet trace
indicates that this appears to be the issue I can give you a patch to try
which should disable it. If not, please send the output from the packet
trace anyway so I can try to diagnose what else might be going on.


Thanks,

-Matt




On Fri, Jul 2, 2021 at 4:04 AM Neale Ranns  wrote:

>
>
> Hi Mechthild,
>
>
>
> Core VRRP issues I can’t help with, I no next to nothing about VRRP. I’ll
> hand over to those who do.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Mechthild
> Buescher via lists.fd.io 
> *Date: *Thursday, 1 July 2021 at 22:55
> *To: *vpp-dev@lists.fd.io 
> *Subject: *Re: [vpp-dev] VRRP issue when using interface in a table
>
> Hi Neale,
>
>
>
> I did some deeper investigations on the vrrp issue. What I observed is as
> follows:
>
>
>
> On one node1 the VRRP config is:
> set interface state Ext-0 up
>
> set interface ip address Ext-0 192.168.61.52/25
>
> vrrp vr add Ext-0 vr_id 61 priority 200 no_preempt accept_mode
> 192.168.61.50
>
>
>
> On the other node2 the VRRP config is:
>
> set interface state Ext-0 up
>
> set interface ip address Ext-0 192.168.61.51/25
>
> vrrp vr add Ext-0 vr_id 61 priority 100 no_preempt accept_mode
> 192.168.61.50
>
>
>
> When I start vpp and vrrp (vppctl vrrp proto start Ext-0 vr_id 61) on both
> nodes, everything looks fine:
>
> The node1 is master and has VIP:
> vppctl show int addr
>
> Ext-0 (up):
>
>   L3 192.168.61.52/25
>
>   L3 192.168.61.50/25
>
>
>
> The node2 is backup:
>
> vppctl show int addr
>
> Ext-0 (up):
>
>   L3 192.168.61.51/25
>
>
>
> I can also swap the roles (master/backup) of the nodes by stopping and
> starting vrrp on the node1:
>
> vppctl vrrp proto stop Ext-0 vr_id 61
>
> vppctl vrrp proto start Ext-0 vr_id 61
>
>
>
> But if node1 (master) goes down because the interface is flapping,
> simulated with:
>
> vppctl set int state Ext-0 down; vppctl set int state Ext-0 up
>
>
>
> then node2 is getting master as expected but node1 is changing from state
> ‘Interface Down’ to ‘Backup’ and then to ‘Master’.
>
> Now both nodes are master and both have the VIP.
>
>
>
> Is this another bug in VRRP?
>
>
>
> Your help is really appreciated.
>
>
>
> Thanks, BR/Mechthild
>
>
>
>
>
> *From:* Mechthild Buescher
> *Sent:* Wednesday, 30 June 2021 17:40
> *To:* vpp-dev@lists.fd.io
> *Subject:* RE: VRRP issue when using interface in a table
>
>
>
> Hi Neale,
>
>
>
> Thanks for your reply. The bugfix partly solved the issue – VRRP goes into
> master/backup and keeps stable for a while. Unfortunately, it changes back
> to master/master after some time (15 minutes – 1 hour). We are currently
> trying to get more details and will come back to you.
>
> But thanks for your support so far,
>
>
>
> BR/Mechthild
>
>
>
> *From:* Neale Ranns 
> *Sent:* Thursday, 24 June 2021 12:33
> *To:* Mechthild Buescher ;
> vpp-dev@lists.fd.io
> *Subject:* Re: VRRP issue when using interface in a table
>
>
>
> Hi Mechthild,
>
>
>
> You’ll need to include:
>
>   https://gerrit.fd.io/r/c/vpp/+/32298
> 
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Mechthild
> Buescher via lists.fd.io 
> *Date: *Thursday, 24 June 2021 at 10:49
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] VRRP issue when using interface in a table
>
> Hi all,
>
>
>
> we are using VPP on two nodes where we would like to run VRRP. This works
> fine if the VRRP VR interface is in fib 0 but 

Re: [vpp-dev] heap sizes

[Matthew Smith via lists.fd.io]

On Thu, Jul 1, 2021 at 10:07 AM Damjan Marion  wrote:

>
>
> > On 01.07.2021., at 16:12, Matthew Smith  wrote:
> >
> >
> >
> > On Thu, Jul 1, 2021 at 6:36 AM Damjan Marion  wrote:
> >
> >
> > > On 01.07.2021., at 11:12, Benoit Ganne (bganne) via lists.fd.io
>  wrote:
> > >
> > >> Yes, allowing dynamic heap growth sounds like it could be better.
> > >> Alternatively... if memory allocations could fail and something more
> > >> graceful than VPP exiting could occur, that may also be better. E.g.
> if
> > >> I'm adding a route and try to allocate a counter for it and that
> fails, it
> > >> would be better to refuse to add the route than to exit and take the
> > >> network down.
> > >>
> > >> I realize that neither of those options is easy to do btw. I'm just
> trying
> > >> to figure out how to make it easier and more forgiving for users to
> set up
> > >> their configuration without making them learn about various memory
> > >> parameters.
> > >
> > > Understood, but setting a very high default will just make users of
> smaller config puzzled too  and I think changing all memory allocation
> callsites to check for NULL would be a big paradigm change in VPP.
> > > That's why I think a dynamically growing heap might be better but I do
> not really know what would be the complexity.
> > > That said, you can probably change the default in your own build and
> that should work.
> > >
> >
> > Fully agree wirth Benoit. We should not increase heap size default value.
> >
> > Things are actually a bit more complicated. For performance reasons
> people should use
> > hugepages whenever they are available, but they are also not default.
> > When hugepages are used all pages are immediately backed with physical
> memory.
> >
> > So different use cases require different heap configurations and end
> user needs to tune that.
> > Same applies for other things like stats segment page size which again
> may impact forwarding
> > performance significantly.
> >
> > If messing with startup.conf is too complicated for end user, some nice
> configuration script may be helpful.
> > Or just throwing few startup.confs into extras/startup_configs.
> >
> > Dynamic heap is possible, but not straight forward, as at some places we
> use offsets
> > to the start of the heap, so additional allocation cannot be anywhere.
> > Also it will not help in some cases, i.e. when 1G hugepage is used for
> heap, growing up to 2G
> > will fail if 2nd 1G page is not pre-allocated.
> >
> >
> > Sorry for not being clear. I was not advocating any change to defaults
> in VPP code in gerrit. I was trying to figure out the impact of changing
> the default value written in startup.conf by the management plane I work
> on. And also have a conversation on whether there are ways that it could be
> made easier to tune memory parameters correctly.
>
> ok, so let me try to answer your original questions:
>
> > It's my understanding that when you set the size of the main heap or the
> stat segment in startup.conf, the size you specify is used to set up
> virtual address space and the system does not actually allocate that full
> amount of memory to VPP. I think when VPP tries to read/write addresses
> within the address space, then memory is requested from the system to back
> the chunk of address space containing the address being accessed. Is my
> understanding correct(ish)?
>
> heap-size parameter defines size of memory mapping created for the heap.
> With the normal 4K pages mapping is not backed by physical memory. Instead,
> first time you try to access specific page CPU will generate page fault,
> and kernel will handle it by allocating 4k chunk of physical memory to back
> that specific virtual address and setup MMU mapping for that page.
>
> In VPP we don’t have reverse process, even if all memory allocations which
> use specific 4k page are freed, that 4K page will not be returned to
> kernel, as kernel simply doesn’t know that specific page is not in use
> anymore.
> Solution would be to somehow track number of memory allocations sharing
> single 4K page and call madvise() system call when last one is freed...
>
> If you are using hugepages, all virtual memory is immediately backed by
> physical memory so VPP with 32G of hugepage heap will use 32G of physical
> memory as long as VPP is running.
>
> If you do `show memory main-heap` you will actually see how many physical
> pages are allocated:
>
> vpp# show memory main-heap
> Threa

Re: [vpp-dev] heap sizes

[Matthew Smith via lists.fd.io]

On Thu, Jul 1, 2021 at 6:36 AM Damjan Marion  wrote:

>
>
> > On 01.07.2021., at 11:12, Benoit Ganne (bganne) via lists.fd.io  cisco@lists.fd.io> wrote:
> >
> >> Yes, allowing dynamic heap growth sounds like it could be better.
> >> Alternatively... if memory allocations could fail and something more
> >> graceful than VPP exiting could occur, that may also be better. E.g. if
> >> I'm adding a route and try to allocate a counter for it and that fails,
> it
> >> would be better to refuse to add the route than to exit and take the
> >> network down.
> >>
> >> I realize that neither of those options is easy to do btw. I'm just
> trying
> >> to figure out how to make it easier and more forgiving for users to set
> up
> >> their configuration without making them learn about various memory
> >> parameters.
> >
> > Understood, but setting a very high default will just make users of
> smaller config puzzled too  and I think changing all memory allocation
> callsites to check for NULL would be a big paradigm change in VPP.
> > That's why I think a dynamically growing heap might be better but I do
> not really know what would be the complexity.
> > That said, you can probably change the default in your own build and
> that should work.
> >
>
> Fully agree wirth Benoit. We should not increase heap size default value.
>
> Things are actually a bit more complicated. For performance reasons people
> should use
> hugepages whenever they are available, but they are also not default.
> When hugepages are used all pages are immediately backed with physical
> memory.
>
> So different use cases require different heap configurations and end user
> needs to tune that.
> Same applies for other things like stats segment page size which again may
> impact forwarding
> performance significantly.
>
> If messing with startup.conf is too complicated for end user, some nice
> configuration script may be helpful.
> Or just throwing few startup.confs into extras/startup_configs.
>
> Dynamic heap is possible, but not straight forward, as at some places we
> use offsets
> to the start of the heap, so additional allocation cannot be anywhere.
> Also it will not help in some cases, i.e. when 1G hugepage is used for
> heap, growing up to 2G
> will fail if 2nd 1G page is not pre-allocated.
>
>
Sorry for not being clear. I was not advocating any change to defaults in
VPP code in gerrit. I was trying to figure out the impact of changing the
default value written in startup.conf by the management plane I work on.
And also have a conversation on whether there are ways that it could be
made easier to tune memory parameters correctly.

-Matt

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

[Matthew Smith via lists.fd.io]

On Wed, Jun 30, 2021 at 3:01 AM Benoit Ganne (bganne) 
wrote:

> > What I'm trying to figure out is this: do I need to try and determine a
> > formula for the sizes that should be used for main heap and stat segment
> > based on X number of routes and Y number of worker threads? Or is there a
> > downside to just setting the main heap size to 32G (which seems like a
> > number that is unlikely to ever be exhausted sans memory leaks)?
>
> I do not think it would be a good idea:
>  - it depends upon overcommit configuration:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/vm/overcommit-accounting.rst
>  - under the default overcommit setting ("heuristic") this would prevent
> small configs to run VPP by default: think developer VMs or smaller cloud
> instances (eg. AWS C5n.large are 4GB) which are pretty common
>
> Maybe having an (optional) dyncamically growing heap could be a better
> option?
>
> ben
>

Hi Ben,

Ah, thanks for the pointer!

Yes, allowing dynamic heap growth sounds like it could be better.
Alternatively... if memory allocations could fail and something more
graceful than VPP exiting could occur, that may also be better. E.g. if I'm
adding a route and try to allocate a counter for it and that fails, it
would be better to refuse to add the route than to exit and take the
network down.

I realize that neither of those options is easy to do btw. I'm just trying
to figure out how to make it easier and more forgiving for users to set up
their configuration without making them learn about various memory
parameters.

Thanks,
-Matt

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

[Matthew Smith via lists.fd.io]

Hi Pim,

The defaults we use are 96M for stat segment and 1G for main heap (default
main heap size). I know these need to scale up as the numbers of routes
and/or threads increase. These values can accommodate a million routes or
so when running single threaded, but allocations on the stat segment
fail if 2 worker threads are enabled with 1M routes. Allocations on the
main heap fail if the number of routes gets too far above 1M.

What I'm trying to figure out is this: do I need to try and determine a
formula for the sizes that should be used for main heap and stat segment
based on X number of routes and Y number of worker threads? Or is there a
downside to just setting the main heap size to 32G (which seems like a
number that is unlikely to ever be exhausted sans memory leaks)?

-Matt


On Mon, Jun 28, 2021 at 5:20 PM Pim van Pelt  wrote:

> Hoi Matt,
>
> Out of curiosity how large is your heap and stats segment? I ask because
> running VPP with a large FIB I needed 2G heap size (and I used page size of
> 2M), and 96M of statsseg:
>
> memory {
>   main-heap-size 3G
>   main-heap-page-size 2M
> }
>
> statseg {
> socket-name /run/vpp/stats.sock
> size 96M
> per-node-counters off
> }
>
> On Mon, Jun 28, 2021 at 11:53 PM Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
>
>> Hi all,
>>
>> It's my understanding that when you set the size of the main heap or the
>> stat segment in startup.conf, the size you specify is used to set up
>> virtual address space and the system does not actually allocate that full
>> amount of memory to VPP. I think when VPP tries to read/write addresses
>> within the address space, then memory is requested from the system to back
>> the chunk of address space containing the address being accessed. Is my
>> understanding correct(ish)?
>>
>> When I add a large number of routes to the FIB (>1M), I have seen VPP
>> crash when the main heap or stats segment run out of space. I am wondering
>> if it makes sense to just set the heap sizes to some huge value that I am
>> confident will not be exceeded. If memory is not allocated unless it's
>> needed, it seems like that would be ok to do.
>>
>> Thanks,
>> -Matt
>>
>>
>>
>> 
>>
>>
>
> --
> Pim van Pelt 
> PBVP1-RIPE - http://www.ipng.nl/
>

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

[vpp-dev] heap sizes

[Matthew Smith via lists.fd.io]

Hi all,

It's my understanding that when you set the size of the main heap or the
stat segment in startup.conf, the size you specify is used to set up
virtual address space and the system does not actually allocate that full
amount of memory to VPP. I think when VPP tries to read/write addresses
within the address space, then memory is requested from the system to back
the chunk of address space containing the address being accessed. Is my
understanding correct(ish)?

When I add a large number of routes to the FIB (>1M), I have seen VPP crash
when the main heap or stats segment run out of space. I am wondering if it
makes sense to just set the heap sizes to some huge value that I am
confident will not be exceeded. If memory is not allocated unless it's
needed, it seems like that would be ok to do.

Thanks,
-Matt

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19643): https://lists.fd.io/g/vpp-dev/message/19643
Mute This Topic: https://lists.fd.io/mt/83856384/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] Proposed removal of Centos-8 jobs from master

[Matthew Smith via lists.fd.io]

Hi,

I mentioned at the community meeting that Netgate currently builds &
distributes VPP RPMs for CentOS 8 and I would need to confirm internally
whether disabling those jobs would cause any problems for us.

I confirmed that we do not have any issue with removing those CI jobs. We
generate our own RPMs and do not distribute the ones that are uploaded to
packagecloud. Since the Makefiles & spec files for building RPMs will be
left intact and we will still be able to generate RPMs on our own, we have
no objection to the CI jobs being disabled.

Thanks!
-Matt


On Mon, Jun 7, 2021 at 10:43 AM Damjan Marion via lists.fd.io  wrote:

>
>
> On 07.06.2021., at 17:24, Dave Wallace  wrote:
>
> Folks,
>
> The RPM builds have been unmaintained for a couple years now and the
> CentOS-8 jobs have become the long pole in the CI verification cycle as
> well as costing time to maintain the builds due to changes upstream.
>
> I am proposing that the vpp-*-master-centos-8-* jobs be removed from the
> CI until someone steps up to invest in removal of the technical debt that
> has accumulated in the RPM build infrastructure.
>
> If no one steps up to maintain the RPM build infrastructure, then I would
> also recommend that it be removed from the VPP build infrastructure as well.
>
> Damjan, can you please add this to the agenda for tomorrow's VPP Monthly
> Community meeting?
>
>
> Fully agree. Will add….
>
> —
> Damjan
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19538): https://lists.fd.io/g/vpp-dev/message/19538
Mute This Topic: https://lists.fd.io/mt/83372643/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] IPsec crash with async crypto

[Matthew Smith via lists.fd.io]

Hi  Fan,

Thanks for working on it!

I found a separate related issue which exacerbates the problem - async
crypto frames leak when using more than one worker thread. The ESP
encrypt/decrypt nodes allocate a frame for the crypto operation which needs
to be applied to a packet if there has not already been a frame allocated.
After allocating the frame, it may be decided that the packet should be
handed off to another thread or dropped for some other reason. When this
happens, if the frame never had any packets/operations added to it, it does
not get submitted and it is also not freed. The leak is what caused the
pool to need to be expanded in my test environment. I uploaded a patch to
gerrit to try and fix this - https://gerrit.fd.io/r/c/vpp/+/32596. If you
have any feedback on it, that would be appreciated.

-Matt


On Tue, Jun 8, 2021 at 7:14 AM Zhang, Roy Fan 
wrote:

> Hi Matthew and Florin,
>
>
>
> We managed to recreate the problem.
>
> The cause is most likely caused by pool got expanded while there are
> pending frame left to be dequeued. Once frame is dequeued later returning
> it to the pool will cause seg-fault as the pool is in new memory location.
>
>
>
> We are working on the fix – currently in validation stage. If everything
> is fine we are to upstream by tomorrow evening.
>
>
>
> Regards,
>
> Fan
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Matthew
> Smith via lists.fd.io
> *Sent:* Thursday, May 27, 2021 2:02 PM
> *To:* Florin Coras 
> *Cc:* vpp-dev 
> *Subject:* Re: [vpp-dev] IPsec crash with async crypto
>
>
>
> Hi Florin!
>
>
>
> It appears that the quic plugin is disabled in my build:
>
>
>
> 2021/05/27 07:44:49:044 notice plugin/loadPlugin disabled
> (default): quic_plugin.so
>
>
>
> I didn't mean to give the impression that I thought this issue was caused
> by quic. My mention of the quic commit was just intended to indicate how up
> to date my build is with the gerrit master branch in case there were
> recent/pending patches that people know of that might be relevant. That
> quic commit is from about 2 weeks ago, which is the last time I merged
> upstream changes.
>
>
>
> Thanks,
>
> -Matt
>
>
>
>
>
> On Wed, May 26, 2021 at 5:58 PM Florin Coras 
> wrote:
>
> Hi Matt,
>
> Did you try checking if quic plugin is loaded, just to see if there’s a
> connection there.
>
> Regards,
> Florin
>
> > On May 26, 2021, at 3:19 PM, Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
> >
> > Hi,
> >
> > I saw VPP crash several times during some tests that were running to
> evaluate IPsec performance. The last upstream commit on my build of VPP is
> 'fd77f8c00 quic: remove cmake --target'. The tests ran on a C3000 with an
> onboard QAT. The tests were repeated with the QAT removed from the device
> whitelist in startup.conf (using async crypto with sw_scheduler) and the
> same thing happened.
> >
> > The relevant part of the stack trace looks like this:
> >
> > #8  0x7fdbb4006459 in os_out_of_memory () at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/unix-misc.c:221
> > #9  0x7fdbb400d1fb in clib_mem_alloc_aligned_at_offset
> (size=2305843009213692256, align=8, align_offset=8,
> os_out_of_memory_on_failure=1) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/mem.h:243
> > #10 vec_resize_allocate_memory (v=0x7fdb36a9b7f0,
> length_increment=288230376151711515, data_bytes=2305843009213692256,
> header_bytes=8, data_align=8, numa_id=255) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/vec.c:111
> > #11 0x7fdbb60efe01 in _vec_resize_inline (v=0x7fdb36a9b7f0,
> length_increment=288230376151711515, data_bytes=2305843009213692248,
> header_bytes=0, data_align=8, numa_id=255) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/vec.h:170
> > #12 clib_bitmap_ori_notrim (ai=0x7fdb36a9b7f0, i=18446744073709537927)
> at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/bitmap.h:643
> > #13 vnet_crypto_async_free_frame (vm=0x7fdb356f7a80,
> frame=0x7fdb3461c280) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/crypto.h:585
> > #14 crypto_dequeue_frame (vm=0x7fdb356f7a80, node=0x7fdb36bbd280,
> ct=0x7fdb33537f80, hdl=0x7fdb2bc32810 , n_cache=1,
> n_total=0x7fdb145053dc) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/node.c:135
> > #15 crypto_dispatch_node_fn (vm=0x7fdb356f7a80, node=0x7fdb36bbd280,
> frame=0x0) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/node.c:166
> > #16 0x7fdbb4b78

Re: linux_nl_plugin routing issues [Was: Re: [vpp-dev] linux_nl_plugin causes VPP crash when importing a full IPv4 table]

[Matthew Smith via lists.fd.io]

Hi Mike,

The first problem you mentioned (packets matching a route are not sent when
the next hop has not been resolved at the time the route is added) is
likely fixed by this patch:

e2353a7f6 linux-cp: Add delegate to adjacencies

It was merged after fd77f8c00, so you would either need to cherry-pick it
or rebase onto that commit or some more recent one on master.

I have heard another report of the second issue you mentioned (changing
default netns does not work correctly) but I haven't gotten time to look at
it yet.

Thanks,
-Matt


On Thu, May 27, 2021 at 6:59 PM Mike Beattie  wrote:

> On Thu, May 27, 2021 at 11:36:02AM +0200, Pim van Pelt wrote:
> > Hoi Nate,
> >
> > further to what Andrew suggested, there are a few more hints I can offer:
> > 
> > Then you should be able to consume the IPv4 and IPv6 DFZ in your router.
> I
> > tested extensively with FRR and Bird2, and so far had good success.
>
> Pim, thank you for those hints - I plan to be implementing a new core
> routing infrastructure using VPP & FRR w/ linux-cp & linux-nl that will be
> consuming full tables in the near future. Your hints will be invaluable I
> susect.
>
> However, in my testing, I discovered an interesting behaviour with regards
> to routing. I have previously tried to reply with my findings to the list,
> but I wasn't subscribed at the time of Neale's posts, and I wanted to
> continue on his thread ... I composed a detailed report on the web
> interface
> of the list, then managed to completely miss the "CC list" checkbox. So I
> think Neale got it himself only. (Sorry Neale).
>
> I digress... what I discovered was that if a route entry is created before
> a
> neighbor entry with the next hop is established, no traffic flows:
>
>
> root@vpp-test:~# ip netns exec dataplane bash
> root@vpp-test:~# systemctl restart vpp.service
> root@vpp-test:~# vppctl set interface mtu 1500 GigabitEthernet0/13/0
> root@vpp-test:~# vppctl lcp create GigabitEthernet0/13/0 host-if vpp1
> netns dataplane
> root@vpp-test:~# ip l
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode
> DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> root@vpp-test:~# ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 15: vpp1:  mtu 1500 qdisc mq state DOWN group default
> qlen 1000
> link/ether 32:dc:fa:93:9e:fe brd ff:ff:ff:ff:ff:ff
> root@vpp-test:~# cat init50.sh
> #!/bin/sh
>
> ip link set up dev vpp1
>
> ip link add link vpp1 vpp1.50 type vlan id 50
> ip link set up dev vpp1.50
> ip addr add 10.xxx.yyy.202/24 dev vpp1.50
>
> root@vpp-test:~# ./init50.sh
> root@vpp-test:~# ping 1.1.1.1
> ping: connect: Network is unreachable
> root@vpp-test:~# ip route add default via 10.xxx.yyy.254
> root@vpp-test:~# ping 1.1.1.1
> PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
> ^C
> --- 1.1.1.1 ping statistics ---
> 5 packets transmitted, 0 received, 100% packet loss, time 4077ms
>
> root@vpp-test:~# ping 10.xxx.yyy.254
> PING 10.xxx.yyy.254 (10.xxx.yyy.254) 56(84) bytes of data.
> ^C
> --- 10.xxx.yyy.254 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3070ms
>
> root@vpp-test:~# ip route delete default
> root@vpp-test:~# ping 10.xxx.yyy.254
> PING 10.xxx.yyy.254 (10.xxx.yyy.254) 56(84) bytes of data.
> ^C
> --- 10.xxx.yyy.254 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3062ms
>
>
>
> No traffic passed... ping router before adding route:
>
>
>
> root@vpp-test:~# systemctl restart vpp.service
> root@vpp-test:~# ./init50.sh
> root@vpp-test:~# ping 10.xxx.yyy.254
> PING 10.xxx.yyy.254 (10.xxx.yyy.254) 56(84) bytes of data.
> 64 bytes from 10.xxx.yyy.254: icmp_seq=1 ttl=64 time=0.780 ms
> 64 bytes from 10.xxx.yyy.254: icmp_seq=2 ttl=64 time=0.306 ms
> 64 bytes from 10.xxx.yyy.254: icmp_seq=3 ttl=64 time=0.310 ms
> ^C
> --- 10.xxx.yyy.254 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2038ms
> rtt min/avg/max/mdev = 0.306/0.465/0.780/0.222 ms
> root@vpp-test:~# ip route add default via 10.xxx.yyy.254
> root@vpp-test:~# ping 1.1.1.1
> PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
> 64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=23.5 ms
> 64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=23.9 ms
> ^C
> --- 1.1.1.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1002ms
> rtt min/avg/max/mdev = 23.541/23.710/23.879/0.169 ms
> root@vpp-test:~#
>
>
> Traffic passes fine.
>
> This is a basic VPP installation built with
> https://gerrit.fd.io/r/c/vpp/+/31122 rebased onto master of a couple weeks
> ago (fd77f8c00). Ping plugin disabled, linux-cp and linux-nl enabled, with
> linux-cp config of:
>
> linux-cp {
> default netns dataplane
> 

Re: [vpp-dev] IPsec crash with async crypto

[Matthew Smith via lists.fd.io]

Hi Florin!

It appears that the quic plugin is disabled in my build:

2021/05/27 07:44:49:044 notice plugin/loadPlugin disabled
(default): quic_plugin.so

I didn't mean to give the impression that I thought this issue was caused
by quic. My mention of the quic commit was just intended to indicate how up
to date my build is with the gerrit master branch in case there were
recent/pending patches that people know of that might be relevant. That
quic commit is from about 2 weeks ago, which is the last time I merged
upstream changes.

Thanks,
-Matt


On Wed, May 26, 2021 at 5:58 PM Florin Coras  wrote:

> Hi Matt,
>
> Did you try checking if quic plugin is loaded, just to see if there’s a
> connection there.
>
> Regards,
> Florin
>
> > On May 26, 2021, at 3:19 PM, Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
> >
> > Hi,
> >
> > I saw VPP crash several times during some tests that were running to
> evaluate IPsec performance. The last upstream commit on my build of VPP is
> 'fd77f8c00 quic: remove cmake --target'. The tests ran on a C3000 with an
> onboard QAT. The tests were repeated with the QAT removed from the device
> whitelist in startup.conf (using async crypto with sw_scheduler) and the
> same thing happened.
> >
> > The relevant part of the stack trace looks like this:
> >
> > #8  0x7fdbb4006459 in os_out_of_memory () at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/unix-misc.c:221
> > #9  0x7fdbb400d1fb in clib_mem_alloc_aligned_at_offset
> (size=2305843009213692256, align=8, align_offset=8,
> os_out_of_memory_on_failure=1) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/mem.h:243
> > #10 vec_resize_allocate_memory (v=0x7fdb36a9b7f0,
> length_increment=288230376151711515, data_bytes=2305843009213692256,
> header_bytes=8, data_align=8, numa_id=255) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/vec.c:111
> > #11 0x7fdbb60efe01 in _vec_resize_inline (v=0x7fdb36a9b7f0,
> length_increment=288230376151711515, data_bytes=2305843009213692248,
> header_bytes=0, data_align=8, numa_id=255) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/vec.h:170
> > #12 clib_bitmap_ori_notrim (ai=0x7fdb36a9b7f0, i=18446744073709537927)
> at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/bitmap.h:643
> > #13 vnet_crypto_async_free_frame (vm=0x7fdb356f7a80,
> frame=0x7fdb3461c280) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/crypto.h:585
> > #14 crypto_dequeue_frame (vm=0x7fdb356f7a80, node=0x7fdb36bbd280,
> ct=0x7fdb33537f80, hdl=0x7fdb2bc32810 , n_cache=1,
> n_total=0x7fdb145053dc) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/node.c:135
> > #15 crypto_dispatch_node_fn (vm=0x7fdb356f7a80, node=0x7fdb36bbd280,
> frame=0x0) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/node.c:166
> > #16 0x7fdbb4b789e5 in dispatch_node (vm=0x7fdb356f7a80,
> node=0x7fdb36bbd280, type=VLIB_NODE_TYPE_INPUT,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0,
> last_time_stamp=207016971809128) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vlib/main.c:1024
> > #17 vlib_main_or_worker_loop (vm=0x7fdb356f7a80, is_main=0) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vlib/main.c:1618
> >
> > In vnet_crypto_async_free_frame() it appears that a call to pool_put()
> is trying to return a pointer to a pool that it is not a member of:
> >
> > (gdb) frame 13
> > #13 vnet_crypto_async_free_frame (vm=0x7fdb356f7a80,
> frame=0x7fdb3461c280) at
> /usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/crypto.h:585
> > 585  pool_put (ct->frame_pool, frame);
> > (gdb) p frame - ct->frame_pool
> > $1 = -13689
> >
> > It seems like maybe a pointer to a vnet_crypto_async_frame_t was stored
> by the crypto engine and before it could be dequeued the pool filled and
> had to be reallocated. The per-thread frame_pool's are allocated with room
> for 1024 entries initially and ct->frame_pool had a vector length of 1025
> when the crash occurred.
> >
> > Can anyone with knowledge of the async crypto code confirm or refute
> that theory? Anyone have suggestions on the best way to fix this?
> >
> > Thanks,
> > -Matt
> >
> >
> > 
> >
>
>

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

[vpp-dev] IPsec crash with async crypto

[Matthew Smith via lists.fd.io]

Hi,

I saw VPP crash several times during some tests that were running to
evaluate IPsec performance. The last upstream commit on my build of VPP is
'fd77f8c00 quic: remove cmake --target'. The tests ran on a C3000 with an
onboard QAT. The tests were repeated with the QAT removed from the device
whitelist in startup.conf (using async crypto with sw_scheduler) and the
same thing happened.

The relevant part of the stack trace looks like this:

#8  0x7fdbb4006459 in os_out_of_memory () at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/unix-misc.c:221
#9  0x7fdbb400d1fb in clib_mem_alloc_aligned_at_offset
(size=2305843009213692256, align=8, align_offset=8,
os_out_of_memory_on_failure=1) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/mem.h:243
#10 vec_resize_allocate_memory (v=0x7fdb36a9b7f0,
length_increment=288230376151711515, data_bytes=2305843009213692256,
header_bytes=8, data_align=8, numa_id=255) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/vec.c:111
#11 0x7fdbb60efe01 in _vec_resize_inline (v=0x7fdb36a9b7f0,
length_increment=288230376151711515, data_bytes=2305843009213692248,
header_bytes=0, data_align=8, numa_id=255) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/vec.h:170
#12 clib_bitmap_ori_notrim (ai=0x7fdb36a9b7f0, i=18446744073709537927) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vppinfra/bitmap.h:643
#13 vnet_crypto_async_free_frame (vm=0x7fdb356f7a80, frame=0x7fdb3461c280)
at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/crypto.h:585
#14 crypto_dequeue_frame (vm=0x7fdb356f7a80, node=0x7fdb36bbd280,
ct=0x7fdb33537f80, hdl=0x7fdb2bc32810 , n_cache=1,
n_total=0x7fdb145053dc) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/node.c:135
#15 crypto_dispatch_node_fn (vm=0x7fdb356f7a80, node=0x7fdb36bbd280,
frame=0x0) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/node.c:166
#16 0x7fdbb4b789e5 in dispatch_node (vm=0x7fdb356f7a80,
node=0x7fdb36bbd280, type=VLIB_NODE_TYPE_INPUT,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0,
last_time_stamp=207016971809128) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vlib/main.c:1024
#17 vlib_main_or_worker_loop (vm=0x7fdb356f7a80, is_main=0) at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vlib/main.c:1618

In vnet_crypto_async_free_frame() it appears that a call to pool_put() is
trying to return a pointer to a pool that it is not a member of:

(gdb) frame 13
#13 vnet_crypto_async_free_frame (vm=0x7fdb356f7a80, frame=0x7fdb3461c280)
at
/usr/src/debug/vpp-21.01-568~g67ff5da46.el8.x86_64/src/vnet/crypto/crypto.h:585
585  pool_put (ct->frame_pool, frame);
(gdb) p frame - ct->frame_pool
$1 = -13689

It seems like maybe a pointer to a vnet_crypto_async_frame_t was stored by
the crypto engine and before it could be dequeued the pool filled and had
to be reallocated. The per-thread frame_pool's are allocated with room for
1024 entries initially and ct->frame_pool had a vector length of 1025 when
the crash occurred.

Can anyone with knowledge of the async crypto code confirm or refute that
theory? Anyone have suggestions on the best way to fix this?

Thanks,
-Matt

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

Re: [vpp-dev] #plugin #vpp Linux-cp multicast issue

[Matthew Smith via lists.fd.io]

Hi Petr,

My earlier statement that multicast should work with no additional
configuration required was wrong. That's only true if you have the netlink
listener patch (https://gerrit.fd.io/r/c/vpp/+/31122) applied. I have that
applied to my local builds and I incorrectly thought it was part of the
linux-cp code that had already been merged to master. Sorry for the
confusion.

To punt multicast packets arriving on GigabitEthernet3/0/0 to the host, I
think you can run these commands:

vppctl ip mroute add 224.0.0.0/24 via local Forward
vppctl ip mroute add 224.0.0.0/24 via GigabitEthernet3/0/0 Accept

The explanation of the purpose of those commands that I received a while
back was "In mfib you need to specify both where the traffic can come from
(via an Accept path) so it passes the RPF check and where it's going to
(via a Forward path)".

-Matt


On Wed, May 26, 2021 at 1:40 PM Petr Boltík  wrote:

> Hi,
> thank you . answers are inline below.
>
> Predispositions
> The host is apu4d4 + Debian 10.9 + bird 1.66 (old, but in repo), clear
> install + VPP 21.06-rc1~0-ge82d59f38~b1 (10.10.50.1/24). The opposite
> side is MikroTik rb4011 (10.10.50.2/24). There is no disabled plugins,
> only enabled linux-cp.
>
> st 26. 5. 2021 v 19:08 odesílatel Matthew Smith 
> napsal:
>
>> Hi Petr,
>>
>> Responses are inline...
>>
>> On Wed, May 26, 2021 at 10:23 AM  wrote:
>>
>>> Hello,
>>>
>>> I'm sorry for the beginner question, but I was unable to find the
>>> answer. I tested the linux-cp feature in VPP 21.10-rc0. Nice job, but I
>>> cannot get to work ospf multicast, probably I'm doing something wrong, or
>>> should it work?
>>>
>>
>>
>> Multicast should work without any special configuration.
>>
>> What is the output of 'vppctl show ip mfib 224.0.0.0/24' after you apply
>> your linux-cp and interface configurations?
>>
>
> There is first interesting point. There is no mbib route for 224.0.0.0/24
>
> vpp# show ip mfib 224.0.0.0/24
> ipv4-VRF:0, fib_index:0 flags:none
> (*, 0.0.0.0/0):  flags:Drop,
>  fib:0 index:0 locks:1
>   src:Default Route flags:none locks:1:  flags:Drop,
> Extensions:
> Interface-Forwarding:
>   Interfaces:
>   multicast-ip4-chain
>   [@0]: dpo-drop ip4
>
>
>
>>
>>
>>>
>>> BGP communication works fine (tcp), OSPF NBMA works fine.
>>> Communication from host to physical interface already passes (224.0.0.5).
>>> Communication from the physical interface to the host did not pass
>>> (224.0.0.5).
>>>
>>>
>>
>> What did you observe while determining that inbound multicast was not
>> being passed to the host? Did you run a packet trace and confirm that the
>> packets are arriving on the VPP hardware interface? If so, can you please
>> send trace output for 1 or 2 of the inbound multicast packets? If not, you
>> can run a trace via a sequence of commands like:
>>
>> vppctl clear trace
>> vppctl trace filter include ip4-mfib-forward-lookup 100
>> vppctl trace add dpdk-input 100
>> sleep 10
>> vppctl show trace
>>
>
> Packets successfully arrived from physical interface  ip4-input report
> several problems:
> Step 1:
>
> Packet 3
> 00:11:11:019194: dpdk-input
>   GigabitEthernet3/0/0 rx queue 0
>   buffer 0x9c0c2: current data 0, length 82, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x2
>   ext-hdr-valid
>   l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 1, nb_segs 1, pkt_len 82
> buf_len 2176, data_len 82, ol_flags 0x180, data_off 128, phys_addr
> 0x72103100
> packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Offload Flags
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>   PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>   IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05
>   OSPF: 10.10.50.2 -> 224.0.0.5
> tos 0xc0, ttl 1, length 68, checksum 0x1214 dscp CS6 ecn NON_ECN
> fragment id 0x8a7c
> 00:11:11:019235: ethernet-input
>   frame: flags 0x3, hw-if-index 2, sw-if-index 2
>   IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05
> 00:11:11:019250: ip4-input-no-checksum
>   OSPF: 10.10.50.2 -> 224.0.0.5
> tos 0xc0, ttl 1, length 68, checksum 0x1214 dscp CS6 ecn NON_ECN
> fragment id 0x8a7c
> 00:11:11:019258: ip4-mfib-forward-lookup
>   fib 0 entry 0
> 00:11:11:019268: ip4-mfib-forwar

Re: [vpp-dev] #plugin #vpp Linux-cp multicast issue

[Matthew Smith via lists.fd.io]

Hi Petr,

Responses are inline...

On Wed, May 26, 2021 at 10:23 AM  wrote:

> Hello,
>
> I'm sorry for the beginner question, but I was unable to find the answer.
> I tested the linux-cp feature in VPP 21.10-rc0. Nice job, but I cannot get
> to work ospf multicast, probably I'm doing something wrong, or should it
> work?
>


Multicast should work without any special configuration.

What is the output of 'vppctl show ip mfib 224.0.0.0/24' after you apply
your linux-cp and interface configurations?


>
> BGP communication works fine (tcp), OSPF NBMA works fine.
> Communication from host to physical interface already passes (224.0.0.5).
> Communication from the physical interface to the host did not pass
> (224.0.0.5).
>
>

What did you observe while determining that inbound multicast was not being
passed to the host? Did you run a packet trace and confirm that the packets
are arriving on the VPP hardware interface? If so, can you please send
trace output for 1 or 2 of the inbound multicast packets? If not, you can
run a trace via a sequence of commands like:

vppctl clear trace
vppctl trace filter include ip4-mfib-forward-lookup 100
vppctl trace add dpdk-input 100
sleep 10
vppctl show trace

Several possible outcomes based on the trace output:

1. No multicast packets arrive on the hardware interface. That would
obviously be a problem with the external network rather than VPP or
linux-cp.
2. Multicast packets arrive on the hardware interface and the trace shows
them being dropped during some phase of processing. Hopefully there would
be some indication of why they are being dropped in the trace output or in
the output of 'vppctl show errors'.
3. Multicast packets arrive on the hardware interface and the trace shows
them being transmitted on the host tap interface. If that is the case, does
'tcpdump -i ge300' on the host show any packets arriving? Are you running
any kernel-based packet filter like iptables or nftables on the host?

Thanks,
-Matt


Is there any way how to configure multicast redirect? A have tried a lot of
> configurations (ip mroute, ) with no success.
> Many thanks for your answers. Regards Petr
>
> example configuration (enable linux-cp plugin)
> # vpp
> set int ip address GigabitEthernet3/0/0 10.10.50.1/24
> set int state GigabitEthernet3/0/0 up
> lcp create GigabitEthernet3/0/0 host-if ge300
> # linux host
> ip addr add 10.10.50.1/24 dev ge300
> ip link set dev ge300 mtu 1500
> ip link set dev ge300 up
>
>
>
>
> 
>
>

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

Re: [vpp-dev] plugin to filter packets

[Matthew Smith via lists.fd.io]

Hi Alex,

In order to drop some packets while passing all others on to the next node
in the feature arc, you can use vnet_feature_next(). It will find the index
of the next node on the feature arc and populate it into a pointer that you
pass in. The next_nodes in your node declaration (  .next_nodes = {
[CHECKER_NEXT_DROP] = "error-drop", } ) does not need to be altered at all
presuming that there is an enumeration declared with CHECKER_NEXT_DROP set
to 0 and CHECKER_N_NEXT set to 1.

In your loop that iterates the buffers in a frame, if next is a u16 * that
points into an array of next node indices and b is a vlib_buffer_t * that
points to the current buffer, you can call 'vnet_feature_next(next, b);'
early in your loop to set the next node on the feature arc as the default
next node. After that your code can examine the packet to figure out
whether it needs to be dropped. If it needs to be dropped, you can set
next[0] = CHECKER_NEXT_DROP.

-Matt


On Tue, May 18, 2021 at 3:15 PM Alex Syrnikov  wrote:

> Hello, VPP developers.
>
> I can't understand how to write plugin to filter some packets and
> passing others.
> I need to hook on some feature graph, check every packet and remove
> matched.
>
> I bound required IP for interface, hooked arc "ip4-local" (it can also
> be "ip4-unicast") with my node "checker" and do not understand how to
> write node function. My node function work if I enable plugin for
> interface.
>
> If I use node with next nodes as created by extras/emacs/make-plugin.sh
> VLIB_REGISTER_NODE (checker_node) =
> {
>// ...
>.n_next_nodes = CHECKER_N_NEXT,
>.next_nodes = {
>  [CHECKER_NEXT_DROP] = "error-drop",
>},
> };
>
> I do not understand how to pass buffer to further nodes on arc in node
> function
> - so all packets dropped because next[0] = 0;
>
> Also as I understand feature arc can have many features enabled and all
> packets
> will be processed by all nodes on arc, so I do not know which node on
> "ip4-local"
> or "ip4-unicast" arc will be after my node to pass buffer there. So I do
> not
> understand what to write in .next_nodes except "error-drop" to pass
> unfiltered
> packets to further processing.
>
> If I use .n_next_nodes = 0, all packets will pass to next node on
> feature arc,
> but how to drop matched buffers?
>
> The best solution I found is to use vlib_buffer_free() or code like this
>
>vlib_node_t* drop_node = vlib_get_node_by_name (vm, (u8 *)"error-drop");
>vlib_frame_t* f = vlib_get_frame_to_node (vm, drop_node->index );
>f->n_vectors = 1;
>u32* to_next = vlib_frame_vector_args( f );
>to_next[0] = buffer_index;
>
>vlib_put_frame_to_node( vm, drop_node->index, f );
>
> and remove matched buffer indexes from vlib_buffer_enqueue_to_next().
>
> (I know vlib_get_node_by_name() can be moved out of loop - this is not
> important.)
> But this solution will break batch processing architecture of vpp and I
> think
> there is better way (this looks like hack).
>
> As I understand I just need to assign some index to next[0] which is
> nexts for
>
> vlib_buffer_enqueue_to_next (vm, node, from, nexts, frame->n_vectors)
>
> but I do not understand how to get it.
>
> Please help to write node function which will drop matched packets and
> pass to
> next node on arc unmatched. What do I need to write in
>
> .next_nodes of VLIB_REGISTER_NODE
>
> and how to drop matched buffers and pass others to next nodes on feature
> arc in node function.
>
> Alex
>
>
> 
>
>

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

[Matthew Smith via lists.fd.io]

Hi Ole,

I just tested. Your patch fixes the problem. I can see gre_tunnel_add_del
and gre_tunnel_dump in a trace now.

Thanks!
-Matt


On Tue, May 18, 2021 at 4:55 AM  wrote:

> Hi Matt,
>
> Would you mind seeing if this solves the issue?
> https://gerrit.fd.io/r/c/vpp/+/32358
>
> Cheers,
> Ole
>
>
> > On 14 May 2021, at 22:04, Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
> >
> > Hi all,
> >
> > When I create a GRE tunnel using the API, and then try to look at an API
> trace to see exactly how it was added, the gre_tunnel_add_del message
> requesting the tunnel creation does not show up in the output. Neither do
> subsequent gre_tunnel_dump messages. The tunnels are successfully created
> and when I send a gre_tunnel_dump I receive a gre_tunnel_details, so I know
> the messages are being received and processed.
> >
> > I'm retrieving the trace by running:
> >
> > vppctl api trace save foo
> > vppctl api trace dump /tmp/foo
> >
> > The build I'm seeing this on is from a copy of master from wednesday.
> This is the last commit:
> > fd77f8c00 quic: remove cmake --target
> >
> > I poked around and tracked this down to api_global_main.api_trace_cfg
> having trace_enable set to 0 on the entries for the GRE messages:
> >
> > (gdb) p api_global_main.msg_names[1253]
> > $23 = 0x7f95985ed677 "gre_tunnel_add_del"
> > (gdb) p api_global_main.api_trace_cfg[1253]
> > $24 = {size = 0, trace_enable = 0, replay_enable = 0}
> >
> > (gdb) p api_global_main.msg_names[1255]
> > $27 = 0x7f95985ed6a3 "gre_tunnel_dump"
> > (gdb) p api_global_main.api_trace_cfg[1255]
> > $28 = {size = 0, trace_enable = 0, replay_enable = 0}
> >
> > Are the GRE messages intentionally excluded from being traced? Or is
> this an oversight?
> >
> > Thanks!
> > -Matt
> >
> >
> > 
> >
>
>

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

[vpp-dev] missing API trace output

[Matthew Smith via lists.fd.io]

Hi all,

When I create a GRE tunnel using the API, and then try to look at an API
trace to see exactly how it was added, the gre_tunnel_add_del message
requesting the tunnel creation does not show up in the output. Neither do
subsequent gre_tunnel_dump messages. The tunnels are successfully created
and when I send a gre_tunnel_dump I receive a gre_tunnel_details, so I know
the messages are being received and processed.

I'm retrieving the trace by running:

vppctl api trace save foo
vppctl api trace dump /tmp/foo

The build I'm seeing this on is from a copy of master from wednesday. This
is the last commit:
fd77f8c00 quic: remove cmake --target

I poked around and tracked this down to api_global_main.api_trace_cfg
having trace_enable set to 0 on the entries for the GRE messages:

(gdb) p api_global_main.msg_names[1253]
$23 = 0x7f95985ed677 "gre_tunnel_add_del"
(gdb) p api_global_main.api_trace_cfg[1253]
$24 = {size = 0, trace_enable = 0, replay_enable = 0}

(gdb) p api_global_main.msg_names[1255]
$27 = 0x7f95985ed6a3 "gre_tunnel_dump"
(gdb) p api_global_main.api_trace_cfg[1255]
$28 = {size = 0, trace_enable = 0, replay_enable = 0}

Are the GRE messages intentionally excluded from being traced? Or is this
an oversight?

Thanks!
-Matt

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19384): https://lists.fd.io/g/vpp-dev/message/19384
Mute This Topic: https://lists.fd.io/mt/82833140/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] punt drops packets with TTL 1

[Matthew Smith via lists.fd.io]

Hi Aloys,

Your patch has been merged.

-Matt


On Tue, May 11, 2021 at 10:00 AM Aloys Augustin (aloaugus) via lists.fd.io
 wrote:

> Hello,
>
> I recently ran into an issue where VPP would drop a packet immediately
> after going through the punt path if the incoming packet has a TTL of 1. I
> think it would make sense not to decrease the TTL when punting a packet.
>
> I made the following patch to fix it: https://gerrit.fd.io/r/c/vpp/+/31969
>
>
> Could I kindly ask a committer to review it?
>
> Thanks,
> Aloys
>
> 
>
>

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

[vpp-dev] vnet_rename_interface()

[Matthew Smith via lists.fd.io]

Hi all,

Source file src/vnet/interface.c has a function vnet_rename_interface(). It
only appears to be called by the lisp plugin currently. It would be handy
to be able to rename a DPDK interface without having to change startup.conf
and restart VPP. I am wondering if I could do that by adding a
sw_interface_rename API and calling vnet_rename_interface() in the handler
function. Before I spend much time working on that, I want to find out if
there are any known issues which would prevent that from working or if
anyone has any objections to doing it.

Thanks!
-Matt

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

[Matthew Smith via lists.fd.io]

+1

-Matt


On Wed, Mar 31, 2021 at 12:58 PM Damjan Marion via lists.fd.io  wrote:

>
> Dear VPP Committers,
>
> I would like to propose Roy Fan Zhang from Intel as a new VPP committer.
> Fan made significant contributions to the VPP including the async crypto
> infrastructure and crypto scheduler.
> Beside that I found that Fan is active in the community, and willing to
> help.
>
> Please let me know if you agree/neutral/disagree with +1/0/-1 (committers
> only please).
>
> My +1 is here.
>
> Thanks,
>
> Damjan
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19077): https://lists.fd.io/g/vpp-dev/message/19077
Mute This Topic: https://lists.fd.io/mt/81756505/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] question about reverting a change

[Matthew Smith via lists.fd.io]

On Mon, Feb 8, 2021 at 4:44 PM Matthew Smith via lists.fd.io  wrote:

> Hi all,
>
> I reviewed and submitted this change earlier today -
> https://gerrit.fd.io/r/c/vpp/+/31162. After it was merged, the jenkins
> job 'vpp-merge-master-ubuntu1804-x86_64' failed because two tests failed.
> The two failed tests seem related to the change so I created a new change
> to revert the earlier one - https://gerrit.fd.io/r/c/vpp/+/31178. The
> checkstyle job failed for the revert because the original patch removed
> some pre-existing '/* INDENT-(ON|OFF) */' so the revert adds them back in.
> It seems that checkstyle doesn't like that.
>
> My question is should I try to fix the checkstyle errors or just
> remove the -1 that jenkins set on the change and merge it as is? I don't
> know if doing the latter will cause checkstyle to continue complaining
> about INDENT-(ON|OFF) whenever someone submits a new change. It's somewhat
> easy to fix those errors, but then my "revert" would not be actually
> restoring the original code. Maybe that doesn't matter?
>
> Anyway, I'm trying to get the tests passing again while causing the least
> possible amount of pain and/or confusion to others. If anyone has a strong
> opinion on which option is better, I'd love to hear it.
>
> Thanks!
> -Matt
>
>
 I started to look into fixing the INDENT-(ON|OFF) that the checkstyle job
complained about with the reverted change (31178). When I ran checkstyle.sh
locally, it complained about many other formatting issues besides INDENT-ON
and INDENT-OFF. If I fixed them all, the "reverted" code would have looked
significantly different than the original code, which seems wrong. So I
just removed the jenkins -1 verify score and set it to +1 manually and
merged it.

-Matt

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

[vpp-dev] question about reverting a change

[Matthew Smith via lists.fd.io]

Hi all,

I reviewed and submitted this change earlier today -
https://gerrit.fd.io/r/c/vpp/+/31162. After it was merged, the jenkins job
'vpp-merge-master-ubuntu1804-x86_64' failed because two tests failed. The
two failed tests seem related to the change so I created a new change to
revert the earlier one - https://gerrit.fd.io/r/c/vpp/+/31178. The
checkstyle job failed for the revert because the original patch removed
some pre-existing '/* INDENT-(ON|OFF) */' so the revert adds them back in.
It seems that checkstyle doesn't like that.

My question is should I try to fix the checkstyle errors or just remove
the -1 that jenkins set on the change and merge it as is? I don't know if
doing the latter will cause checkstyle to continue complaining about
INDENT-(ON|OFF) whenever someone submits a new change. It's somewhat easy
to fix those errors, but then my "revert" would not be actually restoring
the original code. Maybe that doesn't matter?

Anyway, I'm trying to get the tests passing again while causing the least
possible amount of pain and/or confusion to others. If anyone has a strong
opinion on which option is better, I'd love to hear it.

Thanks!
-Matt

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

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

[Matthew Smith via lists.fd.io]

Hi Stanislav,

As you noted, vlib_buffer_validate_alloc_free() is the only place that
would change the "known state" of a buffer. All of the calls to that
function are in vlib/buffer_funcs.h in inline functions in conditional
blocks with a condition like 'if (CLIB_DEBUG > 0)'. One of those calls is
made when vlib_buffer_alloc() is called - it
calls vlib_buffer_alloc_on_numa() which calls vlib_buffer_alloc_from_pool()
which has several invocations of vlib_buffer_validate_alloc_free() which
all look like this:

  if (CLIB_DEBUG > 0)
vlib_buffer_validate_alloc_free (vm, buffers, n_buffers,
 VLIB_BUFFER_KNOWN_FREE);

Since these calls occur in inline functions and are only made when
CLIB_DEBUG is defined as a value greater than 0, it seems like the issue is
probably that VPP and the router plugin are being built with CLIB_DEBUG
defined to different values - one of them is being built with CLIB_DEBUG ==
0 and one of them is built with CLIB_DEBUG > 0. Since your backtrace
shows vlib_buffer_validate_alloc_free() being called from one of the VPP
virtio nodes, that suggests that VPP was built with CLIB_DEBUG > 0. You are
probably building the router plugin without explicitly defining a value for
CLIB_DEBUG so it is ending up defined to 0. To remedy the issue, you could
either build VPP with CLIB_DEBUG set to 0 (run 'make build-release' instead
of 'make build') or explicitly define CLIB_DEBUG when you build the router
plugin.

-Matt


On Sat, Jan 16, 2021 at 5:50 AM Stanislav Zaikin  wrote:

> I've dug more into this issue. And I noticed strange thing:
>
> 187   {
> (gdb) next
> 188 tap_inject_main_t * im = tap_inject_get_main ();
> (gdb)
> 190 u32 bi = ~0;
> (gdb)
> 194 sw_if_index = tap_inject_lookup_sw_if_index_from_tap_fd (fd);
> (gdb)
> 195 if (sw_if_index == ~0)
> (gdb)
> 199 if( vlib_buffer_alloc (vm, , 1) != 1 )
> (gdb)
> 202 b = vlib_get_buffer (vm, bi);
> (gdb)
> 207 n_bytes = read (fd, b->data, vlib_buffer_get_default_data_size (vm));
> (gdb)
> 208 if (n_bytes < 0)
> (gdb) print b
> $31 = (vlib_buffer_t *) 0x10027db5c0
> (gdb) print *b
> $32 = {{cacheline0 = 0x10027db5c0 "", current_data = 0, current_length = 0, 
> flags = 0, flow_id = 0, ref_count = 1 '\001', buffer_pool_index = 0 '\000', 
> error = 0, next_buffer = 0, {current_config_index = 0,
>   punt_reason = 0}, opaque = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, template_end 
> = 0x10027db600 "", second_half = 0x10027db600 "", trace_handle = 0, 
> total_length_not_including_first_buffer = 0, opaque2 = {
>   0 }, headroom = 0x10027db640 "", pre_data = '\000' 
> , "\001", data = 0x10027db6c0 "33"}}
> (gdb) print bi
> $33 = 653015
> (gdb) call vlib_buffer_is_known (vm, bi)
> $34 = VLIB_BUFFER_KNOWN_FREE
>
> For some reason the allocated buffer was marked as free. The only function 
> that could change its state is vlib_buffer_validate_alloc_free.
>
> always_inline __clib_warn_unused_result u32
> vlib_buffer_alloc_from_pool (vlib_main_t * vm, u32 * buffers, u32
> n_buffers,
> u8 buffer_pool_index)
> {
> /* omit */
> if (CLIB_DEBUG > 0)
> vlib_buffer_validate_alloc_free (vm, buffers, n_buffers,
> VLIB_BUFFER_KNOWN_FREE);
> return n_buffers;
>
> But there's another strange issue. I've tried to debug it with gdb and
> sometimes vlib_buffer_validate_alloc_free isn't calling for some reason:
>
> Thread 1 "vpp_main" hit Breakpoint 1, vlib_buffer_alloc_from_pool 
> (buffer_pool_index=0 '\000', n_buffers=1, buffers=0x7fffafc727e0, 
> vm=0x76d67bc0 )
> at /usr/include/vlib/buffer_funcs.h:569
> 569 vlib_buffer_main_t *bm = vm->buffer_main;
> (gdb) next
> 585 bp = vec_elt_at_index (bm->buffer_pools, buffer_pool_index);
> (gdb)
> 586 bpt = vec_elt_at_index (bp->threads, vm->thread_index);
> (gdb)
> 588 dst = buffers;
> (gdb)
> 589 n_left = n_buffers;
> (gdb)
> 590 len = bpt->n_cached;
> (gdb)
> 593 if (len >= n_buffers)
> (gdb)
> 595 src = bpt->cached_buffers + len - n_buffers;
> (gdb)
> 596 vlib_buffer_copy_indices (dst, src, n_buffers);
> (gdb)
> 597 bpt->n_cached -= n_buffers;
> (gdb)
> 602 return n_buffers;
> (gdb) nextvlib_buffer_alloc_on_numa (numa_node=0, n_buffers=1, 
> buffers=0x7fffafc727e0, vm=0x76d67bc0 ) at 
> /usr/include/vlib/buffer_funcs.h:664
> 664 return vlib_buffer_alloc_from_pool (vm, buffers, n_buffers, index);
> (gdb) cont
> Continuing.
> [New Thread 0x7fffacc9b700 (LWP 127836)]
> [Thread 0x7fffacc9b700 (LWP 127836) exited]
>
> Thread 1 "vpp_main" hit Breakpoint 1, vlib_buffer_alloc_from_pool 
> (vm=0x76d67bc0 , buffers=0x7fffb74e4dfc, n_buffers=64, 
> buffer_pool_index=0 '\000')
> at /home/zstas/vpp/src/vlib/buffer_funcs.h:569
> 569 vlib_buffer_main_t *bm = vm->buffer_main;
> (gdb) next
> 585 bp = vec_elt_at_index (bm->buffer_pools, buffer_pool_index);
> (gdb)
> 586 bpt = vec_elt_at_index (bp->threads, vm->thread_index);
> (gdb)
> 588 dst = buffers;
> (gdb)
> 589 

[vpp-dev] question about crypto_sw_scheduler plugin

[Matthew Smith via lists.fd.io]

Hello,

I am looking into enabling VPP's asynchronous crypto for IPsec in Netgate's
control plane. I was looking at the crypto_sw_scheduler plugin and noticed
that crypto_sw_scheduler_dequeue_aead()
and crypto_sw_scheduler_dequeue_link() each have a loop like this:

  vec_foreach_index (i, cm->per_thread_data)
  {
ptd = cm->per_thread_data + i;
q = ptd->queues[async_op_id];
f = crypto_sw_scheduler_get_pending_frame (q);
if (f)
  break;
  }

It looks like this loop will iterate the per-thread data of each thread
sequentially starting at thread 0 and try to retrieve a pending frame from
that thread's queue and break the loop if one is retrieved. Will this end
up causing the operations which were queued by the threads with lower
indices to be handled more quickly than operations which were queued by the
threads with higher indices?

E.g. - assume 4 worker threads. The main thread has ID 0 and the workers
have IDs 1 - 4. If thread 1 has 5 frames queued for some crypto operation
and thread 4 has 1 frame queued for the same operation, will all 5 frames
from thread 1 be handled before the 1 frame from thread 4 is? Or am I
misunderstanding something?

Thanks!
-Matt

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18413): https://lists.fd.io/g/vpp-dev/message/18413
Mute This Topic: https://lists.fd.io/mt/79156990/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] Latest master, dpdk and mlx5 failing

[Matthew Smith via lists.fd.io]

On Fri, Oct 2, 2020 at 12:52 PM Christian Hopps  wrote:

> I just noticed this error I'm getting
>
> net_mlx4: cannot load glue library:
> /home/chopps/w/vpp/build-root/install-vpp-native/external/lib/dpdk/pmds-20.0.3-glue/librte_pmd_mlx4_glue.so.18.02.0:
> cannot open shared object file: No such file or directory
> net_mlx4: cannot initialize PMD due to missing run-time dependency on
> rdma-core libraries (libibverbs, libmlx4)
> common_mlx5: Cannot load glue library:
> /home/chopps/w/vpp/build-root/install-vpp-native/external/lib/dpdk/pmds-20.0.3-glue/librte_pmd_mlx5_glue.so.20.02.0:
> cannot open shared object file: No such file or directory
> common_mlx5: Cannot initialize MLX5 common due to missing run-time
> dependency on rdma-core libraries (libibverbs, libmlx5)
>
> And:
>
> (default) [17:50:17 ...]$ find ../build-root/*-vpp-native/external -name
> '*glue*'
>
> ../build-root/build-vpp-native/external/src-dpdk/drivers/common/mlx5/linux/mlx5_glue.c
>
> ../build-root/build-vpp-native/external/src-dpdk/drivers/common/mlx5/linux/mlx5_glue.h
>
> ../build-root/build-vpp-native/external/src-dpdk/drivers/net/mlx4/mlx4_glue.c
>
> ../build-root/build-vpp-native/external/src-dpdk/drivers/net/mlx4/mlx4_glue.h
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/common/mlx5/linux/librte_pmd_mlx5_glue.so
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/common/mlx5/linux/b7c1ada@
> @rte_pmd_mlx5_glue@sha
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/common/mlx5/linux/b7c1ada@
> @rte_pmd_mlx5_glue@sha/mlx5_glue.c.o
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/common/mlx5/linux/librte_pmd_mlx5_glue.so.20.02.0
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/net/mlx4/librte_pmd_mlx4_glue.so
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/net/mlx4/8672f8e@
> @rte_pmd_mlx4_glue@sha
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/net/mlx4/8672f8e@
> @rte_pmd_mlx4_glue@sha/mlx4_glue.c.o
>
> ../build-root/build-vpp-native/external/build-dpdk/drivers/net/mlx4/librte_pmd_mlx4_glue.so.18.02.0
> ../build-root/install-vpp-native/external/lib/dpdk/pmds-20.0.3-glue
> (default) [17:50:24 ...]
>
> So it looks like the glue is being built but not installed?
>
> Thanks,
> Chris.
>
>
Yeah, it seems so. Either build configurations need to be updated to
install the glue libraries or you might be able to change
ibverbs_link=dlopen to ibverbs_link=static.

-Matt




>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17636): https://lists.fd.io/g/vpp-dev/message/17636
Mute This Topic: https://lists.fd.io/mt/77247865/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] Latest master, dpdk and mlx5 failing

[Matthew Smith via lists.fd.io]

Hi Mohammed,

I think it will only affect builds where DPDK_MLX5_PMD=y is set, but I
cannot say for sure. The scripts/configurations I build with always set
that flag, so I have not tried to generate a build without it set recently.

-Matt


On Fri, Oct 2, 2020 at 12:57 AM Mohammed HAWARI 
wrote:

> Hello Chris, Matthew,
>
> Thanks for raising that issue. Just to be clear and better understand,
> does the problem occur with the default config, i.e., without trying to
> compile any MLX driver in DPDK? Or does it only appear when setting 
> DPDK_MLX5_PMD=y
> ?
> Thanks
> Best regards
> Mohammed
>
> On 1 Oct 2020, at 22:33, Matthew Smith via lists.fd.io <
> mgsmith=netgate@lists.fd.io> wrote:
>
> Hi Chris,
>
> I did this in my local build:
>
> diff --git a/build/external/packages/dpdk.mk b/build/external/packages/
> dpdk.mk
> index 49761cd56..a30ffd2ac 100644
> --- a/build/external/packages/dpdk.mk
> +++ b/build/external/packages/dpdk.mk
> @@ -139,6 +139,7 @@ DPDK_MESON_ARGS = \
> -Dtests=false \
> "-Ddisable_drivers=$(DPDK_DRIVERS_DISABLED)" \
> "-Ddisable_libs=$(DPDK_LIBS_DISABLED)" \
> +   -Dibverbs_link=dlopen \
> -Db_pie=true \
> -Dmachine=$(DPDK_MACHINE) \
> --buildtype=$(DPDK_BUILD_TYPE)
>
> If I try to submit it upstream, I would probably do something nicer using
> a DPDK_ environment variable, but for the moment this got me
> past that error. I have not actually tested with an mlx5 device yet, so I
> don't know if something additional will be required in order to forward
> packets via an mlx5 NIC, but it did fix the error you pasted and
> allow dpdk_plugin.so to be loaded.
>
> -Matt
>
>
> On Thu, Oct 1, 2020 at 2:10 PM Christian Hopps  wrote:
>
>> I've rebased my local branch on the latest master and dpdk is failing to
>> load now b/c
>>
>> 2020/10/01 18:31:54:514 errplugin/load
>> /home/chopps/w/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins/dpdk_plugin.so:
>> undefined symbol: ibv_fork_init
>>
>> I noticed that the dpdk build system has been changed is there something
>> I need to do to get it to link properly with the required libraries now?
>>
>> I did change "n" in
>>
>>   DPDK_MLX5_PMD?= n
>>   DPDK_MLX5_COMMON_PMD ?= n
>>
>> to "y" to try and get MLX5 PMD to build.
>>
>> I also added
>>
>>   vpp_uses_dpdk_mlx5_pmd = yes
>>
>> to build-data/platforms/vpp.mk
>>
>> I also tried adding:
>>
>>   vpp_uses_dpdk_ibverbs_link_dlopen = yes
>>
>> which didn't fix the problem.
>>
>> Any suggestions on how to fix this?
>>
>> Thanks,
>> Chris.
>>
>>
>>
>>
> 
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17629): https://lists.fd.io/g/vpp-dev/message/17629
Mute This Topic: https://lists.fd.io/mt/77247865/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] Latest master, dpdk and mlx5 failing

[Matthew Smith via lists.fd.io]

Hi Chris,

I did this in my local build:

diff --git a/build/external/packages/dpdk.mk b/build/external/packages/
dpdk.mk
index 49761cd56..a30ffd2ac 100644
--- a/build/external/packages/dpdk.mk
+++ b/build/external/packages/dpdk.mk
@@ -139,6 +139,7 @@ DPDK_MESON_ARGS = \
-Dtests=false \
"-Ddisable_drivers=$(DPDK_DRIVERS_DISABLED)" \
"-Ddisable_libs=$(DPDK_LIBS_DISABLED)" \
+   -Dibverbs_link=dlopen \
-Db_pie=true \
-Dmachine=$(DPDK_MACHINE) \
--buildtype=$(DPDK_BUILD_TYPE)

If I try to submit it upstream, I would probably do something nicer using a
DPDK_ environment variable, but for the moment this got me past
that error. I have not actually tested with an mlx5 device yet, so I don't
know if something additional will be required in order to forward packets
via an mlx5 NIC, but it did fix the error you pasted and
allow dpdk_plugin.so to be loaded.

-Matt


On Thu, Oct 1, 2020 at 2:10 PM Christian Hopps  wrote:

> I've rebased my local branch on the latest master and dpdk is failing to
> load now b/c
>
> 2020/10/01 18:31:54:514 errplugin/load
> /home/chopps/w/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins/dpdk_plugin.so:
> undefined symbol: ibv_fork_init
>
> I noticed that the dpdk build system has been changed is there something I
> need to do to get it to link properly with the required libraries now?
>
> I did change "n" in
>
>   DPDK_MLX5_PMD?= n
>   DPDK_MLX5_COMMON_PMD ?= n
>
> to "y" to try and get MLX5 PMD to build.
>
> I also added
>
>   vpp_uses_dpdk_mlx5_pmd = yes
>
> to build-data/platforms/vpp.mk
>
> I also tried adding:
>
>   vpp_uses_dpdk_ibverbs_link_dlopen = yes
>
> which didn't fix the problem.
>
> Any suggestions on how to fix this?
>
> Thanks,
> Chris.
>
> 
>
>

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

[Matthew Smith via lists.fd.io]

+1


On Fri, Sep 25, 2020 at 2:14 PM Dave Barach via lists.fd.io  wrote:

> Folks,
>
>
>
> The self-nomination period closed yesterday. We had one self-nomination,
> from Damjan Marion. At this point, we can proceed with a vote.
>
>
>
> I’m sure that Damjan will do a great job, so let me start:
>
>
>
> Damjan Marion as VPP PTL: +1
>
>
>
> Please vote +1, 0, -1. For once, the “reply-all” button is everyone’s
> friend.
>
>
>
> Thanks... Dave
>
>
>
> -Original Message-
> From: d...@barachs.net 
> Sent: Thursday, September 17, 2020 10:32 AM
> To: 'vpp-dev@lists.fd.io' ; 't...@lists.fd.io' <
> t...@lists.fd.io>
> Subject: Happy Trails to Me...
>
>
>
> Folks,
>
>
>
> I’m departing the employment rolls towards the end of next month. Although
> I intend to remain active in the fd.io vpp community as a coder,
> committer, and resident greybeard, it’s time for the community to pick a
> new PTL.
>
>
>
> According to the project governance document,
> https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf:
>
>
>
>
> 3.2.3.1 Project Technical Leader Candidates Candidates for the project’s
> PTL will be derived from the Committers of the Project. Candidates must
> self-nominate.
>
>
>
> I'd like to invite any interested vpp project committer to self-nominate
> for the PTL role. Please email vpp-dev@lists.fd.io.
>
>
>
> Let's close the self-nomination period in one week: more specifically, by
> 5pm EDT on Thursday, September 24, 2020; committer vote to follow
> thereafter.
>
>
>
> I'll be glad to answer unicast questions about the PTL role from eligible
> committers.
>
>
>
> Thanks... Dave
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>
>

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

Re: [vpp-dev] How to include my custom plugin in the rpm packages.

[Matthew Smith via lists.fd.io]

Hi Himanshu,

When I created a plugin, I started by running extras/emacs/make-plugin.sh.
That script automatically set things up so the plugin could be built and
installed with the other VPP plugins. Then I started adding actual code to
the stubbed-out files which the script created. I tested that script again
just now and the stub plugin that is created by that script seems to have
been built successfully and it was included in the vpp-plugins RPM that was
built when I ran 'make pkg-rpm'. I did the following while in a directory
containing a VPP repo which was freshly cloned from gerrit:

sudo dnf install emacs
cd src/plugins
../../extras/emacs/make-plugin.sh
I was asked for a name of the plugin and whether it was dual loop, I typed
'foobar' for the name and chose dual loop. The script ran for a second and
there were files under src/plugins/foobar when it completed.
git add foobar
git commit
cd ../..
make pkg-rpm

After waiting a while for the build to complete:

$ rpm -qlp build-root/vpp-plugins-21.01-rc0~84_gf79b34036.x86_64.rpm | grep
foobar
/usr/lib/vpp_api_test_plugins/foobar_test_plugin.so
/usr/lib/vpp_plugins/foobar_plugin.so
/usr/share/vpp/api/foobar.api.json

It should be noted that this didn't work on my first attempt because I did
not commit the files under src/plugins/foobar. The pkg-rpm target builds
a tar archive of source files using 'git archive'. If you had files for the
plugin which are on your local filesystem and the files have not been
committed in the local repo, they won't be built.

Even if you don't feel like using that script, you shouldn't need to do
anything special. The RPM spec file at extras/rpm/vpp.spec has this:

%files plugins
%defattr(-,bin,bin)
/usr/lib/vpp_plugins/*
/usr/lib/vpp_api_test_plugins/*
/usr/share/vpp/api/*

If your plugin files are being installed under /usr/lib/vpp_plugins,
/usr/lib/vpp_api_test_plugins, and /usr/share/vpp/api, the above ought to
cause it to be included in vpp-plugins automatically. In src/plugins/, is there a CMakeLists.txt with an add_vpp_plugin() in it?

-Matt



On Fri, Mar 13, 2020 at 11:42 PM Himanshu Rakshit  wrote:

> Hi All,
>
> We have developed a custom plugin (under the folder *src/plugin*). We are
> able to compile it successfully and also able to run in the local setup
> using *make run* or *make debug* command.
>
> Our intention is not run in a different system(different for the build
> system). So we make the rpm package using the *make pkg-rpm *command and
> install the rpms in the remote system. But the custom plugin is not a part
> of the rpm packages and not installed in the system.
>
> Need your help on this.
>
> What is best possible way to install the custom plugin in a remote
> system(different form the build system.)
>
> I followed the following steps
>
> *make install-dep*
> *make build*
> *make pkg-rpm*
>
> *rpm -ivh *
>
> Thanks,
> Himanshu
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17485): https://lists.fd.io/g/vpp-dev/message/17485
Mute This Topic: https://lists.fd.io/mt/71944155/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] Question about acl match/permit behavior.

[Matthew Smith via lists.fd.io]

On Tue, Sep 22, 2020 at 12:21 PM Andrew Yourtchenko 
wrote:

> I suggest making a unit test that captures this behavior and fails, then
> we can look at what is the best way of fixing it and incorporate into the
> CI...
>
> I remember this type of scenario being addressed once, not sure if it was
> the same one or not...
>
> But you could probably work around it by having the ACLs on the inner
> interface.
>
> --a
>
>
Hi Andrew,

In general, for NAT and stateful ACL to coexist, the NAT and ACL nodes must
be ordered in the opposite order for in2out vs out2in packets. E.g. if you
the NAT ran first followed by a stateful output ACL for outbound packets,
then inbound packets must use the reverse ordering - input ACL followed by
NAT. I ran into the same problem Venkat is having a while back due to the
order of the NAT & ACL features nodes being the same in both directions. I
did fix it and added a unit test, but I think I only fixed it for endpoint
dependent mode. The endpoint independent in2out nodes look like some of
them are running after the ACL plugin output node:

VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
  .arc_name = "ip4-output",
  .node_name = "nat44-in2out-output",
  .runs_after = VNET_FEATURES
("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
};
VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
  .arc_name = "ip4-output",
  .node_name = "nat44-in2out-output-worker-handoff",
  .runs_after = VNET_FEATURES
("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
};
VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
  .arc_name = "ip4-output",
  .node_name = "nat44-hairpin-src",
  .runs_after = VNET_FEATURES
("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
};

I'm not positive about the "hairpin" node, but I think it ought to work if
the code above is changed to look like this:

VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
  .arc_name = "ip4-output",
  .node_name = "nat44-in2out-output",
  .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
  .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
};
VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
  .arc_name = "ip4-output",
  .node_name = "nat44-in2out-output-worker-handoff",
  .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
  .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
};
VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
  .arc_name = "ip4-output",
  .node_name = "nat44-hairpin-src",
  .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
  .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
};

Venkat, are you using any of the nodes listed above (i.e. are you using the
output-feature variant of the in2out node in endpoint independent mode)? If
so, I suggest applying the change I described and building from that code
and test whether it solves your problem.

-Matt




> On 22 Sep 2020, at 18:58, Venkat  wrote:
>
> 
> Thank you Andrew for the pointers and setting the expectations for VPP
> ACL.
>
> On another topic, since the stateful behavior of ACL is per interface, I
> setup permit+reflect output ACL on WAN interface ( Internet-facing Public
> IP) for internet bound traffic. And I also have to Deny all incoming
> traffic (input ACL on WAN interface) for security purposes. In addition, I
> have SNAT configured on the same interface so that packets get source NATed
> when going to the internet.
>
> Now the problem is since the ACL node comes before the SNAT node in the
> feature ARC, stateful ACL sessions are built for the original Source/Dest
> IP pair prior to SNAT.
> Return traffic coming into the WAN interface comes with WAN IP (public
> IP), gets dropped because of Deny all input ACL and the purpose of stateful
> ACL is lost.
> How is this scenario typically addressed?
>
> thanks
> Venkat
>
>
>
> On Thu, Sep 17, 2020 at 3:19 PM Andrew  Yourtchenko 
> wrote:
>
>>
>>
>> On 17 Sep 2020, at 23:55, Venkat  wrote:
>>
>> 
>>
>> 2. What happens when ACL config is modified while traffic is flowing?
>> Would the packets continue to hit the special-case "-1" session until the
>> session is timed out and re-claimed? If that's true, then packets would
>> continue to sneak through even when a user modifies the ACL from
>> Permit+Reflect to Deny.
>>
>>
>> Yep. You can look at the code, there is a debug CLI tweak to reclassify
>> sessions, but I am not sure anyone actually uses it.
>>
>> There is no “always right” answer to this ~20 year old question.
>>
>> ACL plugin is very explicitly not a “fancy firewall”.
>>
>> [VD]: One more question on this behavior. If packets continue to hit
>> the special-case "-1" session, would they ever hit the modified ACL? Or
>> does the reclassify sessions logic kick in periodically (every timeout
>> independent of traffic hit) and cleans up the special-case "-1" sessions so
>> that new sessions build up again based on the current state of ACLs rule? I
>> would assume, 

Re: [vpp-dev] VRRP issue

[Matthew Smith via lists.fd.io]

Hi Naveen,

The trace file appears to show two VRRP advertisements which were received.
There does not seem to be any indication that those packets ever reached
the vrrp4-input node. For both packets the trace shows this at the end:

00:21:49:755122: error-drop
  rx:loop0
00:21:49:755122: drop
  ip4-local: ip4 source lookup miss

The error counter for ip4 source lookup miss also appears to be increasing
in the output of 'show err'.

Does the backup have an IP address in the same subnet with 10.4.4.3
configured on loop0? Your original diagram showed addresses in that subnet
configured on the loop0 interface on both VRs, but you mentioned that the
configuration has changed.

It is pretty hard for me to guess what's happening here without having the
full configuration available. Can you give me a full set of commands I
could run in vppctl to exactly replicate the configuration of both VRs? I
don't just mean the settings related to VRRP, but all interface
configuration, bridge domain, etc

Thanks,
-Matt


On Fri, Aug 14, 2020 at 8:10 PM Naveen Joy (najoy)  wrote:

> Hi Matthew,
>
>
>
> Thanks!  I have attached packet captures to this email. I have captured a
> few more packets as the uplink was quite chatty.
>
> The VRRP speakers are on Vlan 110.
>
> The second file has the untruncated show err output run a few times.
>
> Also, apologies for not clarifying the IP address change. During
> troubleshooting, I had switched the backup and master VRs – still seeing
> the same behavior.
>
> The IP address of the master i.e. 10.4.4.3 shown below is correct
> (Attached: updated diagram).
>
>
>
> Regards,
>
> Naveen
>
>
>
> *From: * on behalf of "Matthew Smith via lists.fd.io"
> 
> *Reply-To: *"mgsm...@netgate.com" 
> *Date: *Friday, August 14, 2020 at 2:47 PM
> *To: *"Naveen Joy (najoy)" 
> *Cc: *"vpp-dev@lists.fd.io" 
> *Subject: *Re: [vpp-dev] VRRP issue
>
>
>
>
>
> Hi Naveen,
>
>
>
> See replies inline below...
>
>
>
> On Fri, Aug 14, 2020 at 12:53 PM Naveen Joy (najoy) 
> wrote:
>
> Thanks, Matthew. I am seeing the same behavior with the default
> advertisement interval of 1s.
>
> Tcpdump on a linux tap interface plugged into the same BD as the backup VR
> shows VRRP advertisements arriving at the configured rate of 1s (100cs),
>
> So, there is no packet loss of advertisements or delays in sending
> advertisements by the master VR.
>
>
>
> 10:37:19.991540 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:20.991619 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:21.991783 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:22.991792 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:23.991926 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:24.991976 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:25.992057 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:26.992131 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:27.992257 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:28.992311 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:29.992402 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:30.992513 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 10:37:31.992586 IP 10.4.4.3 > vrrp.mcast.net: VRRPv3, Advertisement, vrid
> 10, prio 110, intvl 100cs, length 12
>
> 
>
>
>
>
>
> Ok, its good to know that the packets are all arriving on the backup.
>
>
>
> The diagram attached to the first message in this thread said that the
> master has address 10.4.4.1 and the backup has 10.4.4.3. Is that diagram
> still accurate? The packets in the capture have a source address of
> 10.4.4.3, which is the address that is supposed to be configured on the
> backup according to the diagram. If the diagram is still accurate, it seems
> like those packets should be dropped by the backup as 'spoofed' packets
> since their source address is configured locally on the backup.
>
>
>
> If the diagram is not accurate and the master VR i

Re: [vpp-dev] VRRP issue

[Matthew Smith via lists.fd.io]

ing
> virtual MAC address 00:00:5e:00:01:0a on hardware interface 13
>
> Aug 14 10:44:01 ml-ucs-01 vnet[5504]: vrrp_input_process:223: Received
> advertisement for master VR [0] sw_if_index 14 VR ID 10 IPv4
>
> Aug 14 10:44:01 ml-ucs-01 vnet[5504]: vrrp_vr_transition:283: VR [0]
> sw_if_index 14 VR ID 10 IPv4 transitioning to Backup
>
> Aug 14 10:44:01 ml-ucs-01 vnet[5504]: vrrp_vr_transition_addrs:238:
> Deleting VR addresses on sw_if_index 14
>
> Aug 14 10:44:01 ml-ucs-01 vnet[5504]: vrrp_vr_transition_vmac:123:
> Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 13
>
> Aug 14 10:44:04 ml-ucs-01 vnet[5504]: vrrp_vr_transition:283: VR [0]
> sw_if_index 14 VR ID 10 IPv4 transitioning to Master
>
> Aug 14 10:44:04 ml-ucs-01 vnet[5504]: vrrp_vr_transition_addrs:238: Adding
> VR addresses on sw_if_index 14
>
> Aug 14 10:44:04 ml-ucs-01 vnet[5504]: vrrp_vr_transition_vmac:123: Adding
> virtual MAC address 00:00:5e:00:01:0a on hardware interface 13
>
> Aug 14 10:44:05 ml-ucs-01 vnet[5504]: vrrp_input_process:223: Received
> advertisement for master VR [0] sw_if_index 14 VR ID 10 IPv4
>
> Aug 14 10:44:05 ml-ucs-01 vnet[5504]: vrrp_vr_transition:283: VR [0]
> sw_if_index 14 VR ID 10 IPv4 transitioning to Backup
>
> Aug 14 10:44:05 ml-ucs-01 vnet[5504]: vrrp_vr_transition_addrs:238:
> Deleting VR addresses on sw_if_index 14
>
> Aug 14 10:44:05 ml-ucs-01 vnet[5504]: vrrp_vr_transition_vmac:123:
> Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 13
>
> Aug 14 10:44:08 ml-ucs-01 vnet[5504]: vrrp_vr_transition:283: VR [0]
> sw_if_index 14 VR ID 10 IPv4 transitioning to Master
>
> Aug 14 10:44:08 ml-ucs-01 vnet[5504]: vrrp_vr_transition_addrs:238: Adding
> VR addresses on sw_if_index 14
>
> Aug 14 10:44:08 ml-ucs-01 vnet[5504]: vrrp_vr_transition_vmac:123: Adding
> virtual MAC address 00:00:5e:00:01:0a on hardware interface 13
>
> Aug 14 10:44:09 ml-ucs-01 vnet[5504]: vrrp_input_process:223: Received
> advertisement for master VR [0] sw_if_index 14 VR ID 10 IPv4
>
>
>
>
>

Those log messages do not necessarily indicate that advertisements are only
being processed every 4s. When a VR is in backup state it does not log
anything about advertisements it receives unless there is something
significant about them. The messages above that are logged about
advertisements being received are only logged because the VR is in the
master state. The fact that it received an advertisement indicates that
either a peer is advertising when it should not be, or a higher priority VR
is preempting this one.

Thanks,
-Matt




>
>
> *From: *Matthew Smith 
> *Date: *Friday, August 14, 2020 at 6:14 AM
> *To: *"Naveen Joy (najoy)" 
> *Cc: *"vpp-dev@lists.fd.io" 
> *Subject: *Re: VRRP issue
>
>
>
> Hi Naveen,
>
>
>
> Generally a transition from backup to master occurs if the master down
> timer expires and no advertisement has been received. So it seems like some
> advertisement packets from the higher priority VR are not being received or
> are not being processed before the timer expires. Since the lower priority
> VR keeps switching from master to backup after receiving an advertisement
> from the higher priority VR, at least some of the advertisements from the
> higher priority VR are clearly being received.
>
>
>
> Packet loss of advertisements is the first thing that I suggest
> you investigate. A packet trace or capture on the lower priority VR would
> probably be helpful in determining whether the advertisements are arriving.
> It also might be helpful to see what 'vppctl show errors' says.
>
>
>
> Another possibility is that there are delays in sending advertisements by
> the higher priority VR or in receiving/processing them on the lower
> priority VR. The advertisement interval appears to be set to 0.3s and the
> master down timer is 1.08s. It seems unlikely that with packets being sent
> every 0.3s that either sending or receiving could be delayed by enough that
> the receiving side would not process one within 1.08s. Just to rule out
> that possibility, you could try increasing the advertisement interval to a
> higher value and see if the situation improves. Do you still see the same
> behavior if you configure the default advertisement interval of 1s (100cs)
> on both VRs?
>
>
>
> Thanks,
>
> -Matt
>
>
>
>
>
> On Thu, Aug 13, 2020 at 5:34 PM Naveen Joy (najoy) 
> wrote:
>
> Hi Matthew/All,
>
>
>
> I am facing an issue with VRRP in VPP and would appreciate your help.
>
>
>
> (Attached - architecture diagram)
>
>
>
>1. I have 2 nodes with VPP & in each node, VRRP is configured to back
>up a router

Re: [vpp-dev] VRRP issue

[Matthew Smith via lists.fd.io]

Hi Naveen,

Generally a transition from backup to master occurs if the master down
timer expires and no advertisement has been received. So it seems like some
advertisement packets from the higher priority VR are not being received or
are not being processed before the timer expires. Since the lower priority
VR keeps switching from master to backup after receiving an advertisement
from the higher priority VR, at least some of the advertisements from the
higher priority VR are clearly being received.

Packet loss of advertisements is the first thing that I suggest
you investigate. A packet trace or capture on the lower priority VR would
probably be helpful in determining whether the advertisements are arriving.
It also might be helpful to see what 'vppctl show errors' says.

Another possibility is that there are delays in sending advertisements by
the higher priority VR or in receiving/processing them on the lower
priority VR. The advertisement interval appears to be set to 0.3s and the
master down timer is 1.08s. It seems unlikely that with packets being sent
every 0.3s that either sending or receiving could be delayed by enough that
the receiving side would not process one within 1.08s. Just to rule out
that possibility, you could try increasing the advertisement interval to a
higher value and see if the situation improves. Do you still see the same
behavior if you configure the default advertisement interval of 1s (100cs)
on both VRs?

Thanks,
-Matt


On Thu, Aug 13, 2020 at 5:34 PM Naveen Joy (najoy)  wrote:

> Hi Matthew/All,
>
>
>
> I am facing an issue with VRRP in VPP and would appreciate your help.
>
>
>
> (Attached - architecture diagram)
>
>
>
>1. I have 2 nodes with VPP & in each node, VRRP is configured to back
>up a router BVI interface in a bridge domain.
>2. The VRRP VRs are speaking VRRP (multicast) over an uplink VLAN
>interface connected to an external switch.
>3. The active router has a VR priority of 110 and is set to preempt.
>
> The backup router has a VR priority of 100 and is not in preempt.
>
>
>
>1. The issue is that VRRP in the backup router is unstable and keeps
>transitioning between the master and backup states every second.
>
> However, the VRRP in the master node is stable.
>
>
>
> I am running the  latest VPP release installed from master  this week.
>
>
>
> vpp# show version verbose
>
> Version:  v20.09-rc0~283-g40c07ce7a~b1542
>
> Compiled by:  root
>
> Compile host: 1f7cd9b19229
>
> Compile date: 2020-08-11T20:40:47
>
> Compile location: /w/workspace/vpp-merge-master-ubuntu1804
>
> Compiler: Clang/LLVM 9.0.0 (tags/RELEASE_900/final)
>
> Current PID:  5504
>
>
>
> *On the backup node –*
>
>
>
> Aug 13 12:59:48 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238:
> Deleting VR addresses on sw_if_index 11
>
> Aug 13 12:59:48 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123:
> Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
>
> Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0]
> sw_if_index 11 VR ID 10 IPv4 transitioning to Master
>
> Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding
> VR addresses on sw_if_index 11
>
> Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding
> virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
>
> Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received
> advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4
>
> Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0]
> sw_if_index 11 VR ID 10 IPv4 transitioning to Backup
>
> Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238:
> Deleting VR addresses on sw_if_index 11
>
> Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123:
> Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
>
> Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0]
> sw_if_index 11 VR ID 10 IPv4 transitioning to Master
>
> Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding
> VR addresses on sw_if_index 11
>
> Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding
> virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
>
> Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received
> advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4
>
> Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0]
> sw_if_index 11 VR ID 10 IPv4 transitioning to Backup
>
> Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238:
> Deleting VR addresses on sw_if_index 11
>
> Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123:
> Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
>
> Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0]
> sw_if_index 11 VR ID 10 IPv4 transitioning to Master
>
> 

Re: [vpp-dev] Query on Feature arc for tapping all IP packets after reassembly

[Matthew Smith via lists.fd.io]

Hi Satya,

A node on ip4-local will process packets which have a destination IPv4
address that is local to VPP. Usually these are addresses configured on a
VPP interface but they can also be addresses in a NAT pool or any other
address which has a local path in the FIB. If those are the only packets
you want your node to process, then ip4-local should work. Otherwise, if
you want to process packets which  VPP will forward elsewhere, you might
want to use the ip4-unicast arc and set runs_after to
"ip4-full-reassembly-feature".

-Matt


On Wed, Aug 12, 2020 at 6:16 AM Satya Murthy 
wrote:

> Hi,
>
> We have a query on one of the requirements we have.
>
> 1. We would like to tap all the ip4 packets into our custom graph node.
> 2. But, we want to tap the ip packets only after reassembly is completed,
> if fragments are received.
>
> I was looking at ip-local feature arc, if this works for our requirement
> or not. But, I am not 100% sure, if the reassembly restriction will be met
> by registering our feature in ip4-local feature arc as below.
>
> VNET_FEATURE_INIT (our_custom_feature, static) =
> {
>   .arc_name = "ip4-local",
>   .node_name = "our-custom-node",
>   .runs_before = VNET_FEATURES("ip4-local-end-of-arc"),
> };
>
> If this does not work, can you please let us know any pointers on how to
> achieve this.
>
> Thanks & Regards,
> Murthy 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Issue in VRRP functionality when compiling with devtoolset-7 with single worker configuration

[Matthew Smith via lists.fd.io]

Hi Amit,

This patch was merged on friday to address the same issue -
https://gerrit.fd.io/r/c/vpp/+/28192.

Please try applying that patch to your build and let me know if it fixes
the problem.

Thanks,
-Matt


On Mon, Aug 10, 2020 at 12:55 AM Amit Mehra  wrote:

> Hi Matthew,
>
> Can you please confirm if this is a known issue of VRRP with devtoolset-7
> or VRRP has a dependency on devtoolset-9 and should always be compiled with
> devtoolset-9?
>
> Regards
> Amit Mehra
>
> On Fri, Aug 7, 2020 at 10:52 AM Amit Mehra via lists.fd.io  gmail@lists.fd.io> wrote:
>
>> Hi,
>>
>> I am testing the Master/Backup functionality using the vrrp plugin
>> available in vpp-20.05 but i am observing the following issue when
>> compiling using devtoolset-7 and using 1 main thread and 1 worker thread in
>> my startup.conf
>>
>> 1) Master Node is sending vrrp broadcast advertisement messages on
>> 224.0.0.18
>> 2) These broadcast messages are getting dropped by vrrp plugin of Backup
>> Node with error "VRRP_ERROR_UNKNOWN_VR"(I could see the stats for this
>> error in show error as well). It seems that mhash_get() is not able to find
>> the hash entry on worker thread.
>> 3) However, when i am giving "vrrp vr add" again for same vr_id and
>> intfc, i am observing the error "VNET_API_ERROR_ENTRY_ALREADY_EXISTS". Here
>> also it call mhash_get() and is able to find the hash entry for the same
>> key but it is on main thread.
>> 4) Also, when i am using only main thread and no worker thread, then the
>> messages are not getting dropped and things seems to work fine.
>>
>> Is there some known issue in vrrp/vpp-20.05 if testing vrrp with workers
>> when using devtoolset-7 for compilation?
>>
>> Also, when i am using devtoolset-9 and using workers in my configuration,
>> then also i am not observing any issues and it seems to work fine.
>>
>> Any suggestions or workaround for testing vrrp while using devtoolset-7
>> in multiple worker config?
>>
>> Regards
>> Amit
>> 
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17182): https://lists.fd.io/g/vpp-dev/message/17182
Mute This Topic: https://lists.fd.io/mt/76043759/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] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

[Matthew Smith]

HI Amit,

Here's a patch which I think will fix the problem:
https://gerrit.fd.io/r/c/vpp/+/27563. If you are able to build with the
patch applied and test it, that would be very helpful.

Thanks,
-Matt



On Sun, Jun 14, 2020 at 12:51 AM Amit Mehra  wrote:

> Thanks Muthu Raj for the Response.
>
> When i am setting "accept_mode" to NO while configuring VRRP router on VPP
> instance-2 (refer my configurations for VPP inst1 and inst 2 in initial
> mail) and when i kill VPP instance-1, then VRRP router running on VPP
> instance-2 is becoming the Master (IP 10.20.37.118 is not added to vpp
> interface this time, as accept_mode was NO) but when i am trying to ping
> 10.20.37.118 from external machine(having same subnet as 10.20.37.xx) then
> ping is not successful. I tried capturing the trace on vpp interface, as is
> being as shown as packets getting dropped.
>
> vpp# show vrrp vr
> [0] sw_if_index 1 VR ID 1 IPv4
>state Master flags: preempt yes accept no unicast no
>priority: configured 200 adjusted 200
>timers: adv interval 100 master adv 100 skew 21 master down 321
>virtual MAC 00:00:5e:00:01:01
>addresses 10.20.37.118
>peer addresses
>tracked interfaces
>
> vpp# show int addr
> GigabitEthernet13/0/0 (up):
>   L3 10.20.37.109/24
> GigabitEthernet1b/0/0 (dn):
> local0 (dn):
>
> vpp# show trace
> 00:03:38:573635: dpdk-input
>   GigabitEthernet13/0/0 rx queue 1
>   buffer 0x1e3492: current data 0, length 98, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle
> 0x102
>ext-hdr-valid
>l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 98
> buf_len 2176, data_len 98, ol_flags 0x82, data_off 128, phys_addr
> 0x88cd2500
> packet_type 0x91 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0xe0a3989 fdir.hi 0x0 fdir.lo 0xe0a3989
> Packet Offload Flags
>   PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without
> extension headers
>   IP4: 00:50:56:9b:e8:ab -> 00:00:5e:00:01:01
>   ICMP: 10.20.37.21 -> 10.20.37.118
> tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
> fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573648: ethernet-input
>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>   IP4: 00:50:56:9b:e8:ab -> 00:00:5e:00:01:01
> 00:03:38:573653: ip4-input
>   ICMP: 10.20.37.21 -> 10.20.37.118
> tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
> fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573656: ip4-lookup
>   fib 0 dpo-idx 0 flow hash: 0x
>   ICMP: 10.20.37.21 -> 10.20.37.118
> tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
> fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573659: ip4-glean
> ICMP: 10.20.37.21 -> 10.20.37.118
>   tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>   fragment id 0x7b52, flags DONT_FRAGMENT
> ICMP echo_request checksum 0xdf6e
> 00:03:38:573664: ip4-drop
> ICMP: 10.20.37.21 -> 10.20.37.118
>   tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>   fragment id 0x7b52, flags DONT_FRAGMENT
> ICMP echo_request checksum 0xdf6e
> 00:03:38:573675: error-drop
>   rx:GigabitEthernet13/0/0
> 00:03:38:573676: drop
>   ip4-glean: ARP requests sent
>
> Moreover, as per RFC-5798(https://tools.ietf.org/html/rfc5798), sec 6.1
> 
>
> Accept_ModeControls whether a virtual router in
>Master state will accept packets
>addressed to the address owner's IPvX
>address as its own if it is not the IPvX
>address owner.  The default is False.
>Deployments that rely on, for example,
>pinging the address owner's IPvX address
>may wish to configure Accept_Mode to
>True.
>
> And also sec 6.4.3, when VRRP router acting as Master
> (650) - MUST accept packets addressed to the IPvX address(es)
>   associated with the virtual router if it is the IPvX address owner
>   or if Accept_Mode is True.  Otherwise, MUST NOT accept these
>   packets.
>
> So, as per my understanding I need to set "accept_mode" to YES as per my
> use-case. My usecase is that IP 10.20.37.118 should always be pingable from
> outside machine (having same subnet as 10.20.37.118)
>
> Please let me know if my understanding is correct or whether I am missing
> anything in my configuration?
>
> Regards
> Amit
> 
>

Re: [vpp-dev] Unable to ping vpp interface from outside after configuring vrrp on vpp interface and making it as Master

[Matthew Smith via lists.fd.io]

That appears to be correct. The vmxnet3 DPDK PMD looks like it does not
support adding or deleting a MAC address. I never attempted to add support
for secondary MAC addresses to the native VPP vxmnet3 driver either. So
VRRP is not able to manage secondary MAC addresses on vmxnet3 devices.

Adding a VRRP virtual MAC address to a device as a secondary MAC address is
primarily intended to avoid putting the device in promiscuous mode. Since
the vmxnet3 DPDK does not support secondary MAC addresses, you can try
setting the device in promiscuous mode. I haven't tested that in a while,
but it worked the last time I tried it.

-Matt



On Mon, Jun 8, 2020 at 11:36 AM steven luong via lists.fd.io  wrote:

> Vmxnet3 is a paravirtualized device. I could be wrong, it does not appear
> it supports adding virtual mac address. This error returns from dpdk
> indicates just that.
>
>
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> vrrp_vr_transition_vmac:120: Adding virtual MAC address 00:00:5e:00:01:01
> on hardware interface 1
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> dpdk_add_del_mac_address: mac address add/del failed: -95
>
>
>
> #define EOPNOTSUPP  95  /* Operation not supported on transport
> endpoint */
>
>
>
> I suggest you try it on the physical NIC to see if that works.
>
>
>
> Steven
>
>
>
> *From: * on behalf of Amit Mehra 
> *Date: *Monday, June 8, 2020 at 5:57 AM
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] Unable to ping vpp interface from outside after
> configuring vrrp on vpp interface and making it as Master
>
>
>
> Hi,
>
>
>
> I am trying to test VRRP functionality using VRRP plugin available in
> VPP-20.05 and after running VRRP functionality on one of the VPP nodes and
> configuring it as a master, i am not able to ping the vpp interface from
> outside. I am using the following configuration
>
>
>
> modprobe -r vfio_pci
>
> modprobe -r vfio
>
>
>
> ./bin/dpdk-devbind.py -s  // bind to vfio-pci driver
>
>
>
> Network devices using DPDK-compatible driver
>
> 
>
> :13:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3
>
> :1b:00.0 'VMXNET3 Ethernet Controller' drv=vfio-pci unused=vmxnet3
>
>
>
> ./bin/vppctl create interface vmxnet3 :13:00.0
>
> ./bin/vppctl set interface ip address vmxnet3-0/13/0/0 10.20.53.143/24
>
> ./bin/vppctl set int state vmxnet3-0/13/0/0 up
>
>
>
> ./bin/vppctl vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 255
> interval 1 accept_mode 10.20.53.143
>
> ./bin/vppctl vrrp proto start GigabitEthernet13/0/0 vr_id 1
>
>
>
> Also, when i am trying to ping this vpp interface ip(10.20.53.143) from
> outside machine(which is having same subnet as 10.20.53.xx), I could see
> that ARP request was received by vpp and responded with a MAC address as
> 00:00:5E:00:01:01 in ARP Reply.
>
> However, the icmp packets were not entering the vpp. Verified the same
> using "trace" functionality available in vpp i.e. trace add vmxnet3-input
> 200
>
>
>
> Moreover, i could see that vrrp packets(Announcement) continuously being
> transmitted by the vpp interface.
>
>
>
> Can someone confirm whether i am following correct steps and what could be
> the reason why icmp packets are not being received by vpp? I tried by
> enabling promiscuous mode on vpp interface using "set interface promiscuous
> on vmxnet3-0/13/0/0" but still icmp packets were not entering the vpp.
>
> Also, is there any CLI by which i can see that virtual MAC has been
> assigned on the vpp interface?
>
>
>
> I also tried testing with dpdk plugin, but observing the following log in
> vpp.log while executing ./bin/vppctl vrrp proto start GigabitEthernet13/0/0
> vr_id 1 CLI
>
>
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> vrrp_vr_transition_vmac:120: Adding virtual MAC address 00:00:5e:00:01:01
> on hardware interface 1
>
> Jun  8 12:32:43 bfs-dl360g10-14-vm17 vnet[29645]:
> dpdk_add_del_mac_address: mac address add/del failed: -95
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16693): https://lists.fd.io/g/vpp-dev/message/16693
Mute This Topic: https://lists.fd.io/mt/74750885/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.05 RC1 milestone is complete! RC2 - on Wednesday 20th May

[Matthew Smith via lists.fd.io]

Sorry for polluting this thread. I just noticed (too late) that Chris
started a new thread with a different subject to address Govind's issue.

Thanks,
-Matt


On Thu, May 14, 2020 at 9:38 AM Matthew Smith via lists.fd.io  wrote:

>
> Hi Govind,
>
> I recently started seeing errors similar to the one you reported when
> running git review on CentOS 7. I updated to a newer version of git review
> and that fixed the issue.
>
> Older versions of git review use a branch format that is deprecated in
> gerrit. I think it changed at some point from refs/publish/master to
> refs/for/master. Gerrit still allowed the old format for a while, but at
> some point it stopped supporting it.
>
> -Matt
>
>
>
> On Wed, May 13, 2020 at 6:24 PM Govindarajan Mohandoss <
> govindarajan.mohand...@arm.com> wrote:
>
>> Hello Maintainers,
>>  I am doing the patch submission for the first time.
>>  I am following the page
>> https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pulling
>> and getting the error below. Can you please help to fix this ?
>>
>> #:~/vpp_external/vpp$ git review
>> remote: error: branch refs/publish/master:
>> remote: You need 'Create' rights to create new references.
>> remote: User: mgovind
>> remote: Contact an administrator to fix the permissions
>> remote:
>> remote: Processing changes: refs: 1
>> remote: Processing changes: refs: 1, done
>> To ssh://gerrit.fd.io:29418/vpp
>>  ! [remote rejected] HEAD -> refs/publish/master (prohibited by
>> Gerrit: not permitted: create)
>> error: failed to push some refs to 'ssh://mgov...@gerrit.fd.io:29418/vpp'
>>
>> Thanks
>> Govind
>>
>> > -Original Message-
>> > From: vpp-dev@lists.fd.io  On Behalf Of Andrew
>> > Yourtchenko via lists.fd.io
>> > Sent: Wednesday, May 13, 2020 6:05 PM
>> > To: vpp-dev 
>> > Subject: [vpp-dev] VPP 20.05 RC1 milestone is complete! RC2 - on
>> Wednesday
>> > 20th May
>> >
>> > Hi all,
>> >
>> > This is to announce that the VPP 20.05 RC1 milestone is complete!
>> >
>> > The newly created stable/2005 branch is ready for your fixes in
>> preparation
>> > for the RC2 milestone.
>> >
>> > They need to have a Jira ticket for the issue, and to avoid forgetting
>> adding
>> > them to master, where practical, *should* be first merged there and then
>> > cherry-picked into the stable/2005 branch - but as soon as the Jira
>> ticket is
>> > mentioned in the commit message and the fix ends up in both master and
>> > stable/2005 (and if it is important/urgent - maybe earlier branches),
>> then
>> > either order is fine.
>> >
>> > The installation packages for the RC1 for Ubuntu 18.04 and Centos 7
>> from the
>> > new branch are available on https://packagecloud.io/fdio/2005/
>> >
>> > The master branch is open for all commits.
>> >
>> > Our next milestone for VPP 20.05 is RC2, happening next Wednesday 20th
>> > May.
>> >
>> > Thanks a lot to Vanessa Valderrama, Dave Wallace and Ed Warnicke for the
>> > help!
>> >
>> > --a
>> > /* Your friendly 2005 release manager */
>>
>> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16384): https://lists.fd.io/g/vpp-dev/message/16384
Mute This Topic: https://lists.fd.io/mt/74194208/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.05 RC1 milestone is complete! RC2 - on Wednesday 20th May

[Matthew Smith via lists.fd.io]

Hi Govind,

I recently started seeing errors similar to the one you reported when
running git review on CentOS 7. I updated to a newer version of git review
and that fixed the issue.

Older versions of git review use a branch format that is deprecated in
gerrit. I think it changed at some point from refs/publish/master to
refs/for/master. Gerrit still allowed the old format for a while, but at
some point it stopped supporting it.

-Matt



On Wed, May 13, 2020 at 6:24 PM Govindarajan Mohandoss <
govindarajan.mohand...@arm.com> wrote:

> Hello Maintainers,
>  I am doing the patch submission for the first time.
>  I am following the page
> https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pulling
> and getting the error below. Can you please help to fix this ?
>
> #:~/vpp_external/vpp$ git review
> remote: error: branch refs/publish/master:
> remote: You need 'Create' rights to create new references.
> remote: User: mgovind
> remote: Contact an administrator to fix the permissions
> remote:
> remote: Processing changes: refs: 1
> remote: Processing changes: refs: 1, done
> To ssh://gerrit.fd.io:29418/vpp
>  ! [remote rejected] HEAD -> refs/publish/master (prohibited by
> Gerrit: not permitted: create)
> error: failed to push some refs to 'ssh://mgov...@gerrit.fd.io:29418/vpp'
>
> Thanks
> Govind
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Andrew
> > Yourtchenko via lists.fd.io
> > Sent: Wednesday, May 13, 2020 6:05 PM
> > To: vpp-dev 
> > Subject: [vpp-dev] VPP 20.05 RC1 milestone is complete! RC2 - on
> Wednesday
> > 20th May
> >
> > Hi all,
> >
> > This is to announce that the VPP 20.05 RC1 milestone is complete!
> >
> > The newly created stable/2005 branch is ready for your fixes in
> preparation
> > for the RC2 milestone.
> >
> > They need to have a Jira ticket for the issue, and to avoid forgetting
> adding
> > them to master, where practical, *should* be first merged there and then
> > cherry-picked into the stable/2005 branch - but as soon as the Jira
> ticket is
> > mentioned in the commit message and the fix ends up in both master and
> > stable/2005 (and if it is important/urgent - maybe earlier branches),
> then
> > either order is fine.
> >
> > The installation packages for the RC1 for Ubuntu 18.04 and Centos 7 from
> the
> > new branch are available on https://packagecloud.io/fdio/2005/
> >
> > The master branch is open for all commits.
> >
> > Our next milestone for VPP 20.05 is RC2, happening next Wednesday 20th
> > May.
> >
> > Thanks a lot to Vanessa Valderrama, Dave Wallace and Ed Warnicke for the
> > help!
> >
> > --a
> > /* Your friendly 2005 release manager */
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16383): https://lists.fd.io/g/vpp-dev/message/16383
Mute This Topic: https://lists.fd.io/mt/74194208/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 project committer nomination: Benoit Ganne

[Matthew Smith via lists.fd.io]

+1

(Sorry for the delay)
-Matt


On Tue, Apr 21, 2020 at 6:39 AM Dave Barach via lists.fd.io  wrote:

> Vpp project committers: please vote +1, 0, -1 on the mailto:
> vpp-dev@lists.fd.io mailer as to whether we should add Benoit Ganne as a
> vpp project committer.
>
> Ben has about 150 merged patches, see
> https://gerrit.fd.io/r/q/status:merged+owner:bganne%2540cisco.com. He has
> expressed interest in the role, and I believe that he will make a fine
> committer.
>
> Thanks... Dave
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16155): https://lists.fd.io/g/vpp-dev/message/16155
Mute This Topic: https://lists.fd.io/mt/73170252/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 19.08 failed to load in CENTOS 7

[Matthew Smith via lists.fd.io]

On Tue, Apr 7, 2020 at 4:36 AM  wrote:

> maybe this is releated also?
> https://github.com/spdk/spdk/issues/1012
>  -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
>
Yes, it's probably the same issue.

I saw the same error using vfio-pci with iommu enabled on a C3000 board a
couple of months ago. Setting iova-mode to pa in the arguments to
rte_eal_init() made it work. One of my colleagues submitted a patch which
will allow this to be set in startup.conf like so:

dpdk {
iova-mode pa
}

The patch was submitted after 20.01 was released. So it won't help you if
you have to run 19.08. You could build from the current master branch, try
using igb_uio (which should result in the iova mode being set to pa) or
wait for the next release.

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

View/Reply Online (#16036): https://lists.fd.io/g/vpp-dev/message/16036
Mute This Topic: https://lists.fd.io/mt/72808669/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] VRRP Unit Tests failing on Master Ubuntu

[Matthew Smith via Lists.Fd.Io]

Hi Dave,

That sounds fine to me.

Thanks,
-Matt


On Thu, Mar 12, 2020 at 11:32 AM Dave Wallace  wrote:

> Matt,
>
> I will keep an eye on this gerrit and merge it once the verify jobs have
> completed.
> If there are other tests which fail, are you ok if I add them to this
> patch and turn it into a generic 'disable failing tests' gerrit change?
>
> The other possibility is that this is due to the recent disabling of the
> Naginator retry plugin.
>
> I'm going to investigate if this issue may have been masked by Naginator...
>
> Thanks for your help on keeping the CI operational!
> -daw-
>
> On 3/12/2020 12:09 PM, Matthew Smith via Lists.Fd.Io wrote:
>
>
> Change submitted - https://gerrit.fd.io/r/c/vpp/+/25834. Verification
> jobs are running. Hopefully they won't fail :)
>
> -Matt
>
>
> On Thu, Mar 12, 2020 at 10:22 AM Matthew Smith via Lists.Fd.Io  netgate@lists.fd.io> wrote:
>
>>
>> I don't have a solution yet, but one observation has popped up quickly
>>
>> In the 2 failed jobs Ray sent links for, one of them had a test fail
>> which was not related to VRRP. There is a BFD6 test failure for the NAT
>> change https://gerrit.fd.io/r/c/vpp/+/25462:
>>
>>
>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/archives/
>>
>> Looking back through a couple of recent failed runs of that job, there is
>> also a DHCP6 PD test failure for rdma change
>> https://gerrit.fd.io/r/c/vpp/+/25823:
>>
>>
>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2682/archives/
>>
>> The most obvious common thread between BFD6, DHCP6 and VRRP to me seems
>> to be that they all maintain state which is dependent on timers. There
>> could be a more general issue with timing-sensitive tests. I am going to
>> submit a change which will prevent the VRRP tests from running temporarily
>> while I can figure out a proper solution. Based on the above, other tests
>> may need the same treatment.
>>
>> -Matt
>>
>>
>>
>>
>> On Thu, Mar 12, 2020 at 8:57 AM Matthew Smith 
>> wrote:
>>
>>> Hi Ray,
>>>
>>> Thanks for bringing it to my attention. I'll look into it.
>>>
>>> -Matt
>>>
>>>
>>> On Thu, Mar 12, 2020 at 8:24 AM Ray Kinsella  wrote:
>>>
>>>> Anyone else noticing seeming spurious failures related to the VRRP
>>>> plugin's unit tests.
>>>> Some examples from un-related commits.
>>>>
>>>> Ray K
>>>>
>>>> nat: timed out session scavenging upgrade (
>>>> https://gerrit.fd.io/r/c/vpp/+/25462)
>>>>
>>>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/console.log.gz
>>>>
>>>>
>>>> ==
>>>> TEST RESULTS:
>>>>  Scheduled tests: 1138
>>>>   Executed tests: 1138
>>>> Passed tests: 1021
>>>>Skipped tests: 112
>>>> Failures: 3
>>>>   Errors: 2
>>>> FAILURES AND ERRORS IN TESTS:
>>>>   Testcase name: IPv4 VRRP Test Case
>>>> FAILURE: IPv4 Master VR does not reply for VIP w/ accept mode off
>>>> [test_vrrp.TestVRRP4.test_vrrp4_accept_mode_disabled]
>>>> FAILURE: IPv4 Master VR preempted by higher priority backup
>>>> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>>>>   Testcase name: IPv6 VRRP Test Case
>>>> FAILURE: IPv6 Master VR preempted by higher priority backup
>>>> [test_vrrp.TestVRRP6.test_vrrp6_master_preempted]
>>>>   ERROR: IPv6 Backup VR preempts lower priority master
>>>> [test_vrrp.TestVRRP6.test_vrrp6_backup_preempts]
>>>>   Testcase name: Bidirectional Forwarding Detection (BFD) (IPv6)
>>>>   ERROR: echo function [test_bfd.BFD6TestCase.test_echo]
>>>>
>>>> ==
>>>>
>>>> vlib: startup multi-arch variant configuration (
>>>> https://gerrit.fd.io/r/c/vpp/+/25798_
>>>>
>>>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2675/console.log.gz
>>>>
>>>>
>>>> ==
>>>> TEST RESULTS:
>>>>  Scheduled tests: 22
>>>>   Executed tests: 22
>>>> Passed tests: 21
>>>> Failures: 1
>>>> FAILURES AND ERRORS IN TESTS:
>>>>   Testcase name: IPv4 VRRP Test Case
>>>> FAILURE: IPv4 Master VR preempted by higher priority backup
>>>> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>>>>
>>>> ==
>>>>
>>>>
>>>>
>>>>
>>
> 
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15764): https://lists.fd.io/g/vpp-dev/message/15764
Mute This Topic: https://lists.fd.io/mt/71901798/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] VRRP Unit Tests failing on Master Ubuntu

[Matthew Smith via Lists.Fd.Io]

Change submitted - https://gerrit.fd.io/r/c/vpp/+/25834. Verification jobs
are running. Hopefully they won't fail :)

-Matt


On Thu, Mar 12, 2020 at 10:22 AM Matthew Smith via Lists.Fd.Io  wrote:

>
> I don't have a solution yet, but one observation has popped up quickly
>
> In the 2 failed jobs Ray sent links for, one of them had a test fail which
> was not related to VRRP. There is a BFD6 test failure for the NAT change
> https://gerrit.fd.io/r/c/vpp/+/25462:
>
>
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/archives/
>
> Looking back through a couple of recent failed runs of that job, there is
> also a DHCP6 PD test failure for rdma change
> https://gerrit.fd.io/r/c/vpp/+/25823:
>
>
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2682/archives/
>
> The most obvious common thread between BFD6, DHCP6 and VRRP to me seems to
> be that they all maintain state which is dependent on timers. There could
> be a more general issue with timing-sensitive tests. I am going to submit a
> change which will prevent the VRRP tests from running temporarily while I
> can figure out a proper solution. Based on the above, other tests may need
> the same treatment.
>
> -Matt
>
>
>
>
> On Thu, Mar 12, 2020 at 8:57 AM Matthew Smith  wrote:
>
>> Hi Ray,
>>
>> Thanks for bringing it to my attention. I'll look into it.
>>
>> -Matt
>>
>>
>> On Thu, Mar 12, 2020 at 8:24 AM Ray Kinsella  wrote:
>>
>>> Anyone else noticing seeming spurious failures related to the VRRP
>>> plugin's unit tests.
>>> Some examples from un-related commits.
>>>
>>> Ray K
>>>
>>> nat: timed out session scavenging upgrade (
>>> https://gerrit.fd.io/r/c/vpp/+/25462)
>>>
>>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/console.log.gz
>>>
>>>
>>> ==
>>> TEST RESULTS:
>>>  Scheduled tests: 1138
>>>   Executed tests: 1138
>>> Passed tests: 1021
>>>Skipped tests: 112
>>> Failures: 3
>>>   Errors: 2
>>> FAILURES AND ERRORS IN TESTS:
>>>   Testcase name: IPv4 VRRP Test Case
>>> FAILURE: IPv4 Master VR does not reply for VIP w/ accept mode off
>>> [test_vrrp.TestVRRP4.test_vrrp4_accept_mode_disabled]
>>> FAILURE: IPv4 Master VR preempted by higher priority backup
>>> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>>>   Testcase name: IPv6 VRRP Test Case
>>> FAILURE: IPv6 Master VR preempted by higher priority backup
>>> [test_vrrp.TestVRRP6.test_vrrp6_master_preempted]
>>>   ERROR: IPv6 Backup VR preempts lower priority master
>>> [test_vrrp.TestVRRP6.test_vrrp6_backup_preempts]
>>>   Testcase name: Bidirectional Forwarding Detection (BFD) (IPv6)
>>>   ERROR: echo function [test_bfd.BFD6TestCase.test_echo]
>>>
>>> ==
>>>
>>> vlib: startup multi-arch variant configuration (
>>> https://gerrit.fd.io/r/c/vpp/+/25798_
>>>
>>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2675/console.log.gz
>>>
>>>
>>> ==
>>> TEST RESULTS:
>>>  Scheduled tests: 22
>>>   Executed tests: 22
>>> Passed tests: 21
>>> Failures: 1
>>> FAILURES AND ERRORS IN TESTS:
>>>   Testcase name: IPv4 VRRP Test Case
>>> FAILURE: IPv4 Master VR preempted by higher priority backup
>>> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>>>
>>> ==
>>>
>>>
>>>
>>> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15762): https://lists.fd.io/g/vpp-dev/message/15762
Mute This Topic: https://lists.fd.io/mt/71901798/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] VRRP Unit Tests failing on Master Ubuntu

[Matthew Smith via Lists.Fd.Io]

I don't have a solution yet, but one observation has popped up quickly

In the 2 failed jobs Ray sent links for, one of them had a test fail which
was not related to VRRP. There is a BFD6 test failure for the NAT change
https://gerrit.fd.io/r/c/vpp/+/25462:

https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/archives/

Looking back through a couple of recent failed runs of that job, there is
also a DHCP6 PD test failure for rdma change
https://gerrit.fd.io/r/c/vpp/+/25823:

https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2682/archives/

The most obvious common thread between BFD6, DHCP6 and VRRP to me seems to
be that they all maintain state which is dependent on timers. There could
be a more general issue with timing-sensitive tests. I am going to submit a
change which will prevent the VRRP tests from running temporarily while I
can figure out a proper solution. Based on the above, other tests may need
the same treatment.

-Matt




On Thu, Mar 12, 2020 at 8:57 AM Matthew Smith  wrote:

> Hi Ray,
>
> Thanks for bringing it to my attention. I'll look into it.
>
> -Matt
>
>
> On Thu, Mar 12, 2020 at 8:24 AM Ray Kinsella  wrote:
>
>> Anyone else noticing seeming spurious failures related to the VRRP
>> plugin's unit tests.
>> Some examples from un-related commits.
>>
>> Ray K
>>
>> nat: timed out session scavenging upgrade (
>> https://gerrit.fd.io/r/c/vpp/+/25462)
>>
>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/console.log.gz
>>
>>
>> ==
>> TEST RESULTS:
>>  Scheduled tests: 1138
>>   Executed tests: 1138
>> Passed tests: 1021
>>Skipped tests: 112
>> Failures: 3
>>   Errors: 2
>> FAILURES AND ERRORS IN TESTS:
>>   Testcase name: IPv4 VRRP Test Case
>> FAILURE: IPv4 Master VR does not reply for VIP w/ accept mode off
>> [test_vrrp.TestVRRP4.test_vrrp4_accept_mode_disabled]
>> FAILURE: IPv4 Master VR preempted by higher priority backup
>> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>>   Testcase name: IPv6 VRRP Test Case
>> FAILURE: IPv6 Master VR preempted by higher priority backup
>> [test_vrrp.TestVRRP6.test_vrrp6_master_preempted]
>>   ERROR: IPv6 Backup VR preempts lower priority master
>> [test_vrrp.TestVRRP6.test_vrrp6_backup_preempts]
>>   Testcase name: Bidirectional Forwarding Detection (BFD) (IPv6)
>>   ERROR: echo function [test_bfd.BFD6TestCase.test_echo]
>>
>> ==
>>
>> vlib: startup multi-arch variant configuration (
>> https://gerrit.fd.io/r/c/vpp/+/25798_
>>
>> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2675/console.log.gz
>>
>>
>> ==
>> TEST RESULTS:
>>  Scheduled tests: 22
>>   Executed tests: 22
>> Passed tests: 21
>> Failures: 1
>> FAILURES AND ERRORS IN TESTS:
>>   Testcase name: IPv4 VRRP Test Case
>> FAILURE: IPv4 Master VR preempted by higher priority backup
>> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>>
>> ==
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15761): https://lists.fd.io/g/vpp-dev/message/15761
Mute This Topic: https://lists.fd.io/mt/71901798/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] VRRP Unit Tests failing on Master Ubuntu

[Matthew Smith via Lists.Fd.Io]

Hi Ray,

Thanks for bringing it to my attention. I'll look into it.

-Matt


On Thu, Mar 12, 2020 at 8:24 AM Ray Kinsella  wrote:

> Anyone else noticing seeming spurious failures related to the VRRP
> plugin's unit tests.
> Some examples from un-related commits.
>
> Ray K
>
> nat: timed out session scavenging upgrade (
> https://gerrit.fd.io/r/c/vpp/+/25462)
>
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2678/console.log.gz
>
>
> ==
> TEST RESULTS:
>  Scheduled tests: 1138
>   Executed tests: 1138
> Passed tests: 1021
>Skipped tests: 112
> Failures: 3
>   Errors: 2
> FAILURES AND ERRORS IN TESTS:
>   Testcase name: IPv4 VRRP Test Case
> FAILURE: IPv4 Master VR does not reply for VIP w/ accept mode off
> [test_vrrp.TestVRRP4.test_vrrp4_accept_mode_disabled]
> FAILURE: IPv4 Master VR preempted by higher priority backup
> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>   Testcase name: IPv6 VRRP Test Case
> FAILURE: IPv6 Master VR preempted by higher priority backup
> [test_vrrp.TestVRRP6.test_vrrp6_master_preempted]
>   ERROR: IPv6 Backup VR preempts lower priority master
> [test_vrrp.TestVRRP6.test_vrrp6_backup_preempts]
>   Testcase name: Bidirectional Forwarding Detection (BFD) (IPv6)
>   ERROR: echo function [test_bfd.BFD6TestCase.test_echo]
>
> ==
>
> vlib: startup multi-arch variant configuration (
> https://gerrit.fd.io/r/c/vpp/+/25798_
>
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1804/2675/console.log.gz
>
>
> ==
> TEST RESULTS:
>  Scheduled tests: 22
>   Executed tests: 22
> Passed tests: 21
> Failures: 1
> FAILURES AND ERRORS IN TESTS:
>   Testcase name: IPv4 VRRP Test Case
> FAILURE: IPv4 Master VR preempted by higher priority backup
> [test_vrrp.TestVRRP4.test_vrrp4_master_preempted]
>
> ==
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15754): https://lists.fd.io/g/vpp-dev/message/15754
Mute This Topic: https://lists.fd.io/mt/71901798/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] APPROVED: add Matt Smith as a vpp committer, subject to TSC approval this Thursday

[Matthew Smith via Lists.Fd.Io]

Thanks Dave (et al)!!

-Matt


On Mon, Mar 2, 2020 at 2:52 PM Dave Barach via Lists.Fd.Io  wrote:

> With 100% of the votes counted: 11 votes +1, no other votes.
>
> Dave
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15665): https://lists.fd.io/g/vpp-dev/message/15665
Mute This Topic: https://lists.fd.io/mt/71684715/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 support for VRRP

[Matthew Smith via Lists.Fd.Io]

Netgate has a plugin which adds VRRPv3 support to VPP. We plan to submit it
in gerrit in the next month or two.

On Mon, Jan 13, 2020 at 4:27 AM Jerome Tollet via Lists.Fd.Io  wrote:

>
> Of course, contributions are more than welcome in case you’d like to work
> on VRRP for VPP.
>
>
>
Netgate has a plugin for VPP which adds VRRPv3 support. We plan to submit
it via gerrit sometime in the next month or so.

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

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

[vpp-dev] plugin API header files

[Matthew Smith via Lists.Fd.Io]

Hi all,

I am trying to build some API client code against a copy of the
master branch I pulled a couple of days ago (ee74376 ip: refactor ip4_mtrie
to use atomic store-release). It seems like some required headers are not
getting installed for plugins.

E.g. - the LACP plugin header lacp.api.h has an '#include
"lacp.api_types.h"' which contains the typedef statements for the LACP API
message structs. The header lacp.api_types.h is generated in the build
directory but is not copied to the install directory.

[~/src/vpp]# grep '#include'
build-root/install-vpp_debug-native/vpp/include/vpp_plugins/lacp/lacp.api.h
#include 
#include "lacp.api_types.h"
[~/src/vpp]# ls build-root/build-vpp_debug-native/vpp/plugins/lacp/*api*
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api.c
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api_enum.h
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api.h
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api.json
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api_test.c
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api_types.h
[~/src/vpp]# ls
build-root/install-vpp_debug-native/vpp/include/vpp_plugins/lacp/
lacp.api.h  mux_machine.h  protocol.h rx_machine.h
machine.h   node.h ptx_machine.h  tx_machine.h

The other plugins that the code tries to build against have the same issue.
The client code I'm trying to build wants to include the header with
'vl_typedefs' defined in order to pull in the struct definitions, which
seem to be populated in lacp.api_types.h now.

API header file auto generation has changed recently. Did something get
missed with the plugins? Or is there something new that I need to do? The
vnet API headers don't seem to have this issue, it only appears to be
plugins that are affected.

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

View/Reply Online (#14465): https://lists.fd.io/g/vpp-dev/message/14465
Mute This Topic: https://lists.fd.io/mt/40407935/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 dpdk crypto performance testing (VPP 19.01)

[Matthew Smith via Lists.Fd.Io]

The issue might be fixed if you upgrade to a newer version than 19.01 - see
https://gerrit.fd.io/r/#/c/vpp/+/19383/

-Matt


On Mon, Sep 9, 2019 at 7:14 AM shi dave  wrote:

> Hi,
>
> Using VPP+DPDK for Ipsec Security Gateway application, want to handle
> traffic (*7Gbps uplink & decrypt + 28Gbps downlink & encrypt* ) with
> below configuration, but there have many rx-miss errors in downlink
> interface, *but the Vectors/Call for ipsec & dpdk crypto node is very low
> (only 3~4)*, and the traffic is balanced in all threads.
>
> *If only run 35Gbps downlink packets, there don't have rx-miss errors in
> downlink interface.*
>
> My initial test is using 16 worker cores, when I found the downlink
> rx-miss, I increased the worker cores to 32 cores, but the rx-miss are
> still there.
>
> Have anyone know how to resolve the rx-miss issue?
> and it seems the crypto scheduler doesn't work in this version.
>
>
> *configuration:*
>
> 40G nic * 2
> 32 work cores
>
> #./vppctl show hard detail
>
>   NameIdx   Link  Hardware
> FortyGigabitEthernet0/a/0  1 up   FortyGigabitEthernet0/a/0
>   Link speed: *40 Gbps*
>   Ethernet address 3c:fd:fe:af:d6:f8
>   Intel X710/XL710 Family
> carrier up full duplex mtu 9206
> flags: admin-up pmd maybe-multiseg tx-offload intel-phdr-cksum
> rx-ip4-cksum
>
> *rx: queues 32 (max 320), desc 4096 (min 64 max 4096 align 32) *
> *tx: queues 32 (max 320), desc 4096 (min 64 max 4096 align 32)*
> tx burst function: i40e_xmit_pkts
> rx burst function: i40e_recv_scattered_pkts_vec
>
> tx frames ok  9958725523
> tx bytes ok   11808362771488
> rx frames ok  4714961077
> rx bytes ok2234400127379
>
>
> FortyGigabitEthernet0/b/0  2 up   FortyGigabitEthernet0/b/0
>   Link speed: *40 Gbps*
>   Ethernet address 3c:fd:fe:af:e2:a0
>   Intel X710/XL710 Family
> carrier up full duplex mtu 9206
> flags: admin-up pmd maybe-multiseg tx-offload intel-phdr-cksum
> rx-ip4-cksum
>
> *rx: queues 32 (max 320), desc 4096 (min 64 max 4096 align 32) *
> *tx: queues 32 (max 320), desc 4096 (min 64 max 4096 align 32)*
> tx burst function: i40e_xmit_pkts
> rx burst function: i40e_recv_scattered_pkts_vec
>
> tx frames ok  4714839685
> tx bytes ok1939591401104
> rx frames ok  9959949511
> rx bytes ok   11194675133398
> *rx missed1126523*
>
>
> *startup.conf*
>
> cpu {
> main-core 0
> corelist-workers 1-32
> }
>
> dpdk {
> socket-mem 16384
> uio-driver igb_uio
> num-mbufs 8388608
> dev :00:0a.0 {
> num-rx-queues 32
> num-tx-queues 32
> num-rx-desc 4096
> num-tx-desc 4096
> }
> dev :00:0b.0 {
> num-rx-queues 32
> num-tx-queues 32
> num-rx-desc 4096
> num-tx-desc 4096
> }
> vdev cryptodev_aesni_mb_pmd0,socket_id=0
> vdev cryptodev_aesni_mb_pmd1,socket_id=0
> vdev cryptodev_aesni_mb_pmd2,socket_id=0
> vdev cryptodev_aesni_mb_pmd3,socket_id=0
> vdev cryptodev_aesni_mb_pmd4,socket_id=0
> vdev cryptodev_aesni_mb_pmd5,socket_id=0
> vdev cryptodev_aesni_mb_pmd6,socket_id=0
> vdev cryptodev_aesni_mb_pmd7,socket_id=0
> }
>
>
> *vpp# show dpdk crypto placement *
>
> Thread 1 (vpp_wk_0):
>   cryptodev_aesni_mb_p dev-id  0 inbound-queue  0 outbound-queue  1
>
> Thread 2 (vpp_wk_1):
>   cryptodev_aesni_mb_p dev-id  0 inbound-queue  2 outbound-queue  3
>
> Thread 3 (vpp_wk_2):
>   cryptodev_aesni_mb_p dev-id  0 inbound-queue  4 outbound-queue  5
>
> Thread 4 (vpp_wk_3):
>   cryptodev_aesni_mb_p dev-id  0 inbound-queue  6 outbound-queue  7
>
> Thread 5 (vpp_wk_4):
>   cryptodev_aesni_mb_p dev-id  1 inbound-queue  0 outbound-queue  1
>
> Thread 6 (vpp_wk_5):
>   cryptodev_aesni_mb_p dev-id  1 inbound-queue  2 outbound-queue  3
>
> ..
>
> Thread 31 (vpp_wk_30):
>
>   cryptodev_aesni_mb_p dev-id  7 inbound-queue  4 outbound-queue  5
>
>
>
> Thread 32 (vpp_wk_31):
>
>   cryptodev_aesni_mb_p dev-id  7 inbound-queue  6 outbound-queue  7
>
>
> *vpp# show interface rx-placement *
> Thread 1 (vpp_wk_0):
>   node dpdk-input:
> FortyGigabitEthernet0/a/0 queue 0 (polling)
> FortyGigabitEthernet0/b/0 queue 0 (polling)
> Thread 2 (vpp_wk_1):
>   node dpdk-input:
> FortyGigabitEthernet0/a/0 queue 1 (polling)
> FortyGigabitEthernet0/b/0 queue 1 (polling)
> Thread 3 (vpp_wk_2):
>   node dpdk-input:
> FortyGigabitEthernet0/a/0 queue 2 (polling)
> FortyGigabitEthernet0/b/0 queue 2 (polling)
> Thread 4 (vpp_wk_3):
>   node dpdk-input:
> FortyGigabitEthernet0/a/0 queue 3 (polling)
> FortyGigabitEthernet0/b/0 queue 3 (polling)
>
> ..
>
> Thread 31 (vpp_wk_30):
>   

[vpp-dev] IPv6 on tunnel interfaces

[Matthew Smith via Lists.Fd.Io]

Hi,

Someone pointed out to me that if an IPv6 address is configured on an IPsec
or GRE tunnel interface, the address is visible if you look at 'vppctl show
int addr' but the address is not included in the data we retrieve from the
API. This does not prevent IPv6 packets from being sent, it just affects
how our control plane can determine whether an IPv6 address is already
configured on an interface in order to decide whether to attempt to add or
delete it.

It seems that if I send an IP_DUMP message to the API with is_ipv6 set to
1, the tunnel interfaces will be filtered out by this condition in
vl_api_ip_dump_t_handler():

if (mp->is_ipv6 && !ip6_interface_enabled (vm, si->sw_if_index))
  {
continue;
  }

ip6_interface_enabled() returns false for the tunnel interfaces.

If I send IP_ADDRESS_DUMP for the tunnel interface with is_ipv6 set to 1, I
do get back an address for the IPv6 address I set on the interface. So it's
possible to get those addresses, but my code is skipping the
IP_ADDRESS_DUMP for IPv6 addresses on the interface because no IP_DETAILS
was received for IPv6 on that interface.

There's no written explanation of IP_DUMP and IP_ADDRESS_DUMP that I recall
seeing, but I inferred that IP_DUMP would indicate whether you should
bother sending an IP_ADDRESS_DUMP for a particular combination of
{sw_if_index, is_ipv6}. Vpp_api_test seems to make the same inference,
which makes sense since I probably copied the behavior of vpp_api_test
initially when I was figuring out how things are supposed to work. Here's
what vat does with the above situation:


vat# ip_dump ipv6
vat# ip_address_dump ipv6 ipsec0
ip address details arrived but not storedip_dump should be called firstvat#


(Note: vat's error output is missing some "\n"s).

vppctl says:

[root@dev-mgsmith-vm-1 ~]# vppctl show int addr ipsec0
ipsec0 (up):
  L3 172.19.0.1/30
  L3 abcd:ef01::1/64



For the short term, I can easily deal with this in my client code and just
dump IP addresses for a particular {sw_if_index, is_ipv6} whether or not I
received an IP_DETAILS for that interface/af. I'm trying to determine for
the longer term whether vl_api_ip_dump_t_handler() or
ip6_interface_enabled() or something else should be modified. Or if this is
just the expected behavior.

Some possibilities:

   1. Change vl_api_ip_dump_t_handler(). Only skip an interface if IPv6 is
   not enabled and there are no IPv6 addresses configured on the interface.
   2. Change ip6_interface_enabled(). It currently seems to return false if
   there is no RA configuration for the interface. This could be expanded so
   that it returns false if there is no RA configuration and there are no IPv6
   addresses configured on the interface.
   3. Change enable_ip6_interface() so that some RA configuration gets set
   up for tunnel interfaces as it does with ethernet interfaces. I have no
   idea whether this is actually feasible.
   4. Don't do anything.
   5. Some other, much better, idea that I am not mentioning.

If I get feedback on what is the preferred course of action, I can submit a
patch.

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

View/Reply Online (#13581): https://lists.fd.io/g/vpp-dev/message/13581
Mute This Topic: https://lists.fd.io/mt/32599641/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] loopback admin status

[Matthew Smith via Lists.Fd.Io]

Hi Neale,

Thanks for your reply.

I noticed that there is a function for IPv6 named
ip6_sw_interface_admin_up_down() in src/vnet/ip/ip6_forward.c which seems
like it iterates the IPv6 addresses on an interface and adds or deletes the
routes for each address if the interface is brought up or down. So maybe
this is already handled for IPv6? If I'm understanding that correctly, do
you think it would be appropriate to add a similar function for IPv4 and
register it with VNET_SW_INTERFACE_ADMIN_UP_DOWN_FUNCTION()?

-Matt


On Wed, Jul 17, 2019 at 3:33 AM Neale Ranns (nranns) 
wrote:

>
>
> Hi Matt,
>
>
>
> I would tend to agree with you. The interface’s IP addresses should not be
> programmed in the FIB if the interface is down.
>
>
>
> /neale
>
>
>
>
>
> *De : * au nom de "Matthew Smith via Lists.Fd.Io"
> 
> *Répondre à : *"mgsm...@netgate.com" 
> *Date : *mardi 16 juillet 2019 à 21:42
> *À : *vpp-dev 
> *Cc : *"vpp-dev@lists.fd.io" 
> *Objet : *[vpp-dev] loopback admin status
>
>
>
> Hi,
>
>
>
> If I create a loopback interface and configure an IP address on it, I am
> able to ping that IP address from another host regardless of whether the
> admin status of the loopback is up or down. Is that intentional? I'm trying
> to figure out if this is something that can be "fixed" or if the current
> behavior is the way it's supposed to be.
>
>
>
> If I use a loopback as an endpoint for services and want to take the
> services offline temporarily, it would be convenient to be able to take the
> interface down and have the services effectively be disabled.
>
>
>
> -Matt
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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