> PFs and VFs share the same structure of NDOs today, and the VFs explicitly
> fails the ndo_xdp() callback stating it doesn't support XDP.
>
> This results in lots of:
>
> [qede_xdp:1032(enp131s2)]VFs don't support XDP
> ------------[ cut here ]------------
> WARNING: CPU: 4 PID: 1426 at net/core/rtnetlink.c:1637
> rtnl_dump_ifinfo+0x354/0x3c0
> ...
> Call Trace:
> ? __alloc_skb+0x9b/0x1d0
> netlink_dump+0x122/0x290
> netlink_recvmsg+0x27d/0x430
> sock_recvmsg+0x3d/0x50
> ...
>
> As every dump request for the VF interface info would fail due to
> rtnl_xdp_fill() returning an error code.
>
> To resolve this, introduce a subset of the NDOs meant for the VF in a
> seperate structure and register that one instead for VFs, and omit the
> ndo_xdp initialization.
>
> Fixes: 40b8c45492ef ("qede: Prevent VFs from using XDP")
> Signed-off-by: Yuval Mintz <yuval.mi...@cavium.com>
I'm currently working on adding XDP support for qede VFs.
Problem is there's quite a bit of IOV infrastructure involved in this,
and legacy [well, current] PFs would prevent their VFs from utilizing it.
Once I have it ready, if I'd add back the ndo_xdp unconditionally for VFs,
then when working over legacy PFs above issue would resurface.
Looking at my alternatives for solving this, I can't see any 'good' options -
it seems mightily unorthodox to modify net_device_ops, I.e., add/remove
an NDO function-pointer based on some device property, and having
multiple ops declared for the sake of a single feature seems unscalable.
Any better solutions?
