netdev - Re: [PATCH intel-next v4 0/8] i40e: support XDP multi-buffer

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: <1fa87a9f-1362-126a-49d5-3df7e84555e6@intel.com>
Date:   Wed, 15 Feb 2023 15:13:28 -0800
From:   Tony Nguyen <anthony.l.nguyen@...el.com>
To:     Tirthendu Sarkar <tirthendu.sarkar@...el.com>,
        <intel-wired-lan@...ts.osuosl.org>
CC:     <jesse.brandeburg@...el.com>, <netdev@...r.kernel.org>,
        <bpf@...r.kernel.org>, <magnus.karlsson@...el.com>,
        <maciej.fijalkowski@...el.com>
Subject: Re: [PATCH intel-next v4 0/8] i40e: support XDP multi-buffer

On 2/15/2023 4:42 AM, Tirthendu Sarkar wrote:
> This patchset adds multi-buffer support for XDP. Tx side already has
> support for multi-buffer. This patchset focuses on Rx side. The last
> patch contains actual multi-buffer changes while the previous ones are
> preparatory patches.
> 
> On receiving the first buffer of a packet, xdp_buff is built and its
> subsequent buffers are added to it as frags. While 'next_to_clean' keeps
> pointing to the first descriptor, the newly introduced 'next_to_process'
> keeps track of every descriptor for the packet.
> 
> On receiving EOP buffer the XDP program is called and appropriate action
> is taken (building skb for XDP_PASS, reusing page for XDP_DROP, adjusting
> page offsets for XDP_{REDIRECT,TX}).
> 
> The patchset also streamlines page offset adjustments for buffer reuse
> to make it easier to post process the rx_buffers after running XDP prog.
> 
> With this patchset there does not seem to be any performance degradation
> for XDP_PASS and some improvement (~1% for XDP_TX, ~5% for XDP_DROP) when
> measured using xdp_rxq_info program from samples/bpf/ for 64B packets.

If you want this to go through Intel Wired LAN, can you base it off that 
tree [1]. This doesn't apply to next-queue/dev-queue.

Thanks,
Tony

[1] https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git/