On 24/07/2018 5:11 AM, Toshiaki Makita wrote:
On 2018/07/24 10:02, Jakub Kicinski wrote:
On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
From: Toshiaki Makita <makita.toshi...@lab.ntt.co.jp>
This allows NIC's XDP to redirect packets to veth. The destination veth
device enqueues redirected packets to the napi ring of its peer, then
they are processed by XDP on its peer veth device.
This can be thought as calling another XDP program by XDP program using
REDIRECT, when the peer enables driver XDP.
Note that when the peer veth device does not set driver xdp, redirected
packets will be dropped because the peer is not ready for NAPI.
Often we can't redirect to devices which don't have am xdp program
installed. In your case we can't redirect unless the peer of the
target doesn't have a program installed? :(
Right. I tried to avoid this case by converting xdp_frames to skb but
realized that should not be done.
https://patchwork.ozlabs.org/patch/903536/
Perhaps it is time to reconsider what Saeed once asked for, a flag or
attribute to enable being the destination of a XDP_REDIRECT.
Yes, something will be necessary. Jesper said Tariq had some ideas to
implement it.
Yes, that bothered me as well.
I think that the driver-out capability of the XDP redirect is totally
unrelated to any XDP program, and is a standalone feature that should be
simply turned on/off just like any other performance feature, via
ethtool -K.
I am going to push my driver implementation (mlx5) of XDP redirect
driver-out side very soon (this week).
As you will see, it does not require loading any XDP program, and the
feature will be always on (for now, until we add a control flow for it).
Later, we plan to push ethtool infrastructure and driver implementation
to control the feature.
Thanks,
Tariq
