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

[Andrew Cagney]

On Wed, 17 Jan 2024 at 21:35, Paul Wouters <paul at nohats.ca> wrote:
>
> 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)

Then the config parameter and whack options should both be renamed to
(the horrible) esp-hw-offload=
Someone seeing esp-hw-offload=crypto is going to look for that text in
our documentation and usage messages, not nic-offload=

> 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.

How is it fragile?

Code for what is, not for what might be.