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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 16 Jan 2023 16:23:56 +0200
From:   Shay Agroskin <shayagr@...zon.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Gal Pressman <gal@...dia.com>,
        "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>,
        "Bernstein, Amit" <amitbern@...zon.com>
Subject: Re: [PATCH V1 net-next 0/5] Add devlink support to ena


Jakub Kicinski <kuba@...nel.org> writes:

> 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.
>
> Hence my preference to expose it as a new tx_push_buf_len, 
> combining
> the semantics of tx_push and rx_buf_len.

We'll proceed with working on and RFC that adds the new param to 
ethtool.

Going forward, can I ask what's the community's stand on adding 
sysfs or procfse entries to the driver as means to tweak custom 
device attributes ?

Thanks,
Shay