Darren Reed wrote:
Reading through ip.c, time and again I find myself wonder "haven't I just seen this
block of code?" due to the prevalence of similar code blocks repeated.
A good example is the seemingly endless number of loops dealing with multirouting IREs
and another is the duplication of "is this an ipsec packet, if so call something
special".
Is anyone working on refactoring the code to address some of these issues?
Or is it not yet recognised as a problem requiring attention?
I've been thinking about refactoring the transmit data paths, which
would enable using the Surya approach to where ARP is done (doing ARP
from ip_xmit_v4, removing the need to ARP from ip_newroute*) and since
that transforms ip_newroute into a function that returns an ire_t, the
only sane way to move forward is to radically simply the multirt code
structure.
I haven't look explicitly at the (transmit side) IPsec code paths, but a
result of moving ARP to ip_xmit_v4 means that we remove ip_newroute* as
a source of asynchrony. This means that many of the things carried in
the ipsec_out can instead be carries as arguments to functions. And
ipsec processing will all be done by the time we have to wait for some
ARP resolution.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
