[PATCH net-next v3 0/2] XDP metadata support for DQ RDA

[PATCH net-next v3 0/2] XDP metadata support for DQ RDA

[Joshua Washington]

This small series enables XDP metadata support in DQ RDA mode. While
space is reserved in the headroom for metadata and the DQ queue format
supports the xmo_rx_timestamp metadata operation, support for adjusting
the metadata and passing metadata along to SKBs was not actually
implemented.

v3:
  - Make use of xdp_build_skb methods to implicitly pass on metadata
    when constructing SKBs from XDP buffs.
  - v2: https://lore.kernel.org/netdev/20260318192450.3400774-1-joshwash@google.com/
v2:
  - Fix referenced commit hash
  - v1: https://lore.kernel.org/netdev/20260316230434.1398828-1-joshwash@google.com/

Joshua Washington (2):
  gve: use xdp_build_skb methods for XDP_PASS case
  gve: add XDP metadata support for DQ RDA

 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

-- 
2.55.0.229.g6434b31f56-goog

[PATCH net-next v3 1/2] gve: use xdp_build_skb methods for XDP_PASS case

[Joshua Washington]

Newer common methods have been introduced to construct SKBs in the
event of XDP_PASS because many drivers replicated very similar
functionality. Update GVE to use these common methods for copy mode and
zero-copy mode.

Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
v3:
  - Newly introduced. Ensures that XDP metadata is passed onto SKB in
    XDP_PASS case.
---
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 02cba280d81a..907a0c15bf30 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -736,8 +736,7 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 	}
 
 	/* Copy the data to skb */
-	rx->ctx.skb_head = gve_rx_copy_data(priv->dev, napi,
-					    xdp->data, buf_len);
+	rx->ctx.skb_head = xdp_build_skb_from_zc(xdp);
 	if (unlikely(!rx->ctx.skb_head)) {
 		xsk_buff_free(xdp);
 		gve_free_buf_state(rx, buf_state);
@@ -745,8 +744,6 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 	}
 	rx->ctx.skb_tail = rx->ctx.skb_head;
 
-	/* Free XSK buffer and Buffer state */
-	xsk_buff_free(xdp);
 	gve_free_buf_state(rx, buf_state);
 
 	/* Update Stats */
@@ -899,9 +896,17 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 			return 0;
 		}
 
+		rx->ctx.skb_head = xdp_build_skb_from_buff(&gve_xdp.xdp);
+		if (unlikely(!rx->ctx.skb_head))
+			goto error;
+		rx->ctx.skb_tail = rx->ctx.skb_head;
+
+		gve_reuse_buffer(rx, buf_state);
+
 		u64_stats_update_begin(&rx->statss);
 		rx->xdp_actions[XDP_PASS]++;
 		u64_stats_update_end(&rx->statss);
+		return 0;
 	}
 
 	if (eop && buf_len <= priv->rx_copybreak &&
-- 
2.55.0.229.g6434b31f56-goog

[PATCH net-next v3 2/2] gve: add XDP metadata support for DQ RDA

[Joshua Washington]

Commit 1b42e07af1ee ("gve: Add Rx HWTS metadata to AF_XDP ZC mode")
exposes support for the XDP RX timestamping metadata operation in the DQ
RDA mode. While the operation works on its own, the intent was to enable
XDP metadata support for the queue format as a whole along with it.
Currently bpf_xdp_adjust_meta fails because meta_valid is set to false.
This change updates xdp_buff preparation to set meta_valid to true, so
metadata can be fully used by XDP programs.

Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
v3:
  - bfp -> bpf
v2:
  - Fix referenced commit in description
---
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 907a0c15bf30..329a2585489b 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -882,7 +882,7 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 				 buf_state->page_info.page_address +
 				 buf_state->page_info.page_offset,
 				 buf_state->page_info.pad,
-				 buf_len, false);
+				 buf_len, true);
 		gve_xdp.gve = priv;
 		gve_xdp.compl_desc = compl_desc;
 
-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH net-next v3 1/2] gve: use xdp_build_skb methods for XDP_PASS case

[Joshua Washington]

