From: Simon Horman <simon.horman@corigine.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Vlad Buslov <vladbu@nvidia.com>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Cong Wang <xiyou.wangcong@gmail.com>,
Jiri Pirko <jiri@mellanox.com>,
netdev@vger.kernel.org, oss-drivers@corigine.com,
Baowen Zheng <baowen.zheng@corigine.com>,
Louis Peens <louis.peens@corigine.com>
Subject: Re: [PATCH net-next 1/3] flow_offload: allow user to offload tc action to net device
Date: Tue, 27 Jul 2021 15:04:23 +0200 [thread overview]
Message-ID: <20210727130419.GA6665@corigine.com> (raw)
In-Reply-To: <13f494c9-e7f0-2fbb-89f9-b1500432a2f6@mojatatu.com>
On Thu, Jul 22, 2021 at 09:33:09AM -0400, Jamal Hadi Salim wrote:
> On 2021-07-22 9:29 a.m., Vlad Buslov wrote:
> > On Thu 22 Jul 2021 at 12:19, Simon Horman <simon.horman@corigine.com> wrote:
> > > From: Baowen Zheng <baowen.zheng@corigine.com>
> > >
> > > Use flow_indr_dev_register/flow_indr_dev_setup_offload to
> > > offload tc action.
> > >
> > > We offload the tc action mainly for ovs meter configuration.
> > > Make some basic changes for different vendors to return EOPNOTSUPP.
> > >
> > > We need to call tc_cleanup_flow_action to clean up tc action entry since
> > > in tc_setup_action, some actions may hold dev refcnt, especially the mirror
> > > action.
> > >
> > > As per review from the RFC, the kernel test robot will fail to run, so
> > > we add CONFIG_NET_CLS_ACT control for the action offload.
> > >
> > > Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com>
> > > Signed-off-by: Louis Peens <louis.peens@corigine.com>
> > > Signed-off-by: Simon Horman <simon.horman@corigine.com>
> > > ---
> > > drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 2 +-
> > > .../ethernet/mellanox/mlx5/core/en/rep/tc.c | 3 ++
>
> > > void *data,
> > > void (*cleanup)(struct flow_block_cb *block_cb))
> > > {
> > > + if (!netdev)
> > > + return -EOPNOTSUPP;
> > > +
> > > switch (type) {
> > > case TC_SETUP_BLOCK:
> > > return mlx5e_rep_indr_setup_block(netdev, sch, cb_priv, type_data,
> > > diff --git a/drivers/net/ethernet/netronome/nfp/flower/offload.c b/drivers/net/ethernet/netronome/nfp/flower/offload.c
>
> [..]
>
> > > + /* offload actions to hardware if possible */
> > > + tcf_action_offload_cmd(actions, extack);
> > > +
> >
> > I think this has already been suggested for RFC, but some sort of
> > visibility for offload status of action would be extremely welcome.
> > Perhaps "IN_HW" flag and counter, similar to what we have for offloaded
> > filters.
> >
>
> Also showing a tc command line in the cover letter on how one would
> ask for a specific action to be offloaded.
In practice actions are offloaded when a flow using them is offloaded.
So I think we need to consider what the meaning of IN_HW is.
Is it that:
* The driver (and potentially hardware, though not in our current
implementation) has accepted the action for offload;
* That a classifier that uses the action has bee offloaded;
* Or something else?
With regards to a counter, I'm not quite sure what this would be:
* The number of devices where the action has been offloaded (which ties
into the question of what we mean by IN_HW)
* The number of offloaded classifier instances using the action
* Something else
Regarding a flag to control offload:
* For classifiers (at least the flower classifier) there is the skip_sw and
skip_hw flags, which allow control of placement of a classifier in SW and
HW.
* We could add similar flags for actions, which at least in my
world view would have the net-effect of controlling which classifiers can
be added to sw and hw - f.e. a classifier that uses an action marked
skip_hw could not be added to HW.
* Doing so would add some extra complexity and its not immediately apparent
to me what the use-case would be given that there are already flags for
classifiers.
next prev parent reply other threads:[~2021-07-27 13:04 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-22 9:19 [PATCH net-next 0/3] flow_offload: hardware offload of TC actions Simon Horman
2021-07-22 9:19 ` [PATCH net-next 1/3] flow_offload: allow user to offload tc action to net device Simon Horman
2021-07-22 12:24 ` Roi Dayan
2021-07-22 13:19 ` Simon Horman
2021-07-22 13:29 ` Vlad Buslov
2021-07-22 13:33 ` Jamal Hadi Salim
2021-07-27 13:04 ` Simon Horman [this message]
2021-07-27 14:38 ` Vlad Buslov
2021-07-27 16:13 ` Jamal Hadi Salim
2021-07-27 16:47 ` Vlad Buslov
2021-07-28 7:46 ` Simon Horman
2021-07-28 8:05 ` Vlad Buslov
2021-07-28 13:51 ` Jamal Hadi Salim
2021-07-28 14:46 ` Simon Horman
2021-07-30 10:17 ` Jamal Hadi Salim
2021-07-30 11:40 ` Vlad Buslov
2021-08-03 9:57 ` Jamal Hadi Salim
2021-08-03 12:02 ` tc offload debug-ability Jamal Hadi Salim
2021-08-03 12:14 ` Vlad Buslov
2021-08-03 12:50 ` Jamal Hadi Salim
2021-08-03 13:34 ` Ido Schimmel
2021-07-30 13:20 ` [PATCH net-next 1/3] flow_offload: allow user to offload tc action to net device Simon Horman
2021-08-03 10:14 ` Jamal Hadi Salim
2021-08-03 11:36 ` Simon Horman
2021-08-03 11:45 ` Jamal Hadi Salim
2021-08-03 12:31 ` Simon Horman
2021-08-03 13:01 ` Jamal Hadi Salim
2021-08-03 14:46 ` Simon Horman
2021-07-22 13:57 ` kernel test robot
2021-07-22 13:57 ` kernel test robot
2021-07-22 15:31 ` kernel test robot
2021-07-22 15:31 ` kernel test robot
2021-08-03 10:50 ` Jamal Hadi Salim
2021-08-03 11:05 ` Jamal Hadi Salim
2021-08-03 11:31 ` Simon Horman
2021-07-22 9:19 ` [PATCH net-next 2/3] flow_offload: add process to delete offloaded actions from " Simon Horman
2021-07-22 14:25 ` Vlad Buslov
2021-07-22 14:50 ` kernel test robot
2021-07-22 14:50 ` kernel test robot
2021-07-22 17:07 ` kernel test robot
2021-07-22 17:07 ` kernel test robot
2021-08-03 10:59 ` Jamal Hadi Salim
2021-07-22 9:19 ` [PATCH net-next 3/3] flow_offload: add process to update action stats from hardware Simon Horman
2021-07-22 14:55 ` Vlad Buslov
2021-08-03 11:24 ` Jamal Hadi Salim
2021-08-03 11:35 ` Simon Horman
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=20210727130419.GA6665@corigine.com \
--to=simon.horman@corigine.com \
--cc=baowen.zheng@corigine.com \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@mellanox.com \
--cc=kuba@kernel.org \
--cc=louis.peens@corigine.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@corigine.com \
--cc=vladbu@nvidia.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.