netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Vlad Buslov <vladbu@mellanox.com>
Cc: netdev@vger.kernel.org, jhs@mojatatu.com,
	xiyou.wangcong@gmail.com, jiri@resnulli.us, davem@davemloft.net,
	pablo@netfilter.org
Subject: Re: [PATCH net-next v3 00/10] Refactor cls hardware offload API to support rtnl-independent drivers
Date: Mon, 26 Aug 2019 10:48:01 -0700	[thread overview]
Message-ID: <20190826104801.70b5edaa@cakuba.netronome.com> (raw)
In-Reply-To: <20190826134506.9705-1-vladbu@mellanox.com>

On Mon, 26 Aug 2019 16:44:56 +0300, Vlad Buslov wrote:
> Currently, all cls API hardware offloads driver callbacks require caller
> to hold rtnl lock when calling them. This patch set introduces new API
> that allows drivers to register callbacks that are not dependent on rtnl
> lock and unlocked classifiers to offload filters without obtaining rtnl
> lock first, which is intended to allow offloading tc rules in parallel.
> 
> Recently, new rtnl registration flag RTNL_FLAG_DOIT_UNLOCKED was added.
> TC rule update handlers (RTM_NEWTFILTER, RTM_DELTFILTER, etc.) are
> already registered with this flag and only take rtnl lock when qdisc or
> classifier requires it. Classifiers can indicate that their ops
> callbacks don't require caller to hold rtnl lock by setting the
> TCF_PROTO_OPS_DOIT_UNLOCKED flag. Unlocked implementation of flower
> classifier is now upstreamed. However, this implementation still obtains
> rtnl lock before calling hardware offloads API.
> 
> Implement following cls API changes:
> 
> - Introduce new "unlocked_driver_cb" flag to struct flow_block_offload
>   to allow registering and unregistering block hardware offload
>   callbacks that do not require caller to hold rtnl lock. Drivers that
>   doesn't require users of its tc offload callbacks to hold rtnl lock
>   sets the flag to true on block bind/unbind. Internally tcf_block is
>   extended with additional lockeddevcnt counter that is used to count
>   number of devices that require rtnl lock that block is bound to. When
>   this counter is zero, tc_setup_cb_*() functions execute callbacks
>   without obtaining rtnl lock.
> 
> - Extend cls API single hardware rule update tc_setup_cb_call() function
>   with tc_setup_cb_add(), tc_setup_cb_replace(), tc_setup_cb_destroy()
>   and tc_setup_cb_reoffload() functions. These new APIs are needed to
>   move management of block offload counter, filter in hardware counter
>   and flag from classifier implementations to cls API, which is now
>   responsible for managing them in concurrency-safe manner. Access to
>   cb_list from callback execution code is synchronized by obtaining new
>   'cb_lock' rw_semaphore in read mode, which allows executing callbacks
>   in parallel, but excludes any modifications of data from
>   register/unregister code. tcf_block offloads counter type is changed
>   to atomic integer to allow updating the counter concurrently.
> 
> - Extend classifier ops with new ops->hw_add() and ops->hw_del()
>   callbacks which are used to notify unlocked classifiers when filter is
>   successfully added or deleted to hardware without releasing cb_lock.
>   This is necessary to update classifier state atomically with callback
>   list traversal and updating of all relevant counters and allows
>   unlocked classifiers to synchronize with concurrent reoffload without
>   requiring any changes to driver callback API implementations.
> 
> New tc flow_action infrastructure is also modified to allow its user to
> execute without rtnl lock protection. Function tc_setup_flow_action() is
> modified to conditionally obtain rtnl lock before accessing action
> state. Action data that is accessed by reference is either copied or
> reference counted to prevent concurrent action overwrite from
> deallocating it. New function tc_cleanup_flow_action() is introduced to
> cleanup/release all such data obtained by tc_setup_flow_action().
> 
> Flower classifier (only unlocked classifier at the moment) is modified
> to use new cls hardware offloads API and no longer obtains rtnl lock
> before calling it.

Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>

  parent reply	other threads:[~2019-08-26 17:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26 13:44 [PATCH net-next v3 00/10] Refactor cls hardware offload API to support rtnl-independent drivers Vlad Buslov
2019-08-26 13:44 ` [PATCH net-next v3 01/10] net: sched: protect block offload-related fields with rw_semaphore Vlad Buslov
2019-08-26 15:39   ` Jiri Pirko
2019-08-26 13:44 ` [PATCH net-next v3 02/10] net: sched: change tcf block offload counter type to atomic_t Vlad Buslov
2019-08-26 13:44 ` [PATCH net-next v3 03/10] net: sched: refactor block offloads counter usage Vlad Buslov
2019-08-26 15:46   ` Jiri Pirko
2019-08-26 13:45 ` [PATCH net-next v3 04/10] net: sched: notify classifier on successful offload add/delete Vlad Buslov
2019-08-26 15:51   ` Jiri Pirko
2019-08-26 13:45 ` [PATCH net-next v3 05/10] net: sched: add API for registering unlocked offload block callbacks Vlad Buslov
2019-08-28 11:53   ` tanhuazhong
2019-08-28 14:15     ` Vlad Buslov
2019-08-26 13:45 ` [PATCH net-next v3 06/10] net: sched: conditionally obtain rtnl lock in cls hw offloads API Vlad Buslov
2019-08-26 18:13   ` Jiri Pirko
2019-08-26 13:45 ` [PATCH net-next v3 07/10] net: sched: take rtnl lock in tc_setup_flow_action() Vlad Buslov
2019-08-26 13:45 ` [PATCH net-next v3 08/10] net: sched: take reference to action dev before calling offloads Vlad Buslov
2019-08-26 13:45 ` [PATCH net-next v3 09/10] net: sched: copy tunnel info when setting flow_action entry->tunnel Vlad Buslov
2019-08-26 13:45 ` [PATCH net-next v3 10/10] net: sched: flower: don't take rtnl lock for cls hw offloads API Vlad Buslov
2019-08-26 17:48 ` Jakub Kicinski [this message]
2019-08-26 21:18 ` [PATCH net-next v3 00/10] Refactor cls hardware offload API to support rtnl-independent drivers 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=20190826104801.70b5edaa@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=vladbu@mellanox.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).