netdev - Re: [PATCH net-next 2/2] net/mlx5e: Query minimum required header copy during xmit

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:	Thu, 21 Jul 2016 19:26:35 +0300
From:	Saeed Mahameed <saeedm@....mellanox.co.il>
To:	David Miller <davem@...emloft.net>
Cc:	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Hadar Har-Zion <hadarh@...lanox.com>
Subject: Re: [PATCH net-next 2/2] net/mlx5e: Query minimum required header
 copy during xmit

On Thu, Jul 21, 2016 at 7:15 PM, David Miller <davem@...emloft.net> wrote:
> From: Saeed Mahameed <saeedm@....mellanox.co.il>
> Date: Thu, 21 Jul 2016 11:22:32 +0300
>
>> On Thu, Jul 21, 2016 at 8:15 AM, Alexei Starovoitov
>> <alexei.starovoitov@...il.com> wrote:
>>> On Thu, Jul 21, 2016 at 01:20:02AM +0300, Saeed Mahameed wrote:
>>>> From: Hadar Hen Zion <hadarh@...lanox.com>
>>>>
>>>> Add support for query the minimum inline mode from the Firmware.
>>>> It is required for correct TX steering according to L3/L4 packet
>>>> headers.
>>>>
>>>> Each send queue (SQ) has inline mode that defines the minimal required
>>>> headers that needs to be copied into the SQ WQE.
>>>> The driver asks the Firmware for the wqe_inline_mode device capability
>>>> value.  In case the device capability defined as "vport context" the
>>>> driver must check the reported min inline mode from the vport context
>>>> before creating its SQs.
>>>>
>>>> Signed-off-by: Hadar Hen Zion <hadarh@...lanox.com>
>>>> Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>
>>> ...
>>>> +     int outlen = MLX5_ST_SZ_BYTES(query_nic_vport_context_out);
>>>> +     u32 *out;
>>>> +
>>>> +     out = mlx5_vzalloc(outlen);
>>>> +     if (!out)
>>>> +             return;
>>>
>>> Just discovered this...
>>> outlen is a small constant here, yet you want to try to vmalloc it?
>>> What is the point?
>>> There are 67 places in mlx5 where failed kmalloc is retried with
>>> vmalloc... was that path ever tested?
>>
>> The point is that there are a lot of places in the code that want to
>> allocate huge commands and mlx5_vzalloc is a nice black box that
>> provides the method to allocate such huge chunks of memory.
>
> If it's a "black box" then don't mention that it uses vmalloc in the
> function name.

Right, mlx5_zalloc would make a better name, I will change this in a
future refactoring patch.
but how is this related to this series ?

I am already working on a series for next kernel release to improve
mlx5 command interface, command layout allocation/filling and
execution.
I will be glad to listen to any suggestion you have regarding using
mlx5_vzalloc for small buffers allocation ..

Thanks,
Saeed.