Re: [PATCH net-next v2 00/12][pull request] ice: switchdev bridge offload

[Vlad Buslov <vladbu@nvidia.com>]

On Mon 24 Jul 2023 at 09:11, Tony Nguyen <anthony.l.nguyen@intel.com> wrote:
> Wojciech Drewek says:
>
> Linux bridge provides ability to learn MAC addresses and vlans
> detected on bridge's ports. As a result of this, FDB (forward data base)
> entries are created and they can be offloaded to the HW. By adding
> VF's port representors to the bridge together with the uplink netdev,
> we can learn VF's and link partner's MAC addresses. This is achieved
> by slow/exception-path, where packets that do not match any filters
> (FDB entries in this case) are send to the bridge ports.
>
> Driver keeps track of the netdevs added to the bridge
> by listening for NETDEV_CHANGEUPPER event. We distinguish two types
> of bridge ports: uplink port and VF's representor port. Linux
> bridge always learns src MAC of the packet on rx path. With the
> current slow-path implementation, it means that we will learn
> VF's MAC on port repr (when the VF transmits the packet) and
> link partner's MAC on uplink (when we receive it on uplink from LAN).
>
> The driver is notified about learning of the MAC/VLAN by
> SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events. This is followed by creation
> of the HW filter. The direction of the filter is based on port
> type (uplink or VF repr). In case of the uplink, rule forwards
> the packets to the LAN (matching on link partner's MAC). When the
> notification is received on VF repr then the rule forwards the
> packets to the associated VF (matching on VF's MAC).
>
> This approach would not work on its own however. This is because if
> one of the directions is offloaded, then the bridge would not be able
> to learn the other one. If the egress rule is added (learned on uplink)
> then the response from the VF will be sent directly to the LAN.
> The packet will not got through slow-path, it would not be seen on
> VF's port repr. Because of that, the bridge would not learn VF's MAC.
>
> This is solved by introducing guard rule. It prevents forward rule from
> working until the opposite direction is offloaded.
>
> Aging is not fully supported yet, aging time is static for now. The
> follow up submissions will introduce counters that will allow us to
> keep track if the rule is actually being used or not.
>
> A few fixes/changes are needed for this feature to work with ice driver.
> These are introduced in first 5 patches.
>
> Reviewed-by: Vlad Buslov <vladbu@nvidia.com>

In my previous reply I meant reviewed-by for the whole series, not for
the cover letter specifically. Sorry for not being more clear!