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]

Message-ID: <20230112115613.0a33f6c4@kernel.org>
Date:   Thu, 12 Jan 2023 11:56:13 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shay Agroskin <shayagr@...zon.com>
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>
Subject: Re: [PATCH V1 net-next 0/5] Add devlink support to ena

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.