Reduce overhead of IPSEC for traffic generated from host

[eri]

Summary

When IPSEC is enabled on the kernel the forwarding path has an optimization to not enter the code paths
for checking security policies but first checks if there is any security policy active at all.

The patch introduces the same optimization but for traffic generated from the host itself.
This reduces the overhead by 50% on my tests for generated host traffic without and SP active.

[ae]

I think it is acceptable as a workaround of the real problem.
Currently we have initialized INPCB security policy for each PCB, when IPSEC is compiled in. And this is cause of overhead for locally generated traffic. It will be better to initialize inpcbpolicy only when application has configured it. And by default it should be NULL. So, this check can be replaced with if (pcbsp == NULL). This also simplifies the migration to the enabled IPSEC in GENERIC kernel. I have WIP in this area, but currently I'm busy with other tasks.

[eri]

Yes, you are right that this is a workaround.

Also, i am not totally convinced that the SP needs to reside on the PCB at all.
If the code does not reside in PCB all the infrastructure put in protocol specific code is not required at all, maybe TCP-MD5 will just need special handling.
I have looked and am not sure where the requirement of the SP per socket/application comes from.... but for sure that is something to be looked in more general scope.

[ae]

As I see, this code currently is used only by IKE daemons to skip IPSEC processing for packets from IKE.
It seems possible for some application to configure security policies for its packets to require IPSEC protection. But I didn't seen any applications that use this feature.

[eri]

Yes application can put some SPDs.
The PCB is used as a cache for better performance but really not much gain there since it complicates the code and scenarios needed to be considered.
For me the link can be broken and everything treated as in the forwarding path!

I will see to prepare such diff and post it here.

[eri]

So ae@ do you approve this diff to push it?

[gnn]

This will do for now. We may want to revisit how we make this decision later but this should clear the path to IPSEC in GENERIC.