[Swan-dev] [libreswan RFC 2/3] pluto, whack: Add nic-offload 'auto' mode

[Paul Wouters]

On Mon, 31 Jul 2017, Ilan Tayari wrote:

>>> It's designed to be compatible anywhere ethtool -k works.
>>> This was introduced around kernel 2.6.38, circa 2011
>>
>> We do still have embedded people, and people on 2.4.x kernels. I think
>> it is safe to assume that if these detection routines fail, we go back
>> to being "no" without attempting to add_sa() twice for each IPsec SA?
>
> Yes, code will treat lack of ETH_SS_FEATURES as if kernel does not
> support the feature (e.g. auto=no)

Ok, sounds good.

> The kernel-wide check is done once only.
>
> Unfortunately it cannot be done on init because the IOCTL requires a real
> device even though it checks for kernel-wide support.
> So I deferred it to the time an SA is installed, but only if it wasn't
> checked already.

Also sounds good.

> The per-device check is done every time an SA is installed (a single ioctl)
> but only if the kernel-wide support exists.
> Each SA might be on a different device, so it must happen at least once
> per device.
> I didn't want to cache these per-device, do you think it's a good idea?

It might make sense to add property to the struct iface_port (see
server.h) so we at least don't have to send a kernel_netlink message
each time? That way the nic-offload state can be unknown,yes,no for the
device. When a device changes (are we detect this in the future, or for
now when whack --listen is called) we set it all back to unknown which
woudl trigger a onetime kernel_netlink message to get the nic-offload
support of the device?

> I tend to think handling such cache is more trouble than gain in this case.

Well, we only have few devices in general and many thousands
connections. So I think it is worth it.

>> I'll reread through the patches again - it's been a while.

> Please do review them, if you can.

Still on my todo list,

Paul