On Tue, Sep 29, 2015 at 04:58:46PM -0600, David Ahern wrote: > Hi Tom: > > On 9/29/15 4:17 PM, Tom Herbert wrote: > >This patch adds xfrm6_xlat_addr which is called in the data path > >to perform address translation (primarily for the receive path). Modules > >may register their own callback to perform a translation-- this > >registration is managed by xfrm6_xlat_addr_add and xfrm6_xlat_addr_del. > >xfrm6_xlat_addr allows translation of addresses for an sk_buff. > > > Seems like a stretch to lump this into xfrms. You have a separate > genl based config as opposed to the netlink xfrm API and you are > calling the xlat_addr function directly in ip6_rcv as opposed to via > some policy with dst_ops driven redirection. Why call this a xfrm?
I have to agree here. We have policies and states to do the lookups and to describe the transformation. Just adding a callback to do this in a different way does not integrate well into xfrm. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
