On Mon, 2019-06-03 at 11:04 +0200, Björn Töpel wrote:

On Sat, 1 Jun 2019 at 21:42, Jakub Kicinski
[off-list ref] wrote:

quoted

On Fri, 31 May 2019 19:18:17 +0000, Saeed Mahameed wrote:

quoted

On Fri, 2019-05-31 at 11:42 +0200, Björn Töpel wrote:

quoted

From: Björn Töpel <redacted>

All XDP capable drivers need to implement the
XDP_QUERY_PROG{,_HW}
command of ndo_bpf. The query code is fairly generic. This
commit
refactors the query code up from the drivers to the netdev
level.

The struct net_device has gained two new members: xdp_prog_hw
and
xdp_flags. The former is the offloaded XDP program, if any, and
the
latter tracks the flags that the supplied when attaching the
XDP
program. The flags only apply to SKB_MODE or DRV_MODE, not
HW_MODE.

The xdp_prog member, previously only used for SKB_MODE, is
shared
with
DRV_MODE. This is OK, due to the fact that SKB_MODE and
DRV_MODE are
mutually exclusive. To differentiate between the two modes, a
new
internal flag is introduced as well.

Just thinking out loud, why can't we allow any combination of
HW/DRV/SKB modes? they are totally different attach points in a
totally
different checkpoints in a frame life cycle.

FWIW see Message-ID: [ref]

I've always seen the SKB-mode as something that will eventually be
removed.

I don't think so, we are too deep into SKB-mode.

Clickable link:
https://lore.kernel.org/netdev/20190201080236.446d84d4@redhat.com/ (local) :-
P

So we are all hanging on Jesper's refactoring ideas that are not
getting any priority for now :).

quoted

quoted

Down the road i think we will utilize this fact and start
introducing
SKB helpers for SKB mode and driver helpers for DRV mode..

Any reason why we would want the extra complexity?  There is
cls_bpf
if someone wants skb features after all..

Donno, SKB mode is earlier in the stack maybe ..