[Swan-dev] pluto: tweak logging and ipsec traffic for HW offload

[Paul Wouters]

On Wed, 17 Jan 2024, Andrew Cagney wrote:

> Much better - keeping with one log line for establishing the child.  BTW,
>  {ESP/ESN... esp-hw-offload=packet ...}
> could be reduced further to:
>  {ESP/ESN... nic-offload=packet ...}
> so the field matches the config file name, or even:
>  {ESP/ESN... offload=packet ...}
> since "esp" and "hw" are redundant here

Yes, but Linux/Nvidia seems to be using esp-hw-offload= as the term for
this, eg when checking the nic with "ethtool -S", which is why I'm
using this term here (and why I used it all the way back in bb244abb4b4)

Also, offload=crypto is confusing on its own. Does this mean CPU AESNI
aes-gcm ghash offloading, or only offloading of the nic. With esp-hw-offload
this is clear(er), although it does not say "nic" and with crypto mode,
it is not "offloading the esp". But I thought it better to stick with
the term used within the other tools and diasgnostics as well.

>>     Also show this in trafficstatus:
>>
>>     Since the new output appears as part of the ESP string before the
>>     existing comma, this shouldn't break people parsing this output.
>>
>>     We don't yet remember the crypto in a state variable, so unfortunately
>>     this uses c->iface->nic_offload with c->config->nic_offload to determine
>>     crypto state. This should really get moved to somewhere in struct state.
>
> You mean h/w offload status?  It isn't negotiated, and no fallback is
> allowed, hence c->config->nic_offload is always correct.
> (yes, there's a rumor that Linux can silently fall back to software
> when crypto, but pluto can't see that).

Yes, which is why I opted to go this way for now. But it seems fragile
for future cases. But we can revisit that once it becomes needed.

Paul