Peter Memishian wrote:
> > > Some background: I ran into this question when I was trying to
> > > coalesce the various duplicated calls of the form:
> > > if (IPIF_CAN_LOOKUP(..)) {
> > > :
> > > } else if IPIF_CAN_WAIT(..) {
> > > :
> > > }
> > > (See CR 6606222)
> >
> > Once Clearview IPMP integrates I think we can actually remove all cases
> > of IPIF_CAN_WAIT.
>
> Sadly, I don't think this is the case -- ill_down_ipifs() and
> ip_sioctl_lnkinfo() still make use of IPIF_CHANGING post-Clearview-IPMP.
> (Unless you're planning to rewrite those?)
I think those are a lot easier to handle than the IPMP movement.
For instance, today we set ipif_changing just because the MTU or some
address field in the ipif_t is changing, but we don't need to have the
bind() system call go asynchronous just because of such a change; the
ipsq already prevents more than one thread changing them at a time.
>
> > Thus I don't think it makes sense trying to improve the use of
> > IPIF_CAN_WAIT right now.
>
> While I'm not too concerned about IPIF_CAN_WAIT() in particular, I *am*
> concerned about the amount of duplication present in code that makes use
> of it and its brethren. For instance, almost all of
> ill_lookup_on_ifindex() has been duplicated into ipif_lookup_on_ifindex(),
> rather than refactoring ipif_lookup_on_ifindex() to call
> ill_lookup_on_ifindex().
From a microscopic perspective such code duplication is bad.
But I'm looking at the macroscopic complexity across 140,000 or 200,000
lines of code and it is pretty clear that the asynchrony is the biggest
source of complexity.
How hard it would be to remove the complexity is a different matter, but
I think being able to have a synchronous bind() kernel code path
shouldn't be that hard.
Erik
ip_newroute delenda est
_______________________________________________
networking-discuss mailing list
[email protected]
