Hi, I figured out the problem. Let me document the issue here for others and hopefully start a discussion. The mlx5 driver uses special queue ids for ZC. If N is the number of configured queues, then for XDP_ZEROCOPY the queue ids start at N. So queue ids [0..N) can only be used with XDP_COPY and queue ids [N..2N) can only be used with XDP_ZEROCOPY. sudo ethtool -L eth0 combined 16 sudo samples/bpf/xdpsock -r -i eth0 -c -q 0 # OK sudo samples/bpf/xdpsock -r -i eth0 -z -q 0 # ERROR sudo samples/bpf/xdpsock -r -i eth0 -c -q 16 # ERROR sudo samples/bpf/xdpsock -r -i eth0 -z -q 16 # OK Why was this done? To use zerocopy if available and fallback on copy mode normally you would set sxdp_flags=0. However, here this is no longer possible. To support this driver, you have to first try binding with XDP_ZEROCOPY and the special queue id, then if that fails, you have to try binding again with a normal queue id. Peculiarities like this complicate the XDP user api. Maybe someone can explain the benefits? Kal On Wed, Aug 7, 2019 at 2:49 PM Kal Cutter Conley <kal.conley@xxxxxxxxxxx> wrote: > > Hello, > I am testing the mlx5e driver with AF_XDP. When I specify > XDP_ZEROCOPY, bind() always returns EINVAL. I observe the same problem > with the xdpsock sample: > > sudo samples/bpf/xdpsock -r -i dcb1-port1 -z > samples/bpf/xdpsock_user.c:xsk_configure_socket:322: errno: > 22/"Invalid argument" > > Without XDP_ZEROCOPY, everything works as expected. Is this a known > issue/limitation? I expected this to be supported looking at the > code/commit history. > > Thanks, > Kal
|