The same problem still exists.
vpp# sh hardware-interfaces eth0
Name Idx Link Hardware
eth0 2 down eth0
Link speed: unknown
Ethernet address b4:96:91:23:1e:d6
Intel 82599
* carrier down *
flags: admin-up promisc pmd rx-ip4-cksum
* rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) tx:
queues 1 (max 64), desc 512 (min 32 max 4096 align 8)*
pci: device 8086:154d subsystem 8086:7b11 address 0000:06:00.01 numa 0
max rx packet len: 15872
promiscuous: unicast on all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
macsec-strip vlan-filter vlan-extend jumbo-frame
scatter
security keep-crc
rx offload active: ipv4-cksum
tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum
sctp-cksum
tcp-tso macsec-insert multi-segs security
tx offload active: none
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex
ipv6-tcp
ipv6-udp ipv6-ex ipv6
rss active: none
tx burst function: (nil)
rx burst function: ixgbe_recv_pkts_vec
vpp#
testpmd shows that interface is up.
testpmd> show port summary 1
Number of available ports: 2
Port MAC Address Name Driver Status Link
*1 B4:96:91:23:1E:D6 0000:06:00.1 net_ixgbe up 10000Mbps*
testpmd>
On Fri, Oct 18, 2019 at 8:16 PM Steven Luong (sluong) <slu...@cisco.com>
wrote:
> Can you reduce your rx and tx queues to 1 and try again?
>
>
>
> rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8)
> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
>
> Steven
>
>
>
> *From: *<vpp-dev@lists.fd.io> on behalf of "Chuan Han via Lists.Fd.Io"
> <chuanhan=google....@lists.fd.io>
> *Reply-To: *"chuan...@google.com" <chuan...@google.com>
> *Date: *Friday, October 18, 2019 at 4:05 PM
> *To: *Chuan Han <chuan...@google.com>
> *Cc: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work
>
>
>
> Hi, Damjan,
>
>
>
> It seems the bug is in vpp.
>
>
>
> On R230, vpp shows eth0 is down.
>
>
>
> vpp# sh hardware-interfaces eth0
> Name Idx Link Hardware
> eth0 2 down eth0
> Link speed: unknown
>
>
> * Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down*
> flags: admin-up promisc pmd rx-ip4-cksum
> rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8)
> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
> pci: device 8086:154d subsystem 8086:7b11 address 0000:06:00.01 numa 0
> max rx packet len: 15872
> promiscuous: unicast on all-multicast on
> vlan offload: strip off filter off qinq off
> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
> macsec-strip vlan-filter vlan-extend jumbo-frame
> scatter
> security keep-crc
> rx offload active: ipv4-cksum
> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum
> sctp-cksum
> tcp-tso macsec-insert multi-segs security
> tx offload active: none
> rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex
> ipv6-tcp
> ipv6-udp ipv6-ex ipv6
> rss active: none
> tx burst function: (nil)
> rx burst function: ixgbe_recv_pkts_vec
>
> extended stats:
> mac local errors 318
> vpp#
>
>
>
> However, the testpmd tool shows it is up.
>
>
>
> testpmd> show port summary 1
> Number of available ports: 2
> Port MAC Address Name Driver Status Link
> *1 B4:96:91:23:1E:D6 0000:06:00.1 net_ixgbe up 10000Mbps*
> testpmd>
>
>
>
> Does this prove something wrong on vpp side?
>
>
>
> Thanks.
>
> Chuan
>
>
>
> On Fri, Oct 18, 2019 at 3:06 PM Chuan Han <chuan...@google.com> wrote:
>
> I built testpmd binary on both r740 and r230, and ran the test. I did see
> testpmd reports some link status change on r230 server. testpmd report on
> r740 is stabler. no status change reported.
>
>
>
> r230 log
>
> ================================
>
> Press enter to exit
>
> Port 0: link state change event
>
> Port 1: link state change event
>
> Port 1: link state change event
>
> r740 log
>
> ================================
>
> Press enter to exitx0 - TX RS bit threshold=32
>
> If it is a dpdk bug, what shall I do? Report to dpdk mailing list?
>
>
>
> On Fri, Oct 18, 2019 at 11:55 AM Chuan Han via Lists.Fd.Io <chuanhan=
> google....@lists.fd.io> wrote:
>
> So, it is a dpdk bug?
>
>
>
> I am new to dpdk/vpp.
>
>
>
> How do I run dpdk testpmd? Shall I install dpdk separately on the r230
> server? Are there any steps to follow?
>
>
>
> On Fri, Oct 18, 2019 at 10:30 AM Damjan Marion <dmar...@me.com> wrote:
>
> In this case we are purely relying on link state provided by DPDK.
>
> Have you tried to check if same problem exists with DPDK testpmd app?
>
>
>
>
>
> On 18 Oct 2019, at 10:26, Chuan Han via Lists.Fd.Io <
> chuanhan=google....@lists.fd.io> wrote:
>
>
>
> I cleaned up startup config a bit. I can still see eth0 down.
>
>
>
> See attachment for config file and log. There are some errors in log, but
> I am not sure they are worrisome or not.
>
>
>
> On Thu, Oct 17, 2019 at 5:22 PM Florin Coras <fcoras.li...@gmail.com>
> wrote:
>
> This looks like a DPDK issue, but I’ll let Damjan be the judge of that.
>
>
>
> To see if this is a config issues, could you simplify your startup config
> by
>
> - removing “workers 0” from the two nics and adding “num-rx-queues 2” to
> the nics or to the default stanza, if you’re running with 2 workers
>
> - comment out the cryptodev config
>
>
>
> If the two nics don’t come up, check if there’s any obvious dpdk error in
> “show log”.
>
>
>
> Florin
>
>
>
> On Oct 17, 2019, at 4:56 PM, Chuan Han via Lists.Fd.Io
> <http://lists.fd.io/> <chuanhan=google....@lists.fd.io> wrote:
>
>
>
> I tried disabling autoneg on R740 side. It is not allowed too. If vpp
> cannot allow two nics to be successfully added to the same vpp instance, it
> seems to be a bug. Is it something which can be easily spotted in the code
> base?
>
>
>
> It is also not possible to enforce symmetricity on internet. The other
> party can do anything as long as basic ping works.
>
>
>
> On Thu, Oct 17, 2019 at 3:55 PM Chuan Han <chuan...@google.com> wrote:
>
> If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is
> up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems
> something is wrong with the nic or vpp does not support this type of
> hardware?
>
>
>
> We tried enabling autoneg on R230. It is not allowed. To avoid asymmetric
> settings, disabling autoneg on R740 will help?
>
>
>
> On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) <
> bala...@cisco.com> wrote:
>
> It plays a role if it is asymmetric at both ends. You could enable it at
> both ends and check.
>
>
>
> On Oct 17, 2019, at 3:15 PM, Chuan Han <chuan...@google.com> wrote:
>
> I rebooted the r230 machine and found the phy nic corresponding to eth has
> autoneg off.
>
>
>
> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1
> Settings for enp6s0f1:
> Supported ports: [ FIBRE ]
> Supported link modes: 10000baseT/Full
> Supported pause frame use: Symmetric
> Supports auto-negotiation: No
> Supported FEC modes: Not reported
> Advertised link modes: 10000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: No
> Advertised FEC modes: Not reported
> Speed: 10000Mb/s
> Duplex: Full
> * Port: Direct Attach Copper*
> PHYAD: 0
> Transceiver: internal
> * Auto-negotiation: off*
> Supports Wake-on: d
> Wake-on: d
> Current message level: 0x00000007 (7)
> drv probe link
> Link detected: yes
> root@esdn-relay:~/gnxi/perf_testing/r230#
>
>
>
> On r740, autoneg is on. It is copper.
>
>
>
> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3
> Settings for eno3:
> Supported ports: [ TP ]
> Supported link modes: 100baseT/Full
> 1000baseT/Full
> 10000baseT/Full
> Supported pause frame use: Symmetric
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 100baseT/Full
> 1000baseT/Full
> 10000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Speed: 10000Mb/s
> Duplex: Full
> * Port: Twisted Pair*
> PHYAD: 0
> Transceiver: internal
> * Auto-negotiation: on*
> MDI-X: Unknown
> Supports Wake-on: umbg
> Wake-on: g
> Current message level: 0x00000007 (7)
> drv probe link
> Link detected: yes
> root@esdn-lab:~/gnxi/perf_testing/r740/vpp#
>
>
>
> not clear if this plays a role or not.
>
>
>
> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io
> <http://lists.fd.io/> <chuanhan=google....@lists.fd.io> wrote:
>
> Restarting ixia controller does not help. We ended up with both ixia ports
> having '!'.
>
>
>
> We are not sure how ixia port plays a role here. eth0 interfaces are the
> interfaces connecting two servers, not to ixia.
>
>
>
> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) <
> bala...@cisco.com> wrote:
>
> Hi Chuan,
>
>
>
> Could you please try to reset the ixia controller connected to port 4?
>
> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I
> suspect the ixia port.
>
>
>
> --
>
> Regards,
>
> Balaji.
>
>
>
>
>
> *From: *Chuan Han <chuan...@google.com>
> *Date: *Thursday, October 17, 2019 at 11:09 AM
> *To: *"Balaji Venkatraman (balajiv)" <bala...@cisco.com>
> *Cc: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Arivudainambi Appachi
> gounder <aappa...@google.com>, Jerry Cen <zhiw...@google.com>
> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work
>
>
>
> Yes. It is unidirectional stream from port 1 to port 4.
>
>
>
> Another engineer, Nambi, configured ixia. What he showed me yesterday is
> that xia port connected to port 1 is green and good. ixia port connected to
> port 4 is green but has a red exclamation mark, which means ping does not
> work.
>
>
>
> We also found eth0 on R230 is down shown by "show hardware eth0" command.
> However "show int" shows it is up.
>
>
>
>
>
> vpp# sh hardware-interfaces eth0
> Name Idx Link Hardware
> eth0 2 down eth0
> Link speed: unknown
> Ethernet address b4:96:91:23:1e:d6
> Intel 82599
> carrier down
> flags: admin-up promisc pmd rx-ip4-cksum
> rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8)
> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
> pci: device 8086:154d subsystem 8086:7b11 address 0000:06:00.01 numa 0
> max rx packet len: 15872
> promiscuous: unicast on all-multicast on
> vlan offload: strip off filter off qinq off
> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
> macsec-strip vlan-filter vlan-extend jumbo-frame
> scatter
> security keep-crc
> rx offload active: ipv4-cksum
> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum
> sctp-cksum
> tcp-tso macsec-insert multi-segs security
> tx offload active: none
> rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex
> ipv6-tcp
> ipv6-udp ipv6-ex ipv6
> rss active: none
> tx burst function: (nil)
> rx burst function: ixgbe_recv_pkts_vec
>
> rx frames ok 33278
> rx bytes ok 3960082
> extended stats:
> rx good packets 33278
> rx good bytes 3960082
> rx q0packets 33278
> rx q0bytes 3960082
> rx size 65 to 127 packets 33278
> rx multicast packets 33278
> rx total packets 33278
> rx total bytes 3960082
> vpp# sh int
> Name Idx State MTU (L3/IP4/IP6/MPLS)
> Counter Count
> eth0 2 up 9000/0/0/0 rx
> packets 33279
> rx
> bytes 3960201
> drops
> 5
> punt
> 1
>
> tx-error 33274
> eth1 1 up 9000/0/0/0 rx
> packets 33274
> rx
> bytes 3959606
> tx
> packets 33273
> tx
> bytes 3959487
> drops
> 33274
>
> tx-error 3
> local0 0 down 0/0/0/0
> vpp#
>
>
>
> On Thu, Oct 17, 2019 at 10:54 AM Balaji Venkatraman (balajiv) <
> bala...@cisco.com> wrote:
>
> Hi Chuan,
>
>
>
> I assume u have unidirectional stream ? ixia->1->2->3->4->ixia?
>
>
>
> vpp# sh int
> Name Idx State MTU (L3/IP4/IP6/MPLS)
> Counter Count
> eth0 2 up 9000/0/0/0 rx
> packets 30925
> rx
> bytes 3680075
> drops
> 5
> punt
> 1
>
> tx-error 30920
> eth1 1 up 9000/0/0/0 rx
> packets 30920 <<< packets are received on port 3
> rx
> bytes 3679480
> tx
> packets 30919
> tx
> bytes 3679361
> drops
> 30920 <<< all dropped at port 3
>
> tx-error 3
> local0 0 down 0/0/0/0
>
>
>
> On sh error logs on R 230 we see
>
> 1 ethernet-input l3 mac mismatch <<<<
> 3 eth1-output interface is down
> 30922 eth0-output interface is down
>
>
>
>
>
> Do u see the arp getting resolved on ixia? The mac on ixia at port with
> 172.16.1.2/24 should be seen on its other port. Are the ixia ports up at
> both ends?
>
>
>
>
>
> --
>
> Regards,
>
> Balaji.
>
>
>
>
>
> *From: *<vpp-dev@lists.fd.io> on behalf of "Chuan Han via Lists.Fd.Io
> <http://lists.fd.io/>" <chuanhan=google....@lists.fd.io>
> *Reply-To: *"chuan...@google.com" <chuan...@google.com>
> *Date: *Thursday, October 17, 2019 at 9:59 AM
> *To: *"Balaji Venkatraman (balajiv)" <bala...@cisco.com>
> *Cc: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work
>
>
>
> It seems R740 vpp works fine. All packets coming from port 1 go to port 2.
>
>
>
> vpp# sh int
> Name Idx State MTU (L3/IP4/IP6/MPLS)
> Counter Count
> eth0 2 up 9000/0/0/0 tx
> packets 30895
> tx
> bytes 3676505
> eth1 1 up 9000/0/0/0 rx
> packets 30895
> rx
> bytes 3676505
> local0 0 down 0/0/0/0
> vpp# sh int
> Name Idx State MTU (L3/IP4/IP6/MPLS)
> Counter Count
> eth0 2 up 9000/0/0/0 tx
> packets 30897
> tx
> bytes 3676743
> eth1 1 up 9000/0/0/0 rx
> packets 30897
> rx
> bytes 3676743
> local0 0 down 0/0/0/0
> vpp# sh error
> Count Node Reason
> 30899 l2-output L2 output packets
> 30899 l2-learn L2 learn packets
> 1 l2-learn L2 learn misses
> 30899 l2-input L2 input packets
> 30899 l2-flood L2 flood packets
> vpp#
>
>
>
> The drop happened on R230 vpp. Port 3 dropped all pkts complaining about
> down interface. However, show command shows interfaces are up.
>
>
>
> vpp# sh int
> Name Idx State MTU (L3/IP4/IP6/MPLS)
> Counter Count
> eth0 2 up 9000/0/0/0 rx
> packets 30925
> rx
> bytes 3680075
> drops
> 5
> punt
> 1
>
> tx-error 30920
> eth1 1 up 9000/0/0/0 rx
> packets 30920
> rx
> bytes 3679480
> tx
> packets 30919
> tx
> bytes 3679361
> drops
> 30920
>
> tx-error 3
> local0 0 down 0/0/0/0
> vpp# sh error
> Count Node Reason
> 2 llc-input unknown llc ssap/dsap
> 61846 l2-output L2 output packets
> 61846 l2-learn L2 learn packets
> 2 l2-learn L2 learn misses
> 61846 l2-input L2 input packets
> 61846 l2-flood L2 flood packets
> 1 ethernet-input l3 mac mismatch
> 3 eth1-output interface is down
> 30922 eth0-output interface is down
> vpp#
>
>
>
> Not sure how to check mac issues. Can you explain a bit more? Here is what
> I can see on R230 vpp.
>
>
>
> vpp# show bridge-domain 1 detail
> BD-ID Index BSN Age(min) Learning U-Forwrd UU-Flood Flooding
> ARP-Term arp-ufwd BVI-Intf
> 1 1 0 off on on flood on
> off off N/A
>
> Interface If-idx ISN SHG BVI TxFlood
> VLAN-Tag-Rewrite
> eth0 2 1 0 - *
> none
> eth1 1 1 0 - *
> none
> vpp# sh l2fib verbose
> Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter bvi
> Interface-Name
> 28:99:3a:f4:3a:a6 1 2 0/1 - - - -
> eth0
> 28:99:3a:f4:3a:9c 1 1 0/1 - - - -
> eth1
> L2FIB total/learned entries: 2/2 Last scan time: 0.0000e0sec Learn
> limit: 4194304
> vpp#
>
>
>
> On Wed, Oct 16, 2019 at 6:01 PM Balaji Venkatraman (balajiv) <
> bala...@cisco.com> wrote:
>
> +-------------------------------------------------------------------------+
>
> | |
>
> | |
>
> | IXIA |
>
> | |
>
> | |
>
> +-----------------------------------------------------------^-------------+
>
> |172.16.1.1/24 |172.16.1.2/24
>
> | |
>
> | |
>
> |eth0 | eth0
>
> +-----------v-------------+ +------------+-----------+
>
> | 1 | | 4 |
>
> | | | |
>
> | | | |
>
> | | | |
>
> | |eth1 eth1 | |
>
> | VPP1 2 +--------------------> 3 VPP 2 |
>
> | | | |
>
> | | | |
>
> | | | |
>
> | | | |
>
> +-------------------------+ +------------------------+
>
> R 740 R 230
>
>
>
>
>
> Might help if you could check if the packet counts at ingress (port 1) &
> egress (port 2) match. Similarly 3 & 4. And the mac entries seen on both
> vpp(s). ARP req/rep tracing might also help.
>
>
>
>
>
> /-
>
> Balaji
>
>
>
>
>
>
>
>
>
> *From: *<vpp-dev@lists.fd.io> on behalf of "Damjan Marion via Lists.Fd.Io
> <http://lists.fd.io/>" <dmarion=me....@lists.fd.io>
> *Reply-To: *"dmar...@me.com" <dmar...@me.com>
> *Date: *Wednesday, October 16, 2019 at 5:12 PM
> *To: *"chuan...@google.com" <chuan...@google.com>
> *Cc: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work
>
>
>
>
>
> On 16 Oct 2019, at 16:14, Chuan Han via Lists.Fd.Io <http://lists.fd.io/>
> <chuanhan=google....@lists.fd.io> wrote:
>
>
>
> Hi, vpp experts,
>
>
>
> We are trying to make basic l2 bridge works within vpp.
>
>
>
> We have two servers: r230 and r740, each of which has two phy nics. Two
> servers are connected via cable. On each server, we bring these two nics
> into the same vpp instance and put them into the same l2 bridge. We tried
> sending traffic using ixia. However, ixia shows ping does not work.
>
>
>
> I attached the topology, vpp conf files, startup conf file, and logs.
>
>
>
> Please advise where we could make it wrong.
>
>
>
> Thanks.
>
> Chuan
>
> <r230 vpp.conf><r740 vpp.conf><r230 vpp startup.cfg><r740 vpp
> startup.cfg><r740.log><r230.log><vpp testbed -
> bridge.pdf>-=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14189): https://lists.fd.io/g/vpp-dev/message/14189
> Mute This Topic: https://lists.fd.io/mt/34655826/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> On the 1st look everything look ok including the packet trace.
>
> Can you try to clear counters* and enable packet trace on both instances.
>
> Then send known number of packets and find put where drop happens by
> looking into same outputs you already shared.....
>
>
>
> * "clear int", "clear run", "clear trace"
>
>
>
> --
> Damjan
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14211): https://lists.fd.io/g/vpp-dev/message/14211
> Mute This Topic: https://lists.fd.io/mt/34655826/1991531
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [chuan...@google.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14219): https://lists.fd.io/g/vpp-dev/message/14219
> Mute This Topic: https://lists.fd.io/mt/34655826/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> <log><vpp startup.conf>-=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14240): https://lists.fd.io/g/vpp-dev/message/14240
> Mute This Topic: https://lists.fd.io/mt/34655826/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> --
> Damjan
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14243): https://lists.fd.io/g/vpp-dev/message/14243
> Mute This Topic: https://lists.fd.io/mt/34655826/1991531
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [chuan...@google.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14250): https://lists.fd.io/g/vpp-dev/message/14250
Mute This Topic: https://lists.fd.io/mt/34655826/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
