netdev - Re: [PATCH net 0/2][pull request] Intel Wired LAN Driver Updates 2022-11-14 (i40e)

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: <Y3WAos0k3iGJ1R7n@boxer>
Date:   Thu, 17 Nov 2022 01:30:26 +0100
From:   Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To:     Vladimir Oltean <olteanv@...il.com>
CC:     Tony Nguyen <anthony.l.nguyen@...el.com>, <davem@...emloft.net>,
        <kuba@...nel.org>, <pabeni@...hat.com>, <edumazet@...gle.com>,
        <netdev@...r.kernel.org>, <magnus.karlsson@...el.com>,
        <ast@...nel.org>, <daniel@...earbox.net>, <hawk@...nel.org>,
        <john.fastabend@...il.com>, <bpf@...r.kernel.org>
Subject: Re: [PATCH net 0/2][pull request] Intel Wired LAN Driver Updates
 2022-11-14 (i40e)

On Thu, Nov 17, 2022 at 02:24:33AM +0200, Vladimir Oltean wrote:
> Hi Maciej,
> 
> On Thu, Nov 17, 2022 at 01:03:04AM +0100, Maciej Fijalkowski wrote:
> > Hey Vladimir,
> > 
> > have a look at xdp_convert_zc_to_xdp_frame() in net/core/xdp.c. For XDP_TX
> > on ZC Rx side we basically create new xdp_frame backed by new page and
> > copy the contents we had in ZC buffer. Then we give back the ZC buffer to
> > XSK buff pool and new xdp_frame has to be DMA mapped to HW.
> 
> Ah, ok, I didn't notice the xdp_convert_zc_to_xdp_frame() call inside
> xdp_convert_buff_to_frame(), it's quite well hidden...
> 
> So it's clear now from a correctness point of view, thanks for clarifying.
> This could spark a separate discussion about whether there is any better
> alternative to copying the RX buffer for XDP_TX and re-mapping to DMA
> something that was already mapped. But I'm not interested in that, since
> I believe who wrote the code probably thought about the high costs too.
> Anyway, I believe that in the general case (meaning from the perspective
> of the XSK API) it's perfectly fine to keep the RX buffer around for a
> while, nobody forces you to copy the frame out of it for XDP_TX.

I sort of agree but I will get back to you after getting some sleep.
Basically I am observing better perf when I decide not to convert buff to
frame for XDP_TX (in this case I'm referring to standard data path of
Intel drivers, not the ZC data path). For ZC I am thinking about
converting ZC Rx buff to xdp_buff, but maybe we need to revisit the idea
behind that copy altogether. It was developed way before the times when
XSK buffer pool got introduced.