From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: David Miller <davem@davemloft.net>,
David Ahern <dsahern@gmail.com>,
aring@mojatatu.com, Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Linux Netdev List <netdev@vger.kernel.org>,
oss-drivers@netronome.com,
Quentin Monnet <quentin.monnet@netronome.com>
Subject: Re: [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper
Date: Sat, 20 Jan 2018 03:12:46 -0800 [thread overview]
Message-ID: <CAJpBn1zAog2SSRLNG4xJFf8tb4mQWO6Y5MtwFHNr15Ao9FnL9g@mail.gmail.com> (raw)
In-Reply-To: <20180120105427.GG2147@nanopsycho.orion>
On Sat, Jan 20, 2018 at 2:54 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Sat, Jan 20, 2018 at 11:33:31AM CET, jakub.kicinski@netronome.com wrote:
>>On Sat, Jan 20, 2018 at 2:22 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Sat, Jan 20, 2018 at 11:12:25AM CET, jakub.kicinski@netronome.com wrote:
>>>>net/sched/sch_prio.c: if (!tc_can_offload(dev) ||
>>>>!dev->netdev_ops->ndo_setup_tc)
>>>>net/sched/sch_prio.c: if (!tc_can_offload(dev) ||
>>>>!dev->netdev_ops->ndo_setup_tc)
>>>>net/sched/sch_red.c: if (!tc_can_offload(dev) ||
>>>>!dev->netdev_ops->ndo_setup_tc)
>>>>net/sched/sch_red.c: if (!tc_can_offload(dev) ||
>>>>!dev->netdev_ops->ndo_setup_tc)
>>>>
>>>>Do you mean the qdisc offloads too? The whole lot?
>>>
>>> Yes.
>>
>>Actually looking at the qdisc code and destroy callbacks, if we plumb
>>it through everywhere won't that mean user will see error messages on
>>destroy of qdiscs/filters which were never offloaded?
>>
>>Just looking at prio_offload() as a simple example. prio_destroy()
>>will always call tc_can_offload().
>
> Hmmm. You are right.
> Either we pass null from there (NL_SET_ERR_MSG can cope), or we leave
> tc_can_offload helper as is and let the caller to set the extack.
I'm afraid it doesn't stop there though :/ Even now if one install a
filter on a netdev with offload abilities and no skip_* flag there is
this:
# tc filter add dev eth0 ingress bpf obj drop.o da
Warning: TC offload is disabled on net device.
I'm not sure we should warn the user if there are no skip_* flags,
just because the device has *some* offload capabilities? Perhaps we
should put the flags into tc_cls_common_offload and add a helper to
only set extack if skip_sw is set..
> I see that tc_can_offload_extack is probably good idea then.
>
> But please use it in all drivers that are calling tc_can_offload so the
> user experience is consistent for all.
Certainly, will do.
next prev parent reply other threads:[~2018-01-20 11:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 1:44 [PATCH net-next v4 0/8] net: sched: add extack support for cls offloads Jakub Kicinski
2018-01-20 1:44 ` [PATCH net-next v4 1/8] net: sched: cls_flower: propagate extack support for filter offload Jakub Kicinski
2018-01-20 1:44 ` [PATCH net-next v4 2/8] net: sched: cls_matchall: " Jakub Kicinski
2018-01-20 1:44 ` [PATCH net-next v4 3/8] net: sched: cls_u32: " Jakub Kicinski
2018-01-20 1:44 ` [PATCH net-next v4 4/8] net: sched: cls_bpf: plumb extack support in filter for hardware offload Jakub Kicinski
2018-01-20 1:44 ` [PATCH net-next v4 5/8] net: sched: add extack support for offload via tc_cls_common_offload Jakub Kicinski
2018-01-20 8:54 ` Jiri Pirko
2018-01-20 10:28 ` Jakub Kicinski
2018-01-20 1:44 ` [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper Jakub Kicinski
2018-01-20 8:59 ` Jiri Pirko
2018-01-20 10:12 ` Jakub Kicinski
2018-01-20 10:22 ` Jiri Pirko
2018-01-20 10:33 ` Jakub Kicinski
2018-01-20 10:54 ` Jiri Pirko
2018-01-20 11:12 ` Jakub Kicinski [this message]
2018-01-20 1:44 ` [PATCH net-next v4 7/8] nfp: bpf: plumb extack into functions related to XDP offload Jakub Kicinski
2018-01-20 1:44 ` [PATCH net-next v4 8/8] nfp: bpf: use extack support to improve debugging Jakub Kicinski
2018-01-22 21:32 ` [PATCH net-next v4 0/8] net: sched: add extack support for cls offloads David Miller
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=CAJpBn1zAog2SSRLNG4xJFf8tb4mQWO6Y5MtwFHNr15Ao9FnL9g@mail.gmail.com \
--to=jakub.kicinski@netronome.com \
--cc=alexei.starovoitov@gmail.com \
--cc=aring@mojatatu.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
--cc=quentin.monnet@netronome.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).