Re: [PATCH (repost) net-next] sched: add extack for tfilter_notify

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 8 Nov 2022 17:11:22 +0800 Hangbin Liu wrote:
> On Wed, Nov 02, 2022 at 04:36:46PM -0700, Jakub Kicinski wrote:
> > Eish.
> > 
> > Hangbin, I'm still against this. Please go back to my suggestions /
> > questions. A tracepoint or an attribute should do. Multi-part messages
> > are very hard to map to normal programming constructs, and I don't
> > think there is any precedent for mutli-part notifications.  
> 
> Hi Jakub,
> 
> I checked the doc[1], the NLMSGERR_ATTR_MSG could only be in NLMSG_ERROR and
> NLMSG_DONE messages. But the tfilter_notify() set the nlmsg type to
> RTM_NEWTFILTER. Would you like to help explain what you mean of using
> attribute? Should I send a NLMSG_ERROR/NLMSG_DONE message separately after the
> tfilter_notify()?
> 
> [1] https://www.kernel.org/doc/html//next/userspace-api/netlink/intro.html#ext-ack

My initial thought was to add an attribute type completely independent
of the attribute space defined in enum nlmsgerr_attrs, add it in the
TCA_* space. So for example add a TCA_NTF_WARN_MSG which will carry the
string message.

We can also create a nest to carry the full nlmsgerr_attrs attributes
with their existing types (TCA_NTF_EXT_ACK?). Each nest gets
to choose what attribute set it carries.

That said, most of the ext_ack attributes refer to an input attribute by
specifying the offset within the request. The notification recipient
will not be able to resolve those in any meaningful way. So since only
the string message will be of interest I reckon adding a full nest is
an unnecessary complication?