| Message ID | cover.1597842004.git.lorenzo@kernel.org |
|---|---|
| Headers | show |
| Series | mvneta: introduce XDP multi-buffer support | expand |
General issue (that I think must be resolved/discussed as part of this initial patchset). When XDP_REDIRECT'ing a multi-buffer xdp_frame out of another driver's ndo_xdp_xmit(), what happens if the remote driver doesn't understand the multi-buffer format? My guess it that it will only send the first part of the packet (in the main page). Fortunately we don't leak memory, because xdp_return_frame() handle freeing the other segments. I assume this isn't acceptable behavior... or maybe it is? What are our options for handling this: 1. Add mb support in ndo_xdp_xmit in every driver? 2. Drop xdp->mb frames inside ndo_xdp_xmit (in every driver without support)? 3. Add core-code check before calling ndo_xdp_xmit()? --Jesper On Wed, 19 Aug 2020 15:13:45 +0200 Lorenzo Bianconi <lorenzo@kernel.org> wrote: > Finalize XDP multi-buffer support for mvneta driver introducing the capability > to map non-linear buffers on tx side. > Introduce multi-buffer bit (mb) in xdp_frame/xdp_buffer to specify if > shared_info area has been properly initialized. > Initialize multi-buffer bit (mb) to 0 in all XDP-capable drivers. > Add multi-buff support to xdp_return_{buff/frame} utility routines. > > Changes since RFC: > - squash multi-buffer bit initialization in a single patch > - add mvneta non-linear XDP buff support for tx side
> > > General issue (that I think must be resolved/discussed as part of this initial > patchset). I was thinking about this issue as well. > > When XDP_REDIRECT'ing a multi-buffer xdp_frame out of another driver's > ndo_xdp_xmit(), what happens if the remote driver doesn't understand the > multi-buffer format? > > My guess it that it will only send the first part of the packet (in the > main page). Fortunately we don't leak memory, because xdp_return_frame() > handle freeing the other segments. I assume this isn't acceptable > behavior... or maybe it is? > > What are our options for handling this: > > 1. Add mb support in ndo_xdp_xmit in every driver? I guess this is the optimal approach. > > 2. Drop xdp->mb frames inside ndo_xdp_xmit (in every driver without support)? Probably this is the easiest solution. Anyway if we drop patch 6/6 this is not a real issue since the driver is not allowed yet to receive frames bigger than one page and we have time to address this issue in each driver. Regards, Lorenzo > > 3. Add core-code check before calling ndo_xdp_xmit()? > > --Jesper > > On Wed, 19 Aug 2020 15:13:45 +0200 Lorenzo Bianconi <lorenzo@kernel.org> wrote: > > > Finalize XDP multi-buffer support for mvneta driver introducing the capability > > to map non-linear buffers on tx side. > > Introduce multi-buffer bit (mb) in xdp_frame/xdp_buffer to specify if > > shared_info area has been properly initialized. > > Initialize multi-buffer bit (mb) to 0 in all XDP-capable drivers. > > Add multi-buff support to xdp_return_{buff/frame} utility routines. > > > > Changes since RFC: > > - squash multi-buffer bit initialization in a single patch > > - add mvneta non-linear XDP buff support for tx side > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer >
Finalize XDP multi-buffer support for mvneta driver introducing the capability to map non-linear buffers on tx side. Introduce multi-buffer bit (mb) in xdp_frame/xdp_buffer to specify if shared_info area has been properly initialized. Initialize multi-buffer bit (mb) to 0 in all XDP-capable drivers. Add multi-buff support to xdp_return_{buff/frame} utility routines. Changes since RFC: - squash multi-buffer bit initialization in a single patch - add mvneta non-linear XDP buff support for tx side Lorenzo Bianconi (6): xdp: introduce mb in xdp_buff/xdp_frame xdp: initialize xdp_buff mb bit to 0 in all XDP drivers net: mvneta: update mb bit before passing the xdp buffer to eBPF layer xdp: add multi-buff support to xdp_return_{buff/frame} net: mvneta: add multi buffer support to XDP_TX net: mvneta: enable jumbo frames for XDP drivers/net/ethernet/amazon/ena/ena_netdev.c | 1 + drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 1 + .../net/ethernet/cavium/thunder/nicvf_main.c | 1 + .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 1 + drivers/net/ethernet/intel/i40e/i40e_txrx.c | 1 + drivers/net/ethernet/intel/ice/ice_txrx.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 1 + .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 1 + drivers/net/ethernet/marvell/mvneta.c | 92 +++++++++++-------- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 + drivers/net/ethernet/mellanox/mlx4/en_rx.c | 1 + .../net/ethernet/mellanox/mlx5/core/en_rx.c | 1 + .../ethernet/netronome/nfp/nfp_net_common.c | 1 + drivers/net/ethernet/qlogic/qede/qede_fp.c | 1 + drivers/net/ethernet/sfc/rx.c | 1 + drivers/net/ethernet/socionext/netsec.c | 1 + drivers/net/ethernet/ti/cpsw.c | 1 + drivers/net/ethernet/ti/cpsw_new.c | 1 + drivers/net/hyperv/netvsc_bpf.c | 1 + drivers/net/tun.c | 2 + drivers/net/veth.c | 1 + drivers/net/virtio_net.c | 2 + drivers/net/xen-netfront.c | 1 + include/net/xdp.h | 25 ++++- net/core/dev.c | 1 + net/core/xdp.c | 37 ++++++++ 26 files changed, 135 insertions(+), 44 deletions(-)