Subject: Re: [PATCH v2 net-next 3/6] sfc: optional logging of TC offload errors

From: Jakub Kicinski <[email-masked]>
Date: Wed, 28 Sep 2022 11:32:53 -0700

On Wed, 28 Sep 2022 19:17:51 +0100 Edward Cree wrote:
> > Because extack does not work somehow?  
> 
> Last I checked, flow rules coming from an indirect binding to a tunnel
>  netdev did not report the hw driver's extack (or even rc) back to the
>  user.
> Also, extack can only contain fixed strings (netlink.h: "/* Currently
>  string formatting is not supported (due to the lack of an output
>  buffer.) */") which was a real problem for us.
> 
> > Somehow you limitations are harder to debug that everyone else's so you
> > need a private flag? :/  
> 
> It's not about debugging the driver, it's about communicating the
>  limitations to the end user.  Having TC rules mysteriously fail to be
>  offloaded with no indication of why is not a great UX :(

Yes, but everyone has the same problem.

> I couldn't see a way to handle this without vendor-specific ugliness,
>  but if you have a proposal I don't mind putting in some work to
>  implement it.

I won't help with the indirect stuff, I fixed it once a while
back already and it keeps getting broken. It must be a case of 
the extack not being plumbed thru, or people being conservative
because the errors are not fatal, right? Solvable.

The printf'ing? I recon something simple like adding a destructor 
for the message to the exack struct so you can allocate the message, 
or adding a small buffer in place (the messages aren't very long,
usually) come to mind.