> > 3. ifconfig can use the dynamic ppa assignment code in kernel than going
> > in a loop to find the next unused ppa for the IPMP interface.
> > (L3887 ifconfig.c). We already have code in IP for this (for plumbing
> vlans)
> > ifconfig needs to pass in UINT_MAX as ppa and ill_alloc_ppa() will do
> it.
>
> Interesting. That would be a nice bit of logic to simplify; I will put it
> on the TODO list.
I just explored this a bit. Unfortunately, I don't think it's sufficient.
The problem is related to a scenario you mentioned earlier -- e.g.:
ifconfig ipmp0 ipmp group ipmp1
ifconfig ce0 group a
In this case, the second ifconfig invocation will try to use the dynamic
PPA assignment code to find the next available ipmpN. The kernel will
pick ipmp1, since 1 is the next available PPA. However, since there's
already a group named "ipmp1", ipif_set_values_tail() will fail with
EEXIST (after the fix I mentioned in my previous email). Thus the
SIOCSLIFNAME will fail with EEXIST too, when it should've just plumbed
"ipmp2" instead.
I don't see any non-hacky way to have the kernel handle this case.
I could do a hybrid approach of trying to have the kernel choose a PPA
(which will almost always work), and then fallback to the old brute-force
way if it returns EEXIST. This would improve performance a little in the
case where there are a lot of groups, but does ugly-up the code a bit.
BTW, while exploring this problem, I found that the illgrp creation code
was in the wrong place. It should be done as part of I_PLINK rather than
as part of ipif_set_values_tail(). Otherwise, if an application (e.g.,
ifconfig) closes the socket after doing the SIOCSLIFNAME but before doing
the I_PLINK, the illgrp created in ipif_set_values_tail() will never be
destroyed. Moving creation to I_PLINK makes it symmetric with destruction
(which is in I_PUNLINK), and also automatically handles the
ipmp_grp_destroy() problem that you brought up in ipif_set_values_tail().
--
meem
