On Sat, Nov 21, 2020 at 04:28:23PM +0200, Eyal Birger wrote: > This commit adds support for 'collect_md' mode on xfrm interfaces. > > Each net can have one collect_md device, created by providing the > IFLA_XFRM_COLLECT_METADATA flag at creation. This device cannot be > altered and has no if_id or link device attributes. > > On transmit to this device, the if_id is fetched from the attached dst > metadata on the skb. The dst metadata type used is METADATA_IP_TUNNEL > since the only needed property is the if_id stored in the tun_id member > of the ip_tunnel_info->key.
Can we please have a separate metadata type for xfrm interfaces? Sharing such structures turned already out to be a bad idea on vti interfaces, let's try to avoid that misstake with xfrm interfaces. > On the receive side, xfrmi_rcv_cb() populates a dst metadata for each > packet received and attaches it to the skb. The if_id used in this case is > fetched from the xfrm state. This can later be used by upper layers such > as tc, ebpf, and ip rules. > > Because the skb is scrubed in xfrmi_rcv_cb(), the attachment of the dst > metadata is postponed until after scrubing. Similarly, xfrm_input() is > adapted to avoid dropping metadata dsts by only dropping 'valid' > (skb_valid_dst(skb) == true) dsts. > > Policy matching on packets arriving from collect_md xfrmi devices is > done by using the xfrm state existing in the skb's sec_path. > The xfrm_if_cb.decode_cb() interface implemented by xfrmi_decode_session() > is changed to keep the details of the if_id extraction tucked away > in xfrm_interface.c. > > Signed-off-by: Eyal Birger <eyal.bir...@gmail.com> The rest of the patch looks good. Thanks!
