[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes

Xing, Beilei beilei.xing at intel.com
Fri Jul 22 11:04:46 CEST 2016


Hi Ceara,

> -----Original Message-----
> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
> Sent: Thursday, July 21, 2016 6:58 PM
> To: Xing, Beilei <beilei.xing at intel.com>
> Cc: Zhang, Helin <helin.zhang at intel.com>; Wu, Jingjing
> <jingjing.wu at intel.com>; dev at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710
> NICs for some RX mbuf sizes
> 
> 
> Following your testpmd example run I managed to replicate the problem on
> my dpdk 16.04 setup like this:
> 
> I have two X710 adapters connected back to back:
> $ ./tools/dpdk_nic_bind.py -s
> 
> Network devices using DPDK-compatible driver
> ============================================
> 0000:01:00.3 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio unused=
> 0000:81:00.3 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio unused=
> 
> The firmware of the two adapters is up to date with the latest
> version: 5.04 (f5.0.40043 a1.5 n5.04 e24cd)
> 
> I run testpmd with mbuf-size 1152 and txpktsize 1024 such that upon receival
> the whole mbuf (except headroom) is filled.
> I enabled RX IP checksum in hw and RX RSS hashing for UDP.
> With test-pmd forward mode "rxonly" and verbose 1 I see that incoming
> packets have PKT_RX_RSS_HASH set but the hash value is 0.
> 
> ./testpmd -c ffff1 -n 4 -w 0000:01:00.3 -w 0000:81:00.3 -- -i
> --coremask=0xffff0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 1024 --
> enable-rx-cksum --rss-udp [...]
> testpmd> set verbose 1
> Change verbose level from 0 to 1
> testpmd> set fwd rxonly
> Set rxonly packet forwarding mode
> testpmd> start tx_first
>   rxonly packet forwarding - CRC stripping disabled - packets/burst=32
>   nb forwarding cores=16 - nb forwarding ports=2
>   RX queues=16 - RX desc=128 - RX free threshold=32
>   RX threshold registers: pthresh=8 hthresh=8 wthresh=0
>   TX queues=16 - TX desc=512 - TX free threshold=32
>   TX threshold registers: pthresh=32 hthresh=0 wthresh=0
>   TX RS bit threshold=32 - TXQ flags=0xf01 port 0/queue 1: received 32
> packets
>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
> length=1024 - nb_segs=1 - RSS hash=0x0 - RSS queue=0x1 - (outer) L2
> type: ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN - (outer) L4 type: UDP
> - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 type:
> Unknown - Inner L4 type: Unknown
>  - Receive queue=0x1
>   PKT_RX_RSS_HASH
>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
> length=1024 - nb_segs=1 - RSS hash=0x0 - RSS queue=0x1 - (outer) L2
> type: ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN - (outer) L4 type: UDP
> - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 type:
> Unknown - Inner L4 type: Unknown
>  - Receive queue=0x1
>   PKT_RX_RSS_HASH

What's the source ip address and destination ip address of the packet you sent to port 0? Could you try to change ip address or port number to observe if hash value changes? I remember I saw hash value was 0 before, but with different ip address, there'll be different hash values. 

> 
> If I use a different mbuf-size, for example 2048, everything is fine:
> 
> ./testpmd -c ffff1 -n 4 -w 0000:01:00.3 -w 0000:81:00.3 -- -i
> --coremask=0xffff0 --rxq=16 --txq=16 --mbuf-size 2048 --txpkts 1024 --
> enable-rx-cksum --rss-udp [...]
> testpmd> set verbose 1
> Change verbose level from 0 to 1
> testpmd> set fwd rxonly
> Set rxonly packet forwarding mode
> testpmd> start tx_first
>   rxonly packet forwarding - CRC stripping disabled - packets/burst=32
>   nb forwarding cores=16 - nb forwarding ports=2
>   RX queues=16 - RX desc=128 - RX free threshold=32
>   RX threshold registers: pthresh=8 hthresh=8 wthresh=0
>   TX queues=16 - TX desc=512 - TX free threshold=32
>   TX threshold registers: pthresh=32 hthresh=0 wthresh=0
>   TX RS bit threshold=32 - TXQ flags=0xf01 port 0/queue 1: received 32
> packets
>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
> length=1024 - nb_segs=1 - RSS hash=0x5263c3f2 - RSS queue=0x1 -
> (outer) L2 type: ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN - (outer)
> L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner
> L3 type: Unknown - Inner L4 type: Unknown
>  - Receive queue=0x1
>   PKT_RX_RSS_HASH
> 

Did you send the same packet as before to port 0?

> Another weird thing I noticed is when I run test-pmd without --enable-rx-
> cksum (which is the default mode) then the RSS flag doesn get set at all.
> Instead the PKT_RX_FDIR flag gets set. This happens even though fdir_mode
> is set to RTE_FDIR_MODE_NONE in the device
> configuration:
> 
> ./testpmd -c ffff1 -n 4 -w 0000:01:00.3 -w 0000:81:00.3 -- -i
> --coremask=0xffff0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 1024 --rss-
> udp [...]
> testpmd> set verbose 1
> Change verbose level from 0 to 1
> testpmd> set fwd rxonly
> Set rxonly packet forwarding mode
> testpmd> start tx_first
>   rxonly packet forwarding - CRC stripping disabled - packets/burst=32
>   nb forwarding cores=16 - nb forwarding ports=2
>   RX queues=16 - RX desc=128 - RX free threshold=32
>   RX threshold registers: pthresh=8 hthresh=8 wthresh=0
>   TX queues=16 - TX desc=512 - TX free threshold=32
>   TX threshold registers: pthresh=32 hthresh=0 wthresh=0
>   TX RS bit threshold=32 - TXQ flags=0xf01 port 0/queue 1: received 16
> packets
>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
> length=1024 - nb_segs=2 - FDIR matched hash=0xc3f2 ID=0x5263 Unknown
> packet type
>  - Receive queue=0x1
>   PKT_RX_FDIR
>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
> length=1024 - nb_segs=2 - FDIR matched hash=0xc3f2 ID=0x5263 Unknown
> packet type
>  - Receive queue=0x1
>   PKT_RX_FDIR
> 

For this issue, I think following patch can solve your problem, please apply this patch.
http://dpdk.org/dev/patchwork/patch/13593/

Beilei

> Please let me know if there's more debug info that might be of interest in
> troubleshooting the RSS=0 issue.
> 
> Thanks,
> Dumitru
> 
> > /Beilei
> >
> >> Thanks,
> >> Dumitru
> >>


More information about the dev mailing list