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: <98e54fb7-febd-7d7a-0e6c-308b4203d221@mellanox.com>
Date:   Tue, 24 Oct 2017 09:28:56 +0300
From:   Alex Vesker <valex@...lanox.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        Saeed Mahameed <saeedm@...lanox.com>
CC:     "David S. Miller" <davem@...emloft.net>,
        Doug Ledford <dledford@...hat.com>, <netdev@...r.kernel.org>,
        <linux-rdma@...r.kernel.org>, Leon Romanovsky <leonro@...lanox.com>
Subject: Re: [for-next 08/12] net/mlx5e: IPoIB, Use hash-table to map between
 QPN to child netdev



On 10/23/2017 6:47 PM, Jason Gunthorpe wrote:
> On Sat, Oct 14, 2017 at 11:48:23AM -0700, Saeed Mahameed wrote:
>> From: Alex Vesker <valex@...lanox.com>
>>
>> This change is needed for PKEY support, since the RQs are shared
>> between the child interface and the parent. The parent is responsible
>> for NAPI and the precessing of RX completions. Using the dqpn in the
>> completion descriptor we set the corresponding child IPoIB netdevice
>> on the SKB.
>> The mapping between the dqpn and the netdevice is done using a HT,
>> each mlx5 IPoIB interface registers its mapping on creation.
> It seems really really weird to share the receive Q across all of the
> children and do the sorting in software.. why is this done like this?
>
> Wouldn't it be better to allow the children to progress concurrently,
> potentially on multiple cores? They all have their own QPs after all..
>
> Jason
The child interface RQs are in minimum size since they are not used.
The reason for this is saving resources, since we want to be able to 
support many PKEYs
and allocating less memory while reusing HW resources such as flow 
steering table.
This solution allowed us save memory on allocating the RQs of the child 
and use the same
HW flow steering table, TIR, RQT. Using the hash table doesn't impact on 
performance.
The parent have multiple RQs on different cores running in parallel.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