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] [day] [month] [year] [list]

Message-ID: <f11d1ff2-b16b-37d3-0e17-4a051c29a9b5@gmail.com>
Date:   Mon, 4 May 2020 17:04:21 -0600
From:   David Ahern <dsahern@...il.com>
To:     Saeed Mahameed <saeedm@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: max channels for mlx5

On 5/4/20 3:46 PM, Saeed Mahameed wrote:
> 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

64

> 
> So if number of msix is 64, we can only use 63 for data path
> completions .. 
> 
> do you have sriov enabled ? 

no

> 
> what is the FW version you have ?

$ ethtool -i eth0
driver: mlx5_core
version: 5.0-0
firmware-version: 14.27.1016 (MT_2420110034)

> 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

Understood for port to port redirect.

This use case is a virtual machine with a tap device + vhost bypassing
host kernel stack and redirecting to a port. Losing a third of the cpus
for vhost threads is a huge limitation.