netdev - Re: max channels for mlx5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 May 2020 21:46:13 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "dsahern@...il.com" <dsahern@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: max channels for mlx5

On Sun, 2020-05-03 at 18:41 -0600, David Ahern wrote:
> Hi Saeed:
> 
> When I saw this commit last year:
> 
> commit 57c7fce14b1ad512a42abe33cb721a2ea3520d4b
> Author: Fan Li <fanl@...lanox.com>
> Date:   Mon Dec 16 14:46:15 2019 +0200
> 
>     net/mlx5: Increase the max number of channels to 128
> 
> I was expecting to be able to increase the number of channels on
> larger
> systems (e.g., 96 cpus), but that is not working as I expected.
> 

this patch should help, unless you are limited by FW/system MSI-x .. 

what is the amount of msix avaiable for eth0 port ?

businfo=$(ethtool -i eth0 | grep bus-info | cut -d":" -f2-)
cat /proc/interrupts | grep $businfo | wc -l

> This is on net-next as of today:
>     60bcbc41ffb3 ("Merge branch 'net-smc-add-and-delete-link-
> processing'")
> 
> $ sudo ethtool -L eth0 combined 95
> Cannot set device channel parameters: Invalid argument
> 
> As it stands the maximum is 63 (or is it 64 and cpus 0-63?):
> $ sudo ethtool -l eth0
> Channel parameters for eth0:
> Pre-set maximums:
> RX:		0
> TX:		0
> Other:		0
> Combined:	63
> Current hardware settings:
> RX:		0
> TX:		0
> Other:		0
> Combined:	63
> 

So if number of msix is 64, we can only use 63 for data path
completions .. 

do you have sriov enabled ? 

what is the FW version you have ?
we need to figure out if this is a system MSIX limitation or a FW
limitation.

> A side effect of this limit is XDP_REDIRECT drops packets if a vhost
> thread gets scheduled on cpus 64 and up since the tx queue is based
> on
> processor id:
> 
> int mlx5e_xdp_xmit(struct net_device *dev, int n, struct xdp_frame
> **frames,
>                    u32 flags)
> {
> 	...
>         sq_num = smp_processor_id();
>         if (unlikely(sq_num >= priv->channels.num))
>                 return -ENXIO;
> 
> So in my example if the redirect happens on cpus 64-95, which is 1/3
> of
> my hardware threads, the packet is just dropped.
> 

Know XDP redirect issue,  you need to tune the RSS and affinity on RX
side and match TX count and affinity on TX side, so you won't end up on
a wrong CPU on the TX side
 
> Am I missing something about how to use the expanded maximum?
> 
> David