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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.