> sowmini.varadhan at Sun.COM wrote: > >> Agreed, but can we do #3 without essentially getting rid of ip_newroute > >> (at least making ip_newroute return an ire) and as a result have to > >> rewhack the MULTIRT loops? > > > > How so? ip_newroute itself has some of the MULTIRT loops :-( > > I don't understand your question.
I meant the following: in the past, when I have tried to think about doing this in a surya-like manner (where the ip_newroute() call from ip_rput_noire() was changed so that it gets back an incomplete ire but still continues on), things always get sticky because of ipsec, cgtp etc. The forwarding path was easier to massage because many of these features (e.g., cgtp) were not pertinent to the forwarding path. So I was trying to understand your proposal for having ip_newroute return an ire and having the caller continue on with that ire. > My point is that I have no idea (and it seems very very hard) to find > some minimal changes to the code base to allow unresolved ire/nces in > the xmit path, largely because of the interaction of multirt and > ip_newroute. > > But perhaps I'm not exploring solutions that require us to add lots more > code - since I prefer deleting and refactoring code. I think refactoring the code is unavoidable.. --Sowmini
