# Re: \[PATCH net-next v19 03/13\] netdev: support binding dma-buf to netdevice

- From: Jakub Kicinski \<kuba@kernel.org\>
- Date: 2024-08-20 15:19:24 
- List: netdev
- Page: https://ratatoskr.run/netdev/2024/08/2715091
- Thread: https://ratatoskr.run/netdev/2024/08/2706702/t.md

```text
On Tue, 20 Aug 2024 00:01:02 -0400 Mina Almasry wrote:
> Took a bit of a look here. Forgive me, I'm not that familiar with XDP
> and virtual interfaces, so I'm a bit unsure what to do here.
> 
> For veth, it seems, the device behind the veth is stored in
> veth_priv->peer, so it seems maybe a dev_get_max_mp_channel() check on
> veth_priv->peer is the way to go to disable this for veth? I think we
> need to do this check on creation of the veth and on the ndo_bpf of
> veth.

veth is a SW device pair, it can't reasonably support netmem.
Given all the unreasonable features it grew over time we can't
rule out that someone will try, but that's not our problem now.

> For bonding, it seems we need to add mp channel check in bond_xdp_set,
> and bond_enslave?

Sort of, I'd factor out that logic into the core first, as some
sort of "xdp propagate" helper. Then we can add that check once.
I don't see anything bond specific in the logic.

> There are a few other drivers that define ndo_add_slave, seems a check
> in br_add_slave is needed as well.

I don't think it's that broad. Not many drivers propagate XDP:

$ git grep -C 200 '\.ndo_add_slave' | grep '\.ndo_bpf'
drivers/net/bonding/bond_main.c-	.ndo_bpf		= bond_xdp,

$ git grep --files-with-matches  'ops->ndo_bpf' -- drivers/
drivers/net/bonding/bond_main.c
drivers/net/hyperv/netvsc_bpf.c

> This seems like a potentially deep rabbit hole with a few checks to
> add all of the place. Is this blocking the series?

Protecting the stack from unreadable memory is *the* challenge
in this series. The rest is a fairly straightforward.
```