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

Paul Wouters paul at nohats.ca
Mon Jul 31 13:51:27 UTC 2017


On Mon, 31 Jul 2017, Ilan Tayari wrote:

>> For the second and the third patch here is my suggestion.
>>
>> no|yes|auto is probably better keywords in the libreswan context.
>> Libreswan do not use first letter capitalizing as you proposed.
>
> Sure, no problem, I'll change in v2
>
>>
>> I am not sure about making auto default. Paul would ethtool detection work
>> on RHEL 6.x?  Ilan have tested this on RHEL/CentOS 6.x, without a Mellanox
>> NIC?
>
> 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?

> On a machine with older kernel (prior to 4.11), it detects lack of the capability.
> On machine with newer kernel, but incapable NIC, it also detects lack of the capability.
>
> In both cases, 'auto' behaves as 'no'
>
> Paul, can you comment on this behavior?

That sounds good with me. It is important that we do not do these checks
every SA and that we detect the lack of capability in the kernel once on
startup. Otherwise, it will cause a delay for each tunnel, which adds up
if you run thousands+ tunnels. So the only add_sa() retry without
offload should happen when we see unexpected errors from a supported
card.

Are any of the NIC cards that support this offload hotpluggable? If not,
we could also ensure this is only probed on startup.

I'll reread through the patches again - it's been a while. But I think
we are in good shape for them, as long we can still compile on older
systems, so we should make sure we agree on when to use our own copy
of xfrm.h / {rt}netlink.h and when to use our bundled versions. AFAIK,
these files are always backwards compatible, so we can always use a
newer version, except the kernel might not support all options we are
aware of.

Paul


More information about the Swan-dev mailing list