<snip>
>
> On 10/14/20 7:57 PM, Honnappa Nagarahalli wrote:
> >>>> On 13/10/2020 18:46, Michel Machado wrote:
> >>>>> On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
> >>>>>> Hi Michel,
> >>>>>>
> >>>>>> Could you please describe a condition when LPM gets inconsistent?
> >>>>>> As I can see if there is no free tbl8 it will return -ENOSPC.
> >>>>>
> >>>>> Consider this simple example, we need to add the following
> >>>>> two prefixes with different next hops: 10.99.0.0/16,
> >>>>> 18.99.99.128/25. If the LPM table is out of tbl8s, the second
> >>>>> prefix is not added and Gatekeeper will make decisions in
> >>>>> violation of the policy. The data structure of the LPM table is
> >>>>> consistent, but its content inconsistent with the policy.
> > max_rules and number_tbl8s in 'struct rte_lpm' contain the config
> information. These 2 fields do not change based on the routes added and do
> not indicate the amount of space left. So, you cannot use this information to
> decide if there is enough space to add more routes.
>
> We are aware that those fields hold the config information not a status of
> the LPM table.
>
> Before updating a LPM table that holds network prefixes derived from
> threat intelligence, we compute the minimum values for max_rules and
> number_tbl8s. Here is an example of how we do it:
> https://github.com/AltraMayor/gatekeeper/blob/95d1d6e8201861a0d0c698
> bfd06ad606674f1e07/lua/examples/policy.lua#L135-L166
>
> Once these minimum values are available, we get the parameters of the
> LPM table to be updated and check if we can update it, or have to recreate it.
>
> >>>> Aha, thanks. So do I understand correctly that you need to add a
> >>>> set of routes atomically (either the entire set is installed or nothing)?
> >>>
> >>> Yes.
> >>>
> >>>> If so, then I would suggest having 2 lpm and switching them
> >>>> atomically after a successful addition. As for now, even if you
> >>>> have enough tbl8's, routes are installed non atomically, i.e. there
> >>>> will be a time gap between adding two routes, so in this time
> >>>> interval the table will be inconsistent with the policy.
> >>>> Also, if new lpm algorithms are added to the DPDK, they won't have
> >>>> such a thing as tbl8.
> >>>
> >>> Our code already deals with synchronization.
> > If the application code already deals with synchronization, is it possible
> > to
> revert back (i.e. delete the routes that got added so far) when the addition
> of the route-set fails?
>
> The way the code is structured, this would require a significant rewrite
> because the code assumes that it will succeed since the capacity of the LPM
> tables was already checked.
>
> >>>>>> On 13/10/2020 15:58, Michel Machado wrote:
> >>>>>>> Hi Kevin,
> >>>>>>>
> >>>>>>> We do need fields max_rules and number_tbl8s of struct
> >>>>>>> rte_lpm, so the removal would force us to have another patch to
> >>>>>>> our local copy of DPDK. We'd rather avoid this new local patch
> >>>>>>> because we wish to eventually be in sync with the stock DPDK.
> >>>>>>>
> >>>>>>> Those fields are needed in Gatekeeper because we found a
> >>>>>>> condition in an ongoing deployment in which the entries of some
> >>>>>>> LPM tables may suddenly change a lot to reflect policy changes.
> >>>>>>> To avoid getting into a state in which the LPM table is
> >>>>>>> inconsistent because it cannot fit all the new entries, we
> >>>>>>> compute the needed parameters to support the new entries, and
> >>>>>>> compare with the current parameters. If the current table
> >>>>>>> doesn't fit everything, we have to replace it with a new LPM table.
> >>>>>>>
> >>>>>>> If there were a way to obtain the struct rte_lpm_config of
> >>>>>>> a given LPM table, it would cleanly address our need. We have
> >>>>>>> the same need in IPv6 and have a local patch to work around it
> >>>>>>> (see
> >>>>>>>
> >>
> https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db
> >> 26a78115cb8c8f).
> > I do not see why such an API is not possible, we could add one API that
> returns max_rules and number_tbl8s (essentially, the config that was passed
> to rte_lpm_create API).
> > But, is there a possibility to store that info in the application as that
> > data
> was passed to rte_lpm from the application?
>
> A suggestion for what this API could look like:
>
> void rte_lpm_get_config(const struct rte_lpm *lpm, struct rte_lpm_config
> *config); void rte_lpm6_get_config(const struct rte_lpm6 *lpm, struct
> rte_lpm6_config *config);
>
> If the final choice is for not supporting a way to retrieve the config
> information on the API, we'll look for a place to keep a copy of the
> parameters in our code.
IMO, this is not a performance critical path and it is not a difficult solution
to store these values in the application. My suggestion is to skip adding the
API and store the values in the application.
Vladimir, what's your opinion?
