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: <20230117093115.03d3dc13@kernel.org>
Date:   Tue, 17 Jan 2023 09:31:15 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Gal Pressman <gal@...dia.com>
Cc:     Shay Agroskin <shayagr@...zon.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 Sun, 15 Jan 2023 12:05:33 +0200 Gal Pressman wrote:
> > 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?

Complete DMA buffers. Basically whether the optimization
only kicks in if skb->len < configured_len or 
skb_headlen() < configured_len.

> > 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?

We can decide either way, but I _think_ rx_buf_len refers to the size
as allocated, not necessarily usable size (in case the first buffer has
padding / headroom). But as long as we clearly document - either way is
fine.