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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
root@esdn-relay:~/dpdk/x86_64-native-linuxapp-gcc/app# ./testpmd
EAL: Detected 8 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: PCI device 0000:06:00.0 on NUMA socket -1
EAL: Invalid NUMA socket, default to 0
EAL: probe driver: 8086:154d net_ixgbe
EAL: PCI device 0000:06:00.1 on NUMA socket -1
EAL: Invalid NUMA socket, default to 0
EAL: probe driver: 8086:154d net_ixgbe
testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=203456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
Configuring Port 0 (socket 0)
Port 0: B4:96:91:23:1E:D4
Configuring Port 1 (socket 0)
Port 1: B4:96:91:23:1E:D6
Checking link statuses...
Done
No commandline core given, start packet forwarding
io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MP allocation mode: native
Logical Core 1 (socket 0) forwards packets on 2 streams:
RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01
RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00
io packet forwarding packets/burst=32
nb forwarding cores=1 - nb forwarding ports=2
port 0: RX queue number: 1 Tx queue number: 1
Rx offloads=0x0 Tx offloads=0x0
RX queue: 0
RX desc=256 - RX free threshold=32
RX threshold registers: pthresh=8 hthresh=8 wthresh=0
RX Offloads=0x0
TX queue: 0
TX desc=256 - TX free threshold=32
TX threshold registers: pthresh=32 hthresh=0 wthresh=0
TX offloads=0x0 - TX RS bit threshold=32
port 1: RX queue number: 1 Tx queue number: 1
Rx offloads=0x0 Tx offloads=0x0
RX queue: 0
RX desc=256 - RX free threshold=32
RX threshold registers: pthresh=8 hthresh=8 wthresh=0
RX Offloads=0x0
TX queue: 0
TX desc=256 - TX free threshold=32
TX threshold registers: pthresh=32 hthresh=0 wthresh=0
TX offloads=0x0 - TX RS bit threshold=32
Press enter to exit
Port 0: link state change event
Port 1: link state change event
Port 1: link state change event
root@esdn-lab:~/dpdk/x86_64-native-linuxapp-gcc/app# ./testpmd
EAL: Detected 96 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Probing VFIO support...
EAL: PCI device 0000:19:00.0 on NUMA socket 0
EAL: probe driver: 8086:1563 net_ixgbe
EAL: PCI device 0000:19:00.1 on NUMA socket 0
EAL: probe driver: 8086:1563 net_ixgbe
EAL: PCI device 0000:1a:00.0 on NUMA socket 0
EAL: probe driver: 8086:1563 net_ixgbe
EAL: PCI device 0000:1a:00.1 on NUMA socket 0
EAL: probe driver: 8086:1563 net_ixgbe
testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=907456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=907456, size=2176, socket=1
testpmd: preferred mempool ops selected: ring_mp_mc
Configuring Port 0 (socket 0)
Port 0: 24:6E:96:B4:B2:05
Configuring Port 1 (socket 0)
Port 1: 24:6E:96:B4:B2:06
Checking link statuses...
Done
No commandline core given, start packet forwarding
io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MP allocation mode: native
Logical Core 1 (socket 1) forwards packets on 2 streams:
RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01
RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00
io packet forwarding packets/burst=32
nb forwarding cores=1 - nb forwarding ports=2
port 0: RX queue number: 1 Tx queue number: 1
Rx offloads=0x0 Tx of[81459.659018] irq 209: nobody cared (try booting with the "irqpoll" option)
floads=0x0
[81459.666782] handlers:
[81459.670411] [<000000006be52f14>] uio_interrupt [uio]
[81459.675385] Disabling IRQ #209
RX queue: 0
RX desc=256 - RX free threshold=32
RX threshold registers: pthresh=8 hthresh=8 wthresh=0
RX Offloads=0x0
TX queue: 0
TX desc=256 - TX free threshold=32
TX threshold registers: pthresh=32 hthresh=0 wthresh=0
TX offloads=0x0 - TX RS bit threshold=32
port 1: RX queue number: 1 Tx queue number: 1
Rx offloads=0x0 Tx offloads=0x0
RX queue: 0
RX desc=256 - RX free threshold=32
RX threshold registers: pthresh=8 hthresh=8 wthresh=0
RX Offloads=0x0
TX queue: 0
TX desc=256 - TX free threshold=32
TX threshold registers: pthresh=32 hthresh=0 wthresh=0
Press enter to exitx0 - TX RS bit threshold=32
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14244): https://lists.fd.io/g/vpp-dev/message/14244
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]
-=-=-=-=-=-=-=-=-=-=-=-
