From: Mohsin Bashir <mohsin.bashr@gmail.com>
To: Daniel Machon <daniel.machon@microchip.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Horatiu Vultur <horatiu.vultur@microchip.com>,
Steen Hegelund <steen.hegelund@microchip.com>,
UNGLinuxDriver@microchip.com, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Herve Codina <herve.codina@bootlin.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: [PATCH net-next 08/10] net: lan966x: add PCIe FDMA XDP support
Date: Sun, 22 Mar 2026 00:11:39 -0700 [thread overview]
Message-ID: <ab2f788b-7214-4aa6-bfca-b33d3ab37321@gmail.com> (raw)
In-Reply-To: <20260320-lan966x-pci-fdma-v1-8-ef54cb9b0c4b@microchip.com>
> +static int lan966x_xdp_pci_run(struct lan966x_port *port, void *data,
> + u32 data_len)
> +{
> + struct bpf_prog *xdp_prog = port->xdp_prog;
> + struct lan966x *lan966x = port->lan966x;
> + struct xdp_buff xdp;
> + u32 act;
> +
> + xdp_init_buff(&xdp, lan966x->rx.max_mtu, &port->xdp_rxq);
> +
> + xdp_prepare_buff(&xdp,
> + data - XDP_PACKET_HEADROOM,
> + IFH_LEN_BYTES + XDP_PACKET_HEADROOM,
> + data_len - IFH_LEN_BYTES,
> + false);
> +
> + act = bpf_prog_run_xdp(xdp_prog, &xdp);
> + switch (act) {
> + case XDP_PASS:
> + return FDMA_PASS;
> + case XDP_TX:
> + return lan966x_fdma_pci_xmit_xdpf(port, data, data_len) ?
> + FDMA_DROP : FDMA_TX;
What if the BPF program modifies packet boundaries (e.g.,
headroom/tailroom adjustment)? After bpf_prog_run_xdp(), xdp.data and
xdp.data_end may differ from the original data and data_len, but
lan966x_fdma_pci_xmit_xdpf() is called with the original values.
Wouldn't any adjustments made by the XDP program be silently lost?
> + default:
> + bpf_warn_invalid_xdp_action(port->dev, xdp_prog, act);
> + fallthrough;
> + case XDP_ABORTED:
> + trace_xdp_exception(port->dev, xdp_prog, act);
> + fallthrough;
> + case XDP_DROP:
> + return FDMA_DROP;
> + }
> +}
> +
next prev parent reply other threads:[~2026-03-22 7:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 15:00 [PATCH net-next 00/10] net: lan966x: add support for PCIe FDMA Daniel Machon
2026-03-20 15:00 ` [PATCH net-next 01/10] net: microchip: fdma: rename contiguous dataptr helpers Daniel Machon
2026-03-20 15:00 ` [PATCH net-next 02/10] net: microchip: fdma: add PCIe ATU support Daniel Machon
2026-03-20 15:00 ` [PATCH net-next 03/10] net: lan966x: add FDMA LLP register write helper Daniel Machon
2026-03-20 15:01 ` [PATCH net-next 04/10] net: lan966x: export FDMA helpers for reuse Daniel Machon
2026-03-20 15:01 ` [PATCH net-next 05/10] net: lan966x: add FDMA ops dispatch for PCIe support Daniel Machon
2026-03-20 15:01 ` [PATCH net-next 06/10] net: lan966x: add PCIe FDMA support Daniel Machon
2026-03-20 15:01 ` [PATCH net-next 07/10] net: lan966x: add PCIe FDMA MTU change support Daniel Machon
2026-03-20 15:01 ` [PATCH net-next 08/10] net: lan966x: add PCIe FDMA XDP support Daniel Machon
2026-03-22 7:11 ` Mohsin Bashir [this message]
2026-03-22 20:30 ` Daniel Machon
2026-03-20 15:01 ` [PATCH net-next 09/10] misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space Daniel Machon
2026-03-20 15:01 ` [PATCH net-next 10/10] misc: lan966x-pci: dts: add fdma interrupt to overlay Daniel Machon
2026-03-23 14:52 ` [PATCH net-next 00/10] net: lan966x: add support for PCIe FDMA Herve Codina
2026-03-23 16:26 ` Herve Codina
2026-03-23 19:40 ` Daniel Machon
2026-03-24 8:07 ` Herve Codina
2026-03-26 15:48 ` Daniel Machon
2026-03-27 10:33 ` Herve Codina
2026-03-27 11:07 ` Daniel Machon
2026-04-07 13:20 ` Daniel Machon
2026-04-08 9:51 ` Herve Codina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ab2f788b-7214-4aa6-bfca-b33d3ab37321@gmail.com \
--to=mohsin.bashr@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew+netdev@lunn.ch \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel.machon@microchip.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hawk@kernel.org \
--cc=herve.codina@bootlin.com \
--cc=horatiu.vultur@microchip.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=steen.hegelund@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.