[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190826.141817.262857334547814479.davem@davemloft.net>
Date: Mon, 26 Aug 2019 14:18:17 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: vladbu@...lanox.com
Cc: netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
jiri@...nulli.us, jakub.kicinski@...ronome.com, pablo@...filter.org
Subject: Re: [PATCH net-next v3 00/10] Refactor cls hardware offload API to
support rtnl-independent drivers
From: Vlad Buslov <vladbu@...lanox.com>
Date: Mon, 26 Aug 2019 16:44:56 +0300
> 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.
...
Looks good, series applied, thanks.
Powered by blists - more mailing lists