> On Fri, 18 Mar 2022 20:54:51 +0100 Lorenzo Bianconi wrote: > > > IIUC the initial purpose of SKB mode was to be able to test or > > > experiment with XDP "until drivers add support". If that's still > > > the case the semantics of XDP SKB should be as close to ideal > > > XDP implementation as possible. > > > > XDP in skb-mode is useful if we want to perform a XDP_REDIRECT from > > an ethernet driver into a wlan device since mac80211 requires a skb. > > Ack, I understand the use case is real, but given that the TC > alternative exists we can apply more scrutiny to the trade offs. > IMO production use of XDP skb mode would be a mistake, the thing > is a layering violation by nature. Our time is better spent making > TC / XDP code portability effortless. ack, got your point, but I guess there is still a value running the same xdp program instead of switching to a tc one if the driver does not support native xdp. Anyway I am fine dropping this patch. > > > > We had a knob for specifying needed headroom, is that thing not > > > working / not a potentially cleaner direction? > > > > > > > which one do you mean? I guess it would be useful :) > > We have ndo_set_rx_headroom and dev->needed_headroom. > Sorry for brevity, I'm on the move today, referring to things > from memory :) :) Do you mean set dev->needed_headroom based on XDP_HEADROOM if the device is running in xdp mode, right? I guess this is doable for veth, but what is the right value for generic-xdp? Am I missing something? Regards, Lorenzo
Attachment:
signature.asc
Description: PGP signature