On Wed, Jul 22, 2026 at 3:16 PM Joshua Washington <joshwash@google.com> wrote:
>
> Newer common methods have been introduced to construct SKBs in the
> event of XDP_PASS because many drivers replicated very similar
> functionality. Update GVE to use these common methods for copy mode and
> zero-copy mode.
>
> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
> Reviewed-by: Jordan Rhee <jordanrhee@google.com>
> Signed-off-by: Joshua Washington <joshwash@google.com>
> ---
> v3:
>   - Newly introduced. Ensures that XDP metadata is passed onto SKB in
>     XDP_PASS case.
> ---
>  drivers/net/ethernet/google/gve/gve_rx_dqo.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> index 02cba280d81a..907a0c15bf30 100644
> --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> @@ -736,8 +736,7 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>         }
>
>         /* Copy the data to skb */
> -       rx->ctx.skb_head = gve_rx_copy_data(priv->dev, napi,
> -                                           xdp->data, buf_len);
> +       rx->ctx.skb_head = xdp_build_skb_from_zc(xdp);

Sashiko says:
---
[Severity: High]
This isn't a bug introduced by this patch, but does this unconditionally
overwrite the SKB head on every fragment for multi-fragment packets?

If an AF_XDP enabled interface receives a jumbo frame (e.g., 9000 bytes),
the hardware splits the packet across multiple RX descriptors. For each
descriptor, gve_rx_xsk_dqo() allocates a new SKB here and assigns it to
rx->ctx.skb_head.

Since this ignores whether rx->ctx.skb_head is already populated from previous
fragments, does it leak the SKBs of prior fragments and truncate the delivered
packet?
---

Multi-buffer XDP is not supported in GVE DQ.

>         if (unlikely(!rx->ctx.skb_head)) {
>                 xsk_buff_free(xdp);
>                 gve_free_buf_state(rx, buf_state);
> @@ -745,8 +744,6 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>         }
>         rx->ctx.skb_tail = rx->ctx.skb_head;
>
> -       /* Free XSK buffer and Buffer state */
> -       xsk_buff_free(xdp);
>         gve_free_buf_state(rx, buf_state);
>
>         /* Update Stats */
> @@ -899,9 +896,17 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>                         return 0;
>                 }
>
> +               rx->ctx.skb_head = xdp_build_skb_from_buff(&gve_xdp.xdp);
> +               if (unlikely(!rx->ctx.skb_head))
> +                       goto error;
> +               rx->ctx.skb_tail = rx->ctx.skb_head;
> +
> +               gve_reuse_buffer(rx, buf_state);
> +
>                 u64_stats_update_begin(&rx->statss);
>                 rx->xdp_actions[XDP_PASS]++;
>                 u64_stats_update_end(&rx->statss);
> +               return 0;

Sashiko says:
---
[Severity: High]
Does returning 0 here bypass the copy-on-demand safety check for XDP_PASS
packets?

The gve_rx_should_trigger_copy_ondemand() check at the end of gve_rx_dqo()
appears to be skipped. By bypassing this check, could the networking stack
hold onto the QPL pages indefinitely?

This might drive used_buf_states_cnt to num_buf_states, exhausting the buffer
pool and preventing new RX buffers from being posted to hardware, ultimately
starving the RX ring.
---

DQ QPL doesn't have XDP support, so QPL pages are not in use.

>         }
>
>         if (eop && buf_len <= priv->rx_copybreak &&
> --
> 2.55.0.229.g6434b31f56-goog
>


Sashiko says:
---
> @@ -894,14 +891,22 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>               buf_state->page_info.pad += gve_xdp.xdp.data - old_data;
>               buf_len = gve_xdp.xdp.data_end - gve_xdp.xdp.data;
>               if (xdp_act != XDP_PASS) {
>                       gve_xdp_done_dqo(priv, rx, &gve_xdp.xdp, xprog, xdp_act,
>                                        buf_state);
>                       return 0;
>               }

[Severity: High]
This is a pre-existing issue, but if the first fragment of a multi-descriptor
packet is dropped (e.g. XDP_DROP), does the driver fail to track that the rest
of the packet must be dropped?

When the next descriptor containing the middle of the payload arrives,
rx->ctx.skb_head will be NULL. Will the driver incorrectly treat this fragment
as a new Ethernet frame and run the XDP program on arbitrary payload data?
---

Again, GVE DQ doesn't support multi-buffer XDP. This will be addressed
when support is added.

-- 

Joshua Washington | Software Engineer | joshwash@google.com | (414) 366-4423

Re: [PATCH net-next v3 2/2] gve: add XDP metadata support for DQ RDA

[Joshua Washington]

On Wed, Jul 22, 2026 at 3:16 PM Joshua Washington <joshwash@google.com> wrote:
>
> Commit 1b42e07af1ee ("gve: Add Rx HWTS metadata to AF_XDP ZC mode")
> exposes support for the XDP RX timestamping metadata operation in the DQ
> RDA mode. While the operation works on its own, the intent was to enable
> XDP metadata support for the queue format as a whole along with it.
> Currently bpf_xdp_adjust_meta fails because meta_valid is set to false.
> This change updates xdp_buff preparation to set meta_valid to true, so
> metadata can be fully used by XDP programs.
>
> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
> Reviewed-by: Jordan Rhee <jordanrhee@google.com>
> Signed-off-by: Joshua Washington <joshwash@google.com>
> ---
> v3:
>   - bfp -> bpf
> v2:
>   - Fix referenced commit in description
> ---
>  drivers/net/ethernet/google/gve/gve_rx_dqo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> index 907a0c15bf30..329a2585489b 100644
> --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> @@ -882,7 +882,7 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>                                  buf_state->page_info.page_address +
>                                  buf_state->page_info.page_offset,
>                                  buf_state->page_info.pad,
> -                                buf_len, false);
> +                                buf_len, true);
>                 gve_xdp.gve = priv;
>                 gve_xdp.compl_desc = compl_desc;
>
> --
> 2.55.0.229.g6434b31f56-goog
>

