On Tue, Feb 25, 2020 at 10:04:22AM -0500, Andrew Cagney wrote: > The libreswan's code base has reached an interesting point. We > support (or are at least trying to support :-) two network interfaces: > > - BSDKAME > - XFRM (does xfrmi qualify as a separate stack?)
no. xfrmi can't work without xfrm. It is just creates an interface for routed vpn. > (ok, there's a third - nokernel but I'm struggling to see its value - > on linux the network stack is prewired to xfrmi etc) and the kernels: > > - BSD* > - Linux > > however currently only one combination is valid: > > - xfrm + linux > - kame + bsd I see DPDK getting popular. AFIK both BSD and Linux would support for it. On Linux DPDK + VPP on Intel Xeon scalable processors looks very promising . So, I 'predict' libreswan DPDK support soon! AFKIK DPDK support can co exist with the native stack. On Linux a connection could choose xfrm or dpdk stack for ESP, data plane path. > So, notionally, kernel_ops is no longer required. While I'm assuming Wonder what would happen when DPDK get addded to both Linux and BSD. > that we're not about to delete it I do think its worth asking its > purpose - like for any portable kernel dependent software the we > struggle with the questions: > > - does this go in kernel_ops - "kernel" for network interface ops > - does this go in kernel_{bsd,linux} - how we have "kernel" for os? ops, hmm, > - does this get wrapped in in #ifdef > > So, what is a "kernel" - we've got two - and as a rule, what should live > where? that is good question. My thoughts are start seperating kernel ops along the following lines. 1. IKE sockets listen and send (network interfaces) - sockets + netlink cb??? 2. address secltion addconn (left=%defaultroute) - netlink 3. address selection using sockets (left=%eth1) - socket calls 4. address changes (MOBIKE) - netlink RTM callbacks. 5. xfrm SADB and SPDB manipulations - netlink add SA, update SA, mobike migration, delete SA, xfrmi, traffic status, and call backs for acquire, timer/byte count expirations. 6. creating ipv6 holes - netlink 7. detecting xfrm ofload - ioctl, possibly also netlink. 8. adding address and refcounting them, leftinterface-ip - netlink 9. in the future we may add route detection - netlink RTM_ call backs. If addconn run before default route is added that connection would not work when default route get added? Currently many of these are grouped together with kernel/xfrm + netlink. > To help things, here are two examples, I don't see either as bad just > illustrations of the compromise: > > - (pre-my recent changes, I should probably rename process_... to merge_...): > > mark_ifaces_dead(); > kernel_ops->process_raw_ifaces(find_raw_ifaces4()); > kernel_ops->process_raw_ifaces(find_raw_ifaces6()); > > find_raw_ifaces[46]() is presumably os specific (and should be > merged); however, is process_raw_ifaces() really part of the network > interface or part of the os? While BSD uses all the parameters passed yes. I would call IKE send and receive. > in, linux does some extra filtering, and I'm not sure why it can't Some of the filtering is to avoid IKE over ipsecX interfaces(from the KLIPs era) I think those are useful also with xfrmi too. > simply be done in find_raw_ifaces(). With my recent changes, that's > become very obvious - the BSD code base has been reduced to a simple > for loop. does BSD has ipsec only interface? if yes would that be selected by addconn? > > - iface_udp.c: > > - #ifdef SOL_UDP - "The SOL (aka socket level) is really the the > protocol number which, for UDP, is always 17. Linux provides a SOL_* > macro, the others don't." - since IPPROTO_UDP is defined, why bother? > - #ifdef SO_PRIORITY - arguably this should live in kernel_linux(?) > but honestly there's only one use and anyone reading code like this > expects this stuff > - its got #ifdef linux - it should probably test for the feature > - its got kernel_ops. - to poke holes in the NETKEY stack so looks reasonable > > and then of course there's the MSG_ERRQUEUE stuff - again it could > live in *_linux, but to what benefit - at least it is currently local > ... _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev