From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: jiri@resnulli.us
Cc: netdev@vger.kernel.org, oss-drivers@netronome.com,
dsahern@gmail.com, Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: [RFC net-next 0/8] use tc_can_offload_extack() throughout the drivers
Date: Tue, 23 Jan 2018 13:33:32 -0800 [thread overview]
Message-ID: <20180123213340.19235-1-jakub.kicinski@netronome.com> (raw)
Hi!
I have a number of patches for drivers to use tc_can_offload_extack()
as requested, but I wanted to ask for early comments and one specific
question - should we assume that type_data in block_cbs is always going
to contain struct tc_cls_common_offload as first argument? In that
case we could just make it that struct instead of void?
It wasn't clear to me this assumption was safe therefore I pushed the
checks after enum tc_setup_type is checked against known values. And
there is only one driver now (cxgb4) which supports two classifiers in
the same code base, so checking tc_can_offload before type_data is
cast doesn't buy much LOC.
Jiri, WDYT?
(i40e patch is queued up for later to avoid conflicts.)
Jakub Kicinski (8):
pkt_cls: make tc_can_offload_extack() check chain index
mlx5: use tc_can_offload_cls()
mlxsw: use tc_can_offload_cls()
cls_bpf: drivers: don't try to use extack before callback type is
validated
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 7 ++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 5 +----
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 5 +----
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 5 +----
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 +----
drivers/net/ethernet/netronome/nfp/bpf/main.c | 9 ++-------
drivers/net/ethernet/netronome/nfp/flower/offload.c | 11 +++--------
drivers/net/netdevsim/bpf.c | 10 ++--------
include/net/pkt_cls.h | 20 +++++++++++++-------
12 files changed, 29 insertions(+), 54 deletions(-)
--
2.15.1
next reply other threads:[~2018-01-23 21:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 21:33 Jakub Kicinski [this message]
2018-01-23 21:33 ` [RFC net-next 1/8] pkt_cls: make tc_can_offload_extack() check chain index Jakub Kicinski
2018-01-24 8:28 ` Jiri Pirko
2018-01-24 8:53 ` Jakub Kicinski
2018-01-23 21:33 ` [RFC net-next 2/8] bnxt: use tc_can_offload_cls() Jakub Kicinski
2018-01-23 21:33 ` [RFC net-next 3/8] nfp: flower: " Jakub Kicinski
2018-01-23 21:33 ` [RFC net-next 4/8] cxgb4: " Jakub Kicinski
2018-01-23 21:33 ` [RFC net-next 5/8] ixgbe: " Jakub Kicinski
2018-01-23 21:33 ` [RFC net-next 6/8] mlx5: " Jakub Kicinski
2018-01-23 21:33 ` [RFC net-next 7/8] mlxsw: " Jakub Kicinski
2018-01-23 21:33 ` [RFC net-next 8/8] cls_bpf: drivers: don't try to use extack before callback type is validated Jakub Kicinski
2018-01-24 10:25 ` [RFC net-next 0/8] use tc_can_offload_extack() throughout the drivers Jiri Pirko
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=20180123213340.19235-1-jakub.kicinski@netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=dsahern@gmail.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@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).