Re: [RFC PATCH] ila: Resolver mechanism
From: Thomas Graf <tgraf@suug.ch>
Date: 2016-06-30 22:02:03
On 06/30/16 at 12:41pm, Tom Herbert wrote:
This is not yet complete, we would still need to some controls to rate limit number of resolution requests and a means to track pending requests. I'm posting this as RFC because it seems like this might be part of a general mechanism to a perform address resolution in userspace and I would appreciate comments with regard to that.
I wouldn't mind having the rate limiting done as generic route attribute so it could be applied to non-ILA routes as well.
quoted hunk ↗ jump to hunk
diff --git a/include/uapi/linux/lwtunnel.h b/include/uapi/linux/lwtunnel.h index a478fe8..d880e49 100644 --- a/include/uapi/linux/lwtunnel.h +++ b/include/uapi/linux/lwtunnel.h@@ -9,6 +9,7 @@ enum lwtunnel_encap_types { LWTUNNEL_ENCAP_IP, LWTUNNEL_ENCAP_ILA, LWTUNNEL_ENCAP_IP6, + LWTUNNEL_ENCAP_ILA_NOTIFY, __LWTUNNEL_ENCAP_MAX, };
Neat.
quoted hunk ↗ jump to hunk
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h index 262f037..271215f 100644 --- a/include/uapi/linux/rtnetlink.h +++ b/include/uapi/linux/rtnetlink.h@@ -144,6 +144,9 @@ enum { RTM_GETSTATS = 94, #define RTM_GETSTATS RTM_GETSTATS + RTM_ADDR_RESOLVE = 95, +#define RTM_ADDR_RESOLVE RTM_ADDR_RESOLVE +
I realize this is currently only kernel->user but let's plan ahead. Each RTM_ group should start aligned to 4 with types specified in the order new, del, get, set. RTM_ADDR_RESOLVE probably maps best to NEW in terms of behaviour. See the magic around 'kind' in rtnetlink_rcv_msg().