netdev - Re: [PATCH V1 net-next 0/5] Add devlink support to ena

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 for Android: free password hash cracker in your pocket

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

Message-ID: <157d3005-29a8-939e-f63a-784833dbf17b@nvidia.com>
Date:   Sun, 15 Jan 2023 12:05:33 +0200
From:   Gal Pressman <gal@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Shay Agroskin <shayagr@...zon.com>
Cc:     "Arinzon, David" <darinzon@...zon.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Machulsky, Zorik" <zorik@...zon.com>,
        "Matushevsky, Alexander" <matua@...zon.com>,
        "Bshara, Saeed" <saeedb@...zon.com>,
        "Bshara, Nafea" <nafea@...zon.com>,
        "Saidi, Ali" <alisaidi@...zon.com>,
        "Kiyanovski, Arthur" <akiyano@...zon.com>,
        "Dagan, Noam" <ndagan@...zon.com>,
        "Itzko, Shahar" <itzko@...zon.com>,
        "Abboud, Osama" <osamaabb@...zon.com>
Subject: Re: [PATCH V1 net-next 0/5] Add devlink support to ena

On 12/01/2023 21:56, Jakub Kicinski wrote:
> On Thu, 12 Jan 2023 15:47:13 +0200 Shay Agroskin wrote:
>> Gal Pressman <gal@...dia.com> writes:
>>> TX copybreak? When the user sets it to > 96 bytes, use the large 
>>> LLQ.
>>>
>>> BTW, shouldn't ethtool's tx_push reflect the fact that LLQs are 
>>> being
>>> used? I don't see it used in ena.  
>>
>> Using tx copybreak does sound like it can work for our use 
>> case. Thanks for the tip Gal (:
>>
>> Jakub, do you see an issue with utilizing tx_copybreak ethtool 
>> parameter instead of the devlink param in this patchset ?
> 
> IDK, the semantics don't feel close enough.
> 
> As a user I'd set tx_copybreak only on systems which have IOMMU enabled 
> (or otherwise have high cost of DMA mapping), to save CPU cycles.
> 
> The ena feature does not seem to be about CPU cycle saving (likely 
> the opposite, in fact), and does not operate on full segments AFAIU.

Segments?

> Hence my preference to expose it as a new tx_push_buf_len, combining
> the semantics of tx_push and rx_buf_len.

Sounds like a good idea.
To clarify, buf_len here refers to the size of the inline'd part, not
the WQE itself, correct? The driver will use whatever WQE size it needs
in order to accommodate the requested inline size?