Re: [RFC PATCH net-next 1/9] net: switchdev: remove the transaction structure from port object notifiers

[Florian Fainelli <f.fainelli@gmail.com>]

On 12/16/2020 5:58 PM, Vladimir Oltean wrote:
> Since the introduction of the switchdev API, port objects were
> transmitted to drivers for offloading using a two-step transactional
> model, with a prepare phase that was supposed to catch all errors, and a
> commit phase that was supposed to never fail.
> 
> Some classes of failures can never be avoided, like hardware access, or
> memory allocation. In the latter case, merely attempting to move the
> memory allocation to the preparation phase makes it impossible to avoid
> memory leaks, since commit 91cf8eceffc1 ("switchdev: Remove unused
> transaction item queue") which has removed the unused mechanism of
> passing on the allocated memory between one phase and another.
> 
> It is time we admit that separating the preparation from the commit
> phase is something that is best left for the driver to decide, and not
> something that should be baked into the API, especially since there are
> no switchdev callers that depend on this.
> 
> This patch removes the struct switchdev_trans member from switchdev port
> object notifier structures, and converts drivers to not look at this
> member.
> 
> Where driver conversion is trivial (like in the case of the Marvell
> Prestera driver, NXP DPAA2 switch, TI CPSW, and Rocker drivers), it is
> done in this patch.
> 
> Where driver conversion needs more attention (DSA, Mellanox Spectrum),
> the conversion is left for subsequent patches and here we only fake the
> prepare/commit phases at a lower level, just not in the switchdev
> notifier itself.
> 
> Where the code has a natural structure that is best left alone as a
> preparation and a commit phase (as in the case of the Ocelot switch),
> that structure is left in place, just made to not depend upon the
> switchdev transactional model.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian