Thanks Damjan and Nikhil for your time.

I also find below logs via dmesg (Intel X710/XL710 )

[root@bfs-dl360g10-25 vpp]# uname -a
Linux bfs-dl360g10-25 3.10.0-957.5.1.el7.x86_64 #1 SMP Wed Dec 19 10:46:58
EST 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@bfs-dl360g10-25 vpp]# uname -r
3.10.0-957.5.1.el7.x86_64


Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: DRHD: handling fault status
reg 400
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: DRHD: handling fault status
reg 402
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: [DMA Read] Request device
[12:00.0] fault addr 5ec7f31000 [fault reason 06] PTE Read access is not set
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: DRHD: handling fault status
reg 502
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: [DMA Read] Request device
[12:00.0] fault addr 5ec8040000 [fault reason 06] PTE Read access is not set
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: [DMA Read] Request device
[12:00.0] fault addr 5ec53be000 [fault reason 06] PTE Read access is not set
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: DRHD: handling fault status
reg 700
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: DRHD: handling fault status
reg 702
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: [DMA Read] Request device
[12:00.0] fault addr 5ec6f24000 [fault reason 06] PTE Read access is not set
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: [DMA Write] Request device
[12:00.0] fault addr 5ec60eb000 [fault reason 05] PTE Write access is not
set
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: [DMA Write] Request device
[12:00.0] fault addr 5ec6684000 [fault reason 05] PTE Write access is not
set
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: [DMA Write] Request device
[12:00.0] fault addr 5ec607d000 [fault reason 05] PTE Write access is not
set
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: DRHD: handling fault status
reg 300
Feb 17 10:38:46 bfs-dl360g10-05 kernel: DMAR: DRHD: handling fault status
reg 302

Thanks,
Chetan

On Mon, Feb 17, 2020 at 3:47 PM Damjan Marion <dmar...@me.com> wrote:

>
> Dear Nitin,
>
> if you read Chetan’s email bellow, you will see that this one is already
> excluded…
>
> Also, it will not be easy to explain how this patch blows tx function in
> dpdk mlx5 pmd…
>
> —
> Damjan
>
> > On 17 Feb 2020, at 11:12, Nitin Saxena <nsax...@marvell.com> wrote:
> >
> > Hi Prashant/Chetan,
> >
> > I would try following change first to solve the problem in 1908
> >
> > commit b6e8b1a7c8bf9f9fbd05cdc3c90111d9e7a6897b
> > Author: Damjan Marion <damar...@cisco.com>
> > Date:   Tue Mar 12 18:14:15 2019 +0100
> >
> >     vlib: don't use vector for keeping buffer indices in
> >
> >     Type: refactor
> >
> >     Change-Id: I72221b97d7e0bf5c93e20bbda4473ca67bfcdeb4
> >     Signed-off-by: Damjan Marion damar...@cisco.com
> >
> > You can also try copying src/plugins/dpdk/buffer.c from stable/2001
> branch to stable/1908
> >
> > Thanks,
> > Nitin
> >
> > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Damjan
> Marion via Lists.Fd.Io
> > Sent: Monday, February 17, 2020 1:52 PM
> > To: chetan bhasin <chetan.bhasin...@gmail.com>
> > Cc: vpp-dev@lists.fd.io
> > Subject: [EXT] Re: [vpp-dev] Regarding buffers-per-numa parameter
> >
> > External Email
> >
> > On 17 Feb 2020, at 07:37, chetan bhasin <chetan.bhasin...@gmail.com>
> wrote:
> >
> > Bottom line is stable/vpp 908 does not work with higher number of
> buffers but stable/vpp2001 does. Could you please advise which area we can
> look at ,as it would be difficult for us to move to vpp2001 at this time.
> >
> > I really don’t have idea what caused this problem to disappear.
> > You may try to use “git bisect” to find out which commit fixed it….
> >
> > —
> > Damjan
> >
> >
> >
> > On Mon, Feb 17, 2020 at 11:01 AM chetan bhasin via Lists.Fd.Io
> <chetan.bhasin017=gmail....@lists.fd.io> wrote:
> > Thanks Damjan for the reply!
> >
> > Following are my observations on Intel X710/XL710 pci-
> > 1) I took latest code base from stable/vpp19.08  : Seeing error as "
> ethernet-input             l3 mac mismatch"
> >                         With Buffers 537600
> > vpp# show buffers
>                                                        |
> > Pool Name            Index NUMA  Size  Data Size  Total  Avail  Cached
>  Used
> > default-numa-0         0     0   2496     2048   537600 510464   1319
> 25817
> > default-numa-1         1     1   2496     2048   537600 528896    390
> 8314
> >
> > vpp# show hardware-interfaces
> >               Name                Idx   Link  Hardware
> > BondEthernet0                      3     up   BondEthernet0
> >   Link speed: unknown
> >   Ethernet address 3c:fd:fe:b5:5e:40
> > FortyGigabitEthernet12/0/0         1     up   FortyGigabitEthernet12/0/0
> >   Link speed: 40 Gbps
> >   Ethernet address 3c:fd:fe:b5:5e:40
> >   Intel X710/XL710 Family
> >     carrier up full duplex mtu 9206
> >     flags: admin-up pmd rx-ip4-cksum
> >     rx: queues 16 (max 320), desc 1024 (min 64 max 4096 align 32)
> >     tx: queues 16 (max 320), desc 4096 (min 64 max 4096 align 32)
> >     pci: device 8086:1583 subsystem 8086:0001 address 0000:12:00.00 numa
> 0
> >     max rx packet len: 9728
> >     promiscuous: unicast off all-multicast on
> >     vlan offload: strip off filter off qinq off
> >     rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum
> qinq-strip
> >                        outer-ipv4-cksum vlan-filter vlan-extend
> jumbo-frame
> >                        scatter keep-crc
> >     rx offload active: ipv4-cksum
> >     tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum
> sctp-cksum
> >                        tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
> >                        gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
> >                        mbuf-fast-free
> >     tx offload active: none
> >     rss avail:         ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other
> ipv6-frag
> >                        ipv6-tcp ipv6-udp ipv6-sctp ipv6-other l2-payload
> >     rss active:        ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv6-frag
> ipv6-tcp
> >                        ipv6-udp ipv6-other
> >     tx burst function: i40e_xmit_pkts_vec_avx2
> >     rx burst function: i40e_recv_pkts_vec_avx2
> >     tx errors                                             17
> >     rx frames ok                                        4585
> >     rx bytes ok                                       391078
> >     extended stats:
> >       rx good packets                                   4585
> >       rx good bytes                                   391078
> >       tx errors                                           17
> >       rx multicast packets                              4345
> >       rx broadcast packets                               243
> >       rx unknown protocol packets                       4588
> >       rx size 65 to 127 packets                         4529
> >       rx size 128 to 255 packets                          32
> >       rx size 256 to 511 packets                          26
> >       rx size 1024 to 1522 packets                         1
> >       tx size 65 to 127 packets                           33
> > FortyGigabitEthernet12/0/1         2     up   FortyGigabitEthernet12/0/1
> >   Link speed: 40 Gbps
> >   Ethernet address 3c:fd:fe:b5:5e:40
> >   Intel X710/XL710 Family
> >     carrier up full duplex mtu 9206
> >     flags: admin-up pmd rx-ip4-cksum
> >     rx: queues 16 (max 320), desc 1024 (min 64 max 4096 align 32)
> >     tx: queues 16 (max 320), desc 4096 (min 64 max 4096 align 32)
> >     pci: device 8086:1583 subsystem 8086:0000 address 0000:12:00.01 numa
> 0
> >     max rx packet len: 9728
> >     promiscuous: unicast off all-multicast on
> >     vlan offload: strip off filter off qinq off
> >     rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum
> qinq-strip
> >                        outer-ipv4-cksum vlan-filter vlan-extend
> jumbo-frame
> >                        scatter keep-crc
> >     rx offload active: ipv4-cksum
> >     tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum
> sctp-cksum
> >                        tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
> >                        gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
> >                        mbuf-fast-free
> >     tx offload active: none
> >     rss avail:         ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other
> ipv6-frag
> >                        ipv6-tcp ipv6-udp ipv6-sctp ipv6-other l2-payload
> >     rss active:        ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv6-frag
> ipv6-tcp
> >                        ipv6-udp ipv6-other
> >     tx burst function: i40e_xmit_pkts_vec_avx2
> >     rx burst function: i40e_recv_pkts_vec_avx2
> >     rx frames ok                                        4585
> >     rx bytes ok                                       391078
> >     extended stats:
> >       rx good packets                                   4585
> >       rx good bytes                                   391078
> >       rx multicast packets                              4344
> >       rx broadcast packets                               243
> >       rx unknown protocol packets                       4587
>                                                         |
> >       rx size 65 to 127 packets                         4528
> >       rx size 128 to 255 packets                          32
> >       rx size 256 to 511 packets                          26
> >       rx size 1024 to 1522 packets                         1
> >       tx size 65 to 127 packets                           33
> >
> >
> > As per packet trace -
> > Packet 4
> > 00:00:54:955863: dpdk-input
> >   FortyGigabitEthernet12/0/0 rx queue 0
> >   buffer 0x13fc728: current data 0, length 68, buffer-pool 0, ref-count
> 1, totlen-nifb 0, trace handle 0x1000003
> >                     ext-hdr-valid
>                                                        |
> >                     l4-cksum-computed l4-cksum-correct
> >   PKT MBUF: port 0, nb_segs 1, pkt_len 68
> >     buf_len 2176, data_len 68, ol_flags 0x180, data_off 128, phys_addr
> 0xde91ca80
> >     packet_type 0x1 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
> >   0x0000: 00:00:00:00:00:00 -> 00:00:00:00:00:00
> > 00:00:54:955864: bond-input
> >   src 00:00:00:00:00:00, dst 00:00:00:00:00:00,
> FortyGigabitEthernet12/0/0 -> BondEthernet0
> > 00:00:54:955864: ethernet-input
> >   0x0000: 00:00:00:00:00:00 -> 00:00:00:00:00:00
> > 00:00:54:955865: error-drop
> >   rx:BondEthernet0
> > 00:00:54:955865: drop
> >   ethernet-input: l3 mac mismatch
> >
> > 2) I have took latest code-base from stable/vpp2001 branch: Everything
> looks fine with  Buffers 537600
> >
> > 3) I took previous commit of  "vlib: don't use vector for keeping buffer
> indices in the pool " ie "df0191ead2cf39611714b6603cdc5bdddc445b57" :
> Everything looks fine with Buffers 537600.
> > So this cleary shows the above commit will not fix our problem.
> >
> >
> >
> > Thanks,
> > Chetan
> >
> > On Wed, Feb 12, 2020 at 9:07 PM Damjan Marion <dmar...@me.com> wrote:
> >
> > Shouldn’t be too hard to checkout commit prior to that one and test if
> problem is still there…
> >
> > —
> > Damjan
> >
> >
> >
> > On 12 Feb 2020, at 14:50, chetan bhasin <chetan.bhasin...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > Looking into the changes in vpp 20.1 , the below change looks good
> important related to buffer indices .
> >
> > vlib: don't use vector for keeping buffer indices in the pool
> > Type: refactor
> >
> > Change-Id: I72221b97d7e0bf5c93e20bbda4473ca67bfcdeb4
> > Signed-off-by: Damjan Marion <damar...@cisco.com>
> >
> >
> https://github.com/FDio/vpp/commit/b6e8b1a7c8bf9f9fbd05cdc3c90111d9e7a6897b#diff-2260a8080303fbcc30ef32f782b4d6df
> >
> > Can anybody suggest  ?
> > Shouldn’t be too hard to checkout commit prior to that one and test if
> problem is still there…
> >
> > —
> > Damjan
> >
> >
> >
> > 
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Reply via email to