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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
