netdev - Re: [RFC PATCH 1/2] vmxnet3: Add basic XDP support.

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: <CALDO+SYoYXKqvHb6ZjHpY_gFXtzXcEhH+5SeGBShTcdfgFB9qA@mail.gmail.com>
Date:   Fri, 1 Jul 2022 07:16:38 -0700
From:   William Tu <u9012063@...il.com>
To:     Jesper Dangaard Brouer <jbrouer@...hat.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        doshir@...are.com, Lorenzo Bianconi <lorenzo.bianconi@...hat.com>,
        gyang@...are.com, William Tu <tuc@...are.com>
Subject: Re: [RFC PATCH 1/2] vmxnet3: Add basic XDP support.

On Fri, Jul 1, 2022 at 12:11 AM Jesper Dangaard Brouer
<jbrouer@...hat.com> wrote:
>
>
> On 29/06/2022 03.49, William Tu wrote:
> > The patch adds native-mode XDP support: XDP_DROP, XDP_PASS, and XDP_TX.
> > The vmxnet3 rx consists of three rings: r0, r1, and dataring.
> > Buffers at r0 are allocated using alloc_skb APIs and dma mapped to the
> > ring's descriptor. If LRO is enabled and packet size is larger than
> > 3K, VMXNET3_MAX_SKB_BUF_SIZE, then r1 is used to mapped the rest of
> > the buffer larger than VMXNET3_MAX_SKB_BUF_SIZE. Each buffer in r1 is
> > allocated using alloc_page. So for LRO packets, the payload will be
> > in one buffer from r0 and multiple from r1, for non-LRO packets,
> > only one descriptor in r0 is used for packet size less than 3k.
> >
> [...]
> >
> > Need Feebacks:
> [...]
>
> > e. I should be able to move the run_xdp before the
> >     netdev_alloc_skb_ip_align() in vmxnet3_rq_rx_complete
> >     so avoiding the skb allocation overhead.
>
> Yes please!
>
> Generally speaking the approach of allocating an SKB and then afterwards
> invoking XDP BPF-prog goes against the principle of native-XDP.

That's a great point, thank you!
I will work on the next version.
William