From: Jakub Kicinski <kuba@kernel.org>
To: Hangbin Liu <liuhangbin@gmail.com>, Jamal Hadi Salim <jhs@mojatatu.com>
Cc: netdev@vger.kernel.org, Cong Wang <xiyou.wangcong@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, David Ahern <dsahern@kernel.org>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Subject: Re: [PATCH (repost) net-next] sched: add extack for tfilter_notify
Date: Fri, 30 Sep 2022 19:03:31 -0700 [thread overview]
Message-ID: <20220930190331.3b830b2a@kernel.org> (raw)
In-Reply-To: <20220929033505.457172-1-liuhangbin@gmail.com>
On Thu, 29 Sep 2022 11:35:05 +0800 Hangbin Liu wrote:
> In commit 81c7288b170a ("sched: cls: enable verbose logging") Marcelo
> made cls could log verbose info for offloading failures, which helps
> improving Open vSwitch debuggability when using flower offloading.
>
> It would also be helpful if "tc monitor" could log this message, as it
> doesn't require vswitchd log level adjusment. Let's add the extack message
> in tfilter_notify so the monitor program could receive the failures.
> e.g.
The title read as "just another extack addition" but this is much
more than that :S
Jamal, you may want to take a look.
> # tc monitor
> added chain dev enp3s0f1np1 parent ffff: chain 0
> added filter dev enp3s0f1np1 ingress protocol all pref 49152 flower chain 0 handle 0x1
> ct_state +trk+new
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 1 ref 1 bind 1
>
> Warning: mlx5_core: matching on ct_state +new isn't supported.
>
> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
>
> Rebase the patch to latest net-next as the previous could not
> apply to net-next.
> + nlh = nlmsg_put(skb, portid, seq, event, sizeof(*tcm),
> + (extack && extack->_msg) ? flags | NLM_F_MULTI : flags);
> +
> + if (extack && extack->_msg) {
> + nlh = nlmsg_put(skb, portid, seq, NLMSG_DONE, 0, flags | NLM_F_ACK_TLVS);
> + if (!nlh)
> + goto out_nlmsg_trim;
> +
> + if (nla_put_string(skb, NLMSGERR_ATTR_MSG, extack->_msg))
> + goto nla_put_failure;
> +
> + nlmsg_end(skb, nlh);
> + }
> +
So you're adding a fake* _F_MULTI on the notification just so you
can queue a NLMSG_DONE after and not break the "NLMSG_DONE terminates
a _F_MUTLI" sequence rule?
* fake as in there's only one message, there's no multi-ness here.
I don't think _F_MULTI should be treated lightly and I don't think
NLMSG_DONE as part of notification sequences is a good idea either :(
(1) does the tracepoint not give you want you need?
(netlink:netlink_extack), failing that -
(2) why not wrap the extack msg in an attribute
next prev parent reply other threads:[~2022-10-01 2:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 3:35 [PATCH (repost) net-next] sched: add extack for tfilter_notify Hangbin Liu
2022-10-01 2:03 ` Jakub Kicinski [this message]
2022-10-01 18:39 ` Cong Wang
2022-10-01 20:39 ` Marcelo Ricardo Leitner
2022-10-02 15:27 ` Jamal Hadi Salim
2022-10-26 9:58 ` Hangbin Liu
2022-11-02 1:26 ` Hangbin Liu
2022-11-02 15:33 ` Jamal Hadi Salim
2022-11-02 23:36 ` Jakub Kicinski
2022-11-04 2:39 ` Hangbin Liu
2022-11-08 9:11 ` Hangbin Liu
2022-11-08 18:55 ` Jakub Kicinski
2022-11-09 11:53 ` Hangbin Liu
2022-11-10 1:52 ` Jamal Hadi Salim
2022-11-10 2:20 ` Jakub Kicinski
2022-11-10 6:29 ` Hangbin Liu
2022-11-10 17:12 ` Jakub Kicinski
2022-11-10 14:27 ` Jamal Hadi Salim
2022-11-10 17:27 ` Jakub Kicinski
2022-11-15 3:07 ` Hangbin Liu
2022-11-15 4:51 ` Jakub Kicinski
2022-11-15 12:42 ` Jamal Hadi Salim
2022-11-15 12:44 ` Hangbin Liu
2022-11-15 13:13 ` Jamal Hadi Salim
2022-11-15 13:57 ` Hangbin Liu
2022-11-15 16:26 ` Jamal Hadi Salim
2022-11-17 8:42 ` Hangbin Liu
2022-11-29 8:07 ` Hangbin Liu
2022-11-29 15:43 ` Jakub Kicinski
2022-11-30 8:44 ` Hangbin Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220930190331.3b830b2a@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=liuhangbin@gmail.com \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).