Thread (26 messages) 26 messages, 6 authors, 2021-09-28

Re: Redux: Backwards compatibility for XDP multi-buff

From: Jesper Dangaard Brouer <hidden>
Date: 2021-09-27 12:44:03
Also in: bpf

On 23/09/2021 15.46, Jakub Kicinski wrote:
Let me make a general statement that we can't build large systems
without division of responsibilities. Device specific logic has to
be left to the driver. It's up to veth to apply its extra rules.

As Zvi said, tho, this can be left for later. IMHO initial patches can
drop all mb frames on redirect in the core, so we can make progress.
I agree that for *initial* patchset for REDIRECT (func calling 
ndo_xdp_xmit) it can drop MB frames on redirect in the core, when the 
drivers ndo_xdp_xmit doesn't support this.
BUT only so we can make progress.

As soon as possible (preferably in same kernel release) a follow-up 
patchset should make a serious attempt at updating all drivers 
ndo_xdp_xmit to support multi-buffer (MB).

As MB use the same/compatible layout as skb_shared_info, it should be a 
fairly small effort to update drivers, for *transmitting* multi-buff. As 
drivers already support this for normal SKBs.

It will be a larger effort to support XDP multi-buff on RX, as often the 
RX-loop need to be adjusted/reordered to "delay" calling XDP-prog until 
all fragments have been "collected".  And MTU check adjusted.

This imply that the driver net_device xdp_features need two feature bits 
for this MB feature.
IMHO it makes sense to detangle RX and TX, as IMHO we should allow MB 
frames to be TX redirect out a driver that have an old non-MB aware 
XDP-prog loaded.

--Jesper
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help