Sashiko says:
---
>       if (xprog) {
>               struct gve_xdp_buff gve_xdp;
>               void *old_data;
>               int xdp_act;
>
>               xdp_init_buff(&gve_xdp.xdp, buf_state->page_info.buf_size,
>                             &rx->xdp_rxq);
>               xdp_prepare_buff(&gve_xdp.xdp,
>                                buf_state->page_info.page_address +
>                                buf_state->page_info.page_offset,
>                                buf_state->page_info.pad,
> -                              buf_len, false);
> +                              buf_len, true);
>               gve_xdp.gve = priv;
>               gve_xdp.compl_desc = compl_desc;
>
>               old_data = gve_xdp.xdp.data;
>               xdp_act = bpf_prog_run_xdp(xprog, &gve_xdp.xdp);
>               buf_state->page_info.pad += gve_xdp.xdp.data - old_data;

[Severity: High]
This is a pre-existing issue, but does accumulating the XDP head adjustment
into buf_state->page_info.pad lead to out-of-bounds hardware DMA?

When XDP programs adjust the packet head, the difference is accumulated into
the pad. When the buffer is recycled, it appears the pad is never reset to
the default headroom.

Could this cause subsequent reuses of the buffer to continue accumulating
the offset and eventually calculate an out-of-bounds DMA address in
gve_alloc_buffer():

drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c:gve_alloc_buffer() {
    ...
    desc->buf_addr = cpu_to_le64(buf_state->addr +
                                 buf_state->page_info.page_offset +
                                 buf_state->page_info.pad);
    ...
}
---

This is not acutally a concern becasue gve_alloc_buffer() always
resets the the pad based on the page pool's offset parameter. This is
something that would need to be accounted for in the case of DQ QPL,
which does not yet support XDP.

Re: [PATCH net-next v3 1/2] gve: use xdp_build_skb methods for XDP_PASS case

[Larysa Zaremba]

On Thu, Jul 23, 2026 at 08:39:47PM -0700, Joshua Washington wrote:
> On Wed, Jul 22, 2026 at 3:16 PM Joshua Washington <joshwash@google.com> wrote:
> >
> > Newer common methods have been introduced to construct SKBs in the
> > event of XDP_PASS because many drivers replicated very similar
> > functionality. Update GVE to use these common methods for copy mode and
> > zero-copy mode.
> >
> > Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
> > Reviewed-by: Jordan Rhee <jordanrhee@google.com>
> > Signed-off-by: Joshua Washington <joshwash@google.com>
> > ---
> > v3:
> >   - Newly introduced. Ensures that XDP metadata is passed onto SKB in
> >     XDP_PASS case.
> > ---
> >  drivers/net/ethernet/google/gve/gve_rx_dqo.c | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >

[...]

> Sashiko says:
> ---
> [Severity: High]
> Does returning 0 here bypass the copy-on-demand safety check for XDP_PASS
> packets?
> 
> The gve_rx_should_trigger_copy_ondemand() check at the end of gve_rx_dqo()
> appears to be skipped. By bypassing this check, could the networking stack
> hold onto the QPL pages indefinitely?
> 
> This might drive used_buf_states_cnt to num_buf_states, exhausting the buffer
> pool and preventing new RX buffers from being posted to hardware, ultimately
> starving the RX ring.
> ---
> 
> DQ QPL doesn't have XDP support, so QPL pages are not in use.

Yes, given how gve_set_netdev_xdp_features() looks, this does seem like a false 
positive. Patch looks good to me.

Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>